Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Tom Herbert <[e-mail]>]

On Sun, Aug 26, 2018 at 2:12 PM, Joe Touch <[e-mail]> wrote:
>
>
> On Aug 26, 2018, at 12:58 PM, Tom Herbert <[e-mail]> wrote:
>
> On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch <[e-mail]> wrote:
>
>
>
> On Aug 26, 2018, at 10:31 AM, Christian Huitema <[e-mail]> wrote:
>
> It seems that the biggest obstacle to fragmentation are NAT and Firewall.
> They need the port numbers in order to find and enforce context. NAT might
> be going away with IPv6, maybe, but firewalls are not.
>
> Have considered strategies that move the port number inside the IP header?
> For example, have an UDP replacement for IPv6 that does not have any port
> number in the new UDP header, and relies instead on unique IPv6 addresses
> per context?
>
>
> NATs already have what they need to do the proper job - they need to
> reassemble and defragment using unique IDs (or cache the first fragment when
> it arrives and use it as context for later - or earlier cached - fragments).
> There’s no rule that IP packets that are fragmented MUST have a transport
> header both visible (not encrypted) and immediately following the IP header.
>
> Firewalls are just delusions; the context they think they’re enforcing has
> no meaning except at the endpoints; it never did.
>
> Using part of the IPv6 space for this solution would then break per-address
> network management (different UDP ports would use different IPv6 addresses,
> presumably).
>
> The “disease" is that NATs don’t reassemble (or emulate it). It’s not useful
> to try to address the symptoms of that disease individually.
>
> Joe,
>
> That is only a better solution, not a complete or robust one.
>
>
> It is complete and robust...
>
> For
> reassembly to work all fragments of a packet must traverse the same
> NAT device. There is no rule that IP packets going to the same
> destination (fragments or not) ever MUST follow the same path.
>
>
> Correct, but there has to be a rule that all packets in a NAT’d flow go
> through the same NAT or multiple devices that emulate a single NAT.
>
Again, there is no such rule in IP. Multiple devices could emulate a
NAT, but the overhead of doing this down to the granularity of
fragmented packets would be extraordinary. The way implementations
have handled dynamic transport state in the network is to assume
consistent per flow routing, or only one egress point.

> So in a
> multi-homed environment this will eventually break someone. For IPv6,
> this is also a clear violation of RFC8200 since intermediate nodes are
> processing a non-HBH extension header in a packet not addressed to the
> them.
>
>
> A NAT is not a router. A router is not allowed to modify the IP addresses or
> port numbers.
>
Maybe so, but a NAT is not a host either. NAT is one example of
intermediate nodes attempting participate in transport level protocols
and thereby breaking the end-to-end model. But, unlike a host, there
is no guarantee that it will be given all the necessary information to
produce the same behavior as a host. A set of assumptions external to
the protocols are required to achieve something close to correctness.
Best way to fix that is eliminate the need for dynamic state.
Accordingly, I think a recommendation in this draft should recommend
use IPv6 without NAT in order to address the NAT-fragmentation
problem.

Tom



> When a NAT does these changes, it is acting as a proxy endpoint in the
> public Internet; as such, it is *required* to do whatever is necessary to
> ensure that its behavior follows that of a host.
>
> The only robust solution to NAT and its fragmentation problems,
> as well as a bunch of other problems NAT brings, is to not use NAT!
> (i.e. switch to IPv6)
>
>
> As I’ve mentioned, there are rules under which a NAT is a valid Internet
> device, but it is simply not just a router.
>
If it's not a router, then I don't believe it could  could a host or
> Joe
>
>
>
> Tom
>
> Joe
>
>