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

[Tom Herbert <[e-mail]>]

On Wed, Dec 2, 2020 at 11:48 AM Fernando Gont <[e-mail]> wrote:
>
> Hello, Gorry,
>
> 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 :-)
>
>
>
>
> > * 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.
>
>
>
> > 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".

Fernando,

That's true of a lot protocols. If you use fragmentation, any protocol
other than TCP or UDP, encryption, encapsulation, or even IPv6  your
chances of packets being dropped increase in the general case. In fact
many of the reason noted in this draft for drops are the same those
other cases. So it's generally true that any deviation from a narrow
set of protocols and options that are known to be commonly supported
by routers risks increased chance of packet drop.

I view this draft is another case of trying to document and explain
the status quo for how routers and middleboxes implement the protocol
(we saw the similar discussion in RFC8900 and
draft-ietf-tsvwg-transport-encrypt-18). Documenting current real world
behavior is good, however it needs to been in context (similar to
concerns raised for other like drafts):
1) Some of the behaviors being documented are either contrary with the
Internet architecture or downright non-conformant with the standards.
IMO this needs to be clarified and called when discussing some
particualar mechanism a vendor has chosen to implement. This may be
describing current practice, but as Gorry this in no way should be
construed as IETF best practice
2) We need to realize there are potentially conflicting rrequirements.
For instance, in this draft there is a statement "contemporary routers
and middle-boxes that need to find the layer-4 header must process the
entire IPv6 extension header chain.". I do not believe there is any
core IETF standard that requires routers to access the transport
layer, that's more a design choice vendors have made. In fact, from a
host perspective, we are trying to obsolete that by encrypting
transport headers like in QUIC for instance (there are both security
and protocol evolution motivations for doing that).
3) We need to very careful about making conclusions or even those that
are inferred by the reader. It should be very clear that this
documenting is not advocating obsoleting extension headers nor that
arbitrary dropping of packets with extension headers is acceptable.
4) It would be nice to have some guidance on a way forward. Assuming
that the consensus is that extension headers are still useful, what
can we do to increase their viablitiy? We already have a couple of
examples of this: RFC8200 relaxed the requirements that all nodes must
process HBH EH, RFC8883 describes ICMP errors to send when an
intermeidate does drop a packet with EH.
5) Specific to this draft, almost all the references are at least five
years old. For instance, RFC7872 which is considered the reference for
measurement of EH drops on the Internet dates back to 2016. So these
aren't really fresh and  in the case of RFC7872 that was publsihed
before RFC8200 so it doesn't reflect the impact of the updated EH
related requirements in RFC8200. More recent data and analysis would
strengthen the discussion.

Tom

> 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")
>
>
>
> > 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.
>
>
>
>
> > 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....
>
>
> > 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?
>
>
> > 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])
>
>
>
> >>>>
> > /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.
>
>
>
> >>>> 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?
>
>
> > 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.
> 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
>
>
>
> > 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.
>
>
> > 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.
>
>
>
> >  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?
>
>
> Same for this one:
>
> > Packets with attached IPv6 Extension Headers can impact performance
> > on routers that forward them.
>
>
>
> > [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.
>
>
> >>>> 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,
> --
> 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