Tom,
> On Mar 7, 2019, at 7:53 AM, Tom Herbert <[email protected]> wrote:
....
> Yes, some intermediate nodes will arbitrarily drop packets. Some will
> only allow certain UDP ports, some will drop all IPv6, some will drop
> every transport protocol but TCP, some will drop packets with
> extension headers, some will drop fragments, some will drop packets
> with IP options, some will drop ICMP, some will drop UDP packets with
> surplus space, some will parse into HTTP and drop packets with URLs
> they don't like, some will drop anything else they please. That's
> reality. But, DPI in the network => ossification => Internet doesn't
> evolve. IMO, we need to address this instead of just accepting it as
> status quo,
Firewalls are critical network security devices - even when they’re located
within the client hosts’ control (e.g., enterprise edge) and thus more
E2E-‘compliant’, they currently filter by server port number (i.e., TCP SYN
dest port) - which your solution buries in a chain.
Your proposal provides port numbers for demuxing (substantially fewer per
endpoint, because it would fix the server port as GUE), but buries the
transport type far enough that intermediate devices would more likely “give up”
and drop packets than go diving for it.
> lest plain TCP/IPv4 is the only thing left that works on
> the Internet. Transport layer encryption, extending happy eyeballs
> approach to other features, limited domains, showing value in forward
> looking features, using the architecturally correct methods of host to
> network signalling-- are ways to start undoing the harmful effects of
> ossification.
If you’re on a quest to avoid ossification, you’re digging in the wrong place
and you might not want the result you get.
Ossification is never fixed by providing “yet another” way to do something we
already can do.
And, importantly, one person’s ossification is another’s “stable foundation”
that ensures interoperability (i.e., one layer up). So a solution needs to
address a real need in a way that we actually expect will be deployed and used.
The solution proposed here intends to increase work by intermediate devices
that have made it very clear they barely want to do forwarding (high speed
routers), obscures information needed by intermediate devices for security (by
burying the transport port at an unpredictable offset), and offers a network
solution to a problem we already understand is better solved at the transport
layer (fragmentation and reassembly).
So, even after this detailed discussion, we're back where I started - asking
“where’s the need”?
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
