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

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 5 Mar 2019 14:21:45 +0000

Hi Tom,

I'm sorry I haven't had a chance to read this yet, but the AERO draft has for
a long time  proposed including an IPv6 fragment header as the next header
in an IPv4 packet (see Appendix A of 'draft-templin-intarea-6706bis'). Is what
you are proposing essentially the same thing?

Thanks - Fred 

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Wednesday, February 27, 2019 12:48 PM
> To: [email-masked]
> Subject: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt
> 
> Hello,
> 
> The goal of this draft is to define a common (and hopefully feasible)
> method of extensibility and netwrok signaling between IPv4 and IPv6.
> The draft specifies two things:
> 
> - IPv4 extension headers. Basically this is just IPv6 extension
> headers that are recast to be used in IPv4.
> - Encapsulating extension headers and trailing transport protocol in
> UDP so as to make extension headers transparent to intermediate
> devices that have problems processing them.
> 
> Tom
> 
> 
> ---------- Forwarded message ---------
> From: <[email-masked]>
> Date: Wed, Feb 27, 2019 at 12:19 PM
> Subject: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt
> To: Tom Herbert <[email-masked]>
> 
> 
> 
> A new version of I-D, draft-herbert-ipv4-udpencap-eh-00.txt
> has been successfully submitted by Tom Herbert and posted to the
> IETF repository.
> 
> Name:           draft-herbert-ipv4-udpencap-eh
> Revision:       00
> Title:          IPv4 Extension Headers and UDP Encapsulated Extension Headers
> Document date:  2019-02-27
> Group:          Individual Submission
> Pages:          27
> URL:
> https://www.ietf.org/internet-drafts/draft-herbert-ipv4-udpencap-eh-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-herbert-ipv4-udpencap-eh/
> Htmlized:       https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-udpencap-eh
> 
> 
> Abstract:
>    This specification defines extension headers for IPv4 and a method to
>    encapsulate extension headers in UDP to facilitate transmission over
>    the Internet. The goal is to provide a uniform and feasible method of
>    extensibility that is shared between IPv4 and IPv6.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Mar 2019 07:36:09 -0800

> you are proposing essentially the same thing?
Fred,

Looks like it is for fragmentaton (ESP and AH are already extension
headers used with IPv4). Use of the fragment header with IPv4 is
compelling because it could address deficencies in IPv4 fragmentation
like the small ID field. It might also free up IPID to be used as an
IPv4 flow label (RFC6864 states IPID can be arbitrarily set for atomic
datagrams).

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Mar 2019 22:08:25 -0800

Isn't the biggest problem with IP fragmentation the inability to NAT
because the transport headers are in the first fragment only (which may
go via another path)?

I.e., 6864 already relaxes the ID field to allow reuse as long as it's
not within expected reordering, overcoming the speed limit. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Wed, 6 Mar 2019 08:22:53 -0800

> because the transport headers are in the first fragment only (which may

Joe,

The size of the IP identifier is mentioned as one of the problems with
IPv4 fragmentation in draft-ietf-intarea-frag-fragile. The fact that
intermediate nodes might fragment in IPv4 and not in IPv6 is another
discrepancy between the protocols. The transport layer not in all
fragments is a problem for NAT, that might addressed by encapsulating
the fragmention in UDP.

Tom

---

From: Joe Touch <[email-masked]>
Date: Wed, 6 Mar 2019 09:03:40 -0800

On 3/6/2019 8:22 AM, Tom Herbert wrote:
> IPv4 fragmentation in draft-ietf-intarea-frag-fragile. 

That could have been handled by new rules to drop incompletely
reassembled datagrams based on measured expected reordering, rather than
max lifetime.

> The fact that
> discrepancy between the protocols. 

Well, strictly the difference is only whether intermediate nodes violate
IPv4 or IPv6. IPv4 with DF isn't supposed to be on-path fragmented any
more than IPv6 is; in both cases, nodes that violate the protocols can -
and will - do whatever they want.

But there's no point in making "laws for the lawless", as I've
repeatedly noted throughout the IETF.

> The transport layer not in all

That is a problem for NAT and transport-based ECMP.

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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 6 Mar 2019 09:12:46 -0800

Joe,

Please view the proposal in its entirety. The stated objectives are to
support IPv6 extension headers in IPv4 and to allow encapsulate of
extension headers (both for IPv6 and Ipv4) in UDP to improve
deliverability. Fragmentation header is just one example.

Tom

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Mar 2019 10:59:03 -0800

On 2019-03-06 09:12, Tom Herbert wrote:

>> ...
> 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 

- DPI looks for transport port numbers that are expected, either for
service gating or even deeper DPI 
  and GUE isn't one of them 

- 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 

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 6 Mar 2019 20:09:44 +0000

Hi Tom,

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2019 7:36 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt
> 

'draft-templin-intarea-6706bis' is where the idea of including an IPv6-specific
extension header as a next header in an IPv4 packet came from. So, IMHO,
it should be cited as a reference.

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Wed, 6 Mar 2019 14:38:20 -0800

On Wed, Mar 6, 2019 at 10:59 AM Joe Touch <[email-masked]> wrote:
> Here are the problems, which I already stated, but seem to need restating in the exact context of the proposal:
>
>   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
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"

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?
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 6 Mar 2019 21:29:25 -0800

> On Mar 6, 2019, at 2:38 PM, Tom Herbert <[email-masked]> wrote:
> 
> On Wed, Mar 6, 2019 at 10:59 AM Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>> 
>> 
> Some routers drop extension headers, but not all of them.

See RFC 7126.

> If all of

No argument there.

> 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
> renders DPI into the transport layer useless.

Yes, but not the transport ports.
> 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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 7 Mar 2019 07:53:58 -0800

Joe,

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, 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.

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Mar 2019 08:27:34 -0800

Tom,

> On Mar 7, 2019, at 7:53 AM, Tom Herbert <[email-masked]> wrote:
...
> 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

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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 7 Mar 2019 09:03:00 -0800

Joe,

Extension headers are the means of extending the IPv6 protocol, IP
options are the means to extend the IPv4 protocol. IP options are not
receiving any attention by IETF, have disadvantages, and are otherwise
considered obsolete. IPv6 extension headers are gaining traction as
there is active development in things like segment routing and other
proposal for new options.

This proposal has two components:

1) Allow IPv4 to carry IPv6 extension header numbers in the protocol
field, and process as IPv4 extension headers.
2) Encapsulate extension headers and following transport packet in GUE/UDP

#1 Brings a valuable feature from IPv6 into IPv4. This allows us to
leverage all the good work being done in IPv6 to be in IPv4.
#2 Facilitates deployability of extension headers (both IPv4 and IPv6
extension headers) in environments for which natively using extension
extension headers is problematic,

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Mar 2019 23:57:16 -0800

> field, and process as IPv4 extension headers.

I heard someone on another list argue strongly for fixed headers of the
sort IPv4 already uses. ;-)

> 2) Encapsulate extension headers and following transport packet in GUE/UDP

Which, as I noted, undermines the useful work performed by firewalls.

All so we can have routers process options - something they basically
don't do anyway...(I don't know who's pushing otherwise in 6man, but
this issue has been a big one for *many* years)

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Mar 2019 06:38:51 -0300

Hi, Joe,

> On 3/7/2019 9:03 AM, Tom Herbert wrote:
[....]
> this issue has been a big one for *many* years)

Not sure what you mean.

The argument has typically been as follows:

 * Folks need to get some upper-layer values (see:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops for
reasons)

 * EHs make that painful

 * As a result, many folks frop EHs. See RFC7872

 * In some circles this is well-understood and "no problem", in others
   it is probably "incomfortably understood" and prefer not to talk
   about it

   + the conversation would boil down to something like:
       - this feature is not usable on the public internet
       - many devices are not really IPv6-ready (standards wise)
       - with the previous two issues probably suggesting that the
         functionality should be removed.

   + fwiw, i don't care that much about the outcome, as long as there's
     some level of convergence among specs, devices, and deployed
     reality

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Mar 2019 06:47:04 -0300

> IPv4 flow label (RFC6864 states IPID can be arbitrarily set for atomic

Isn't the general consensus to move away from fragmentation as much as
possible?

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Mar 2019 07:37:49 -0800

> Isn't the general consensus to move away from fragmentation as much as
I don't believe so. There are still a lot of valid use cases for
fragmentation. draft-ietf-intarea-frag-fragile-09 talks about the
current state fo fragmentation.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Mar 2019 07:56:33 -0800

Joe,

Then so does QUIC, TLS, IPsec and anything else that would obfuscate
the data that firewalls might want to inspect. You seem to be
convoluting firewalls and security, they are not the same thing.
Firewalls are not required for security, real security comes in the
application and end point processing. Consider that QUIC purpose
encrypts as much of the transport layer as possible. Only the two
endpoints of communication have the key. And when a QUIC end point
receives a packet, it can decrypt and process the packet. Note that is
_not_ the actions of a firewall at the endpoint, it is the action of
an end host processing an end to end protocol and being compliant with
the protocol specification.

> this issue has been a big one for *many* years)

Take a look at 6man. There are efforts underway and there is starting
to be deployment of extension headers (segment routing for instance).

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Mar 2019 08:53:22 -0800

> current state fo fragmentation.

Agreed, but if UDP supports fragmentation (it will), then we don't need
that capability buried in obscure layering.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Mar 2019 08:57:30 -0800

On 3/8/2019 7:56 AM, Tom Herbert wrote:
> the data that firewalls might want to inspect.

Of those, only IPsec hides application transport numbers. And your
proposal - though not encrypted, it buries them far enough that
firewalls won't go looking.

>  You seem to be
> convoluting firewalls and security,

Security has 4 dimensions:

- privacy

- integrity

- authentication (identity)

- resource protection

Firewalls help with the 4th dimension. It's still called security and
they're still very widely used (much more widely than any support likely
to come of new IP EHs, I'll happily wager).

And I know there are some in 6man talking about deployment. There were
those who started to deploy Active Nets in the 1990s too. Wouldn't they
be just as effective for what you want?

Oh, wait - they' were fringe at best and disappeared. Curious why...

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Mar 2019 09:33:55 -0800

On Fri, Mar 8, 2019 at 8:53 AM Joe Touch <[email-masked]> wrote:
> Agreed, but if UDP supports fragmentation (it will), then we don't need that capability buried in obscure layering.
>
UDP fragmentation would only with UDP, it doesn't help any other
transport protovcol. Also, I don't understand how the fragmentation
extension header, which has been defined for over twenty years and is
now part of an Internet standard, can be called "obscured layering".

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Mar 2019 09:42:06 -0800

On 3/8/2019 9:33 AM, Tom Herbert wrote:
> transport protovcol.

Stream transports already do this for the entire stream.

The only other exception might be DCCP - I'd have to check that.

>  Also, I don't understand how the fragmentation

Not IPv4; the one where the network EHs would be buried after a GUE
transport header.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Mar 2019 10:01:05 -0800

> The only other exception might be DCCP - I'd have to check that.
IPsec, GRE, MPLS, Ether/IP, IPIP, etc. The whole point of having
things like fragmentation into the network layer is that it applies to
all protocols and we don't need to "reinvent the wheel" every time a
new protocol comes along.

> Not IPv4; the one where the network EHs would be buried after a GUE

If by "network EHs" you mean Hop-by-Hop options, the draft specifies
how intermediate nodes can parse them in the GUE payload, and a magic
number is used to ensure with high probability that a middlebox is
indeed inspecting a GUE packet. Also, there is no requirement that any
intermediate nodes must process IPv4 Hop-by-Hop options.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Mar 2019 15:57:39 -0800

> On Mar 8, 2019, at 10:01 AM, Tom Herbert <[email-masked]> wrote:
> 
> IPsec, GRE, MPLS, Ether/IP, IPIP, etc.

These are not transport protocols. My point is that your proposal doesn’t help transports.

If a transport can avoid net-level frag, it’s always better to do so (see PLPMTUD).

> The whole point of having
> things like fragmentation into the network layer

Yes - at the network layer for those. Which is what IPv4 and IPv6 already support. 

Your proposal buries a pseudo-net layer inside a transport - at which point we don’t need the pseudo-net layer, at least not for fragmentation.

> is that it applies to
>>> extension header, which has been defifor over twenty years and is
> indeed inspecting a GUE packet.

Yes - boxes that don’t do IPv4 options for performance reasons will *magically* now support this extra work (thus the magic number?)

You specify how that can be done by examining headers nobody currently supports. So when (or if) nodes upgrade, they’ll be able to do something they currently refuse to do (that is simpler).

> Also, there is no requirement that any

RFC1812:

4.2.2.1 <https://tools.ietf.org/html/rfc1812#section-4.2.2.1> Options: RFC 791 Section 3.2 <https://tools.ietf.org/html/rfc791#section-3.2>

   In datagrams received by the router itself, the IP layer MUST
   interpret IP options that it understands and preserve the rest
   unchanged for use by higher layer protocols.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Mar 2019 16:27:48 -0800

> Not IPv4; the one where the network EHs would be buried after a GUE

The draft is clear on how intermediate devices can parse that.

> You specify how that can be done by examining headers nobody currently supports. So when (or if) nodes upgrade, they’ll be able to do something they currently refuse to do (that is simpler).

That's not true. GUE has been in deployment for quite a while and the
extension header encapsulation is already supported by virtue of the
design. IPv4 extension headers have not be developed as of of yet,
however adding host support is easy. Intermediate nodes parsing of GUE
(which again is optional) is not particular difficult either given the
emergence of programmable network devices.

> 4.2.2.1 Options: RFC 791 Section 3.2
>
Not an applicable requirement. Hop-by-Hop Options are not Ipv4 options.