Subject: Re: [v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-ipv6-ehs-packet-drops-06: (with COMMENT)

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 9 Jun 2021 11:51:01 +0400

On Sat, Apr 24, 2021 at 2:39 AM Nick Hilliard <[email-masked]> wrote:
>
> Hi Éric
>
>
>
> Éric Vyncke via Datatracker wrote on 21/04/2021 06:29:
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank you for the work put into this document. The authors know my deep
> > interest in this kind of work on the IPv6 extensibility.
>
> And thank you for reviewing!
>
> > Please find below some non-blocking COMMENT points (but replies would be
> > appreciated), and one nit.
> >
> > Special thanks to Loganaden Velvindron and Tim Winters for the IoT/INT
> > directorates reviews:
> > https://datatracker.ietf.org/doc/review-ietf-v6ops-ipv6-ehs-packet-drops-06-iotdir-telechat-velvindron-2021-04-19/
> > https://datatracker.ietf.org/doc/review-ietf-v6ops-ipv6-ehs-packet-drops-06-intdir-telechat-winters-2021-04-20/
>
> ok, interesting perspective, and not surprising to hear that IoT devices
> can choke on EHs.  Gate counts are important on tiny devices.
>

Hi Nick,

This would be up to you. I would suggest something along the lines of:
Many IOT implementations do not have v6 extension headers such as
https://github.com/FreeRTOS/FreeRTOS-Plus-TCP.

For those who support IPv6 extension header, it is a separate module:
https://doc.riot-os.org/group__net__ipv6.html

> > == COMMENTS ==
> >
> > Generic comment: does the word "carrier-grade router" represent the 'core'
> > and/or 'edge' routers ?
>
> tl;dr: "yes".
>
> This is one of those pieces of text that has been changed several times
> during the various review processes.  What we're talking about here is a
> router which with separated forwarding plane and management plane. On
> the ground, the difference between "edge" and "core" is often a matter
> of interpretation, and it is usual to see everything from top-of-rack L3
> switches to PCs running DPDK to traditional large chassis units handling
> either core, or else, or both.
>
> In other words, even though we might like to think of nice clean
> distinctions between "core" and "edge", or "hardware" and "software"
> forwarding, these things blend into each other in real life.  What we
> mean is a router that might be used by a carrier, which will involve
> hardware-facilitated routine, separate management plane and plenty of
> forwarding intelligence to deal with complex packet forwarding
> configurations.
>
> > -- Section 1 --
> >    "evidence exists that IPv6 packets with EHs are
> >     intentionally dropped in the public Internet in some network
> >     deployments."
> > The above strong assertion is really generic... Did the authors check about
> > "intentionally" (by the network operator)?  I also fail to understand the mix > of "public Internet", which is global, and "in some network
> deployments", which
> > is quite specific. Should there be a comma ? Or is it about my generic question
> > on whether it is edge / core ?
>
> Would "evidence exists that IPv6 packets with EHs are intentionally
> dropped in the public Internet in some circumstances" work better?
> They're not generally dropped, but there are situations where they can
> be and are dropped by policy for reasons described in the document.
>
> > Also, a fresh reference to "evidence" would be welcome.
> >
> > In the set of goal, is it on purpose that both bullets 1 and 3 are about
> > "operational ... implications " and "operational issues" ? Should those bullet
> > be merged ?
>
> They're different goals.  Goal 1 is to describe the causes and effects.
> Goal 3 is to encourage the IETF to take the outcomes into consideration
> in future.  We would prefer to keep these separate, even though they
> start from the same point.
>
> > -- Section 4 --
> > It appears to me that "Some of the operational implications of IPv6 Extension
> > Headers " is also about security implications.
>
> Yes, operational can refer to both, but we can change this to
> "operational and security implications".
>
> > Does RFC 7112 still apply for RFC 8200 ? As the first fragment MUST contain all
> > header up-to and including the upper-layer one? (in this case the ICMPv6). So,
> > this reference should perhaps be in the second list ?
>
> It already is in the second list, no?  Page 5 says:
>
> >    o  [RFC7112] discusses the issues arising in a specific fragmentation
> >       case where the IPv6 header chain is fragmented into two or more
> >       fragments (and formally forbids such fragmentation).
>
>
> > -- Section 5 --
> > BTW, I think that NPU have no real problem to parse deep in the EH chain
> > (except for some performance hit) as opposed to ASIC/TCAM/...
>
> The issue is often not necessarily with the NPU per se.  It's that
> packet processing is often handled differently to forwarding lookupg,
> and when you throw a packet into a lookup engine to find the egress
> interface / next-hop, the lookup engine will only inspect so far into
> the packet.  Sometimes, there are hardware limits imposed by the
> hardware.  We quoted numbers in previous versions of the draft, but took
> them out on reviewer advice.
>
> > Please also note
> > that many high speed routers are now VMs with normal generic processors in a
> > data center (of course not in the public Internet).
>
> The lines where we've traditionally delineated things are very blurry in
> real life - there are many different technologies used, even on low-end
> commodity hardware.  E.g. high speed routers could be powered from
> 72-core tileras to
>
> > Please add a reference to the NOTE.
> >
> > -- Section 6 --
> > I like the term "intermediate system" to represent router and middle box. May I
> > suggest to use this term from the beginning of the document through the end and
> > introduce it in the terminology?
>
> Ok, this is probably a good idea.  I've added it to the intro and have
> used it in various places to help readability.
>
> > -- Section 6.2 --
> > Suggest to reword "Infrastructure ACLs (iACLs) drop unwanted packets destined
> > to a network's infrastructure IP addresses" since the rest of the section is
> > not limited to 'IP addresses'.
>
> Will remove 'IP addresses' from that phrase.
>
> > Should "management plane" be added to "against router control planes" ?
>
> "control plane" is used interchangeably with "management plane".  This
> would be well-understood in the operations community.  We can change it,
> but there's an element here of writing in a style which is easily
> accessible, and that's not necessarily compatible with writing in a
> style which is 100% self-consistent.  On the basis that a small amount
> of unambiguous variety helps the readability of a document, I'd prefer
> to leave this, but we can change it if you feel it's important.
>
> > -- Sections 6.4 and 6.5 --
> > If NIDS/NIPS/firewalls are unable to understand EH chain, then they have no
> > excuse and simply are buggy or unfit for their job. Is there a need to cite
> > this kind of buggy devices in an IETF document ?
>
>
> two things here: firstly, the target audience of this document is the
> operations community and they would be specifically interested in
> information relating equipment relevant to their work, so it's important
> to call out FWs and NIDS devices explicitly.
>
> Secondly, You may have seen the URL I quoted to Roman's reply yesterday:
>
> > https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html
>
> i.e. the ipv6 header structure is complex, and this complexity leads to
> both differences in interpretation semantics and bugs.
>
> > -- Section 7.2 --
> > Please add a reference to the statement "many operators currently drop IPv6
> > packets containing this extension header"
>
> The reference here is rfc7872 (now added).
>
> > -- Section 7.3 --
> > Any reason why this section is only about "router" and not the usual "router
> > and middle boxes" or even "intermediate systems".
>
> I've changed to "intermediate systems" because that's a more general
> term, but mostly this would be an issue for routers, as other types of
> middle-boxes would tend to have more comprehensive packet analysis
> functionality.
>
> > -- Section 7.4 --
> > Please consider to promote sub-section 7.4 to its own section or at least add
> > "security" to the section 7 title.
> >
> > The text repeats some elements, which were previously discussed. Please
> > consider trimming the text :-)
>
> I've changed the title to "Operational and Security Implications", and
> have added a reference to section 5 to the first paragraph.  Again
> there's a readability / accessibility thing going on here, which
> conflicts with brevity / atomicity.  For standards track documents, it's
> important to be concise, but operational documents need to be readable.
> In this particular case, I think there's a benefit in having the
> security concerns outlined in a single location so that someone can
> easily browse through them without having to page through to other
> internal references.
>
> > The penultieme paragraph appears to present some 2013 references as fairly
> > recent. Please consider removing this part.
>
> Yes, this is probably too stale at this point.  Removed.
>
> > -- Section 10 --
> > The authors know me deep interest in getting fresh measurements, so, I am
> > puzzled by
> >    "thank Jan Zorz / Go6 Lab
> >     <https://go6lab.si/>, Jared Mauch, and Sander Steffann
> >     <https://steffann.nl/>, for providing access to systems and networks
> >     that were employed to perform experiments and measurements involving
> >     packets with IPv6 Extension Headers."
> >
> > as there is no indication in this document whether those measurements are fresh
> > and interesting when compared to RFC 7872 ? If so, is there a plan to make them
> > public
>
> Fernando might better placed to reply to this.
>
> > == NITS ==
> >
> > -- Section 5 --
> > Please expand "NPU" and "CAM" at first use.
>
> changed.
>
> > -- Section 6.1 --
> > "ECMP (equal cost multi path) load sharing", the usual way it to use
> > "balancing" rather than sharing ? Also, please use the usual way "equal cost
> > multi-path (ECMP)"
>
> changed.
>
> updates (for final internal review) on:
>
> > https://github.com/nickhilliard/ipv6-ehs-packet-drops/commit/613cd6b4040084662a4c684c6e1f932d0366a494
>
> Nick