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

[Joe Touch <[e-mail]>]

> On Mar 6, 2019, at 2:38 PM, Tom Herbert <[e-mail]> wrote:
> 
> On Wed, Mar 6, 2019 at 10:59 AM Joe Touch <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>> 
>> 
>> On 2019-03-06 09:12, Tom Herbert wrote:
>> 
>> On Wed, Mar 6, 2019 at 9:03 AM Joe Touch <[e-mail]> wrote:
>> 
>> ...
>> 
>> And yes, we can build an Internet on the Internet - again, as I've noted
>> repeatedly throughout the IETF. Or we can use UDP fragmentation - which
>> ought to solve all these issues in one shot.
>> 
>> So what's the gain here?
>> 
>> 
>> Joe,
>> 
>> Please view the proposal in its entirety.
>> 
>> 
>> Here are the problems, which I already stated, but seem to need restating in the exact context of the proposal:
>> 
>> - IP options already cause routers to drop traffic
>>  this is true for both IPv4 and IPv6; making those options look like IPv6 just gives routers a different WAY to drop them
>> 
> Some routers drop extension headers, but not all of them.

See RFC 7126.

> If all of
> them drop extension headers, then a whole bunch of effort in 6man is
> pointless.

No argument there.

> 
>> - DPI looks for transport port numbers that are expected, either for service gating or even deeper DPI
>>  and GUE isn't one of them
>> 
> There's no requirement to support DPI into the transport layer.

Sure, but the current problem is that mechanisms that defeat DPI can result in traffic being blocked.

> In
> fact, encryption of the transport layer, like in QUIC, effectively
> renders DPI into the transport layer useless.

Yes, but not the transport ports.
> ...
> 
>> - pushing the actual UDP port numbers used inside a GUE header creates an "internet in an internet"
>>  as noted above, that's a losing battle we've repeatedly tried
> 
> I'm not sure what you mean by "actual UDP port numbers”.

The E2E transport being used, rather than the encapsulation layer that you need to create a place between IP and transport for these options as if they were protocols.

The issue is that DPI that allows port 443 (even encrypted) and a finite set of other ports would likely block the GUE port. And it wouldn’t dive in to the sequence of headers to find the “actual” transport port inside.

— 

What we know so far is that:
- for on-path signaling, routers don’t want to be signaled or interacted with; they’re too busy just forwarding packets
- the only other reason for these headers are endpoint features that can - and IMO should - be done at the transport layer

Joe