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

[Tom Herbert <[e-mail]>]

On Wed, Mar 6, 2019 at 10:59 AM Joe Touch <[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. If all of
them drop extension headers, then a whole bunch of effort in 6man is
pointless.

> - 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. In
fact, encryption of the transport layer, like in QUIC, effectively
renders DPI into the transport layer useless. That's a good thing! We
know encryption is one of the best tools in the battle against
protocol ossification. Encryption of the transport header does leave a
void in host signaling to the network, but that can be filled with
proper use of extension headers.

> - 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". A GUE packet
encapsulates using actual  UDP  port numbers. GUE even allows
connection oriented semantics to get through stateful devices. GUE can
carry any IP protocol which may or may not even have port numbers. And
even if it carries something like TCP with port numbers, we're under
no obligation to not encrypt the packet just because some random node
in the path might want to parse it.

>
> Yes, this may be *intended* for uses other than fragmentation, but will any of them succeed? Will even the fragmentation one succeed?
>
> That's the point I was trying to make. I hope it's clear enough now.
>
> Joe
>