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.
>
> 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.
>
> 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).
>
> 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.
>
Right, that implies that we need to eliminate the motivation to do DPI
by providing a better way to get the same functionality. This is what
FAST proposes. Transport related information of interest to a firewall
is in Hop-by-Hop options. So middleboxes will look at HBH options
which come before fragment EH. No DPI needed, no issues with
fragmentation at middleboxes, and, as a bonus, HBH options are the
only mechanism defined in IP protocol that allows data to be changed
in flight (this will be important property as in-situ OAM starts to
get traction).

Tom

> Joe
>