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

[Gorry Fairhurst <[e-mail]>]

On 02/12/2020 17:52, Fernando Gont wrote:
> Hello, Gorry,
>
Hi!


> Thanks a lot for your feedback! -- We really appreciate it!
>
> 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!
>
>> * 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;-)
>
>> In some other uses, the fact that packets with these options might be 
>> expected to be dropped by many paths - for good reasons, does not 
>> mean that the option is useless to set in general - it might merely 
>> be that for these paths it is not possible to use the option and then 
>> care is needed in deciding which packets set the EH and how this is 
>> used.
>
> We certainly don't mean that. We mean "if you EHs, the chances of your 
> packets being dropped increase, for the general case". 
Yes, the chance that you encounter a path the drops packets with EHs.
> As noted, you may employ them within environments where everything is 
> under your control ("your network, your rules"), or, I guess, might 
> try to use them and have a fall-back mechanism (ala TCP ECN during 3WHS).
>
>
>
> 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.
>> 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/

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

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

>
>>>>>
>> /also did not employ/
>> do you really need to claim that? I suggest we could write this
>> in more neutral language, since some implementations recently
>> changed this practice?
>> 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.
>>>>> 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.
>
>> 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.
> We don't mean to "give permission" to operators, because, at the end 
> of the day, they don't need to ask :-)  (they don't, and they 
> shouldn't, IMO!).  That's why we use "may" -- it's an actual possible 
> operational policy to deal with the problem at hand.
>
>
>> 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"...
>
>
>> As a result, whether because of the challenges represented by
>> extension headers or because the use of IPv6 extension headers has
>> not been explicitly allowed, packets employing IPv6 extension headers
>> can be dropped by network firewalls.
>>>>> /can/ or /have been/are being/ ... to follow the previous argument?
>
> Same as before: I don't think you need reasons for an "ability". What 
> we mean is that firewalls may (as in "possibility of intended 
> behaviour") drop such packets.
>
>
>> 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.
>
>> 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").

???

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

>
>
>> [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. They are actually cited in RFC7872 if taht is 
your reason, so that is already clear!

>>>>> Is it worth also seeing whether Hendriks et al, 
>>>>> http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf
>>>>> contains useful insight instead of these two?
>
> I will read it. Thanks for the pointer! -- I wasn't aware about this 
> paper.
>
> Thanks!
>
> Regards,

-- 
G. Fairhurst, School of Engineering

Gorry