Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

From: "C. M. Heard" <[email-masked]>
Date: Wed, 1 Nov 2017 19:31:55 -0700

On Wed, 01 Nov 2017, Michael Richardson wrote:
> Yet we skip other extension headers in order to find the ULP.

Not so. An end node that encounters an unrecognized extension header is
not supposed to skip the unrecognized extension header; it is supposed
to discard the packet. See Section 4 of RFC 8200:

   If, as a result of processing a header, the destination node is
   required to proceed to the next header but the Next Header value in
   the current header is unrecognized by the node, it should discard the
   packet and send an ICMP Parameter Problem message to the source of
   the packet, with an ICMP Code value of 1 ("unrecognized Next Header
   type encountered") and the ICMP Pointer field containing the offset
   of the unrecognized value within the original packet.

Substantially the same language appears in Section 4 of RFC 2460.

It is, in fact, impossible to reliably tell the difference between an unknown
extension header and an unknown upper layer protocol because they are drawn
from the same numbering space. That fact has been discussed here on more than
one occasion.

> In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown
> header....  Because we got this wrong, we couldn't use AH to secure ND or any
> other multicast (like OSPF) without causing of a flag day.  AH became totally
> USELESS.  It was sad.

There may be problems with AH, but that is not one of them.

Mike Heard

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Nov 2017 07:57:45 -0400

> Not so. An end node that encounters an unrecognized extension header is

Both AH and IPIP are well known and recognized extension headers.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Nov 2017 08:26:29 -0700

> Both AH and IPIP are well known and recognized extension headers.

Not to a node that does not have any IPsec code at all (or that has IPsec
turned off).

 On Wed, 1 Nov 2017, Mikael Abrahamsson wrote:

>
>    > If the device isn't configured to do IPsec (even by default), then I don't
>    > think it should do what you describe.
>
> Right. I forgot that IPSEC is an extension header in IPv6, I tought of it as
> something that was encapsulated. So I take back what I said.

No, you were right the first time. Unknown extension headers are not
skipped; they cause the packet to be discarded (see RFC 8200, Sec 4).

Mike Heard

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Nov 2017 17:48:34 +0100 (CET)

> skipped; they cause the packet to be discarded (see RFC 8200, Sec 4).

Sure, but if the device understands IPSEC but has it turned off, what 
should it do?

I don't know.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Nov 2017 22:04:46 +0400

> On Nov 2, 2017, at 8:48 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Sure, but if the device understands IPSEC but has it turned off, what should it do?

It should behave as if it doesn't understand it. In context, it doesn't.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Nov 2017 08:33:51 +1300

>> Both AH and IPIP are well known and recognized extension headers.

AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
RFC8200 doesn't specify what to do with an unrecognized upper-layer header.

    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Nov 2017 13:55:24 -0700

> Sure, but if the device understands IPSEC but has it turned off, what

Presumably, it should behave as if no SPIs were configured. It would the
treat every IPsec packet as if it had an unknown SPI and discard it. Of
course, an IPsec implementation could have an "AH Bypass" option, but that
would be non-standard behaviour.

--cmh

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Nov 2017 14:30:35 -0700

On Thu, Nov 2, 2017 at 12:33 PM, Brian E Carpenter <
[email-masked]> wrote:

> >>     > Not so. An end node that encounters an unrecognized extension
> header
> >> is
> >>

Actually, it does, and the disposition is exactly the same as for an
unrecognzed
extension header. Both come under the heading of ICMP Code 1 ("unrecognized
Next Header type encountered").  See the second paragraph on page 9. Indeed,
it could hardly be done any other way, since it's not possible for a node
to tell
whether an unrecognized Next Header type represents an extension header
or an upper-layer header.

--cmh

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Nov 2017 14:44:29 +1300

> or an upper-layer header.

Yes, that particular elephant stands politely and quietly in the corner
of the room. However, I'd just read the text you cite when I wrote my
message and I'll stick to what I said: we *specify* action for an
unrecognized extension header, but we ignore the elephant and *don't*
specify action for an unrecognized ULP. Consider it a drafting error,
or a design error. I agree with you about the practical effect: an
unexpected IPIP packet is likely to generate ICMP 1 today.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 04 Nov 2017 21:32:29 -0400

Mikael Abrahamsson <[email-masked]> wrote:
    >>> Right. I forgot that IPSEC is an extension header in IPv6, I tought
    >>> of it as something that was encapsulated. So I take back what I said.
    >> 

    > I don't know.

Exactly.
Depends entirely on what "turned off" means.
Probably it means that the SPI# is not configured.
For ESP, dropping the packet makes sense, because you can't decrypt and you
can't know what's "beyond" the ESP without knowing the parameters (so even
ESP_NULL encryption can't be skipped).

But, AH has the property that we *know* it's not encrypted, and we know the
size of everything, and so we can just skip things if the integrity check is
not for us.

If we can gotten that right, we could have used AH for multicasted traffic,
and even for some interesting uses where we want to authenticate that things
went through certain routers.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 04 Nov 2017 21:37:02 -0400

> unexpected IPIP packet is likely to generate ICMP 1 today.

okay, so shouldn't 6463 fix this part at least?

---

From: Tim Chown <[email-masked]>
Date: Mon, 6 Nov 2017 10:30:14 +0000

Hi Michael,

> On 5 Nov 2017, at 01:37, Michael Richardson <[email-masked]> wrote:
> 
> 

The question is whether we add such “gaps” to 6434-bis, or spin up a new draft to update 8200, which might then be reflected in a future Node Reqs update.

I’m easy either way as an author of the doc, but would err towards minimising adding new material to 6434-bis, and trying where possible to just point to existing documents. 

Some input from the chairs would be welcome.

Tim

---

From: Ole Troan <[email-masked]>
Date: Mon, 6 Nov 2017 12:10:52 +0100

Tim,

> Some input from the chairs would be welcome.

If we are talking about the action for unrecognised next headers, I do not see a gap in existing specifications.
If one want to engage in the sport of extreme hair splitting, I wouldn't mind if 6434bis were to add some a descriptive paragraph of "unrecognized next header including ULP are discarded as specified in 8200...".

If we are talking about the issue of IP in IP encapsulated packets sent to a unsuspecting host, that in my opinion requires a new document.

Best regards,
Ole

---

From: Tim Chown <[email-masked]>
Date: Mon, 6 Nov 2017 11:36:34 +0000

> On 6 Nov 2017, at 11:10, Ole Troan <[email-masked]> wrote:
> 
> Tim,
> 

Thanks Ole.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Nov 2017 15:02:14 -0300

> RFC8200 doesn't specify what to do with an unrecognized upper-layer header.

Based on the std, anything that is unknown is an EH. In the context of
RFC8200/FC2460, there's only:

* Known EHs
* Known ULP
* Unknown EHs

with the last one being the default branch :-)

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Nov 2017 15:19:16 -0300

> okay, so shouldn't 6463 fix this part at least?

You can't, unless you close the door to new EHs or to new ULPs. See:
<https://www.ietf.org/archive/id/draft-gont-6man-ipv6-universal-extension-header-02.txt>

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Nov 2017 08:35:03 +1300

Hi Fernando,

> RFC8200/FC2460, there's only:

Yes, that's what the text says but I wish we'd fixed it in 8200 to
acknowledge that there is a 4th case (Unknown ULP) and that it
cannot be distinguished from the 3rd case. Acknowledging that is
much better than ignoring it. I'm happy with Ole's suggestion that
this (and the resulting ICMP 1 behaviour) should be mentioned in
6434bis - as a clarification, not a new invention.

I also agree that there are enough potential issues in unexpected
IPv6-in-IPv6 that is deserves its own draft.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Nov 2017 16:46:38 -0300

>>>> On Thu, Nov 2, 2017, Michael Richardson <[email-masked]> wrote:
[....]
> much better than ignoring it.

In that sense we probably did a bit worse: the merge of RFC6564 seems to
imply a "unified format" helps... but it doesn't.. because if the type
is unknown, you cannot infer the syntax of what's comming next.

> I'm happy with Ole's suggestion that

mmm.. would this RFC8200 (jut curious...)

> IPv6-in-IPv6 that is deserves its own draft.

Agreed. Just curious: why is this "behaviour" nw found to be of
interest? -- I missed this bit (if it was actually mentioned).

Thanks!

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 7 Nov 2017 11:20:14 +0000

Hi,

> On 6 Nov 2017, at 19:35, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Fernando,
> 

This seems a reasonable approach to me.  Would you like to propose text, Brian?

> IPv6-in-IPv6 that is deserves its own draft.

I’d agree. The same with header insertion for that matter. Focus on the issues and how/if they can be mitigated and in which contexts.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Nov 2017 08:29:26 +1300

> This seems a reasonable approach to me.  Would you like to propose text, Brian?

After this:

5.1.  Internet Protocol Version 6 - RFC 8200

   The Internet Protocol Version 6 is specified in [RFC8200].  This
   specification MUST be supported.

   Any unrecognized extension headers or options MUST be processed as
   described in RFC 8200.

insert something like:

   Note that it is impossible for a node to distinguish between an
   unrecognized extension header and an unrecognized upper layer
   protocol. Therefore, a node will behave in the same way for
   either of these cases, in particular by returning an ICMP
   Parameter Problem message with code 1 ("unrecognized Next Header
   type encountered") even for an unrecognized upper layer protocol.

(Protocol 41 is not special in this regard.)

 - Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Nov 2017 18:24:45 -0300

FWIW, I support Brian's proposed text.

On Tuesday, November 7, 2017, Brian E Carpenter <[email-masked]>
wrote:

> >> On 6 Nov 2017, at 19:35, Brian E Carpenter <[email-masked]
> <javascript:;>> wrote:
> >>
> >> Hi Fernando,
> >>
> >>>>> On Thu, Nov 2, 2017, Michael Richardson <[email-masked]
> <javascript:;>> wrote:
> >>>>>
> >>>>>>
> >>>>>> C. M. Heard <[email-masked] <javascript:;>> wrote:
> > I’d agree. The same with header insertion for that matter. Focus on the
> issues and how/if they can be mitigated and in which contexts.
> >
> > Tim
> >
> >>
> >> Regards
> >>   Brian
> >>
> >> [email-masked] <javascript:;>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Nov 2017 10:10:59 -0500

> unrecognized extension header and an unrecognized upper layer

Does "unrecognized" mean unknown to the writer of the code at the time of
writing, or does it mean a header which the node has no support for?

Or to put it in C, what goes into TBD?

retry:
  switch(proto) {
  case IPPROTO_UDP:
       udp_rcv();
       break;
  case IPPROTO_TCP:
       tcp_rcv();
       break;
  case IPPROTO_AH:
       if(ipsec_enabled) ipsec_rcv();
       else TBD;
  case IPPROTO_HOPOPT:
       process_hopopt();
       goto retry;
  case IPPROTO_MOBILITY_HEADER:
       skip_hopopt();
       goto retry;
  default:
       return_icmp(1);
  }

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Nov 2017 08:15:50 +1300

> writing, or does it mean a header which the node has no support for?

I think it means unrecognized at run time, regardless of whether it was
known or unknown when the code was written, or configured on or off when
the node was instantiated, or even configured off one microsecond before
the packet arrived. So TBD would be return_icmp(1) in your case.

IMHO.

     Brian

---

From: Bob Hinden <[email-masked]>
Date: Sun, 12 Nov 2017 10:50:07 +0800

I went back and looked at the RFC8200 text that deals with header insertion.  It does not actually mention IPIP.  The published text in Section 4. "IPv6 Extension Headers" regarding header insertion is:

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

Some earlier drafts include IPIP as a way of inserting headers, but that wasn’t included in what became RFC8200.

Bob

> On Nov 9, 2017, at 3:15 AM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Sun, 12 Nov 2017 14:52:35 +0800

Hi, Bob,

> Some earlier drafts include IPIP as a way of inserting headers, but that wasn’t included in what became RFC8200.

Does IPIP simply mean tunelling IP over IP?

If so, that'd be tunneling, rather than "header insertion".

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Nov 2017 12:55:46 +1300

> If so, that'd be tunneling, rather than "header insertion".

Yes, but the point was to say that this is a valid way to attach extra
headers. And iirc we concluded that while true, it isn't necessary
to write it down.

(Also there's a proposed standard for this if you need it: RFC2473.)

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Nov 2017 10:34:52 +0800

> (Also there's a proposed standard for this if you need it: RFC2473.)

Agreed. If you create a new packet... "your packet, your headers"..

---

From: Tim Chown <[email-masked]>
Date: Mon, 13 Nov 2017 16:15:43 +0000

> On 7 Nov 2017, at 19:29, Brian E Carpenter <[email-masked]> wrote:
> 

This is the text TimW will present in 6man; it seems fine to me, and hopefully we’ll have consensus.

Tim