Re: [Tsv-art] [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

[Ole Troan <[e-mail]>]

Gert,

>> Vendors are not required to lie when claiming IPv6 support.
> 
> So you prefer that vendors just do not deliver IPv6 at all?
> 
> Let me repeat that: what you want will not be paid by the marketplace.
> 
> Chained EHs are a relict from a time when everybody was nice and 
> cooperative, bandwith was sparse, routers used CPUs to forward packets,
> and money came from governments to research networks in huge amounts.
> 
> This is not today's Internet anymore.
> 
> You can accept that or not, but nothing you can say will magically make 
> the necessary amount of money and development resources (let alone 
> "interest") appear to build and deploy routers that can do what you want 
> all across the Internet.

This is the exact reason we have layering in the Internet protocols.
IPv6 routers are not meant to parse further into packets then the IPv6 header (with one exception (1)).

That network devices find it hard to parse deep into user’s traffic is a feature.
I find the argument that we should then change upper layer protocols to accommodate that, hard to digest.

I agree with Joe, this isn’t a security issue.

Ole

(1) The exception is the HBH header which is intended as a hook for forwarding devices to do further processing of the packet.
To Joe’s point, RFC8200 specifies that the header is to be ignored unless the device is specifically configured to handle the header.
There is obviously no security risk for the router itself in ignoring the NH=0 and forwarding the packet.
There might be a risk if and when an actual HBH option is specified. But that specification should have security considerations.