Hacker News Reader

Comment by Animats | Hacker News Reader

What he's really arguing for is a circuit-switched network, so that connections can be persistent over moves. He just needs a unique connection ID.

One amusing possibility would be to do this at the HTTPS layer. With HTTPS Everywhere, most HTTP connections now have a unique connection ID at the crypto layer - the session key. If you could move an HTTP connection from one IP address to another on the fly, it could be kept alive over moves. HTTPS already protects against MITM attacks, and if the transfer is botched or intercepted, that will break the connection.

I'm not recommending this, but it meets many of his criteria.

The trouble with low-level connection IDs that don't force routing is forgery. You can fake a source IP address, but that won't get you the reply traffic, so this is useful only for denial of service attacks. If you have connection IDs, you need to secure them somehow against replication, playback, etc.

View on HN

> One amusing possibility would be to do this at the HTTPS layer. With HTTPS Everywhere, most HTTP connections now have a unique connection ID at the crypto layer - the session key.

As a network-ignoramus, who likes cryptography, I’ve long dreamt of a networking protocol where endpoints are defined, primarily, by a public key. All messages would be encrypted with the destination public key, and signed by the source private key.

When a destination node receives a packet from a neighboring node, and ACK would constitute the destination node’s signature over the received packet, thus making ACKs provable and portable (“this node has already received that packet, here’s the proof”).

Packet sources addresses would no longer be fake-able, as that would constitute breaking asymmetric cryptography.

The protocol would have no concept of a “connection”.

Routing would be left out of this protocol completely, and networks would use whichever routing protocols they find most efficient.

I wouldn’t be surprised if there were countless issues with a protocol like this, but something about it just seems so elegant to me that I haven’t stopped considering it yet.

You should read about QUIC, which is designed to be able to do this, almost exactly like you describe. https://www.chromium.org/quic

I’d really like to remove the idea of a “connection” from the protocol, and leave that to the routing protocol. In other words, the proposed protocol would be purely logical, and would only define what constitutes a sender (one who can sign a packet with its source public key) and a receiver (one who can sign a packet with its destination public key).

Again, I’m fairly network-ignorant, but as far as I can see this constitutes an inversion of the current architecture: routers need to be aware of signatures, such that they don’t deliver an invalid packet (bad signature) to a destination. So the logical layer would be the lowest one, and a router that delivers a packet with a bad signature would be considered defunct.

The funny thing about the current architecture, in my view, is that the correct destination of an HTTP TLS packet is hidden (encrypted) inside the application data (“Host: google.com”). So routers rely on IP addresses to figure out where the packet needs to go, while the logical destination is only visible to the receiver once it decrypts the packet.

The idea would be moving this information out of the application data, making it cryptographically sound (public key is destination, not domain name), and making routers aware of it such that they know whether a packet was delivered to the correct destination by whether it responds with a valid signature.

The problem is routing. Given a signature, how do you look up the next hop, without needing a full table mapping everything.

IP addresses form a hierarchy, which makes it doable.

You should look at I2P.

I fundamentally believe you should run your encryption over the network, and not try to bake it in.

RPKI and BGPSEC do need to happen but we're an eon away from it being a reality.

> the correct destination of an HTTP TLS packet is hidden (encrypted) inside the application data (“Host: google.com”).

Incorrect, you might want to read about TLS SNI (Thought exercise; the server has to pass your packets to the correct vhost before decryption).

You might want to Google dTLS (TLS over UDP) and then read some of the dialogue about why it's impractical on the public internet.

Consider further that by moving your presentation layer logic into the network layer, every time you want to introduce a new cipher you'll need to upgrade every network device on the internet. Think how bad the export-grade crypto problem has been, then multiply by the momentum of Tier-1 ISP install base. Instead of making the network less important, you're handcuffing yourself to Verizon.

> As a network-ignoramus, who likes cryptography, I’ve long dreamt of a networking protocol where endpoints are defined, primarily, by a public key. All messages would be encrypted with the destination public key, and signed by the source private key.

See https://zerotier.com/

Yup. It's also open source:

https://github.com/zerotier/ZeroTierOne

https://github.com/cjdelisle/cjdns

Have you looked at WireGuard? It uses public keys to identify endpoints, although it doesn't solve the fake source address of the VPN protocol packets itself. I don't think that's possible to support at the same time as NAT and moving across Internet connections (changing IPs as you move across Wifi/Cellular etc).

https://www.wireguard.com

Host Identity Protocol was one attempt: http://infrahip.net/

Something like GNUnet's CADET subsystem?

https://gnunet.org/cadet-subsystem

Check out: https://named-data.net/project/

Interesting idea. One thought would be add encryption and signing to the routing. Meaning unless you have the right permissions, your packets won't even get to the destination.

I'd much rather routing be about getting data from one known point to another.

A /session/ should be able to be serviced by multiple routes, maybe with a preference (use the cheaper ones first, the faster ones first, etc) or maybe over time (in the case of mobile).

Having connectivity based at the session level and having a single server be 'multi-homed' (many addresses, each conforming to a different outbound link) would peel complexity back from the lower layers and allow them to focus on being simple, robust, and easy to diagnose.

It would also move control and management back up to higher layers, and as recently shown with a description of Google's core network devices, back to the end points where a larger and more complete view can be used to determine the best overall solution.

I think my though comes from the use case where you have thing1 and thing2 that you want to be able to communicate via the internet. But you would rather not be accessible from other devices.

I’m not sure I follow why this would be desirable. As a sender of a packet, why would I care who routes my (encrypted) packet to its destination? Why would I want to restrict the number of possible routes from me to the receiver?

Latency, jitter, not wanting to go via country X where national security agency Y will see it......

Mostly your right though.

mosh layers this sort of thing over UDP, to provide client roaming capability.

Yeah, because we only ever use HTTPS protocol. No IMAP, no SMTP, nothing like that, ever.

MQTT, CoAP, SRTP

> I'm not recommending this, but it meets many of his criteria.

Woah...déjà vu.

Reply on news.ycombinator.com