Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 3 Feb 2014 21:47:17 +0100

* Fernando Gont | 2014-01-30 22:02:50 [-0300]:

>Folks,
>
>Mike Heard noted that the Uniform Format specified in RFC 6465 can't
>possibly work.. and after giving some thought about it, it turns out
>that implementing it would hamper the deployment of new transport protocols.
>
>We've written a short I-D that discussed the problem, and that proposes
>an alternative, such that we achieve the same goal without possibly
>messing with our Transport friends. :-)

Hey Fernando, I realized that too and wrote an I-D (back in July 2011):

http://tools.ietf.org/html/draft-pfeifer-6man-exthdr-res-01

Compared to your solution I propose to reserve a range.

Hagen

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Feb 2014 10:43:40 +1300

> Compared to your solution I propose to reserve a range.

Either solution works, but the firewall implementors might
have a preference one way or the other. RFC 7045 says
"Therefore, it is important that forwarding
nodes that inspect IPv6 headers be able to parse all defined
extension headers and deal with them appropriately,..."
So the question is whether they would find a reserved
range or a subtype easier to parse.

     Brian

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 3 Feb 2014 23:00:28 +0100

>range or a subtype easier to parse.

In the appendix of draft-pfeifer-6man-exthdr-res-01 I provided a patch against
Linux net-next-2.6 (see end of this email). In the end the compare do not
matter that match because one additional cmp is used which is fast.

diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c
index 14ed0a9..d7f2e97 100644
--- a/net/ipv6/exthdrs_core.c
+++ b/net/ipv6/exthdrs_core.c
@@ -4,6 +4,9 @@
  */
 #include <net/ipv6.h>

+#define        IP6_EXTHDR_RESERVED_MIN 245
+#define        IP6_EXTHDR_RESERVED_MAX 252
+
 /*
  * find out if nxthdr is a well-known extension header or a protocol
  */
@@ -18,7 +21,8 @@ int ipv6_ext_hdr(u8 nexthdr)
                 (nexthdr == NEXTHDR_FRAGMENT)  ||
                 (nexthdr == NEXTHDR_AUTH)      ||
                 (nexthdr == NEXTHDR_NONE)      ||
-                (nexthdr == NEXTHDR_DEST);
+                (nexthdr == NEXTHDR_DEST)      ||
+                (nexthdr >= IP6_EXTHDR_RESERVED_MIN &&
+                 nexthdr <= IP6_EXTHDR_RESERVED_MAX);
 }

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Feb 2014 12:09:40 +1300

> matter that match because one additional cmp is used which is fast.

By the way, your code extract seems to show exactly the problem
that inspired RFC 7045: the list of nexthdrs needs to include
all of them as per the new registry at
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

    Brian

---

From: Jen Linkova <[email-masked]>
Date: Tue, 4 Feb 2014 15:20:34 +0100

Hi Fernando,

On Fri, Jan 31, 2014 at 2:02 AM, Fernando Gont <[email-masked]> wrote:
> The I-D is available at:
> <http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-00.txt>

Somehow that proposed Universal Extension Header looks exactly like an
Options Extension Header to me.
Am I missing something? I'm trying to use my imagination but couldn't
see any possible scenario when UEH would work and Options header would
not.

> -------- Original Message --------
> Subject: New Version Notification for
> draft-gont-6man-ipv6-universal-extension-header-00.txt
> Date: Thu, 30 Jan 2014 15:07:40 -0800
> From: [email-masked]
> To: Fernando Gont <[email-masked]>, "Fernando Gont"
> <[email-masked]>, "Shucheng LIU (Will)" <[email-masked]>,
> Will (Shucheng) Liu <[email-masked]>
>
>
> A new version of I-D, draft-gont-6man-ipv6-universal-extension-header-00.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
>
> Name:           draft-gont-6man-ipv6-universal-extension-header
> Revision:       00
> Title:          IPv6 Universal Extension Header
> Document date:  2014-01-31
> Group:          Individual Submission
> Pages:          6
> URL:
> http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-universal-extension-header/
> Htmlized:
> http://tools.ietf.org/html/draft-gont-6man-ipv6-universal-extension-header-00
>
>
> Abstract:
>    This document analyzes a problem in the Uniform Format for IPv6
>    Extension Headers specified in RFC 6564, which results in forwarding
>    nodes and middle-boxes not being able to process an IPv6 Header Chain
>    if it contains an unrecognized IPv6 Extension Header that follows the
>    aforementioned Uniform Format.  Additionally, it specifies a new IPv6
>    Extension Header - the Universal Extension Header - that overcomes
>    the aforementioned problem, and enables the extensibility of IPv6
>    without impairing middleboxes that need to process the entire IPv6
>    Header Chain.  Finally, this document formally updates RFC 6564
>
>
>
>
>
> 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
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Tue, 04 Feb 2014 16:18:53 -0300

Hi, Jen,

> see any possible scenario when UEH would work and Options header would

Not sure what you mean.

But please let me provide an example:

Let's say that, tomorrow, the IETF standardizes the GTP (Google
Transport Protocol :-)), and it is assigned the Next Header value 0xFF
(I'm assuming this one is not currently assigned, bbut I'm not checking
the IANA registry right now).

Say a middle-box receives a packet that simply encapsulates GTP in IPv6,
and that middlebox does not yet support GTP. If the middle-box tries to
interpret the GTP header as in RFC6465, it will certainly fail.

The reason? -- RFC 6465 implicitly assumes that every new Next Header
will employ the RFC6465 format. This may be sensible for new *extension
headers*, but certainly not for new transport protocols.

And since transport protocols and extension headers share the same
namespace (see RFC7045), this is a problem.

What we did in our I-D is specify a new Extension Header, that is
assigned a Next-Header value. Let us assume that our proposal moves
forward, and the UEH is assigned the next header value 0xfe.

If a middle-box supports UEH but does not support our (fictitious) GTP
protocol above, then, if a GTP packet encapsulated in IPv6 is received,
GTP will be identified as an "upper-layer protocol", rather than as UEH
(since the Next Header value will be 0xff, rather than UEH's 0xfe).

Clearly, another way to go is to reserve part of the IANA's Next Header
namespace for RFC6465, and leave the rest for transport protocols -- as
suggested by Hagen.

What's clear is that the only way in which RFC6465 can possibly work is
if the middle-box has some a-priori knowledge that what is being
encapsulated follows RFC6465 -- whether as a result of a reserved range
(as originally proposed by Hagen) or by specifying a single UEH, and
then encoding all possible future "extension headers" as subtypes of UEH.

Please do let me know if the above clarifies our rationale...

P.S.: FWIW, we're working together with Hagen to offer 6man a more
unified document that discusses possible approaches, pro's nd con's, etc.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 4 Feb 2014 23:06:38 -0500

Hi Fernando,

Sorry for the long mail, but there is a lot of history here.

The short version is

"Yes we wanted to do this as well, but the WG didn't want to waste a 
protocol number for something that may never be used"

Now for the long version:

When we set out to work on what became RFC6564, this was the *exact* 
problem we set out to solve. e.g. If you look at 
draft-ietf-6man-exthdr-00 differentiating between unknown extension 
headers and unknown upper layer protocols was an explicit goal

"One key advantage of using such a generic IPv6 extension
  header is that it allows nodes to distinguish between unknown
  extension headers and unknown upper layer protocols, which was not
  possible earlier.  Another one is that this generic extension header
  conserves values in the IPv4 protocol numbers registry."

But unfortunately, it turns out that this was not really a problem the 
WG wanted to solve with RFC6564 :-). The documents that lead up to 
RFC6564 (draft-krishnan-ipv6-exthdr-*) and the first two versions of 
draft-ietf-6man-exthdr actually had this idea of an assigned code point 
all along. After WG adoption and subsequent discussion there was severe 
opposition to allocating a protocol number without knowing whether there 
will be any ipv6 extension headers ever defined in the future. The draft 
was changed in version -02 to not request an IANA codepoint anymore. 
Diffs are here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-exthdr-02.txt

I think Thomas Narten's comment summarized the wg feeling at the time 
the best.

"My general sense is that this work is mostly just good common sense
advice to someone who has a need to define a new extension type. But
until we see such a concrete proposal, I am not convinced (yet) that
we should define anything new that suggests people go change
implementations or allocate code points. Both are premature."

Thanks
Suresh

On 01/30/2014 08:02 PM, Fernando Gont wrote:
> Thanks!
> Best regards,
> Fernando

---

From: Fernando Gont <[email-masked]>
Date: Wed, 05 Feb 2014 01:25:03 -0300

Hi, Suresh,

Thanks so much for your response! Please find my comments in-line...

> protocol number for something that may never be used"

Short version of my response :-) :

This seems to have happened two/three years ago... so it might be
worthwhile to revisit that decision. In particular:

1) If this problem remains un-addressed, then it's impossible to
differentiate between new upper-layer headers (e.g. a new transport
protocol) and new extension headers. Since such new extension headers
might be leveraged for malicious purposes, the end-result is that
middle-boxes are going to block *everything* (see RFC7045), which means:

  + no new extension headers
  + no new transport protocols

... so I think we really don't want to go there.

2) Among the possible ways to solve this problem is to just use *a
single* Next Header value -- which turns out how we both tried to solve
separately (which is probably an indication that that's a sensible way
to do it ;-) ). It doesn't seem too onerous to use a single Next Header
value... particularly when the alternative is to implicitly waste all
possible Next Header values (see above).

3) We really want to make the extension headers "workable" (RFC7045).
Current stats seem to indicate that they are being massively dropped in
the public Internet (see e.g.
<http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>
.. and Tim Chown's research show similar numbers). We either do
something about it.. or else we'll have to completey forget about ext
headers.

> WG wanted to solve with RFC6564 :-). 

:-)

> implementations or allocate code points. Both are premature."

The problem here is that unless we do something now, in the event
someone needs to define a new extension header (or transport protocol!),
it simply won't be possible.

So, by doing nothing, we kind of are implicitly saying "No new extension
headers, and no new transport protocols".  *That's* really premature.

Thanks!

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 06 Feb 2014 07:21:49 -0500

> ... so I think we really don't want to go there.

But we are already there. Folk won't deploy anything other than
TCP/UDP because NAT won't deal with it. That has already been reality
and is the reason that other or new transport protocols appear to be
virtually undeployable today.

Reality is that existing middleboxes tend to process what they
understand and have been explicitely coded to deal with. They just
punt on anything else because that is the easiest/safest thing to do.

I see little that we can do to change that.

Thomas

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Feb 2014 09:44:16 -0300

Hi, Thomas,

> virtually undeployable today.

Well, IPv6 *might* give a fresh start in this respect -- there *might*
be IPv6 NAT.. but not necessarily. So.. while the end result might be
the same, it need not.

I don't think we have widespread deployment of IPv6 NAT ("as we know it"
for IPv4), nor that we have such a large/massive deployment of IPv6 that
we can argue "the cat is out of the box".

In any case, I believe this is a discussion to be had. There has been a
lot of work around fragmentation and extension headers, with the more
conservative folks still hoping that EHs are usable on the public
Internet, and the other folks wishing EHs and fragmentation go away
(and, well, actually making that happen by blocking them).

So there seems to be a disconnect between what we expect the IPv6
Internet to be, and how it is being shaped (and is) in practice.

IMHO, we should either accept what's becoming more and more of a fact
(EHs and fragmentation being massively dropped on the public Internet;
e.g.
<http://iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>), or
try to do something to make them usable (after all, we're not planning
for IPv7 anytime soon).

All the above aside, the uniform format in RFC6465 cannot really work as
specified. So it looks like, at the very least, a "please ignore section
X of this document" is warranted... and/or a clear statement that we
have abandoned the possibility of standardizing any new transport
protocols (well, unless we encapsulate them over an existing one).

Thoughts?

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Feb 2014 08:46:41 +1300

> I see little that we can do to change that.

I think we still have a chance with IPv6; of course the game is
over for IPv4. That's why I worked on RFC 7045, and why I think
it's worth trying to knock off this problem too. The current situation
described in Fernando's draft is guaranteed to produce opaque
middleboxes; we can at least make it possible to do better.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Fri, 07 Feb 2014 09:23:38 +0900

> be IPv6 NAT.. but not necessarily. So.. while the end result might be

and cash could fall from the sky

randy

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Feb 2014 23:52:35 -0300

Hi, Randy,

> and cash could fall from the sky

You missed the rest of my response:

I was simply arguing that NATs are not the reason for which anything
other than TCP or UDP wouldn't fly over IPv6. The outcome might be the
same... but for different reasons.

However, what I believe is the high order bit of the discussion is to
try bridge what seems to be a gap between standards making and
operational reality. If what we're heading is towards "no new extensions
nor transport protocols", let's spell that out. And if that's not the
plan, let's see if there's anything that can be done fo that to be
different.

But to keep hearing that e.g. extensions are expected to work when I'm
measuring over 40% of breakage, It seems to boil down to "you, heretic!
don't filter these packets!" on one side and "shut up! you don't know
how to run a network" on another. *That* doesn't seem to be the more
sane approach to this issue.

Thanks,

---

From: Randy Bush <[email-masked]>
Date: Fri, 07 Feb 2014 12:20:15 +0900

> measuring over 40% of breakage, It seems to boil down to "you,
> heretic!  don't filter these packets!" on one side and "shut up! you
> don't know how to run a network" on another. *That* doesn't seem to be
> the more sane approach to this issue.

not sane, but traditional.  "you're idiots because you have not deployed
ipv6."  "you're arrogant fools because you have made it hard to deploy."

randy

---

From: Fernando Gont <[email-masked]>
Date: Fri, 07 Feb 2014 10:21:11 -0300

Hi, Ole,

On 02/07/2014 06:05 AM, Ole Troan wrote:
> 
>> But to keep hearing that e.g. extensions are expected to work
>> when I'm measuring over 40% of breakage, It seems to boil down to
>> "you, heretic! don't filter these packets!" on one side and "shut
>> up! you don't know how to run a network" on another. *That*
>> doesn't seem to be the more sane approach to this issue.
> 
> I think we have to be careful throwing these numbers about without 
> qualifying them.
> 
> aren't you in many cases detecting filtering in front of services, 
> where the operator has very good control of how their traffic
> should look like?

Probably, I guess -- I'm in the process of finding out where these
packets are being filtered.

But widespread filtering of stuff that is supposed to be "ignored if
unsupported" eventually leads to "It's not usable, because if you try
to, your packets get dropped".

If, say, tomorrow you come up with this shiny cool new Dst Opt-based
extension for clients, then, from starters, you would have to think of
a back-up plan, because in more than 40% cases your packets would get
dropped just because of that extension. -- that's where we are right now.

> you are not saying if you, me and 8 of our other friends decided
> to use a new L4 protocol we invented between ourselves, those
> packets would in 40% of cases be filtered by the Internet core?

I'm certainly not.

But let's consider this:

We want IPv6 to be extensible, so we have IPv6 extension headers. And
we want middle-boxes to be able to find the upper layer header (or
else the higher the chances our packets will be dropped on the floor).
The options/scenarios are:

1) Pre-RFC6465: If I'm a middle-box and receive a packet, I have no
way of telling whether it's a protocol that I'm supposed to allow
(that just happens to have a unsupported EH), or an upper-layer
protocol that I shouldn't be letting through. So my options:
      a) Drop those packets -- and now you have widespread deployment of
         devices at the edge that wouldn't allow new transport
         protocols or new EHs

      b) Allow everything -- which I doubt would be the case if e.g. any
         sort of firewalling is meant to be in place.

2) post-RFC6465/now:
Firstly, I'd like to believe that RFC6465 has not been interpreted as
"any other Next-Header values you don't explicitly support should
follow the uniform format". Or else a new transport protocol would
look (to any device trying to process the entire IPv6 header chain)
like a malformed EH and get dropped.  -- it might be a dumb
interpretation.. but that's how many of us interpreted RFC6465 at one
point or another.

Secondly, we really need to provide a mechanism for middle-boxes to
find the upper-layer header. Simple example: Let's say that I have a
home firewall that is meant to just allow outgoing communication
instances (for which extension headers are deemed as "fine"). Without
a way to parsing new EHs (such as in the I-D we posted). Such firewall
would simply drop new EHs, not because it wants, but rather because it
has no way of telling what's an extension, and what's a protocol that
it doesn't want to let through. In that case, we should completely
forget about our ability to specify new (usable) EHs.

Thoughts?

Thanks,

---

From: Karsten Thomann <[email-masked]>
Date: Fri, 07 Feb 2014 21:51:24 +0100

> forget about our ability to specify new (usable) EHs.

Hi,

I think the "simple" solution is to provide middle boxes an offset to the upper layer header, if the 
EH is unknown to the box, it can still identify the upperlayer.

With that offset every middlebox can identify the used transport protocol without knowledge of 
any future EH.

I know that it is not that easy and has it's own pros and cons, but I provide it as an idea to solve 
the problem.

Regards
Karsten

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Fri, 7 Feb 2014 23:23:39 +0100

>virtually undeployable today.

Maybe actual in parts of the Internet. We deploy larger networks with our
router silicon and we _use_ IPv6 extension header to transport signaling
information. Period. Our need is not on the protocol side - UDP is fine for
all - we need additional extension header (think about roaming information).
And we _have_ actual problems with the current situation! This is why I wrote
the I-D back in 2011[1].

I remember a time where ECN did not work properly and where dropped
occasionally by broken middleboxes. LKML started to enabled ECN and things
improved over time.

We should not stop solutions here because administrators/vendors infringe
protocol best practices. We should focus on an proper protocol design which
enables possibilities.

Hagen

[1] http://tools.ietf.org/html/draft-pfeifer-6man-exthdr-res-01

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Feb 2014 11:53:37 +1300

On 08/02/2014 09:51, Karsten Thomann wrote:
...
> EH is unknown to the box, it can still identify the upperlayer.

This was suggested a while back but there was no enthusiasm for it.

http://tools.ietf.org/html/draft-zhang-6man-offset-option-01

   Brian

> ------------------------------------------------------------------------
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 7 Feb 2014 16:06:29 -0800 (PST)

----- Original Message -----
> From: Fernando Gont <[email-masked]>
> To: Ole Troan <[email-masked]>
> Cc: Thomas Narten <[email-masked]>; "[email-masked]" <[email-masked]>; C. M. Heard <[email-masked]>; Suresh Krishnan <[email-masked]>; Tim Chown <[email-masked]>
> Sent: Saturday, 8 February 2014 12:21 AM
> Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
> 
> Hi, Ole,
> 

End-to-end crypto might the backup plan. I think it might be worth remembering that as per the IETF88 Plenary, end-to-end encryption is the general direction, and that middle boxes less effective/in-effective because of it. So putting a lot of time and effort into facilitating them might be wasted effort.

I also think multipathing, to take advantage of smartphone/tablet's multi-homing to the network will also mean middle boxes become less effective/in-effective. IOS 7 is already using MPTCP for Siri for example+.

<snip>

Regards,
Mark.

+ - http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/09/18/mptcp.html

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 9 Feb 2014 11:35:37 -0800 (PST)

> > see any possible scenario when UEH would work and Options header would

In an offline discussion with Fernando before his draft was submitted
I made the following comments:

| This seems technically sound and is probably what RFC 6564 should 
| have said in the first place.  However, playing devil's advocate, 
| let me ask if there is a reason why the Destination Options header 
| would not serve the same purpose as the universal extension header 
| [...], so long as that header is allowed to appear multiple times at 
| any position in between the Hop-By-Hop options header (if present) 
| and the Fragment Header or the upper layer header.

In the absence of a strong argument to the contrary, it seems to me 
that the existing Destination Options header can be used to do 
exactly the same thing as the proposed UEH.  In other words, I agree 
with Jen's comments.

> namespace (see RFC7045), this is a problem.

All this is true.  The implication is that the middlebox must stop 
parsing the header chain when it encounters an unknown Next Header.

In more detail, I see the three cases:

1.) The middlebox encounters an ESP Next Header, signalling that an 
    encrypted payload follows.  In that case it stops parsing the 
    header chain and applies its policy for encrypted payloads.

2.) The middlebox encounters a Next Header corresponding to a known 
    transport protocol.  In that case it may perform filtering 
    actions specific to that transport protocol (and of course may 
    continue parsing into the transport header in order to do so).

3.) The middlebox encounters an unknown Next Header value.  In that 
    case it stops parsing the header chain and applies its policy 
    for packets with unknown Next Header values.  In order to comply 
    with RFC 7045, it MUST be possible to configure the policy to 
    allow such packets, but the default MAY be to drop them.  A 
    high-quality implementation would allow the policy to be 
    configured individually for each unknown Next Header value.

I agree that there are use cases where it is important for a middlebox 
to clearly distinguish between an unknown extension header and an 
unknown transport protocol.  One is RA Guard: see

https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/

> then encoding all possible future "extension headers" as subtypes of UEH.

A third possibility would be to go a step further than RFC 6564 and 
ban new extension headers outright, insisting that a Destination 
Option be used instead.  RFC 6564 already says that a new extension 
header may be defined only as a last resort, requiring proof that a 
Destination Option will not work.

Can anyone offer up a scenario where a Destination Option will not 
work?

Mike Heard

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Feb 2014 11:44:03 +1300

On 10/02/2014 08:35, C. M. Heard wrote:
...
> exactly the same thing as the proposed UEH.  In other words, I agree 

I think we should carry out a thought experiment: consider each
of the existing extension headers, listed in RFC 7045 and at
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
and see which of them could or could not be encoded as
destination options.

For some of them the answer is obvious, of course. But the others would
give us an idea whether the 'option' option has enough flexibility.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2014 08:21:09 -0300

> exactly the same thing as the proposed UEH.  In other words, I agree 

There are two issues here:

1) Your proposed outcome still means that we should still do something
about this issue. i.e., state "New Next Headers will never be specified.
And hereby we deprecate RFC6465's section on the unified format".

2) I wonder whether we really want to close the door to new extension
headers. After all, new ext header will not be more harmful than the
existing ones (in terms of the issues that have been discussed a number
of times on this and other lists).

[....]
> parsing the header chain when it encounters an unknown Next Header.

Agreed. But what we want to achieve is that they don't need to --
particularly when the unknown Next Header is an extension.

>     header chain and applies its policy for encrypted payloads.

Agreed. IN this case, ESP would be the "upper layer protocol" as per our
definition in RFC 7112.

>     continue parsing into the transport header in order to do so).

The problem is that, right now, a middle-box cannot tell whether it's in
the presence of a new transport protocol, or an extension header. This
is the ambiguity we should get rid off. RFC 7045 tackles part of the
problem (ie., for known ext headers)... but there's still the ambiguity
for new ones.

> unknown transport protocol.  

Agreed. This is th key point.

[...]
> Option be used instead.

Yes. That is among the options. I'm not sure that I'd side with this
one. But certainly, any of the three options that have been discussing
(the one currently documented in our I-D, Hagen's, or this one) are
better than the current state of affairs.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2014 16:26:24 -0300

On 02/07/2014 09:06 PM, Mark ZZZ Smith wrote:
>> 
>> If, say, tomorrow you come up with this shiny cool new Dst 
>> Opt-based extension for clients, then, from starters, you would 
>> have to think of a back-up plan, because in more than 40% cases 
>> your packets would get dropped just because of that extension. -- 
>> that's where we are right now.
>> 
> 
> End-to-end crypto might the backup plan.

Depends on what you mean by end-to-end crypto, and in what context.

SSL/TLS for say, web servers and mailservers, fine.

IPsec for the general case...mmm.. unlikely.

Is there any plan for solving the authentication of nodes? Is everyone
expected to get/buy a certificate?

> I think it might be worth remembering that as per the IETF88 Plenary,
> end-to-end encryption is the general direction, and that middle boxes
> less effective/in-effective because of it. So putting a lot of time
> and effort into facilitating them might be wasted effort.

It's a 1-page to 5-page document (and that's including bolierplates).

> I also think multipathing, to take advantage of smartphone/tablet's
> multi-homing to the network will also mean middle boxes become less
> effective/in-effective. IOS 7 is already using MPTCP for Siri for
> example+.

This is a comment from the URL you posted:

> Yes, it works! Thanks Kristian.
> However here in Italy 3G carriers filter out TCP options.. so SIRI gives
> up and stops trying to use mptcp in the long run.

Cheers,

---

From: Ray Hunter <[email-masked]>
Date: Tue, 11 Feb 2014 09:55:59 +0100

> unknown transport protocol.  One is RA Guard: see

I agree with the above analysis for the current situation.

I think this draft is worth pursuing, to see if the decision tree can be 
extended to differentiate between an unknown IPv6 header, and an unknown 
upper layer header.

Some in the IETF seem to think that end to end encrypted tunnels are 
"the solution".

I think this just moves the battlefield: end users will insist that 
encrypted tunnels are terminated on a security device, which then 
inspects the packet, potentially resulting in less security rather than 
more as certificates then have to be installed on the middleware box. 
The middleware box also then becomes a DOS target itself, as it has to 
perform significant amounts of processing.

End users and major enterprises demand that they can look inside packets 
at near wire speed and filter traffic traversing their AS boundary in a 
granular manner according to a security policy that they can tweak 
themselves.

IMHO The IETF should accept that starting point as a basic requirement 
for protocol development, and facilitate simple parsing and granular 
filtering at high speed.

Anything not complying with this basic requirement is unlikely to be 
deployed.

-- 
Regards,
RayH

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 11 Feb 2014 22:42:05 -0800 (PST)

> give us an idea whether the 'option' option has enough flexibility.

That is a good idea and I am going to take a stab at it.  In looking 
over the references for the existing extension headers listed in RFC 
7045 and in the above-referenced IANA registry it appears to me that 
the order in which headers other than experimental use headers 253 
and 254 should appear is as follows (this is an update of RFC 2460 
Section 4.1):

IPv6 header
Hop-by-Hop Options header
Destination Options header (note 1)
Routing header
Shim6 header
Fragment header
Authentication header (note 2)
Encapsulating Security Payload header (note 2)
Destination Options header (note 3)
Mobility Header or Host Identity header (note 4)
upper-layer header

note 1: for options to be processed by the first destination
        that appears in the IPv6 Destination Address field plus 
        subsequent destinations listed in the Routing header.

note 2: additional recommendations regarding the relative
        order of the Authentication and Encapsulating Security 
        Payload headers are given in [RFC-2406].

note 3: for options to be processed only by the final
        destination of the packet.

note 4: at present, these headers are required to contain
        No Next Header, so an upper-layer header will not follow 
        these headers.

To see if the 'option' option has enough flexibility, let's consider 
each header in turn to see whether it could reasonably be replaced 
by one of the following:

- hop-by-hop option
- destination option
- upper-layer header

or (for the three kinds of headers listed above) how the rules for 
usage would be changed by a ban on new IPv6 extension headers.

This is a bit more general question than the one posed by Brian 
Carpenter, but I think it's the right way to go when determining 
whether a ban on new extension headers would limit flexibility.

Hop-by-Hop Options header: this header is needed to clearly 
distinguish hop-by-hop and destination options.  It is (and always 
has been) the only means to include optional IPv6 data with 
hop-by-hop semantics.  A ban on new extension headers would not 
change this.

Destination Options header: this header is needed to clearly 
distinguish hop-by-hop and destination options.  Using a destination 
option in place of an extension header could require that this 
header be allowed to appear more than twice in the IPv6 header chain 
or introduce constraints regarding the order in which destination 
options would be allowed to appear.

Routing header: IPv4 provides an existence proof that this extension 
header could be replaced by a destination option.  Such an option 
would be carried in a Destination Options header immediately 
following the Hop-by-Hop Options header if present or the IPv6 
header otherwise.

Shim6 header: as far as I can tell, the situation is exactly the 
same as for the Routing header.  In cases where an IPv6 packet 
contains only Shim6 control information and no ULP data, the Next 
Header value of the containing Destination Options header would be 
No Next Header.

Fragment header: it is my assessment that while it might be possible 
to make this into a destination option, that would add a good deal 
of awkwardness to an already awkward and error-prone function.  On 
that basis I would say that using an extension header was justified 
in this case.

Authentication header: it certainly would be possible to encode the 
equivalent information into a destination option, but because of the 
fact that the authentication is done prior to fragmentation or after 
reassembly it would be necessary to allow a separate Destination 
Option header to appear where the Authentication header now appears.  
However, since AH is used for both IPv4 and IPv6, that would not 
have been a good engineering choice, and I would say that using an 
extension header was justified in this case.

Encapsulating Security Payload header: as noted in RFC 4303, "in the 
IPv6 context, ESP is viewed as an end-to-end payload," and we treat 
is as such when determining where an IPv6 header chain ends.  It 
would not make sense to replace it with a destination option, 
but if the concept of an extension header did not exist, we would 
just treat it as an upper-layer header that contains tunneled 
encrypted data.

Mobility Header and Host Identity header:  unless I am missing 
something, these are used to carry control messages and always 
have a Next Header value of No Next Header, allowing some 
future flexibility to include piggybacked data in a standard 
way.  As far as I am able to tell, exactly the same goal could 
be achieved by defining these as upper-layer protocol headers.

Experimental Use headers (protocol numbers 253 and 254): since 
these could be either extension headers or transport protocols 
per then whim of the experimenter, there is no defined function 
to evaluate.  However, if we go with the 'option' option, these 
would turn into experimental upper-layer headers, and the 
experimental-use options would be used for experiments that 
wanted to "sandwich" optional data into an IPv6 header.

Thoughts?

Mike Heard

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 12 Feb 2014 00:28:44 -0800 (PST)

----- Original Message -----
> From: Fernando Gont <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>; Fernando Gont <[email-masked]>; Ole Troan <[email-masked]>
> Cc: Thomas Narten <[email-masked]>; C. M. Heard <[email-masked]>; Tim Chown <[email-masked]>; "[email-masked]" <[email-masked]>; Suresh Krishnan <[email-masked]>
> Sent: Tuesday, 11 February 2014 6:26 AM

Any or all of them. In the latter case, BTNS mode of IPsec (RFC5386) would probably be better than NSA can have everything(tm) IP because it shrinks their window to be a MITM.

> It's a 1-page to 5-page document (and that's including bolierplates).

I'm not saying to no do it, just that if e.g., somebody like Google, Apple or Microsoft roll out an update that enables crypto on a very popular service (similar to how within days, millions of iPhones and iPads used MPTCP for Siri), the traffic that these middleboxes are inspecting might "go dark" or become hidden "overnight". If there is a lot of effort involved, it would be wasted if that sort of event happened.

>>  up and stops trying to use mptcp in the long run.

"Encapsulation of TCP and other Transport Protocols over UDP"
http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00

"In fact, TCP options are expected to work
more reliably with TCP-over-UDP, because middleboxes will be less able to easily interfere with such options, modifying them, stripping them, or dropping packets containing TCP options, as they often dotoday with native TCP                     packets.  In particular, Multipath TCP-over-UDP
is expected to work more reliably than native Multipath TCP [RFC6824], because middleboxes that interfere with use of those TCP options will be less able to do that when the packets are encapsulated inside UDP."

;-)

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Feb 2014 05:55:55 -0300

Hi, Mark,

On 02/12/2014 05:28 AM, Mark ZZZ Smith wrote:
>> Is there any plan for solving the authentication of nodes? Is
>> everyone expected to get/buy a certificate?
>> 
> 
> Any or all of them. In the latter case, BTNS mode of IPsec (RFC5386)
> would probably be better than NSA can have everything(tm) IP because
> it shrinks their window to be a MITM.

Which my result in "placebo" security: you never know if you've been
MITM'ed.  :-(

>>> I think it might be worth remembering that as per the IETF88
>>> Plenary, end-to-end encryption is the general direction, and that
>>> middle boxes less effective/in-effective because of it. So
>>> putting a lot of time and effort into facilitating them might be
>>> wasted effort.
>> 
> I'm not saying to no do it, just that if e.g., somebody like Google,
> Apple or Microsoft roll out an update that enables crypto on a very
> popular service (similar to how within days, millions of iPhones and
> iPads used MPTCP for Siri), the traffic that these middleboxes are
> inspecting might "go dark" or become hidden "overnight".

If e.g. TLS is enabled, the TCP header information is still in the clear
(unless you're *tunneling* over TLS).

> If there is
> a lot of effort involved, it would be wasted if that sort of event
> happened.

This shouldn't be "a lot of effort".

>>> Yes, it works! Thanks Kristian. However here in Italy 3G carriers
>>> filter out TCP options.. so SIRI gives up and stops trying to use
>>> mptcp in the long run.
> 
> "In fact, TCP options are expected to work more reliably with
> TCP-over-UDP, because middleboxes will be less able to easily
> interfere with such options, modifying them, stripping them, or
> dropping packets containing TCP options, as they often dotoday with
> native TCP                     packets.  In particular, Multipath
> TCP-over-UDP is expected to work more reliably than native Multipath
> TCP [RFC6824], because middleboxes that interfere with use of those
> TCP options will be less able to do that when the packets are
> encapsulated inside UDP."
> 
> ;-)

Well, how good this is probably depends on whether one assumes the
aforementioned middle-box behavior is intentional or not. If it is, then
this is "middle-box unfriendly". If it's not, this is "middle-box
friendly". FWIW, one would expect this to be an arms race. If this is
*intended middle-box behavior", then you'd expect middle-boxes to become
smarter, and eventually we'll have TCP-over-UDP-over-* :-)

Cheers,

---

From: Dan Lüdtke <[email-masked]>
Date: Fri, 14 Feb 2014 17:57:36 +0100

We all do not know what the future might bring, so being able to
differentiate between an unknown IPv6 extension header and an unknown
upper layer header should not be considered unimportant. I prefer
reserving a range over creating a new registry. The main reason is
that I am developing IPv6 software and it is easier to keep the
parsing tree short.

E.g. exthdr->option vs. exthdr->subexthdr->option

Some nitpicking:
In section "3. Problem Statement": typo: "on the fat" -> "on the fa_c_t"
In section "5. Operation of the UEH": typo: "discusses de operation"
-> "discusses _the_ operation"

That's all for now, have a nice weekend everyone.

-- 
Dan Luedtke
http://www.danrl.de

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 16 Feb 2014 11:39:50 -0800 (PST)

Hi Fernando,

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>; Fernando Gont <[email-masked]>; Ole Troan <[email-masked]>
> Sent: Friday, 14 February 2014 7:55 PM

Given recent revelations, it is probably better to assume we already have been.

I think security is relative, not absolute. BTNS mode of IPsec protecting traffic would be much better than nothing protecting traffic. Even if you are MITM'd, at least the costs of uncovering the traffic go up, creating more of a disincentive to MITM unless they have to.

> friendly".

I think that as it is dropping unknown TCP options, rather than forwarding them, it indicates it is fundamentally intentional. A middle box "in the customers interests" would default to forwarding when it encounters unknown options, field values etc., allowing MPTCP to work.

In this specific case, it could be that as Siri uses 3G as a backup path for MPTCP for Wifi, Italy's 3G carriers might be blocking the MPTCP options to prevent Wifi offload via MPTCP, forcing customers to use and therefore pay for 3G bandwidth use even when they don't have to.

Customers certainly won't like that if they discover it, however the customers won't necessarily realise that it is the carrier that they're paying that is causing them to have a less reliable and more costly service. However, the people who provide Siri to those customers would be capable of finding out where the problem is, and may then develop and deploy work-arounds to the problem of TCP options being dropped. I don't know if you noticed, but the authors of that draft are from Apple, who have a very strong incentive for Siri to work well for their customers.

> FWIW, one would expect this to be an arms race. If this is

I agree it will be an arms race, and I'm confident that the host/application people will eventually win. I think their fundamental desire is network transparency so that they can spend time and effort on better application features, rather than on work around methods to get the data they want between the application end-points. The harder the network makes it for the host/application developers to add new and useful features, the harder the host/application developers will push back, with obfuscation being their weapon.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Feb 2014 17:05:16 +1300

Mike,

You ended this message with

> Thoughts?

I think your analysis is pretty much spot on. Maybe the best we
can do is:

a) State that new requirements SHOULD be defined as payloads.

b) If not, they MUST be defined as options unless there is an
unavoidable technical reason that they can't be. That doesn't
seem to be significantly different from saying that they MUST
be sub-options of a new generic header. In any case, firewalls
will want to parse these options.

BTW, RFC6564 already says this at SHOULD level.

c) Re-iterate that RFC6564 requires a uniform format.

d) Re-iterate that RFC7045 requires middleboxes to handle
all defined extension headers.

Note that a) above is the only really new thing here. But if
d) is implemented, middleboxes can find the payload, and
if a) and b) are implemented, there will not be any new
extensions except in extreme circumstances.

BTW, the subject of this thread has been wrong from the start:
s/6465/6564/. I didn't correct it because of threaded mail
readers.

Regards
   Brian

On 12/02/2014 19:42, C. M. Heard wrote:
> .