Re: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

[Bob Hinden <[e-mail]>]

Mirja,

> On Apr 12, 2017, at 2:48 PM, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> 
> Hi Ole,
> 
> see below.
> 
>> Am 12.04.2017 um 22:35 schrieb [e-mail]:
>> 
>> Mirja,
>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> My discuss is mainly on text in section 4.8 (also based on the tsv-art
>>> review -> Thanks Martin!):
>> 
>> See also Bob's response to Maritn.
>> 
>>> 
>>> I find the recommendation to basically just not use hop-by-hop headers in
>>> section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't it
>>> be maybe time to just deprecate the current hop-by-hop number an assign a
>>> new one? I know that also has deployment problem but maybe it's worth a
>>> try. I guess the assignment could happen in a new document though, but
>>> the deprecation could be done here.
>> 
>> The Hop-by-Hop header (HBH) is a container option. It has the protocol value 0, and has to be first in the header chain, so to make it efficient for routers to check for it's presence.
> 
> Sorry, I meant hop-by-hop option in this case.
>> 
>> RFC2460 has:
>> The Hop-by-Hop Options header is used to carry optional information
>>  that must be examined by every node along a packet's delivery path.
>> 
>> The problem with this was that implementations ended up punting packets with the HBH to software, essentially opening up for a DOS attack, which again led operators to filtering out packets with the HBH == 0.
>> (While at the same time there were no HBH options with cross Internet significance).
>> 
>> How the HBH option could be saved has been discussed for quite some time in the 6MAN working group.
>> Including a draft: https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03
>> Which conclusion got included into 2460bis.
>> 
>> The working group thought it premature to deprecate the HBH option header.
>> As a way to "rescue" the HBH option we have made one significant change:
>> 
>> NOTE: While [RFC2460] required that all nodes must examine and
>> process the Hop-by-Hop Options header, it is now expected that nodes
>> along a packet's delivery path only examine and process the Hop-by-
>> Hop Options header if explicitly configured to do so.
>> 
>> Which means by default routers unless they have been configured to process a particular option contained in an HBH option, shall forward the packet as normal. Thereby rectifying the attack vector.
> 
> I’ve see this change and it’s a step in the right direction but it doesn’t solve the problem given there are already deployment that still put packets with an hop-by-hop header on the slow path which still renders the hop-by-hop header as currently defined unusable.
> 
>> 
>> What we lose by this approach is that one cannot use mandatory options anymore. I.e. options that MUST be processed by every router along the packet's path. RFC2675 for example is a mechanism depending on that. In our view this is not a problem, since routers with links with MTU larger than 64K would have to be configured and would be within a controlled domain anyhow.
> 
> Yes, I also don’t see that as a problem. It’s anyway always hard to ensure that something is process by every hop. Not sure that would have been achievable in reality every.
> 
>> 
>>> 
>>> This related to this comment from Martin's review, also proposing a
>>> potential way forward:
>>> "- Section 4.8. "Defining New Extension Headers and Options":
>>> It says new hop-by-hop headers must never ever defined. This is
>>> problematic, as this closing the door forever, even if future instances
>>> of the IETF do would like to wish to define new hop-by-hop headers. A
>>> better way would have to say "that new hop-by-hop headers must have IETF
>>> consensus".
>> 
>> Yes, the door for a new HBH option header container is closed.
>> Given that this is the signal that every router has to check.
>> Given that this is a container option one can put whatever one likes into the existing HBH options header, so it would be hard to see the use case for a new one.
>> 
>>> - Section 4.8. "Defining New Extension Headers and Options":
>>> Also the „not recommended“ to define new extension headers looks strange,
>>> especially with the phrase "There has to be a very clear justification".
>>> The term "clear justification" is not an exact engineering specification.
>>> Why not using "technical protocol specification and real word use case
>>> required, plus IETF consensus"?"
>> 
>>  Defining new IPv6 extension headers is not recommended.  There has to
>>  be a very clear justification why any new extension header is needed
>>  before it is standardized.
>> 
>> The text does state "standardized" though.
>> 
>> Just to remind you that the Destination options header, the HBH options header and the Routing header are all container options, which allows for arbitrary number of TLVs inside. Since extension headers share the numbering space with upper layer protocols, defining new ones would require all implementations parsing header chains (e.g. to do packet filtering on transport headers) would have to be updated. This is the reason for the strict restriction on adding new ones.
> 
> See my response to Mike’s reply to Martin’s review: I think what you better should say is that it is recommended to use a destination option, if suitable, rather than a new header. I don’t think you need to anything else than this about new headers.

As it says in Section 4.8:

   Defining new IPv6 extension headers is not recommended.  There has to
   be a very clear justification why any new extension header is needed
   before it is standardized.  Instead of defining new Extension
   Headers, it is recommended that the Destination Options header is
   used to carry optional information that must be examined only by a
   packet's destination node(s), because they provide better handling
   and backward compatibility.


> 
>> 
>>> 
>>> As a side note, there is at least one experimental RFC that defines a
>>> destination option to be inspected by a network device, given the know
>>> problems of hop-by-hop option which renders them unusable.
>> 
>> Right, that's a much more costly way of doing it, given that routers would now have to go and hunt for the particular sub option. This also violates RFC2460. And this would obviously neither achieve hop by hop behaviour.
> 
> It’s very costly but unfortunately currently the only way to achieve that at all. Given that this experimental option is intended to be inspected by only a few nodes on the path (not all) and usually these nodes are close the edge, it’s probably still doable.

> 
>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> One question because I'm not sure if I interpret this correct to make it
>>> part of my discuss:
>>> Section 4.5: "The number and content of the headers preceding the
>>> Fragment
>>>    header of different fragments of the same original packet may
>>>    differ.  Whatever headers are present, preceding the Fragment
>>>    header in each fragment packet, are processed when the packets
>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>    those headers in the Offset zero fragment packet are retained in
>>>    the reassembled packet."
>>> Does this mean the ECN codepoint (part of the Traffic Class field) is
>>> copied from the first fragment? This doesn't seem to be correct, however,
>>> also not sure what the correct answer is. I know this was not changed in
>>> this revision but maybe we can still get this right.
>> 
>> When fragments are created most of the fields are copied from the IPv6 headers (e.g., Source Address, Destination address, flow label, traffic class, hop limit).  Some like payload length, next header, and hop limit are modified.
>> 
>> If I understand your question, the answer is yes, the ECN code point is copied from the first fragment, but should be the same from all of the fragments.
> 
> My concern is that the ECN code point could be changed on one of the fragmented packets to signal congestion of a intermediate node and then when you reassemble this information gets lost. That seems wrong.

That is an interesting idea, but I think out of scope for advancing this document to Internet Standard.  Then there is the question of how to encode n of m fragments experienced congestion.  Interesting future work.

Thanks,
Bob