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

Andrew,
That's what
https://www.rfc-editor.org/rfc/rfc8799.html#name-functional-requirements-of-
is getting at. We need more precision indeed, and that requirements list
was intended as a starting point. (We also have an example: RFC8994.)

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Mon, 25 Oct 2021, 22:12 Andrew Alston, <Andrew.Alston=
40liquidtelecom.com@dmarc.ietf.org> wrote:

> Ole,
>
> My problem here is that "limited domain" has become a vague and obscure
> term used to justify the violation of pretty much anything.
>
> Furthermore - I would argue that in the case of srv6 - the concept of
> domain boundary has become so obscure and so vague as to be meaningless.
> When limited domain used to have limited edge devices connecting to other
> networks - you could kinda get away with this - when your limited domain is
> now extended into a hybrid server/network world - and your domain edge is
> so vague and fuzzy as to encompass pretty much every port on the network -
> then the concept of limited domain is, in my view as an operator,
> meaningless.
>
> I actually think it would be interesting to potentially form another
> working group in the IETF - to specifically look at the operational impact
> of ideas being proposed but on a "localized" basis - so while GROW is
> chartered to look at the impact of things on the wider internet - perhaps
> we need to start thinking about something that can analyze the impact of
> proposals from the perspective of a "limited domain" - inside that domain -
> and perhaps this could also be the place where we define what a "limited
> domain" really means - and what the boundaries of this really mean.
>
> Might be something worth considering...
>
> Andrew
>
>
> -----Original Message-----
> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of otroan@employees.org
> Sent: Monday, October 25, 2021 12:05 PM
> To: Warren Kumari <warren@kumari.net>
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent
> drafts?
>
> 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."
>
> 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.
>
> Cheers,
> Ole
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>