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

[Tom Herbert <[e-mail]>]

On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch <[e-mail]> wrote:
>
>
> On Jul 29, 2018, at 9:11 AM, Tom Herbert <[e-mail]> wrote:
>
> ...
>
> That said, there’s no real problem with a NAT *IF* it acts as a host on the
> Internet
> (see ouch, J: Middlebox Models Compatible with the Internet. USC/ISI
> (ISI-TR-711), 2016.)
>
>
> Joe,
>
> It's still a problem though. A NAT (or any stateful device in the
> network) forces the requirement in network architecture that all
> packets of a flow are routed through the same device.
>
>
> I didn’t make that requirement. The Internet does - it’s what it *means* to
> have an IP address.
>
It's not a requirement of the Internet and certainly not a core IETF
requirement that packets always follow the same path. It's an ad hoc
requirement imposed by _some_ solutions that have been deployed.

> A NAT *has* the address of the packets it sources; if it isn’t the sink of
> that address, then it’s being used incorrectly. If it doesn’t reassemble
> those packets before translating them (i.e., by translating only
> unfragmented packets and dropping fragmented ones), then it is broken and
> ought to be returned for a refund.
>
You are only considering the return path. Packets sent from the client
origin to the remote server need to always follow the same path to hit
the same device that has the NAT state for the flow. The destination
address is not the address of the NAT device, so the only way this
works is if the routing in the internal network consistently routes
packets through the right device. If routing changes, packets could be
sent to a different NAT device that doesn't have the state to handle
the packet so it will just drop it. This is a fundamental problem.
Vendors have mostly gotten away with it because NAT and firewalls are
often used in very simple networks, like home networks, that only have
one default router. But in a more complex network with multiple egress
points, including increasing use of multi-homing in home networks and
personal devices, getting consistent routing to satisfy the
requirements of stateful network devices is a major issue.

Fragmentation exacerbates the problem because fragments must be routed
precisely the same way that non-fragments are in order to hit the same
egress device. ECMP routing non-fragments using ports and fragments
without using ports means that they take different paths. Using flow
label instead of ports for ECMP is the best way to ensure all packets
(fragments and non-fragments) of a flow follow the same route (or at
least will produce the same hash for load balancing and packet
steering algorithms).

> This has killed
> our ability to use multi-homing and multi-path.
>
>
> No, the Internet supports multi path between two IP endpoints and allows
> multihoming for a single address when managed by a single endpoint (physical
> or virtual).
>
See above explanation.

Tom

> The disconnect is a failure to understand that a NAT *is* an IP endpoint.
> The term “middlebox” is wrong in that sense, at least it’s not a middle box
> to the Internet (it is to the device behind the NAT).
>
> The best way for an
> intermediate devices to deal with transport layer state is to be an L4
> proxy. The intermediate is a host endpoint for the proxy connections,
>
> but then that has its own problems since it breaks E2E functionality
> (like TCP auth). So the only real solution is to eliminate transport
> state from the network.
>
>
> That would work only if the network didn’t look at or modify transport
> information - and it did work when that was the case.
>
> I'm still holding out hope that IPv6 will
> start to obsolete use of NAT! FAST (draft-herbert-fast-02) is intended
> to provide a viable alternative to stateful firewalls.
>
>
> Getting rid of NATs is only part of the problem. Anything that does DPI is a
> problem when it discards messages it can’t parse because they’re fragmented.
>
> Joe
>