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

[Joel Halpern <[e-mail]>]

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
>     > --------------------------------------------------------------------
>