Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-01.txt

From: [email-masked]
Date: Wed, 14 Oct 2020 05:28:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Operational Implications of IPv6 Packets with Extension Headers
        Authors         : Fernando Gont
                          Nick Hilliard
                          Gert Doering
                          Warren Kumari
                          Geoff Huston
                          Will (Shucheng) Liu
	Filename        : draft-ietf-v6ops-ipv6-ehs-packet-drops-01.txt
	Pages           : 20
	Date            : 2020-10-14

Abstract:
   This document summarizes the operational implications of IPv6
   extension headers, and attempts to analyze reasons why packets with
   IPv6 extension headers may be dropped in the public Internet.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Oct 2020 09:37:38 -0300

Folks,

This rev is meant to address Tom Petch's and Eduard Vasilenko's feedback.

The rev is available at: 

And the diff from the previous rev is available at: 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-01.txt

P.S.: As a co-author, I believe this rev should be ready for WGLC.

Thanks!

Regards,
Fernando

On 14/10/20 09:28, [email-masked] wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> 

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

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 14 Oct 2020 11:19:46 -0500

> https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01

In section 7.4, is it worth referencing covert channel risk from rfc6437's
section 6.1?

In section 7.1, I thought there was a class of devices (routers) where if
configured with a packet filter / acl that when unable to find the upper 
protocol information buried past the size of the lookup engine would actually 
forward traffic even if the policy was to deny.  I could have sworn I saw 
this topic fly by on the v6ops list, but I can't find it (thus I don't want 
to mistakenly name and shame).

I am not sure if I agree with the last paragraph of 6.1 which opines on
the low adoption of rfc6437-style flow label hash entropy.  I would 
expect that the current low adoption in ecmp implementations is a 
chicken/egg problem.  If you have a product that needs to hash and you are 
not confident there is enough adoption in host stacks, you are still forced 
to hunt for entropy from the upper-protocol protocols.  Otherwise all the 
legacy host traffic with the flow label set to 0 risks getting hashed 
entirely to one side or face reordering.

Dale

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Oct 2020 13:39:21 -0300

Hello, Dale,

Thanks a lot for your timely feedback! In-line....

> In section 7.4, is it worth referencing covert channel risk from rfc6437's

Section 7.4 is about the security implications of *EHs*... so that would 
be off-topic, so to speak...

> to mistakenly name and shame).

I do recall reports of that. I guess we can simply note it without a 
reference?  (I don't mind the reference myself, but some of my 
co-authors might differ :-) )

> the low adoption of rfc6437-style flow label hash entropy. 

We don't argue low-entropy, but issues with the Flow  Label 
implementation. See e.g.: 
https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/

> I would

We're just stating that there's marginal usage of the Flow Label, which 
is what the work by Cunha et al seems to indicate. As to the possible 
consequences, part might be LBs lagging behind host implementations. But 
issues in the Flow Label implementation might have also discouraged its use.

That said, the important info that Section 6.1 is meant to convey is 
that there still seems to be marginal use of the FL. And also note that 
issues have been found in FL implementations. -- i.e., we're not trying 
to infer why there's marginal use of the FL.

If you think this warrants some tweaks in the text, please do let us know.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Oct 2020 09:06:10 +1300

On 15-Oct-20 05:39, Fernando Gont wrote:
...
> If you think this warrants some tweaks in the text, please do let us know.

I just re-read that section and sadly I think it is still correct.

   Brian (co-author of several flow label RFCs)

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 14 Oct 2020 16:09:15 -0500

> Thanks a lot for your timely feedback! In-line....

well, you did threaten wglc  ;-)
 
> Section 7.4 is about the security implications of *EHs*... so that would be
> off-topic, so to speak...

Oh right, I get mixed up on that at times, sorry.  But related, covert side 
channel risk is probably on the minds of those justifying filtering EH's.  
This is the first easy reference I found, there are likely others:

Hansen, Raymond A.; Gino, Lourdes; and Savio, Dominic, "Covert6: A Tool
to Corroborate the Existence of IPv6 Covert Channels" (2016). 
Annual ADFSL Conference on Digital Forensics, Security and Law. 13.
https://commons.erau.edu/adfsl/2016/tuesday/13 

> reference?  (I don't mind the reference myself, but some of my co-authors
> might differ :-) )

Maybe it was about fragment processing rather than EH?  I hope this
triggers someone's memory.

> We don't argue low-entropy, but issues with the Flow  Label implementation.
> See e.g.: https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/
> 
> 
> 
> > I would
> We're just stating that there's marginal usage of the Flow Label, which is
> what the work by Cunha et al seems to indicate. As to the possible
> That said, the important info that Section 6.1 is meant to convey is that
> there still seems to be marginal use of the FL. And also note that issues
> have been found in FL implementations. -- i.e., we're not trying to infer
> why there's marginal use of the FL.
> 

Ok, I think it's a misinterpretation of intent.  How about this slight
wordsmith for 6.1, which to me softens the causality claim that I inferred.

   While support of [RFC6437] is currently widespread for current
   versions of all popular host implementations, there is still only
   marginal usage of the IPv6 Flow Label for ECMP and load balancing
   [Cunha-2020].  A contributing factor could be the issues that have 
   been found in host implementations and middle-boxes [Jaeggli-2018].

Overall, I think this is a very useful doc!

Dale

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Oct 2020 18:28:59 -0300

Hi, Brian,

> I just re-read that section and sadly I think it is still correct.

Thanks a lot for double-checking!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Oct 2020 18:44:28 -0300

> well, you did threaten wglc  ;-)

Well, that's our view as authors. But at the end of the day, it's the 
chairs' call, not ours :-)

> https://commons.erau.edu/adfsl/2016/tuesday/13

Not that I know of. At the end of the day, the BW may change, but 
there's always one more covert channel.

The reasons are more concrete and straightforward. Except for veeeery 
:-) specific scenarios, folks don't really care about covert channels.

[....]
>     been found in host implementations and middle-boxes [Jaeggli-2018].

Works for me. Thanks!

I'll wait and see if others complain about the change (I don't expect 
so), and will apply the change otherwise.

> Overall, I think this is a very useful doc!

Thanks a lot!

Regards,