Re: [v6ops] Thoughts about wider operational input

[Simon <[e-mail]>]

On 1 Apr 2022, at 22:36, Joe Maimon <[e-mail]> wrote:

>> Identifying endpoints in a consistent fashion is trivially easy - you use its IP address*.
> 
> Which you know because you have successful communications with it.
> 
> What you dont know is what IP address YOU have from the point of view of the other endpoint.

Indeed, and that’s why Nat == broken. Pretty well the entire foundation of networking falls over if you have no idea who *you* are.


> Which if you consider it carefully, there never was any such guarantee. It was just the path of least resistance.

See the refs Mark provided which are quite clear that yes, you have one or more globally unique and globally routable addresses. That is the foundation of IP - globally unique addresses, so that an address can only refer to one end node; and end-end communication, so any end node can communicate with any other end node.
NAT plus private addressing breaks this - I can tell someone that I’m at 192.168.1.1 and that doesn’t differentiate me from the thousands or millions of other 192.168.1.1 nodes in other 192.168.0.0/16 (or 192.168.1.0/24) address spaces; nor does it enable them to send a packet to me. I.e. the network is broken.


> But you are free to break stuff.

We know that is the philosophy of a number of large corporates (no names, no pack drill), but that is the opposite of what the internet is supposed to be about.


> I read the RFC and I see that it says if you are going to use endpoints identifiers you need to ensure they are consistent.

OK.

> And if they belong to other protocol layers and traverse a network you do not control, more than an assumption is required for that sort of reliable behavior.

That’s a stretch. A reliable network will pass any packet you send provided its validly formed. All I need is a consistent endpoint identifier (address) for myself and the other end.
Note: having an application (e.g.) use multiple ports for different traffic types - such as a port we use for signalling and other ports we use for data streams, and they may mix TCP and UDP, doesn’t change that - that is all within the node and using tools provided by the OS for the purpose. Once that packet leaves my node, the network is not entitled to mangle it. In a transparent network, it is trivially easy to determine what address(es) I can use, and what (for UDP and TCP) ports I can use - I just ask the OS using the tools provided by the network stack.
See the references Mark provided :

On 2 Apr 2022, at 03:31, Mark Smith <[e-mail]> wrote:

> RFC791.
> 
> RFC8200.
> 
> RFC2993.
> 
> RFC5902.

I’ll add RFC 4924 https://datatracker.ietf.org/doc/html/rfc4924

I’ll quote just one paragraph from that :
> A network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core.  It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success.

What that is saying is that the internet “took off” as it did because of the flexibility provided by this “packets in one end, unmangled packets out the other” basic principle. It points out elsewhere that when you break this transparency, then you introduce barriers to innovation - if a new idea needs every NAT gateway in the world to be upgraded to add an ALG then that is an effective barrier to the new idea. And as we’ve seen over the last few years, the problems NAT creates have massively assisted the move from “peers” to “consumers” - where we hear regular stories of (e.g.) door bells not working because some service out in the internet isn’t working.


Just for good measure, I’ll point out that the idea of security being achievable by a “hard shell, gooey centre” network is long past. These days the threats are such that every node needs to be able to stand alone and secure itself. Put another way, who cares if the firewall in the gateway is turned off - with NAT, any of those IoT bits of (often cheap and “poorly coded”) equipment could be your attacker, or any device on the network could get infected - it can tunnel out through the NAT, create a reverse tunnel in, and if your other devices aren't adequately hardened than the NAT will have provided very little by way of security. So the point you make that NAT can’t be turned off, that makes it more secure than a firewall is actually the wrong way round - because it’s often described as good security, it instills a false sense of security which is “a bad thing”.
And I write that as someone who has routinely put devices, on public IPs, onto the internet without the benefit of a separate firewall. And yes, they’ve been attacked and survived.

Simon