Most active commenters

    ←back to thread

    Yggdrasil Network

    (yggdrasil-network.github.io)
    322 points BSDobelix | 14 comments | 16 Nov 24 10:58 UTC | HN request time: 1.483s | source | bottom
    Show context
    foundry27 ◴[16 Nov 24 15:48 UTC] No.42156968[source]▶
    The first thing I tried to find on their website and their GitHub was a protocol specification, to be able to implement it independently from the reference implementation. I thought this would be straightforward since it’s advertised as a scheme/protocol, but such a spec isn’t referenced anywhere! Digging on my own I eventually found [1] on a side-branch of one of their other GitHub projects.

    Kudos to the author: I think it actually covers a lot of what you’d need to know: crypto identities, message formats, wire protocols, peering and stream semantics, spanning tree updates and root selection, the DHT, forwarding logic, sessions, etc. A couple things are TODOs like how to verify and sign root updates, and there’s some ambiguity in the tiebreaker algorithm for next-hop selection.

    It seems to be very tightly coupled to TCP as the transport layer though, since all packets need to be delivered reliably and in the order they were sent, and need to be capable of being fragmented into smaller packets for varying MTU sizes.

    [1] https://github.com/yggdrasil-network/yggdrasil-specs/blob/ys...

    replies(2): >>42157246 #>>42157427 #
    colordrops ◴[16 Nov 24 17:01 UTC] No.42157427[source]▶
    Is coupling with TCP a problem? Does it do anything that goes against their goal of full decentralization?
    replies(1): >>42157454 #
    1. macawfish ◴[16 Nov 24 17:05 UTC] No.42157454[source]▶
    Makes it hard to do hole punching I think? At any rate, direct connections currently cannot be established between multi-hop peers, traffic gets routed through peers instead. I think this has something to do with the TCP choice.
    replies(3): >>42158423 #>>42158464 #>>42159697 #
    2. foundry27 ◴[16 Nov 24 19:06 UTC] No.42158423[source]▶
    Yeaaah. TCP hole punching is goofy and unreliable, last I checked. You have to do some arcane ritual of having both peers start a three-way handshake to each others’s public endpoints simultaneously, relying on NATs to accept inbound SYN packets if they match the outgoing SYN. And nobody’s NAT devices implement simultaneous-open the same way, so all your connections just fail.

    Naturally this leads to slapping even more arcane fixes on top of that, like NAT port assignment oracles to adversarial interoperate with different port allocation strategies (random, sequential, single, etc.) by analyzing patterns in previous port assignments. Networking sucks.

    replies(1): >>42160874 #
    3. Karrot_Kream ◴[16 Nov 24 19:12 UTC] No.42158464[source]▶
    I think this is a pragmatic choice. NAT Hole Punching can be hit or miss no matter the method but doing peer routing guarantees even a client that can only initiate outbound connections can route packets. It can be slow though.

    I also know there's support for other transports like QUIC but TCP is the main default.

    4. AyyEye ◴[16 Nov 24 21:56 UTC] No.42159697[source]▶
    > At any rate, direct connections currently cannot be established between multi-hop peers, traffic gets routed through peers instead. I think this has something to do with the TCP choice.

    Yggdrasil is designed for physical links and multi-hop routing first and foremost. Internet peering is just a way to test/use/join the network until then.

    replies(1): >>42162452 #
    5. beeflet ◴[17 Nov 24 00:30 UTC] No.42160874[source]▶
    https://xkcd.com/2044/
    replies(2): >>42162714 #>>42164180 #
    6. macawfish ◴[17 Nov 24 06:57 UTC] No.42162452[source]▶
    I'd love if my private nodes could peer directly so I wouldn't need to route all traffic through my budget VPs.
    replies(3): >>42163237 #>>42164799 #>>42188665 #
    7. paulddraper ◴[17 Nov 24 08:03 UTC] No.42162714{3}[source]▶
    Actuate
    replies(1): >>42163725 #
    8. wolletd ◴[17 Nov 24 10:20 UTC] No.42163237{3}[source]▶
    If only there was some technology that would allow every peer to have its globally unique address, making direct connections only a matter of firewalls.

    I don't know, something like IPv4, but with more addresses...

    9. ionspin ◴[17 Nov 24 12:01 UTC] No.42163725{4}[source]▶
    I presume you meant to say "Accurate", but it made me think of a off-brand Picard that says "Actuate" instead of "Engage".
    10. gtirloni ◴[17 Nov 24 13:50 UTC] No.42164180{3}[source]▶
    If the new technology referenced in the comic provides a way to securely connect, including auditing, I don't see how it applies to the hole punching hack.
    replies(1): >>42164331 #
    11. beeflet ◴[17 Nov 24 14:25 UTC] No.42164331{4}[source]▶
    People (like ISPs offering routers) set up NAT, often justifying it on the basis of security. Application developers use hole-punching techniques to get past NAT (including stuff like UPnP that requires cooperation from the NAT).

    The end product is:

    #1 A sandboxing system that cannot reliably sandbox.

    #2 A connection system that cannot reliably connect.

    So now you have two problems.

    replies(1): >>42180739 #
    12. dinosaurdynasty ◴[17 Nov 24 15:52 UTC] No.42164799{3}[source]▶
    Both tailscale (partially open source) and nebula (entirely open source, you have to host the "lighthouses" which assist in NAT punching yourself) do this. (Also tinc.)

    Yggdrasil is basically researching a replacement for BGP, so hole punching isn't a priority. (There is a 3rd party project that does something like this for Yggdrasil, but nebula is probably the better fully open source option.)

    13. dev_hugepages ◴[19 Nov 24 07:07 UTC] No.42180739{5}[source]▶
    NAT is not a security measure but a way to save on IP space or avoid remaking a topology on network addresses changes. For actual security you need a firewall
    14. AyyEye ◴[19 Nov 24 22:13 UTC] No.42188665{3}[source]▶
    On ygg as long as the nodes are reachable they can peer. If your nodes are on LAN just turn on multicast peering it's fire and forget.