4 ms·

> Another difficult situation arises if two peers are actually on the same local network behind the same NAT router. ... > It might be tempting for peers to e

> Another difficult situation arises if two peers are actually on the same local network behind the same NAT router. ... > It might be tempting for peers to encode their private IP address and send it to the intermediate server and/or to the other peer. I thought about this when writing ZeroTier. On the plus side, this would work even on large segmented networks where UDP broadcasts don’t make it everywhere. But the problem is that this exposes internal configuration details about the network to potentially random external peers. Many network security administrators are not going to like that, so I decided against it. I tried to think of a way to anonymize the data but couldn’t, since the IPv4 private address space is so small that no form of hashing will adequately protect against exhaustive search. I wonder if it would be possible to encrypt the local address with the internal MAC address of the router/gateway. Then only nodes seeing the same router could decode the information. I also wonder how Dropbox does this (it can tell when two connected computers are on the same LAN, and transfers files directly).

Maakuth 12y ago
Dropbox does the UDP broadcast thing. Try dumping packet in pretty much any LAN today and you see their broadcasts flying around.
- nly 12y ago
  I see Dropbox traffic hitting my servers. People evidently rent Windows dedis, install Dropbox on them, and they spew out broadcast to the local /24
richardwhiuk 12y ago
I know that Dropbox uses multicast packets to announce itself to other nodes. I'd have thought that encrypting the local address with the public IP address of the gateway would be a better solution?
- Perseids 12y ago
  Neither the IP address nor the MAC address contain enough entropy to make that secure. Even assuming they were completely random, 32 and 48 bit keys can be bruteforced in no time. Additionally the MAC address contains mostly static or easily guessable values and the public IP address is, well, public. Thus even key strengthening along the lines of PBKDF2/bcrypt/scrypt is hopeless.
  - captainmuon 12y ago
    But if you brute force the key, when do you know that you got the right one? Its hard to tell a correct IP address from four bytes of garbage. Depending on the encryption scheme, you are bound to get a lot of fake local IPs - potentially all 256^4 of them. Of course this assumes that you don't include a checksum or another way of verifying the key. If you do, then you're right, you can just brute force the key. If you don't, then you have another problem: For every node that you connect to, you have to try the local IP you "decrypted" (well, at least if it makes sense in your subnet). This could be a lot of overhead if you have a lot of nodes. There might also be other sources of entropy that are common to all nodes behind a NAT, for example routing information, or identification strings of the router (most customer routers identify themselves via UPnP). Also you could try to piggyback on other networks, like Windows' workgroups or Apple's bonjour. Finally, since the public IP is public anyway, you could send the (poorly) encrypted local IP only to nodes that have the same public IP as you do. I haven't thought this to the end and this probably won't work when an ISP gives multiple users the same IP, though. So, I think it would definitely be possible to implement this, the question is how much effort you want to put into this. In a real application, I would probably just try the broadcast, and if it doesn't work, give the user the option to manually connect over LAN (e.g. by entering a code word on all nodes).
    - nknighthb 12y ago
      It's much easier to tell a correct private RFC 1918 IP from four bytes of garbage. There are only 17,891,328 valid values. The odds move further in your favor when you have multiple private addresses to work with -- a valid key will most likely result in addresses that are all in a single RFC 1918 block, and very possibly all in the same /24.

Maakuth 12y ago

Dropbox does the UDP broadcast thing. Try dumping packet in pretty much any LAN today and you see their broadcasts flying around.

nly 12y ago
I see Dropbox traffic hitting my servers. People evidently rent Windows dedis, install Dropbox on them, and they spew out broadcast to the local /24

richardwhiuk 12y ago

I know that Dropbox uses multicast packets to announce itself to other nodes. I'd have thought that encrypting the local address with the public IP address of the gateway would be a better solution?

Perseids 12y ago
Neither the IP address nor the MAC address contain enough entropy to make that secure. Even assuming they were completely random, 32 and 48 bit keys can be bruteforced in no time. Additionally the MAC address contains mostly static or easily guessable values and the public IP address is, well, public. Thus even key strengthening along the lines of PBKDF2/bcrypt/scrypt is hopeless.
- captainmuon 12y ago
  But if you brute force the key, when do you know that you got the right one? Its hard to tell a correct IP address from four bytes of garbage. Depending on the encryption scheme, you are bound to get a lot of fake local IPs - potentially all 256^4 of them. Of course this assumes that you don't include a checksum or another way of verifying the key. If you do, then you're right, you can just brute force the key. If you don't, then you have another problem: For every node that you connect to, you have to try the local IP you "decrypted" (well, at least if it makes sense in your subnet). This could be a lot of overhead if you have a lot of nodes. There might also be other sources of entropy that are common to all nodes behind a NAT, for example routing information, or identification strings of the router (most customer routers identify themselves via UPnP). Also you could try to piggyback on other networks, like Windows' workgroups or Apple's bonjour. Finally, since the public IP is public anyway, you could send the (poorly) encrypted local IP only to nodes that have the same public IP as you do. I haven't thought this to the end and this probably won't work when an ISP gives multiple users the same IP, though. So, I think it would definitely be possible to implement this, the question is how much effort you want to put into this. In a real application, I would probably just try the broadcast, and if it doesn't work, give the user the option to manually connect over LAN (e.g. by entering a code word on all nodes).
  - nknighthb 12y ago
    It's much easier to tell a correct private RFC 1918 IP from four bytes of garbage. There are only 17,891,328 valid values. The odds move further in your favor when you have multiple private addresses to work with -- a valid key will most likely result in addresses that are all in a single RFC 1918 block, and very possibly all in the same /24.