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

[Christopher Morrow <[e-mail]>]

On Tue, Nov 27, 2018 at 5:40 AM Joe Touch <[e-mail]> wrote:

> Take that to the standards wg. Don’t stick your head in the sand and try
> to do an end run in ops. And don’t call any of this a security issue that
> it isn’t.
>
>
>
Joe, I think one of the 3 pillars of security is: "Availability" (the other
two are 'Confidentiality' and 'Integrity')

I think the point that Nick and Gert are outlining is that if the case is
that the hardware available will have no fast-path processing for packets
with obtuse patterns or sets of extension headers those packets will get
sent to the control-plane (slow-path). That slow-path being congested will
cause availability problems.

Actually, whether or not the control-plane fails under such load may not
even matter, if the rate-limiting of the packets here is such that (as gert
said) all but a trickle of the interesting packets are forwarded.

A solution might be to have a mode where  a router may just ignore all
headers except the src/dst-ip and simply forward all packets, trusting that
the conversing adults will sort out problems with unknown/new/experimental
headers or with a tortured ordering of headers (for instance). This will
also cause some operational headaches: "Please drop all traffic toward ipX
with protoY and dst-port Z" but perhaps it's still acceptable to some folk
to operate like this?