On Wed, Aug 29, 2018 at 8:11 AM, Joe Touch <[email protected]> wrote: > > > > > On 2018-08-28 17:24, Toerless Eckert wrote: > > ...Sure, i meant to imply that port-numbers are useful pragmatically, > but other context identifiers would long term be better. > Demux-Identifiers at the granualarity of a subscriber or > application wold be a lot more scalable than flow identifiers. > > > There are many problems with this issue. > > First, the reason that port numbers would be needed is that they are > *currently* how NATs demux, firewalls enforce policy, and routers manage
There is no requirement in IP that all packets have a transport layer header that with port numbers. In fact, there are several that don't have them like IPsec, fragmented packets, or ICMP. Firewalls that drop anything but UDP and TCP are doing nothing more that ossifying the Internet. Besides that, there are now better alternatives anyway. Reassembly for NAT doesn't require any knowledge or port numbers or even what the transport protocol is. Routers can now use the IPv6 flow label instead of expensive DPI to get transport ports for ECMP as all major OSes now set non-zero flow labels. > flows. For each of these, a different identifier could be developed, but > they would not then reduce the need for ALL of these at the IP level at some > boxes. E.g., see draft-touch-tcpm-sno > > Ultimately, we have to admit that a device that acts on behalf of a host IS > a host and costs what a host costs. That in turn breaks the the end-to-end model. Middleboxes that attempt to participate transport protocols, like a host, inevitably break things and hence is another source of ossification. This is readily evident apparent in that they can't participate in end-to-end crypto. Of course they have tried to insert themselves into that realm, but then we get abominations such as the forced MITM attacks of SSL inspection. IMO, real end-to-end security is a core requirement that outweighs any tradeoffs we might make for the security benefits of firewalls. > > We can't keep believing there is magic dust that can establish a solution > otherwise. > As they say, the answer to ossification is encryption. It does a long way to at least force the issue. First TLS negated payload inspection at middelboxes. QUIC's encryption of transport layer header subsequently negated intermediate devices ability to peruse the transport layer. But, crypto isn't magic dust either. There is only so much of the packet we can encrypt, and a host at its discretion MAY want to share to share transport layer information in the network to get better service. So we need to keep working on solutions. Tom > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
