Re: [Int-area] New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

[Joe Touch <[e-mail]>]

Tom,

> On Mar 7, 2019, at 7:53 AM, Tom Herbert <[e-mail]> 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