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

["Dale W. Carder" <[e-mail]>]

Thus spake Fernando Gont ([e-mail]) on Wed, Oct 14, 2020 at 01:39:21PM -0300:
> 
> Thanks a lot for your timely feedback! In-line....

well, you did threaten wglc  ;-)
 
> On 14/10/20 13:19, Dale W. Carder wrote:
> > Thus spake Fernando Gont ([e-mail]) on Wed, Oct 14, 2020 at 09:37:38AM -0300:
> > > The rev is available at:
> > > 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?
> 
> 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 

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

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


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

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