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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

> Am 13.04.2017 um 11:40 schrieb [e-mail]:
> 
> Hi Mirja,
> 
>>> 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.
> 
> Ack, and you can define new hop by hop options, as long as you are aware that with the new behaviour only nodes configured to process them will. And it is in general though to make expectations of these options being processed across administrative boundaries.

The draft says:

"New hop-by-hop options are not recommended because nodes may be
   configured to ignore the Hop-by-Hop Option header, drop packets
   containing a hop-by-hop header, or assign packets containing a hop-
   by-hop header to a slow processing path. Designers considering
   defining new hop-by-hop options need to be aware of this likely
   behaviour.“

Now I as a designer am aware that there are problems with HBH option and it might put my traffic on the slow path. I decide that I can’t risk that because that would downgrade the QoS and make my service unusable and I can’t even risk that because I would immediately lose costumers. However, I would like to signal something to midddleboxes that support this new fancy QoS mechanism that makes my service better. What should I do?

> 
>>> 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.
> 
> It has a somewhat higher drop probability but it is not unusable.

Congestion control reacts to drop, thus you’ll get a very low throughput. Yes you still have connectivity, but I would call this unusable.

> When implementations are updated with the new behaviour then the hope is that it will become more usable.

Yes, but that will take a very long time and I can never be sure that I might not hit an old box somewhere on the path.

> 
>>> 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.
>> 
> 
> Exactly.
> 
>>>> 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.
> 
> A destination option would be the wrong thing to use. That violates the premise for how this option is used.
> If you only want a certain set of nodes along a path to process the header, that is the behaviour you will now get with HBH.
> An alternative is to use source routing with the routing header combined with a destination options header.
> 
> Just using the destination header for this is inefficient and is really a "give up" choice, where you end up requiring all routers to go and hunt for "interesting" options.

I know but it WAS done because it was the only usable approach, see https://datatracker.ietf.org/doc/rfc7837/

Source routing is not an option here because the sender is not aware of the box on the path.

> 
>>>> 
>>>> 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.
> 
> HBH or RH also lets you do that. Note that destination options also has a higher drop probability than packets with extension headers.

I aware of this but it’s still better than HBH.

> 
>>>> ----------------------------------------------------------------------
>>>> 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.
> 
> I do see your point. Is this behaviour described somewhere else?

There is an RFC on ECN for tunneling https://tools.ietf.org/html/rfc6040
I don’t think there is anything on fragmentation specifically.

> 
> Best regards,
> Ole