Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

[Nick Buraglio <[e-mail]>]

----
nb


On Mon, Oct 10, 2022 at 2:57 AM Eric Vyncke (evyncke) <evyncke=
[e-mail]> wrote:

> Hmmm I really wonder why a transit network should look into my packets (to
> check for SRH) and decide to drop my packets; assuming of course that my
> packets are not damaging the transit network (like some hop-by-hop years
> ago) or attempting to trick my network (anti-spoofing or using transit
> provider own SID -- both being layer-3 filters BTW).
>

There is some, I think, relevant precedent from a provider perspective. In
the old days when worms with consistent byte boundaries were ravaging the
networks I personally worked on filtering those at the network perimeters.
While I am a very staunch proponent of not meddling with transit packets on
a carrier network, there are a handful of demonstrative examples (primarily
amplification attacks, etc.) that are de facto expected, but in many cases
can be lifted if there is a use case. Filtering SRH filters at the
perimeter of a given network as brian has described feels a lot like that
at a deeper network level.
As we have discussed SRv6 for solving use cases for our organizations, one
of the first questions I have consistently heard is "how do we prevent
abuse of this?" because of the nature of using IPv6 as the traffic
engineering steering stack. Referencing section 8 of RFC8402 is useful, and
also highlights some current operational limitations, and encourages
vendor implementation of the needful filtering options.



>
> -éric
>
>
>
> *From: *ipv6 <[e-mail]> on behalf of Joel Halpern <
> [e-mail]>
> *Date: *Sunday, 9 October 2022 at 16:38
> *To: *Robert Raszuk <[e-mail]>
> *Cc: *6man <[e-mail]>, SPRING WG List <[e-mail]>
> *Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
>
>
>
> We require, per the RFC, blocking SRH outside of the limited domain for
> many reasons.
>
> One example is that it turns SRH into a powerful attack vector, given that
> source address spoofing means there is little way to tell whether an
> unencapsulated packet actually came from another piece of the same domain.
>
> So yes, I think making this restriction clear in this RFC is important and
> useful.
>
> Yours,
>
> Joel
>
> On 10/8/2022 5:07 PM, Robert Raszuk wrote:
>
> Hi Brian,
>
>
>
> Completely agree.
>
>
>
> One thing is not to guarantee anything in respect to forwarding IPv6
> packets with SRH (or any other extension header) and the other thing is to
> on purpose recommending killing it at interdomain boundary as some sort of
> evil.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
>
>
> On Sat, Oct 8, 2022 at 9:51 PM Brian E Carpenter <
> [e-mail]> wrote:
>
> Robert,
>
> > If there is any spec which mandates that someone will drop my IPv6
> packets only because they contain SRH in the IPv6 header I consider this an
> evil and unjustified action.
>
> The Internet is more or less opaque to most extension headers, especially
> to recently defined ones, so I don't hold out much hope for SRH outside SR
> domains.
>
> https://www.rfc-editor.org/rfc/rfc9098.html
> https://datatracker.ietf.org/doc/html/draft-elkins-v6ops-eh-deepdive-fw
>
> Regards
>     Brian Carpenter
>
> On 09-Oct-22 07:52, Robert Raszuk wrote:
> > Hi Joel,
> >
> > I was hoping this is apparent so let me restate that I do not buy into
> "limited domain" business for SRv6.
> >
> > I have N sites connected over v6 Internet. I want to send IPv6 packets
> between my "distributed globally limited domain" without yet one more encap.
> >
> > If there is any spec which mandates that someone will drop my IPv6
> packets only because they contain SRH in the IPv6 header I consider this an
> evil and unjustified action.
> >
> > Kind regards,
> > Robert
> >
> > On Sat, Oct 8, 2022 at 7:40 PM Joel Halpern <[e-mail]
> <mailto:[e-mail]>> wrote:
> >
> >     Robert, I am having trouble understanding your email.
> >
> >     1) A Domain would only filter the allocated SIDs plus what it
> chooses to use for SRv6.
> >
> >     2) Whatever it a domain filters should be irrelevant to any other
> domain, since by definition SRv6 is for use only within a limited domain.
> So as far as I can see there is no way a domain can apply incorrect
> filtering.
> >
> >     Yours,
> >
> >     Joel
> >
> >     On 10/8/2022 3:16 AM, Robert Raszuk wrote:
> >>     Hi Suresh,
> >>
> >>         NEW:
> >>         In case the deployments do not use this allocated prefix
> additional care needs to be exercised at network ingress and egress points
> so that SRv6 packets do not leak out of SR domains and they do not
> accidentally enter SR unaware domains.
> >>
> >>
> >>     IMO this is too broad. I would say that such ingress filtering
> could/should happen only if dst or locator is within locally
> configured/allocated prefixes. Otherwise it is pure IPv6 transit and I see
> no harm not to allow it.
> >>
> >>         Similarly as stated in Section 5.1 of RFC8754 packets entering
> an SR domain from the outside need to be configured to filter out the
> selected prefix if it is different from the prefix allocated here.
> >>
> >>
> >>     Again the way I read it this kills pure IPv6 transit for SRv6
> packets. Why ?
> >>
> >>     (Well I know the answer to "why" from our endless discussions about
> SRv6 itself and network programming however I still see no need to mandate
> in any spec to treat SRv6 packets as unwanted/forbidden for pure IPv6
> transit.)
> >>
> >>     Thx,
> >>     R.
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
ᐧ