[IPv6] Fwd: Feedback on draft-ietf-6man-hbh-processing

[Gorry Fairhurst <[e-mail]>]

Hi Fenando,

*B&G: Thanks, we appreciate the careful read and the feedback, see below.

Begin forwarded message:

Hi, Bob & Gorry,

I've read the latest version of the I-D, and feel that the problem 
statement and challenges discussion are in good shape.


However, I have concerns about the solution being proposed:

*** Say I want to use HBH. What may I expect from the network? -- if all 
bets are off, then I have to assume the least common denominator (i.e., 
packets dropped). So it would seem to me that, whether we like it or 
not, things boil down to:

a) limited domains
b) the  Internet

For a), one may assume you control all routers and not care about 
defaults. For b), not sure whatever we say here or elsewhere won't 
probably result in changes.

*B&G: We think this is out of scope of this document. We can only try to 
imrpove deployment. (Making a position statment in an RFC seems only to 
possibly reduce the possible deployment of a protocol.)

*** Section 5.1
> 5.1.  Processing the Extension Header Carrying Hop-by-Hop Options

Title of this section seems ot have same semantics as that "5.2. 
Hop-by-Hop Options Processing". In any case, both sections cover 
processing of the HbHO header -- maybe disambiguate the two somehow?

*B&G: So, one is about the EH; and one is about the Options within the 
frame. We will try to make these subtitles clearer. This will be in the 
next rev.

>   When a packet includes one or more Extension Headers, the Next Header
>   field of the IPv6 Header does not identify the transport protocol.
>   The Extension Header used to carry Hop-by-Hop options is defined in
>   Section 4.3 of [RFC8200] and is identified by a Next Header value of
>   0 in the IPv6 header.  Section 4.1 of [RFC8200] requires this Hop-by-
>   Hop Options header to appear immediately after the IPv6 header.
>   [RFC8200] also requires that a Hop-by-Hop Options header can only
>   appear once in a packet.
>   The Hop-by-Hop Options Header as defined in [RFC8200] can contain one
>   or more Hop-by-Hop options.  This document updates [RFC8200]:
>   Routers SHOULD process the Hop-by-Hop Options header using the method
>   defined in this document.

This last sentence seems to be a new requirement. However, the previous 
paragraphs are not. I would probably split the summary of existing reqs 
vs the new reqs. -- That said, if this document updates RFC8200, then 
you probably don't need this last sentence.

*B&G: Thanks, helpful, we agree, the para does include two types of 
text. We will review and break into two paras in the next rev.

>   If a router does not process the Hop-by-
>   Hop Options header, it MUST forward the packet normally based on the
>   remaining Extension Header after the Hop-by-Hop option (i.e., a
>   router MUST NOT drop a packet solely because it contains an Extension
>   Header carrying Hop-by-Hop options).
>

The second sentence should probably be amended as "a router MUST NOT, by 
default, drop..." -- at the end of the day, non-defualt behavior is 
operational policy.

*B&G: The word "solely" was introduced to mean "only for that reason", 
we don't think this needs a change.

>   A configuration could control
>   that normal processing skips any or all of the Hop-by-Hop options
>   carried in the Hop-by-Hop Options header.
>   It is expected that the Hop-by-Hop Options header will be processed
>   by the Destination.  Hosts SHOULD process the Hop-by-Hop Options
>   header in received packets.

I assessment this was kind of a MUST before? If it's a SHOULD, then:
  + what would be the reasons for not processing them?
  + if I cannot even rely hosts to procesess HBH (assuming I'm lucky
    enough that packets do get there)...  should I really bother trying
    to use HBH?

*B&G:  True. This is in the host section and we could add an example for 
not following the should - such as a constrained device, we will add 
this text in the next rev.

*** Section 5.1.1:
> 5.1.1.  Configuration Enabling Hop-by-Hop Header Processing
>   Section 4 of [RFC8200] allows a router to control its processing of
>   IPv6 Hop-by-Hop options by local configuration.  The text is:
>      NOTE: While [RFC2460] required that all nodes must examine and
>      process the Hop-by-Hop Options header, it is now expected that
>      nodes along the path only examine and process the Hop-by-Hop
>      Options header if explicitly configured to do so.
>   A configuration could control whether processing skips any specific
>   Hop-by-Hop options carried in the Hop-by-Hop Options header.  A
>   router that does not process the contents of the Hop-by-Hop Options
>   header does not therefore process the identifiers of individual
>   Option Types to perform any specified action.

Is there a change being introduced here?

*B&G : Thanks, this is a helpful feedback. The draft is intended to 
clarify the current after the words "A configuration...", We propose to 
divide the text and create a new para that starts: "This document 
clarifies that a configuration..."

*** Section 5.2
>   A Source creating packets with a Hop-by-Hop Options header SHOULD use
>   a method that is robust to network nodes processing only the first
>   Hop-by-Hop option that is included in the packet, or that forward
>   packets without the option being processed (see Section 6.1).  A
>   Source MAY, based on local configuration, include more than one Hop-
>   by-Hop option [I-D.ietf-6man-eh-limits], but might wish to restrict
>   the size to increase the likelihood of successful transfer across a
>   network path.

There's a number of things here: the text seems to implicitly assume 
that packets with a single HBH are reliable... but they really aren't.

*B&G: We don't understand the problem - this isn't the assumption, we 
understand the word "robust" to mean something other than "reliable", is 
there a need to change this text?

Also, if, when sending packets with HBH options you may get any dynamic 
random combination of

  * all options are processed
  * all options are ignored
  * some options are processed and some ignored, based on their order
  * packets are dropped

*B&G: These are all possible, and we think this is possible, does that 
understanding change the text?
> ... I don't want to be pessimistic, but... could one really come up 
> with a valid use case out of this situation?

*B&G : You seem to give a worse-case-scenario that is pessimistic. The 
purpose of the document is to allow people to improve the situation.
Also, the text seems to suggest that one may either:
a) include a single option, OR,
b) include multiple options, but limit their size

But I would argue that even if you do a), you still need to care about 
the size of that single option. The longer the option, the higher the 
chances of the packet being dropped.

*B&G: This I-D does don’t discuss size (there is another draft that 
could give that advice for an EH (but see later)

*** Section 5.2.:
>   A router MUST NOT be configured to support the Hop-by-Hop Option
>   header if it cannot process the first Hop-by-Hop option at full
>   forwarding rate.

This requirement, as phrased, is problematic: there is probably going to 
be a difference between the router's ability to process a packet with, 
say 8 bytes of options vs 1K of options.

*B&G: If the router is configured to support an Option, it will surely 
know the format, and could have used that to decide if it were to 
support it.

*** Section 5.2
>   This document modifies this behaviour for the "01", "10", and "11"
>   action bits, so that if a router is unable to process any Hop-by-Hop
>   option (or is not configured to do so), it SHOULD behave in the way
>   specified for an unrecognized Option Type when the action bits were
>   set to "00".  It also modifies the behaviour for the "10" and "11"
>   values such if the packet is discarded the node MAY send an ICMP
>   Parameter Problem, Code 2, message to the packet's Source Address,
>   pointing to the unrecognized Option Type.
If a router is not configured to process any HBH options, maybe it's 
best to simply skip the HBH header?
*B&G: We agree. A section says that. Do we need to modify the text?

*** Section 5.2.2
> 5.2.2.  Configuration of Hop-by-Hop Option Processing
>   A router can be configured to process a specific Option.  A possible
>   approach to implementing this is to maintain a lookup table based on
>   Option Type of the IPv6 options that can be processed at full
>   forwarding rate.  This would allow a router to quickly determine if
>   an option is supported and can be processed.  If the option is not
>   supported, then the router processes the option as described in
>   Section 5.1 of this document.
>   The actions of the lookup table SHOULD be configurable by the
>   operator of the router.
>
> Upon reading this section, I get the feeling that this section is a 
> mix of two things:
> * feature for the operator to pick which options to process
> * internal implementation detail for the router to quickly learn if
>   an option can be processed on the fast path

*B&G:  Yes, we agree, this text could be split.

*** Section 6.1
> 6.1.  Example of Robust Usage
>   Recent measurement surveys (e.g., [Cus23a]) show that packets that
>   include Extension Headers can cause the packets to be dropped by some
>   Internet paths.  In a controlled domain, routers can be configured or
>   updated to provide support for any required Hop-by-Hop options.

This is tricky. If the user of the option is some network function, then 
you probably don't have a mechanism to "test whether the option works" 
(as in e.g. TCP's "try with ECN enabled, and if things don't work, try 
disabling ECN").  OTOH, if the user is an application, would an actual 
app really be interested in signaling stuff to specific paths of the 
network path?

*B&G: This is an example that shows one type of use - when the stack 
wishes to add some network layer info and can see if the change is 
proposed was acceptable. Have you a specific suggestion of extra 
examples/text?

*** Section 8, Sec Cons
>   This document changes the way the Hop-by-Hop Options header is
>   processed in several ways that significantly reduce the attack
>   surface.  These changes include:
>   *  All Hop-by-Hop options (with one exception) must be processed at
>      full forwarding rate.  The first Hop-by-Hop option MUST be
>      processed and additional Hop-by-Hop options MAY be processed based
>      on local configuration.

This seems confusing. All options are required to be processed at full 
forwarding rate? Or just the fist one?

*B&G: "All" can be misread, sorry. We will try to dix in trghe next 
revision.

*B&G: True at least in some cases, although this is the same as another 
comment.
>   *  The document limited the default number of Hop-by-Hop options that
>      can be included in a packet to a single Hop-by-Hop option.

In a lot of implementations, what matters is the actual EH size rather 
than the number of options within that header.

*B&G: Certainly it seems plausible some implementations limit the EH 
size, others might worry about the cost of processing others the entire 
EH Chain size. Measurements seem to indicate this is true (or the total 
EH Chain size in some cases) for some devices, we will add something to 
the background to refer to one recent analysis that shows this.

> To quite some extent, the problem at hand seems to be a lot like a cat 
> that's has been out of the box for way too long already...  :-(

*B&G: IPv6 deployments are continuing and evolving, and the intention is 
to help the situation.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494


*B&G : We plan to make a new revision to address the topics above.

Thanks again,

Bob & Gorry