Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?

[Warren Kumari <[e-mail]>]

On Mon, Oct 25, 2021 at 5:04 AM <[e-mail]> wrote:

> Warren,
>
> > The way I see this playing out is operators quickly moving along the
> lines of:
> > If I'm expected to filter "RH type 4 (SRH)" on all of my external
> interfaces in case someone else decides to run SRH, what else should I
> filter? Clearly 5 and 6 (CRH-16/32)... and 7, 8, ... 255.
> > I need to be ready *before* you enable $insert_new_protocol_here, so the
> only sensible thing for me to do is filter all RH/43. Oh, and I don't know
> what sort of new uses there might be for Hop-by-Hop that might affect me,
> so I should clearly just filter all protocol 0 (perhaps in the future I
> might allow specific ones... maybe). HIP? I don't use that, but I might in
> the future, and I certainly don't have time to follow all of the new things
> being proposed in the IETF/by vendors, so obviously I should filter that
> everywhere...
> > Actually, why am I bothering to write this long filter list? I'll just
> allow TCP and UDP, and call it done...
> >
> > (When I started writing the above I thought I would need to add a
> "Warning: Hyperbole ahead" marker -- but I'm no longer sure that that's the
> case).
>
> Proposal for a principle: "If Internet traffic is carried across a limited
> domain, the technology used in the limited domain must not hinder end to
> end transparency."
>

<no hats/>

I must admit I'm having a hard time parsing the last part of the sentence.
I think it is more:
"A limited domain must default to fail closed, and require explicit
configuration to open it."

This is similar to e.g MPLS - I have to manually enable MPLS on an
interface ('set protocols mpls interface et-0/0/0') before the border of my
limited domain extends out the interface, and my neighbor has to enable it
on their side too. We *can* both choose to do so, but if we don't, the
domain doesn't cross the border. Without requiring explicit configuration
it isn't really a "limited domain", it's just a "domain".


>
> You are welcome to suggest more concise ways of saying that.
>
> In the above example, filtering packets with the SRH RH type _and_
> destined towards your own limited domain prefix would adhere to that.
>

Filters get missed sometimes, both ingress and egress. Yes, I can filter
towards my limited domain prefix -- but this only protects *my SRH limited
domain*. I'm also likely to want to protect my customers (who cannot be
trusted to always filter perfectly), if I have an enterprise portion I have
to know whatever prefixes they decide to use and update my filters, etc.
The limited part of "limited domain" implies that it has a clear border
(and also that whatever you do within the privacy of your domain is your
own business!); having a soft border fails the "limited" sniff test.

I somewhat like the idea of having a well known prefix for "limited
domains" - if everyone used $prefix, we could default to filtering it on
external links, and, just like MPLS/OSPF/IS-IS/<whatever>, consciously
decide to allow it between consenting adults. This is far from perfect --
it requires more routes in my IGP, etc, but it's better than nothing.

W


>
> Cheers,
> Ole
>
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra