Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grokking NAT and packet mangling in Linux

vivekn.dev

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Grokking NAT and packet mangling in Linux

#31

Post by EvanAnderson »

mindslight wrote: post #23
EvanAnderson wrote: post #8

Earlier quoted context omitted.

> It's probably the worst mistake in TCP/IP. I vote for TCP/IP lacking a session layer as being the worst mistake. We wouldn't have IP mobility issues if there'd been an explicit session layer to decouple IP from the upper layer protocols.

That's like the Nethead vs Bellhead argument though, and it's easy to say that with the benefit of several decades of adoption and development.

I don't necessarily think a session layer protocol is automatically "Bell-headed". It's a natural place to plug-in per-byte billing and that ilk, for sure.

I don't exactly know the timeline between the ITU protocol suite and/or DecNet (both of which have a concept of a session layer protocol) with IPv4. I think they were somewhat contemporaneous. Certainly, the idea of a session layer isn't something that came decades later than IPv4.

Even just a host identifier, in lieu of the IP address of an interface, being used in the TCP tuple would have been so much better than what we have and probably would have been enough of a "session layer". It would be so amazing to have TCP connections that "just work" when clients or servers hop onto different IP networks, use different interfaces, etc.

Edit: It has been mentioned that Vint Cerf regretted the decision to bind the IP into the TCP tuple, too. I don't have an exact quote but I know I've heard him mention it in a talk. Ref: https://argp.github.io/2006/03/05/vint-cerfs-talk/

Re: Grokking NAT and packet mangling in Linux

#32

Post by [deleted] »

zokier wrote: post #25
colmmacc wrote: post #5

A significant wrinkle in how NAT works is IP fragmentation. UDP datagrams can be larger than an IP packet. When that happens the payload is split into multiple IP packets, but only the first packet has a UDP header in it. The NAT device needs to correlate these packets by looking at fragment IDs, and then rewrite the IP addresses in the headers. That alone implies a second kind of state to maintain, but it gets worse…

> It's probably the worst mistake in TCP/IP. If you think fragmentation was mistake then what other alternative do you think would have been better while also feasible at the time when ipv4 was specified? IPv6 notably traded fragmentation for path mtu discovery, but I don't think requiring pmtud would have been realistic option in 1981.

[deleted]

Re: Grokking NAT and packet mangling in Linux

#33

Post by mindslight »

EvanAnderson wrote: post #31
mindslight wrote: post #23

Earlier quoted context omitted.

That's like the Nethead vs Bellhead argument though, and it's easy to say that with the benefit of several decades of adoption and development.

I don't necessarily think a session layer protocol is automatically "Bell-headed". It's a natural place to plug-in per-byte billing and that ilk, for sure. I don't exactly know the timeline between the ITU protocol suite and/or DecNet (both of which have a concept of a session layer protocol) with IPv4. I think they were somewhat contemporaneous. Certainly, the idea of a session layer isn't something that came decade…

> Even just a host identifier, in lieu of the IP address of an interface, being used in the TCP tuple would have been so much better

What are you imagining as the implementation? Is it just in TCP, and IP (/ the network) is unchanged? I can see the benefit of that, but then there still needs to be some mechanism to change the binding of host->IP. And if it's not part of the core network, then it's not straightforward.

There are also other more complex problems not solved by TCP (eg security). I'd rather have a host ID be a pubkey, than some small-namespace ID with a pubkey required on top of that.

It feels like the real problem is the proliferation of different incompatible solutions to any of these problems, which was going to happen even if there was one less problem that needed to be solved.

Another way of looking at it is that TCP got so entrenched because of NAT, and having a session ID within IP instead of (implicitly) within TCP/UDP might have allowed more flexibility with creating new protocols directly on top of IP. But 2+2 more bytes of addressing would have gone a long way too!

Re: Grokking NAT and packet mangling in Linux

#34

Post by jxjnskkzxxhx »

throawayonthe wrote: post #12
jxjnskkzxxhx wrote: post #10

OT does anyone else find it off topic to see the word "grokking"? Does that mean understanding? Do we need a new word for this extremely basic concept?

the term is 60+ years old https://en.wikipedia.org/wiki/Grok

What's your point? It's 60 years old therefore can't possibly be stupid?

Or perhaps you have no point and are just nitpicking that I called it new? Compared to the word "to understand" it's new, it's pretty obvious that my use of the word new had a context attached.

Re: Grokking NAT and packet mangling in Linux

#35

Post by jekwoooooe »

esseph wrote: post #16
jekwoooooe wrote: post #7

I remember back in the day I had to help a hospital set up some crazy double nat Cisco vpn to another hospital. Old school physical appliance and everything. It was such a pain

"Old school physical appliance" Lololol It's so funny to me how much the past 10 years absolutely decimated on-prem skills a In some areas. I don't know what to tell you folks other than Real Locations doing Physical Things still exist, haven't gone away, and there's actually more of them now than there was. Given the current state of cyber attacks, all eggs in one basket is probably a very bad thing. For instance, C…

On prem has become commoditized though. I would bet on aws having stronger security overall than someone running a bunch of physical appliances in their own rack.

Re: Grokking NAT and packet mangling in Linux

#36

Post by esseph »

jekwoooooe wrote: post #35
esseph wrote: post #16

Earlier quoted context omitted.

"Old school physical appliance" Lololol It's so funny to me how much the past 10 years absolutely decimated on-prem skills a In some areas. I don't know what to tell you folks other than Real Locations doing Physical Things still exist, haven't gone away, and there's actually more of them now than there was. Given the current state of cyber attacks, all eggs in one basket is probably a very bad thing. For instance, C…

On prem has become commoditized though. I would bet on aws having stronger security overall than someone running a bunch of physical appliances in their own rack.

Aws doesn't make batch chemicals, they don't transport fuel or nuclear weapons, they don't control water plants or the electrical grid, etc.

Those things cannot expect to have internet access, and should not.

There are tons of billion dollar companies with multiple datacenters or presences in multiple datacenters because of this.

There is more physical hardware right now deployed by companies of all shapes and sizes than there ever has been in history.

CISA PPD-21 Critical Infrastructure Sectors:

* Chemical Sector

* Commercial Facilities Sector

* Communications Sector

* Critical Manufacturing Sector

* Dams Sector

* Defense Industrial Base Sector

* Emergency Services Sector

* Energy Sector

* Financial Services Sector

* Food and Agriculture Sector

* Government Facilities Sector

* Healthcare and Public Health Sector

* Information Technology Sector

* Nuclear Reactors, Materials, and Waste Sector

* Transportation Systems Sector

* Water and Wastewater Systems Sector

These things need to operate without Internet, full stop. Most of these companies have been around for decades or even centuries. They're not interested in a lot of web/SaaS and can barely even spell SaaS. They're also probably likely to outlive the next few dozen frameworks or language fashions.

Re: Grokking NAT and packet mangling in Linux

#37

Post by EvanAnderson »

mindslight wrote: post #33
EvanAnderson wrote: post #31

Earlier quoted context omitted.

I don't necessarily think a session layer protocol is automatically "Bell-headed". It's a natural place to plug-in per-byte billing and that ilk, for sure. I don't exactly know the timeline between the ITU protocol suite and/or DecNet (both of which have a concept of a session layer protocol) with IPv4. I think they were somewhat contemporaneous. Certainly, the idea of a session layer isn't something that came decade…

> Even just a host identifier, in lieu of the IP address of an interface, being used in the TCP tuple would have been so much better What are you imagining as the implementation? Is it just in TCP, and IP (/ the network) is unchanged? I can see the benefit of that, but then there still needs to be some mechanism to change the binding of host->IP. And if it's not part of the core network, then it's not straightforward…

> What are you imagining as the implementation?

I haven't thought about it hard enough to be doing anything besides spouting bullshit. It's one of those lazy "I don't like what we've got but I can't say what we should have" kind of complaints.

The way SCTP handles multi-homing and failover with the verification tag is what I guess I'm thinking of. I'm a little enamored with SCTP, admittedly, and I'd rather we were using it than TCP.

If I were going back in time, without the 20+ years of real-world experience that went into SCTP, I'd propose something simple like having the initiator and receiver each put a (32-bit?) identifier into a couple of session tracking header fields (initiator on SYN, receiver on SYN/ACK). When an endpoint roamed to a new IP address they'd send a zero-byte ACK from the new IP address to the opposing end. The opposing end would provisionally update their IP binding and ACK back to the new IP address. They would continue to send to both IP addresses until they received an ACK from the new IP address, at which point the old IP address would be discarded.

I can already see, doing "improvisational piano" state machine design here, that there are issues with this design. Like I said, spouting bullshit... >smile<

Re: Grokking NAT and packet mangling in Linux

#38

Post by wredcoll »

jxjnskkzxxhx wrote: post #34
throawayonthe wrote: post #12

Earlier quoted context omitted.

the term is 60+ years old https://en.wikipedia.org/wiki/Grok

What's your point? It's 60 years old therefore can't possibly be stupid? Or perhaps you have no point and are just nitpicking that I called it new? Compared to the word "to understand" it's new, it's pretty obvious that my use of the word new had a context attached.

You just asked us if we need new slang words. The answer is so self-evidently obviously yes that no one can actually understand why you bothered.

Re: Grokking NAT and packet mangling in Linux

#39

Post by commandersaki »

colmmacc wrote: post #5

A significant wrinkle in how NAT works is IP fragmentation. UDP datagrams can be larger than an IP packet. When that happens the payload is split into multiple IP packets, but only the first packet has a UDP header in it. The NAT device needs to correlate these packets by looking at fragment IDs, and then rewrite the IP addresses in the headers. That alone implies a second kind of state to maintain, but it gets worse…

If UDP datagrams were simply fragmented at the UDP layer

Agreed, but then it wouldn't be a datagram service anymore.

Post reply on HN