On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch <[email protected]> wrote: > > > On Jul 29, 2018, at 9:11 AM, Tom Herbert <[email protected]> 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 > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
