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

[Fernando Gont <[e-mail]>]

Hi, Gorry,

Thanks for your timely response! In-line....


On 2/12/20 16:33, Gorry Fairhurst wrote:
[....|]
>>
>> In-line...
>>
>> On 1/12/20 13:30, Gorry Fairhurst wrote:
>> [...]
>>>
>>> * I have some concerns that some of the choices of words could 
>>> (unintentionally) be taken as endorsing a best practice, which I 
>>> don't think the IETF would generally promote. This is more about 
>>> ensuring specific parts can not be quoted out of context. I did a 
>>> careful read and hope I identified most of these and propose 
>>> something that might be helpful (please see attached PDF - RTF is 
>>> identical). I think it would be good to clarify in a few places this 
>>> is the RFC8200 spec, since I have heard there could be new work to 
>>> update that.
>>
>> I don't mind doing that. However, isn't it implicit in all RFCs that 
>> they are referring to the current specifications (unless otherwise 
>> noted)?
>>
>> i.e., regardless of whether there is ongoing work, and whether one is 
>> aware about it, a spec refers to the IETF status at the time the spec 
>> is published (*).
>>
>> (*) Well, modulo RFC Ed processing times.
>>
>>
>> In any case, IIRC, RFC8200 is the current state of affairs when it 
>> comes to EH processing, so I guess explicitly referencing RFC8200 
>> wouldn't hurt.  -- I'm CC'ing Brian, who may correct me if my "of the 
>> top o my head" assessment is not correct :-)
>>
> The above is all true - and I think it is simple to add the REF!

I will apply the proposed ref. I just want to double-check that we're 
not leaving outside e.g. things like RFC7045, which I should 
double-check whether it's fully incorporated into RFC8200. Otherwise, 
just mentioning RFC8200 would be imprecise.



>>> * 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 ;-)



>>
>> 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.



>>> If an IPv6 header chain is sufficiently long that its header exceeds
>>> the packet look-up capacity of the router, then it would be dropped by
>>> hardware that is unable to determine how it should be handled.
>>
>> This seems rather confusing. It's the router that drops the packet.
>>
> /hardware/router hardware/

Would the meaning be  hanged if we just say "router"?



> 
>>> 5.1.
>>> Recirculation
>>> Although TLV chains are amenable to iterative processing on
>>> architectures that have packet look-up engines with deep inspection
>>>>>> is this /that/ ?
>>
>> Not sure what you mean....
>>
> I was suggesting using that in place of /which/... minor nit.

Oops -- my bad! (And thanks for it, btw!  For English-as-second language 
I remember studying "that vs. which"... and it seems I should recheck, 
as the RFC-Ed frequently corrects these for 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....


>>> 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.



> 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.



>>> 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.



>>>>>> 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"?



>>> 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?



>>> 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?



>>> 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?



>>
>>> Some router implementations lack fine-grained filtering of IPv6
>>> extension headers. For example, an operator may want to drop packets
>>> containing Routing Header Type 0 (RHT0) but may only be able to
>>> filter on the extension header type (Routing Header). As a result,
>>> the operator would end up enforcing a more coarse filtering policy
>>> (e.g. "drop all packets containing a Routing Header" vs. "only drop
>>> packets that contain a Routing Header Type 0").
>>
>> The proposed change seems to change the meaning of the paragraph. 
>> i.e., these things *do* happen.
>>
> How about something like:
> 
> Some router implementations do not have fine-grained filtering of IPv6
> extension headers. For example, an operator that wishes to drop packets
> containing Routing Header Type 0 (RHT0), may only be able to
> filter on the extension header type (Routing Header). This would
> 
> result in an operator  enforcing a more coarse filtering policy
> (e.g. "drop all packets containing a Routing Header" vs. "only drop
> packets that contain a Routing Header Type 0").
> 
> ???

Looks good to me! Thanks!



>>>  Additionally, implementation
>>>    inconsistencies in packet forwarding engines can result in evasion of
>>>    security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014]
>>>    [BH-EU-2014].
>>
>> The original text said "...may result in evasion". It would seem to me 
>> that both are correct ("can" = ability, "may" = possibility)? 
>> Actually, the later implies the former?
>>
>>
> /can/will/ or whatever or just /result in/ ?

"often results in"?


>> Same for this one:
>>
>>> Packets with attached IPv6 Extension Headers can impact performance
>>> on routers that forward them.
>>
> Except in this case, I think the performance of some designs of router 
> are impacted when forwarding packets with IPv6 EH.

Other than HbH, the performance impact generally results from looking up 
the L4 header.

That said, upon re-read of your suggestion, it looks good to me.



>>> [Gont-Chown-IEPG89]
>>> Gont, F. and T. Chown, "A Small Update on the Use of IPv6
>>> Extension Headers", IEPG 89. London, UK. March 2, 2014,
>>> <http://www.iepg.org/2014-03-02-ietf89/fgont-iepg-ietf89-
>>> eh-update.pdf>.
>>> [Gont-IEPG88]
>>> Gont, F., "Fragmentation and Extension header Support in
>>> the IPv6 Internet", IEPG 88. Vancouver, BC, Canada.
>>> November 13, 2013, <http://www.iepg.org/2013-11-ietf88/
>>> fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>.
>>>>>> These don’t seem great presentations, and seem like they were
>>>>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0?
>>>>>> I don’t know why these are useful as references? RC7872 also 
>>>>>> covers this?
>>
>> They are listed as they were part of the work that eventually resulted 
>> in RFC7872, and as an indication of for how long the problem has been 
>> looked into. At the time, we didn't even have tools to do the 
>> measurements. For example, the path6 tool I implemented, and the 
>> support in RIPE Atlas were triggered by these efforts.
> I don't agree with that.

Which part, specifically? :-)

Well, I don't think there were tools available at the time. But if you 
know of any, I'd like to know!


> 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.

Thanks!

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