Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01

[Gorry Fairhurst <[e-mail]>]

See below

On 03/12/2020 10:57, Fernando Gont wrote:
> Hi, Gorry!
>
> On 3/12/20 05:32, Gorry Fairhurst wrote:
>> HI, I think we are converging...
>
> Indeed!
>
>
> [....]
>>>>>> * On the measurement evidence: I have a slight concern that the 
>>>>>> results might not cover the wide variety of use cases and you may 
>>>>>> like to be more careful in the words you use to generalise these 
>>>>>> for the "internet".  I think we should be aware that in some 
>>>>>> scenarios an EH might still be effectively used, where path can 
>>>>>> safely support this.
>>>>>
>>>>> We're targeting the general case here. As they say, "with 
>>>>> sufficient thrust, pigs fly just fine". You can, of course, build 
>>>>> a network where EHs can be used just fine. -- but what we're 
>>>>> discussing is the general case.
>>>>>
>>>> Why? - as a transport guy, the only thing that matters is whether a 
>>>> specific path supports them, the average case just tells me whether 
>>>> I need a fallback mechanism to cope with a particular path not 
>>>> supporting;-)
>>>
>>> The evil comment would be that, as a transport guy, you don't 
>>> control the path. Or, furthermore, there's no concept of "path" for 
>>> a transport guy ;-)
>>>
>> We do have the notion of a path... but it may be that is different to 
>> your notion.
>
> For curiosity sake: what would be that notion?  It would seem to me 
> that, if anything, the transport view of a path is kind of single-hop 
> with varying properties.  As opposed to e.g. multiple ways to get to 
> the same destination.
>
> i.e., internet-layer could find a working path, where transport cannot.
>
The transport can sometimes choose between paths it sees available.

Most of the concern of the transport is to characterise the current 
actual path(s) - discovering the PMTU - i.e. the largest size of packet 
are not forwarded, discovering if certain headers are not forwarded, 
often trying to determine the current capacity, rtt, jitter, reordering, 
etc. Possibly trying to associate QoS or other information with packets 
in a flow to influence the network path. etc.

>
>>>>> Some additional comments/questions based on the PDF you've attached:
>>>>>
>>>>>> However, common implementation limitations suggest
>>>>>> that EHs present a challenge for IPv6 packet routing equipment and
>>>>>> middle-boxes, and evidence exists that IPv6 packets with EHs have 
>>>>>> been
>>>>>
>>>>> Doesn't this imply that this is no longer the case? (i.e. your 
>>>>> proposed change is "have been")
>>>>>
>>>>>
>>>> /have been/are/ ... if that makes better sense to you, they're 
>>>> equivalent to me - you observe what has happens and you can predict 
>>>> what is happening, you might now know the future.
>>>
>>> What I mean is that we're not referring to the occurence of some 
>>> event in the past, but rather about something that is still the case.
>>>
>> Sure, why not write this is still the case?
>
> s/may be/are/?
>
>
Fine with me.
>
>>>>>> As layer-4 port
>>>>>> information increases the entropy of the hash, it is normally highly
>>>>>> desirable to use it where possible.
>>>>>>>>> I don’t agree with that actually, - but maybe others think so, 
>>>>>>>>> please check
>>>>>>>>> RFCs relating to ECMP or perhaps rephrase, something like: 
>>>>>>>>> /Layer-4 port
>>>>>> information can increase the entropy of the hash, and is often
>>>>>> thought desirable to use it where it is available.
>>>>>> /?
>>>>>
>>>>> Your suggested change seems fine to me. That said, what would you 
>>>>> employ for the hash if not the ports?
>>>>>
>>>> flow label?
>>>
>>> The thing is that you cannot rely on it. So, if you want entropy, 
>>> your safe bet is to use the port numbers....
>>>
>> OK, but I still do not understand why this particular RFC-to-be would 
>> make a judgment on this issue, it is not related to EH, the desire of 
>> some devices to look for transport headers is irrefutable. This 
>> happens for various reasons of which this is one. There are other 
>> things that happen also - but in the context of this document, the 
>> text can be entirely neutral as to whether this is good or bad practice.
>
> I'll apply the suggested edit unless I hear otherwise from the 
> group/co-authors.
>
> FWIW, the only thing that were meaning was "Yes, we know folks are 
> supposed to use the FL for that... but that's not feasible... hence 
> the *need* to look up the port numbers"
>
>
>
>
>>>>>> We note that in the IPv6 world, flows are expected to be identified
>>>>>> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based
>>>>>> Load-Sharing is possible without the need to process the entire
>>>>>>>>> why /would be possible/ ... some networks do this, and many 
>>>>>>>>> RFCs encourage this?
>>>>>
>>>>> Support for the FL is not widely deployed and implemented (see 
>>>>> [Cunha-2020])
>>>>>
>>>> Yes I looked at Cunha - it's just a slide deck - is there a paper 
>>>> that can be read to check the measurement methodology and results?
>>>
>>> There's also a paper -- my apologies for not referencing it. I will 
>>> check if it's online, and otherwise ask the author for permission to 
>>> share it.
>>>
>> That would help a lot to read that.
>
> I've asked for permission to share. Worst-case scenario, I'll send it 
> unicast.
>
>
Look foward to learning more.
>
>
>>>> I hear others saying that it is now more often being set, ... so 
>>>> I'm just urging caution here, because I am not sure v6OPS need to 
>>>> comment on the results of this on-going work at this stage. For 
>>>> instance... what is the chance that a router now observes a flow 
>>>> label set to non-zero? ...
>>>
>>> It's not only to have a non-zero FL, but also that the FL is set 
>>> correctly -- e.g., some implementations used to employ one FL value 
>>> during 3WHS, and another during the life of a connection. Thus, if 
>>> you were using the FL for load-sharing, it would actually break things.
>>>
>>> FWIW, I wish the FL was widely and correctly implemented and 
>>> deployed -- I'm just the messenger here.
>>>
>> So, I'm urging that the message is represented as saying that at the 
>> time of publication, load-sharing and other techniques utilise the 
>> transport header information [REF]. To access this information, a 
>> router need to process the EH chain, and this leads to issues ... as 
>> you decribe.
>
> Would this be addressed by:
>
> OLD:
> As layer-4 port
>    information increases the entropy of the hash, it is normally highly
>    desirable to use it where possible.
>
> NEW:
>    Most forwarding engines employ layer-4 port information to increase
>    the entropy of the hash, and this implies the need to process the
>    IPv6 header chain, thus leading to the issues discussed in this
>    document.
>
> ?
>
Hmmm... can we more neutral:

"Forwarding engines that employ layer-4 port information to increase
    the entropy of the hash have a need to process the
    IPv6 header chain, thus leading to the issues discussed in this
    document."


>
>>>>>> Perhaps;
>>>>>> /When many IPv6
>>>>>> implementations failed to set the Flow Label, many ECMP and 
>>>>>> Hash-based
>>>>>> Load-Sharing devices also did not include the Flow Label 
>>>>>> [Cunha-2020],
>>>>>> possibly as a result of issues that have been found
>>>>>> in host implementations and middle-boxes [Jaeggli-2018]./
>>>>>> although it seems like
>>>>>
>>>>> The suggested change seems to imply that the situation has 
>>>>> changed, but I believe it hasn't. [Cunha-2020] provides evidence 
>>>>> in this respect. SO assuming that this is something from the past 
>>>>> would be inaccurate.
>>>>>
>>>> Well.... we can debate this, if we need to, however:  - i.e., I 
>>>> think the existence of techniques that utilise ports is sufficient 
>>>> to justify why the router wishes to traverse the header chain, and 
>>>> why extension headers are problematic - that does not need to 
>>>> present anything about what is good practice for ECMP without 
>>>> predjudice to deployment of FL-based methods.
>>>
>>> What we mean here is: the reader might wonder "why don't you just 
>>> use the FL?  -- Because we can't".
>>>
>>> More of empirical evidence than prejudice.
>>
>> Observing this happens is helfpul - with more clarity of recent 
>> trends in setting and using.
>>
>> However, I will objec interpretation of this to how to use (or not) 
>> the FL. This document is not the correct place to offer this advice.
>>
>> One: because this document is not about ECMP and FL, it is about EH.
>
> Not sure what you mean. THis section is discussing why some boxes may 
> need to access the layer-4 information. For load-sharing, the reader 
> might wonder "why aren't you using the FL in the first place?" -- 
> that¡s the only reason why we're mentioning the FL here...
>
> We're not advising whether to use or not the FL. We're simmply 
> explaining why boxes actually need to access the layer-4 info...
>
>> Two: because this is an informational document from an OPS WG trying 
>> to change something that is being used by PS in Transport and 
>> Internet areas.
>
> I'm a bit lost here. This document is not trying to provide any sort 
> of advice. We essentially elaborate on why boxes need to access 
> layer-4 information, and what are the options they have on the table 
> (if any) if they can't.
>
See above suggestion about how you might take a more neutral position?
>
>>>>>>>>> I suggest the section includes mention of the IETF 
>>>>>>>>> recommendation,
>>>>>>>>> and there the path with “clearly...” should be at the end!
>>>>>
>>>>> Ok with moving the para "Clearly.." to the end. That said, could 
>>>>> you elaborate on what IETF recommendation you're referring to?
>>>>>
>>>>>> Use of extension headers can result problematic for NIDS/IPS, since:
>>>>>>>> /may/can/ ... not necessary, but might as well use /can/ in 
>>>>>>>> this case?
>>>>>
>>>>> Doesn't "may" imply possibility here?
>>>>>
>>>> No. In many reader's eyes this is permissive ... do it would read 
>>>> are permitted to.
>>>
>>> Any alternative wording that would convey "possibility" rather than 
>>> "ability" or "permission"?
>>>
>> Trying to be close to your original wording:
>>
>> Problems can arise when EH are used for NIDS/IPS, since:
>
> Maybe /used for/processed by/ ?
>
>
Much better.
>
>>>>>> As a result, in order to increase the efficiency or effectiveness of
>>>>>> these systems, packets employing IPv6 extension headers can be
>>>>>>>>> /can/ or /have been/are being/ ... to follow the previous 
>>>>>>>>> argument?
>>>>>> dropped at the network ingress point(s) of networks that deploy 
>>>>>> these
>>>>>> systems.
>>>>>
>>>>> (Must admit that since you're a native English speaker, I have a 
>>>>> high probability of being wrong :-), but, anyway):
>>>>>
>>>>> Packets can be drop, whether with EHs or anything else (i.e., the 
>>>>> contents of a packet does not affect the ability of a device 
>>>>> dropping them -- at the end of the day, a device can drop *all* 
>>>>> packets if it feels like).
>>>>>
>>>> :-)
>>>>> What we are meaning here is that dropping packets with EHs is 
>>>>> indeed one option to increase the efficiency and effectiveness of 
>>>>> these systems.
>>>> That sounds correct.
>>>
>>> Would modifying the text as phrased address your comment?
>>>
>> Pehaps, you could try something.
>>
>> I'd suggest just being neutral and saying:
>>
>> As a result, IPS systems have been observed to drop packets employing 
>> IPv6 extension headers at the network ingress point(s).
>
> Looks good to me.
>
>
>
>>>>>> o Use of unknown extension headers can prevent an NIDS/IPS to
>>>>>> process layer-4 information
>>>>>
>>>>> I this case, I think both are fine: -- "can" as in ability, and 
>>>>> "may" as in possibility
>>>>>
>>>> - but not may as in "are permitted to"...
>>>
>>> Would "could" be better to convey "posibility" rather than ability 
>>> or permission?
>>>
>>>
>> Could is fine.
>
> Done ;-)
>
>
>>>
>>>>>> When such devices are unable to obtain the
>>>>>> required information, they might simply resort to dropping the
>>>>>>>>> /may/might/ ?
>>>>>
>>>>> "might" reads as a possibly imaginary situation. What we are 
>>>>> meaning is that some devices *do* this.
>>>>>
>>>> OK : then say that devices do this,... rather than they are 
>>>> permitted to.
>>>
>>> I'll tweak to:
>>>
>>> "Some of such devices, when unable to obtain the required 
>>> information, simply resort to...". OK?
>>>
>>>
>> /such/these/ ... seems like a reasonable statement to me:-).
>
> Will do.
>
>
> [....]
>>>> They are actually cited in RFC7872 if taht is your reason, so that 
>>>> is already clear!
>>>
>>> That said, I don't mind removing these two references. They were 
>>> including in this document at a time RFC7872 didn't exist -- i.e. we 
>>> don't have any special motivation for including them.
>>>
>> Aha - that now make sense, if RFC7872 hadn't been finalised. 
>
> Indeed, this text (with these references) had been crafted before 
> RFC7872 got published.
>
>
>> So removing  them would be good for me.
>
> I don't mind, and thus will do unless I hear otherwise from the group.
>
> Thanks!
>
> Regards,

-- 
G. Fairhurst, School of Engineering

Gorry