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

[Christopher Morrow <[e-mail]>]

On Tue, Dec 4, 2018 at 8:10 PM Joe Touch <[e-mail]> wrote:

>
>
> On Dec 4, 2018, at 12:17 PM, Christopher Morrow <[e-mail]>
> wrote:
>
>
>
>
>
> 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’)
>
>
> It is...
>
>
> 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.
>
>
> If that happens, the packets with these headers can easily be throttled -
> thus avoiding a security issue.
>
>
So, perhaps I'm not expressing my point properly... I'll try again in a
different way.
I don't think that they can be meaningfully throttled, no. I think that
they will 'always' be throttled if they can not go on the fast-path,
because the difference between 'fast-path' and 'not fast-path' is ~9 orders
of magnitude. There's not a sane "welp, 50% of bandwidth" or anything like
that possible in this scenario. Except: "meh, just pass along all packets
unchecked, no HBH checking/evaluation nothing".


> However, what you’re basically saying is that “it is a security risk to
> send packets to a router because it might have to do work”.
>

I don't think that's what I said, what i said is that loss of control-plane
functionality is a security risk, because you lose availability.
Yes, that's not a 'big surprise', it's just a fact of life on the public
network, to operate a network connected to the public you don't let things
poke at your control-plane.


> Yeah, big surprise. Either do the work or limit the impact. But that’s not
> the kind of security risk we associate with availability - a good example
> of which would be that sending a single packet would cause the work of 1000.
>
>
'you' (the royal, not you in particular) may not consider loss of
availability to be a security concern, but I expect all network operations
folk to consider it such.
I expect that, by and large, folk who operate networks aren't trying to
make 'your' (royal again) life hard here, 'we' (royal) are just saying:
"there's a tradeoff, let's be sure we agree what the costs are going to be"


But none of that is happening here.
>
>
> 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.
>
>
> But then that’s not a security problem.
>
>
it's a loss of availability for the users of the expected packets. It's not
really "my" concern, unless I'm trying to do some new protocol thingy.


>
> 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?
>
>
> That works only for HBH options of type 00. Others require particular
> actions when not supported.
>
>
can you expand on this some?


> Joe
>