Hacker News Reader

If the source IP is encrypted, the recipient needs to decrypt it first in order to be able to send a response. To decrypt it, it needs to either have some shared secret with the sender, or the sender needs to use the recipient's private key.

The parties cannot obtain the shared secret the usual way, the Diffie-Helman exchange. It cannot be performed, because it requires back-and-forth communication, which we are trying to establish in the first place. Of course, we'd still need to use certificates signed by public authorities to deal with the standard MitM concerns.

The alternative would be for the sender to use the recipient's public key to encrypt the source IP address. That would require a DNS-like system that would store and serve public keys corresponding to a given IP address you are trying to communicate with. This is something doable, especially in IPv6 world where you don't really have to reuse IPv6 addresses, but it leads to all kinds of practical problems, figuring out which is probably best left as an exercise for the reader.

Nit-picking a bit/kind of augmenting your train of thought. You can have non-interactive Diffie-Helman key exchange (via a PKI). As you say, the client would need to know prior to that the public key/have access to the certificate and that would require certainly revamping the DNS approach we now have (even if we did not use DNS, we would still have to deal with DNS requests).

That's literally the second option I describe. What is your point?

What you guys are describing is starting to sound more and more like onion routing.

Point is online security is a bad joke. You wrote it, you own it.

The real interesting question is what happens when you get owned by what you didn't write?

Your tone is unnecessarily harsh.

Just wanted to clarify that the issue was not with the Diffie-Hellman key exchange itself, but the way we currently do DNS plus IP routing are the issues.

Technically, the client could encrypt their IP with the y=H(g^{scr}) key (result of the DH KE) and send (Enc(y, IP), g^{rc})-- where H is the oracle, g^s server public key, rc <session nonce>*key (or generally 1 time key). The server can then compute the same key (g^{rc}^s and then apply H) and decrypt.

So the second and third paragraph contradict a bit each other, which was the sole reason for my clarification. I am not stating you as wrong or anything; I was just augmenting, so other readers don't get the wrong impression and decouple Diffie-Hellman KE from public key cryptography.

P.S. The remaining issue is to make sure the server does not have to decrypt the IP for invalid connections etc (that is avoid DOS or leaking secrets as we are operating on not trusted ciphertext).

> but it leads to all kinds of practical problems, figuring out which is probably best left as an exercise for the reader.

Any examples? I honestly don't see any problems here.

That is a Huuuge number of IP's, at a very high request rate, required for every new connection. It is orders of magnitude greater than DNS, and would be expected to have much lower latency.

Throw onto that the trust issue - such IP certificate repositories are very quickly able to determine who is communicating with each other, and at what time. Whilst this is currently possible anyway, current methods are less centralised, more expensive, and more visible.

You'd have to go full onion

640k is all the memory you'll ever need.

ggm is referring to something more like every router using NAT and having enough room in the packet so they can store something there instead of main memory.

Just a half-baked idea: If you don't want to make a new request for every connection, and the recipient owns a huge block of IPv6 addresses, the recipient can create an asynchronous key pair where the public key is used as the IPv6 suffix. The United States Department of Defense owns /13. This provides 115 bits of public key information. The sender can use the IPv6 address as the public key.

115 bits of security is pretty good, for example 3DES, while not exactly a great choice today, is still considered secure and acceptable for use today, with its 112 bits of security. However, I know of no public key encryption scheme that would give acceptable security with only 115 bits of public key. With RSA, you need at least 1024 bits, and probably should rather use 2048. Elliptic curve cryptography is considerably better here, but an ECC key of length n stil gives you only n/2 bits of security, which would be way too little here.

2048 bits of RSA key is the same amount of security as 112 bits of symmentric key, though.

Yes, that’s my point — you need to use 2048 bits for key to get 128 bits of security, so there is no way to fit the public key in the IPv6 address.

Can't you do something with a key-stretching system [0] maybe, to turn 112 bits of IPV6 into 2048 bits of RSA input, though, since you definitely have the right amount of entropy?

0. https://en.wikipedia.org/wiki/Key_stretching

cjdns[1] is an encrypted ipv6 overlay network that uses the firstbits of your public key hash to generate your ip address.

theoretically, multiple keys can share an ip-hash, but the handshake will fail if the intended recipient doesn't have the expected keypair[2]. so far this hasn't been an issue, but you are better off if you know the destination's pubkey beforehand.

[1]: https://github.com/cjdelisle/cjdns

[2]: https://github.com/cjdelisle/cjdns/blob/master/doc/faq/doppl...

> Src IP is not actually neccessary, in the IP layer.

I like your thoughts, but I don't understand how it would have helped in the Hacker-Verizon-Stingray case.

First, an analogy: Suppose no one ever wrote a return address on postal letters. People wrote only the destination. The recipient has to open the envelope to see who wrote the letter. The postal system still works and it's way more private. However, if the authorities are watching your particular mailbox at your house, copying the outside of every incoming and outgoing letter, what privacy have you gained? They still know who you wrote to and who replied.

Now back to the Hacker-Verizon-Stingray case: When the hacker connects to Verizon, his phone must identify him as a Verizon customer at some protocol layer. The identifying info could be IMEI, IMSI, or Verizon account number. Otherwise anyone could use Verizon for free if there were no account. Likewise, when Verizon transmits info back to the hacker, Verizon has to know which cellphone it should go to, or at least which cell tower.

In your design, the outbound packets from hacker to Verizon contain cleartext destination IP, but the src IP is encrypted. Fine, but then the Stingray finds the Verizon account number associated with that connection -- that info being available at some protocol layer. The Stingray then watches for any connections from Verizon back to the hacker that use the same Verizon account number. The Stingray thus collects both sides of the connection just as before. Am I missing something?

I'm not an expert, but I believe what you're missing is the current legal gray area of meta data like IP addresses. Pulling account numbers associated with contracted accounts sounds more like it needs a warrant.

* Secure handshaking requires interactivity, unless you share secrets with your actual partner (no, your CA trust store isn't enough) in advance. So your first packet would leak it.

* To return ICMP error messages ("destination unreachable"), otherwise you'd have long timeouts.

* Ratelimiting outside the server (e.g. DDOS protection). Many ISPs do actually filter source IPs. (Of course you can't on the backbone, any there are plenty shady AS.)

* Leaving it off won't help against correlation attacks.

* Most applications will need it, so it makes sense to have it in the network layer instead of coming up with incompatible implementations above.

+RPF requires it to help prevent spoofing (BCP 38)

Like AS PATH this is one of the reasons people say but like path security in BGP, its not what people actually do very much. I like BCP38 and I like MANRS but.. traction is hard here.

I was making statements about the road not taken: we have dst IP in the packets, from before BCP existed.

In our thought-experiment world where each address has a public key that can be used to encrypt the payload data destined for it, the public key of the source can also be used to sign the data, ensuring the sender address isn't spoofed.

What validates that - the destination or intermediate devices? Spoofing is often just a means for volumetric DDoS attacks - if the destination is responsible for validate sources then we’re no better off there.

Presumably it would be validated by the destination, but that doesn't matter. The reason spoofing matters so much for volumetric DDOS attacks isn't due to spoofing the traffic sent directly to the target - it's because the target is spoofed as the source address in traffic sent to third-party amplifiers, that respond to the target.

If the third party amplifiers in this scenario can validate that the traffic is spoofed, it cuts out amplification attacks.

Your router requires it, but nobody else on the Internet needs it.

There's way too much baked into the current infrastructure (and two instances of layer 3) for this to be feasible. Access-control lists used for filtering, identifying candidate address for services like NAT, and critical data plane operations like path MTU discovery all rely on the source address being available in the IP header. Sure we could re-engineer things to not be this way, but at what cost?

Realistically (and unfortunately), if you don't want to be tracked then you're going to need to do some combination of tunneling, proxying, and encrypting.

Yes. It wasn't a statement about the future, as much as about the past.

Despite the gargantuan effort, you wouldn't actually gain substantial privacy from such a move. True, a single packet wouldn't identify both parties, but an exchange of packets in rapid succession, a TCP handshake or even an UDP stream would immediately leak the same information to any interested hop in the network.

Furthermore, eavesdropping for metadata on the line is one of the lesser privacy concerns for most people. What really matters are privacy violations by the providers higher up the stack, where the address of both endpoints must be known to enable communication.

How would you return errors if the destination is known to be unreachable?

Or how would you troubleshoot which hop was the source of a routing problem without including a source IP to send a message back to.

These kinds of discussions seem utterly divorced from the reality of networking to me.

Oh. we talked about that. You could include the origin-AS and each AS along the path would change it in flight, was one idea.

Which also didn't fly for obvious reasons. src,dst pair as part of a tuple was just simpler.

AS != hop, especially when BGP isn't even present (e.g. Large private networks).

Putting the return IP encrypted in the payload breaks NAT (see FTP helpers).

You do understand that the IP that the return traffic is destined for has to initially be addressed to the IP of the NAT device, not what the client thinks its IP is, right?

And nothing of value was lost :)

Well except nat doesn't work and the ipv4 internet (which is the vast majority of it) is broken. I wouldn't call the vast majority of the internet something without value.