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. > 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 > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
