Subject: FW: I-D Action: draft-baker-6man-hbh-header-handling-00.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 4 Jun 2015 11:23:23 +0000

I'd appreciate any comments folks have on this. It in part addresses the issues that are being raised in v6ops about extension headers being an attack vector, and in part looks at the manipulation of headers in flight in ways that 2460 didn't envisage. In any event, it is a proposed update to 2460.
________________________________________
From: I-D-Announce [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Thursday, June 04, 2015 4:17 AM
To: [email-masked]
Subject: I-D Action: draft-baker-6man-hbh-header-handling-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : IPv6 Hop-by-Hop Header Handling
        Author          : Fred Baker
        Filename        : draft-baker-6man-hbh-header-handling-00.txt
        Pages           : 6
        Date            : 2015-06-04

Abstract:
   This note updates the IPv6 Specification (RFC 2460), specifically
   commenting on the Hop-by-Hop Options Header (section 4.3) and option
   format and handling (section 4.2).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-baker-6man-hbh-header-handling/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-baker-6man-hbh-header-handling-00

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Havard Eidnes <[email-masked]>
Date: Fri, 05 Jun 2015 17:39:52 +0200 (CEST)

>         Filename        : draft-baker-6man-hbh-header-handling-00.txt

A) Wrt. this part of section 2.1:

   While this is not true of older hardware, modern hardware (which is
   to say, microcode) is capable of parsing the Extension Header chain,

So we need to shell out for new hardware *again*?
Is this moving the goal post?

B) This part of section 2.1 seems overly complex, and the way I
read it it uses "MUST" in a highly non-intuitive way:

   More generally, in routers that implement a fast path, the processing
   of the Hop-by-Hop Extension Header (which must be performed by every
   router a packet transits) MUST be performed in the fast path unless
   there is a specific reason to punt to a slower path, including that
   corresponding software exists in the implementation and is configured
   to process the option.

Why can't this just be

   More generally, in routers that implement a fast path, the processing
   of the Hop-by-Hop Extension Header (which must be performed by every
   router a packet transits) SHOULD be performed in the fast path.

Regards,

- Håvard

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 5 Jun 2015 17:03:16 +0000

> On Jun 5, 2015, at 8:39 AM, Havard Eidnes <[email-masked]> wrote:
> 

It is what it is. I'm not going to apologize for the designer of the hardware using what s/he had available at the time it was designed and working against requirements as they existed at the time.

The way I see it: if the operators think that punting a packet to software is an attack vector (which is what they are saying in v6ops, and I'm not sure I disagree), then we have to find a way to not punt packets. The IETF has two options: deprecate the HBH header, or describe a way to implement it in the fast path.

A side point: I wince a little every time someone says "in hardware". The hardware runs microcode in a controller of some kind; it's not like it's a sea of gates. I'd rather say "in microcode" or "in the fast path".

>   router a packet transits) SHOULD be performed in the fast path.

That's where I started out, and got comments from Joe Abley saying I SHOULD use the word MUST. It's all his fault :-)

I think the issue of the reasons to punt to the slow path are important. Part of that is things like the Vietnamese government requirements on IPv6 implementation, which I saw a draft of recently (and pointed at RIPE 554), which got all screwed up when they saw a SHOULD. I'm worried that the correct interpretation will be deemed to be "MUST NOT PUNT". I'm OK with something being configured to punt when someone actually wants it to, and required to ignore the option (e.g., 001XXXXX option type) in other cases in which they can't deal with it.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 05 Jun 2015 15:04:50 -0300

On 06/05/2015 02:03 PM, Fred Baker (fred) wrote:
>> More generally, in routers that implement a fast path, the
>> processing of the Hop-by-Hop Extension Header (which must be
>> performed by every router a packet transits) MUST be performed in
>> the fast path unless there is a specific reason to punt to a slower
>> path, including that corresponding software exists in the
>> implementation and is configured to process the option.
>> 
>> Why can't this just be
>> 
>> More generally, in routers that implement a fast path, the
>> processing of the Hop-by-Hop Extension Header (which must be
>> performed by every router a packet transits) SHOULD be performed in
>> the fast path.
> 
> That's where I started out, and got comments from Joe Abley saying I
> SHOULD use the word MUST. It's all his fault :-)

I guess (only half-joking?) that if this is a SHOULD, then vendors could
have "hardware constraints" as a valid reason to go against this
recommendation?

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 5 Jun 2015 20:22:25 +0000

> On Jun 5, 2015, at 11:04 AM, Fernando Gont <[email-masked]> wrote:
> 

That's not a joking matter.

> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.

In Fred-speak, MUST means "if you don't do this, something will break", and I like to say what will break. SHOULD means "I'd like to say 'MUST', but I can think of a case in which it might be the wrong answer, or at least can't prove to myself that it is never the wrong answer". When an implementor decides to not do a SHOULD, I'd like to see their online documentation say why they chose to not do it, and if not that, I'd like them to be able to respond sensibly to the question.

I can tell you why the 7600 chose to punt HBH headers. In 2006, the technology available wasn't what we have today. The design had a packet go through a sequence of micro controllers that were horizontally encoded - the microcode essentially "writes hardware", including scheduling reads and writes and all that. Each stage took a stated period of time, no more and no less. Something that could not be defined in terms of the amount of time it would take couldn't be handled in that hardware. Something that could be defined but took more time than the defined quantum had to have its own pipeline stage, and there are a finite number of pipeline stages. In 2006, we couldn't say what the market would require when IPv6 finally took off. The engineer chose to punt the question, and with it, packets with HBH headers.

BTW, people moan and groan about TCAMs being only 64 bits wide and therefore not being able to handle a /128 on a single read. The reason is the same. Statistically, the vast majority of accesses we were seeing were 64 bits or shorter, and the hit of a second TCAM read was acceptable. The alternative was to double the cost of the TCAM.

It's an engineering decision. We're all engineers. We understand engineering decisions.

---

From: Havard Eidnes <[email-masked]>
Date: Sat, 06 Jun 2015 00:31:31 +0200 (CEST)

> SHOULD use the word MUST. It's all his fault :-)

:)

My concern is that the "unless there is a specific reason" clause is
widely open-ended, and can be used for nearly "any specific reason"
including "the hardware design we chose to use makes this impossible",
thereby essentially voiding the 2119 definition of MUST, to wit:

So either the MUST stays, and the weasel-out path needs to be closed,
or this is a SHOULD.

Regards,

- Håvard

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Jun 2015 13:22:48 +1200

>> On Jun 5, 2015, at 8:39 AM, Havard Eidnes <[email-masked]> wrote:
...
> That's where I started out, and got comments from Joe Abley saying I SHOULD use the word MUST. It's all his fault :-)

IMHO, the real problem in either version of this text is the lower-case "must"
inside the parenthesis.

Now I know from private email that Fred disagrees with what I am about to
write, but the current IETF consensus on this point is in RFC 7045, which
already updates RFC 2460:

2.2.  Hop-by-Hop Options

   The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.  Designers
   planning to use a hop-by-hop option need to be aware of this likely
   behaviour.

So, a process point is that Fred's draft would need to say
"Updates: 2460, 7045 (if approved)" and a few corresponding words
in the text. But substantively, I don't agree with Fred's proposal.
Even if some routers are replaced by new ones that handle HbH on
the fast path (i.e. at or close to line speed) there will be many
others that either kick it to the slow path or punt it completely.
I do not believe we should encourage people designing HbH options
to believe otherwise.

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 6 Jun 2015 01:50:03 +0000

> On Jun 5, 2015, at 3:31 PM, Havard Eidnes <[email-masked]> wrote:
> 

Two subjects. MUST implement, and if it is readily implemented in microcode, MUST implement in microcode. A Router Alert, by definition, punts to the software path. My assertion: it should only do so if there is software implemented to punt it to, and the software is configured to expect the punt. Given that a Router Alert, by definition, punts to the software path, I'm not sure how to implement that in microcode.

Tell me how to say that.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 6 Jun 2015 02:08:53 +0000

> On Jun 5, 2015, at 6:22 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> in the text.

That I can do if you wish. You didn't say that in the private email, just pointed at 7045 :-)

> But substantively, I don't agree with Fred's proposal.

My problem with that is that it means that I cannot ever make a change of any kind, because I cannot simultaneously upgrade the entire Internet. Those handcuffs are too tight.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Jun 2015 15:01:08 +1200

Hi Fred,

> That I can do if you wish. You didn't say that in the private email, just pointed at 7045 :-)

Correct, because I only noticed that point today. Really, the statement in
7045 is an operational warning about pre-draft-baker-6man-hbh-header-handling
devices.

> My problem with that is that it means that I cannot ever make a change of any kind, because I cannot simultaneously upgrade the entire Internet. Those handcuffs are too tight.

I know. I really don't have a fix to propose. At the very least,
a section on co-existence with older routers would seem necessary
(and I would claim that the words in RFC 7045 will remain true for them).

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 6 Jun 2015 03:37:22 +0000

> On Jun 5, 2015, at 8:01 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Is the following a reasonable start?

***************
*** 18,23 ****
--- 18,29 ----

+    It also updates RFC 7045, which accepts RFC 2460 as delivered on
+    tables of stone, immutable, and yet broken.  This, of course, is a
+    profoundly unacceptable regard for any specification.
+
+    It tries to address the issue.
+
  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
***************
*** 186,196 ****
     check, and as a result the packet restored to its state as originally
     sent.

! 3.  IANA Considerations

     This memo asks the IANA for no new parameters.

! 4.  Security Considerations

     In general, modification of a datagram in transit is considered very
     closely from the viewpoint of the End-to-End Principle, which in this
--- 193,232 ----
     check, and as a result the packet restored to its state as originally
     sent.

! 3.  Interoperation with RFC 2460
!
!    There are four possible modes of interaction with routers that don't
!    implement the Hop-By-Hop Option in the fast path:
!
!    1.  Presume that they cannot handle the Hop-By-Hop option at close to
!        wire speed, and that's OK.
!
!    2.  Presume that they will drop traffic containing Hop-By-Hop
!        options.
!
!    3.  Presume that they can handle the Hop-By-Hop option at or close to
!        wire speed, and are configured to do so.
!
!    4.  Presume that they don't exist, perhaps because older routers are
!        configured to ignore all Hop-by-Hop options.
!
!    If the first model actually works in a given network, it may be
!    acceptable in that domain.  It is not a model that will work in the
!    general Internet, however.
!
!    The second model (which is most probable at this writing) is a
!    description of the general Internet in 2015.
!
!    The third and fourth models, if applicable in a given context, are
!    what one might hope for.  Vendors are in a position to either have an
!    option to ignore the Hop-By-Hop header in older equipment, or add
!    such an option in upgraded software.
!
! 4.  IANA Considerations

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Jun 2015 15:56:55 +1200

> Is the following a reasonable start?

Well, I think that is unfair, frankly. 7045 points out that the emperor
often has no clothes, and changes the law from "the emperor MUST wear clothes"
to "the emperor SHOULD wear clothes, but don't assume that he will do so".

What would seem fair is something like:

It also updates RFC 7045, which noted that RFC 2460 is widely violated
in this respect, but merely legitimized this situation with a SHOULD.
The present document tries to address the issue more fundamentally.

...

> ! 3.  Interoperation with RFC 2460

Yes, this seems basically correct.

     Brian