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

[Tom Herbert <[e-mail]>]

On Mon, Jul 30, 2018 at 10:34 AM, Joe Touch <[e-mail]> wrote:
>
>
>
>
> On 2018-07-30 08:11, Tom Herbert wrote:
>
> 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.
>
>
> 1122 requires that devices shouldn't be sourcing IP addresses they don't
> own.
>
> And any device behind a NAT would have a similar requirement - that the
> private side is setup such that any translation appears as a single device
> -- which means either that each host on the private side forwards all its
> traffic to one egress (as a stub net) or that the multiple egresses
> coordinate state to look like one egress on the private side and one host on
> the public side.
>
> I.e., the Internet architecture imposes exactly the restrictions you note -
> these aren't ad-hoc, they're derived from the Internet requirements.
>
IP is packet switched not circuit switched. Other than the source and
destination nodes, no two packets sent on a flow are required to
traverse the same nodes, nor does there need to be any symmetry in the
path between two directions of communication. If this is an incorrect
interpretation of the requirements then please reference the RFC that
states otherwise.

>
>
>
> 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.
>
>
> Only for that rule; for the private side, the rule is that the network is a
> stub behind the translator (or emulates that).
>
> ...
>
> This has killed
> our ability to use multi-homing and multi-path.
>
>
> It didn't kill it. It never existed *for this sort of mechanism* - exactly
> because of requirements of the Internet architecture.
>
The mechanism (specifically the requirement that packets traverse
intermediate nodes that are not addressed) breaks multi-homing. All
the hacks and hoops we've had to jump through over the years to make
NAT, stateful firewalls, and L4 load balancers work attest to this
being a real problem.

Tom

>
> If there is only one device that represents a private node on the public
> net, it can work (using the model I describe). If there isn't, then it's the
> Internet architecture that makes the device inherently broken - we shouldn't
> go around believing we can patch the protocols to "make it work again".
>
> Joe