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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 20 Apr 2021 22:29:14 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-ipv6-ehs-packet-drops-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/

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

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/

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment: does the word "carrier-grade router" represent the 'core'
and/or 'edge' routers ?

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

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 ?

-- Section 4 --
It appears to me that "Some of the operational implications of IPv6 Extension
Headers " is also about 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 ?

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

Please add a reference to the NOTE.

-- Section 5.1 --
Can you add a reference to routers doing recirculation ? Honestly, I have never
heard of this for EH parsing. Now, let's hope that this is not my employer ;-)

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

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

Should "management plane" be added to "against router control planes" ?

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

-- Section 7.2 --
Please add a reference to the statement "many operators currently drop IPv6
packets containing this extension header"

-- Section 7.3 --
Any reason why this section is only about "router" and not the usual "router
and middle boxes" or even "intermediate systems".

-- 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 :-)

The penultieme paragraph appears to present some 2013 references as fairly
recent. Please consider removing this part.

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

== NITS ==

-- Section 5 --
Please expand "NPU" and "CAM" at first use.

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

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 23 Apr 2021 23:39:12 +0100

Hi Éric

And thank you for reviewing!

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

> Generic comment: does the word "carrier-grade router" represent the 'core'

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.

> "intentionally" (by the network operator)?  I also fail to understand the mix > of "public Internet", which is global, and "in some network 
deployments", which
> 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.

> "operational ... implications " and "operational issues" ? Should those bullet

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.

> Headers " is also about security implications.

Yes, operational can refer to both, but we can change this to 
"operational and security implications".

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

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

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

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

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

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

> packets containing this extension header"

The reference here is rfc7872 (now added).

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

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

> recent. Please consider removing this part.

Yes, this is probably too stale at this point.  Removed.

> and interesting when compared to RFC 7872 ? If so, is there a plan to make them

Fernando might better placed to reply to this.

> Please expand "NPU" and "CAM" at first use.

changed.

> "balancing" rather than sharing ? Also, please use the usual way "equal cost

changed.

updates (for final internal review) on:

> https://github.com/nickhilliard/ipv6-ehs-packet-drops/commit/613cd6b4040084662a4c684c6e1f932d0366a494

Nick