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

[Tom Herbert <[e-mail]>]

On Wed, Dec 2, 2020 at 5:38 PM Fernando Gont <[e-mail]> wrote:
>
> 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 ;-)

Fernando,

The analogue evil comment would be that, as a network guy, you
shouldn't have any interest in the transport layer. Or furthermore,
there's no concept of a "transport layer" for a network guy ;-)

The fact is that hosts, including the transport layer, do have a
vested interest in the network path to a destination and what its
characteristics are as part of ensuring viable end to end
communications. As Gorry alludes to, if the host can get information
apriori about the capabilities that a particular network path supports
then we're able to apply fallbacks when the path doesn't support the
requested functionality or possibly influence the routing to get a
better path. For instance, if my host has information that EH headers
are supported to some destination on the Internet then why not use
them to that destination if they offer better service for the user?

Tom

>
>
>
> >>
> >> 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
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops