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

From: Fernando Gont <[email-masked]>
Date: Fri, 28 May 2021 03:58:27 -0300

Hi, Eric,

Thanks a lot for your comments! In-line....

On 21/4/21 02:29, Éric Vyncke via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> 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.

Indeed! ;-)

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

Are you actually referring to core vs edge?

I think we meant carrier-grade as in e.g. 
https://en.wikipedia.org/wiki/Carrier_grade ...

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

Certainly not with all, but we did check with some. Folks running a 
popular search engine ;-) are one popular example, IIRC.

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

What we meant was something along the lines of "...dropped in some 
networks", or some parts of he public Internet".  Maybe we could 
rephrase as:

       "evidence exists that IPv6 packets with EHs are often
        intentionally dropped in the public Internet"

?

> Also, a fresh reference to "evidence" would be welcome.

Thatś as fresh as it gets, I think.... :-(

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

Definitely! (good grief!)

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

Not sure I follow....

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

Should we add/tweak anything here?

> Please add a reference to the NOTE.

FWIW, we had it, but we were asked to remove it. :-)

FWIW, rev -03 said:
    NOTE:
       For example, contemporary high-end routers can use up to 192 bytes
       of header (Cisco ASR9000 Typhoon) or 384 bytes of header (Juniper
       MX Trio).

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

I see this one has been discussed, so... Iĺ leave the text äs is as 
suggested...

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

Sounds sensible. So how about a Section 2 "Terminology", with something 
along the lines of:

Intermediate system:
      Any system processing the packet that is neither the source of the
      packet, nor its final destination(s). Examples of intermediate
      systems include, but are not limited to, routers, firewalls,
      load-balancers, and Network Intrusion Detection Systems (NIDS).

?

And then s/router/intermediate system/ where we don't necesarily mean 
routers...

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

You mean that the sentence should also mention the service/protocol 
rather than just the "addresses"?

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

I say "Ÿes".  I will tweak to
"  can be used for attacks
    of different sorts against router control or management planes"

... unless anyone complains.. :-)

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

There are a few things to note here:
* You can't parse past unknown headers.
* Performance impacts may eventually mean "unable".
* Fragmented traffic may require quite a lot of state which, again, may
   eventually mean "unable to process" (unable to cope)

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

Some of these cases are, to some extent, public, as noted above.

In other cases, there'ś probably no public statement -- other than 
anecdotal evidence from those working for them.

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

Not really. Many revs of this doc simply discussed routers, while more 
recent revisions incorporated discussions of other middleboxes such as 
firewalls and NIDS/IPS.

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

Any preference among the two options?

(we probably did it the way we did it because we thought of security as 
"opsec" here...)

> The text repeats some elements, which were previously discussed. Please
> consider trimming the text :-)

Anything in particular?

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

Fair enough. Maybe replace those with this one:
https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html

?

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

FWIW, this was borrowed from the document from which eventually RFC7872 
and the present draft branched.

If you'ŕe interested, I could embark myself on re-doing the experiment, 
and maybe even keep it running regularly...

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

Will do.

> -- Section 6.1 --
> "ECMP (equal cost multi path) load sharing", the usual way it to use
> "balancing" rather than sharing ? 

"balancing" is a specific case of "sharing" -- i.e., you try to make 
sure that you share in a balanced way, so to speak.

> Also, please use the usual way "equal cost
> multi-path (ECMP)"

Will do.

Thanks *a lot* for your thorough review!

Regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1