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

[Joel Halpern <[e-mail]>]

It is accurate that transits that do not use SRH do not need to worry 
about SRH.  And arguably, even those that do use SRH do not need to 
worry about SIDs not in their usage ranges.  Getting that right is 
non-trivial, but...

The point in this particular case is that connecting pieces of your 
domain in the clear over the Internet puts you at significant risk.  You 
can't tell a packet validly from another piece of your domain from a 
packet being sourced by an attacker and spoofing its source address.  So 
if you deploy the use case you have described, that causes you to object 
to other folks filtering SRH, you are doing something that the IETF has 
good reason to say is a bad idea.

So folks who filter the SRH, even if you do not like it, are doing what 
we told them to do.  SRv6 was approved only for limited domains.

While you have said you do not like limited domains, and there is a lot 
of ambiguity and bending of rules around such things, it does seem 
appropraite and legitimate for us to write in restrictions based on that 
property that the RFCs require.

Yours,

Joel

On 10/9/2022 10:49 AM, Robert Raszuk wrote:
> Joel,
>
> > it turns SRH into a powerful attack vector
>
> Really ?
>
> How is this possible if IPv6 destination address of the packet does 
> not belong to the block of locally allocated range used as ASN's infra 
> subnet ? I am talking about a pure IPv6 transit case.
>
> Isn't this the case that SRH should be examined by the node listed in 
> the destination address of the packet ?
>
> And of course it is common and very good practice to filter any 
> external attempt to reach my own address blocks use for management and 
> node configuration. But this is way more granular then to say kill all 
> packets entering my network which have SRH.
>
> Thx,
> R.
>
> On Sun, Oct 9, 2022 at 4:37 PM Joel Halpern <[e-mail]> wrote:
>
>     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
>>         >
>>         --------------------------------------------------------------------
>>