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

[Robert Raszuk <[e-mail]>]

Hi Suresh,

> One thing that is for certain is that this draft (draft-ietf-6man-sids)
does not specify any
> restrictions or provide any recommendations on filtering if this
allocated prefix is not used

OK many thx for this clarification I was not clear on this hence comments
made. In general I would consider such a block to be part of my infra and
naturally do filter on ingress.

However one point still remains unclear. What if a distributed domain
interconnected over the Internet is using a mix of these new allocated
prefixes within each site and publicly routable IPv6 addressing to jump
between sites within SRH ?

Then still blind filtering based on SRH presence would be a bad thing.

Not sure if this could be reflected in the document with a bit more
precision ...

Cheers,
R.

On Sun, Oct 9, 2022 at 6:01 PM Suresh Krishnan <[e-mail]>
wrote:

> Hi Robert,
>   Thanks for your further clarifications on the topic. I think I do
> understand your concern now based on your discussions with Joel and Brian.
> If I understand it correctly, the concern exists whether or not someone is
> using their own allocated address block or if they use the prefix allocated
> in this draft (Please correct me if this is not right). One thing that is
> for certain is that this draft (draft-ietf-6man-sids) does not specify any
> restrictions or provide any recommendations on filtering if this allocated
> prefix is not used, and that would be covered by what Section 5.1 of
> RFC8754 states.
>
> The generic concern you mentioned is something that needs to be discussed
> in the scope of the operational guidelines draft. I certainly do see this
> as a polarizing topic between the transit operators who would carry SR
> traffic and those who do not wish to do so and as you say below we can only
> provide recommendations.
>
> Regards
> Suresh
>
> On Oct 9, 2022, at 11:42 AM, Robert Raszuk <[e-mail]> wrote:
>
> Joel,
>
> > 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.
>
> Please rest assured that it is way easier to filter unplanned actions
> carried in SRH inserted by an attacker than to protect all end systems from
> globally reachable IPv6 destinations.
>
> So the former is a "bad idea" and the latter great one ... very
> interesting observation.
>
> Nevertheless it is great that all you can do is to write an operational
> recommendation. What will be actually done in the production networks is
> beyond your control.
>
> Cheers,
> R.
>
> On Sun, Oct 9, 2022 at 5:26 PM Joel Halpern <[e-mail]> wrote:
>
>> 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
>>>> > --------------------------------------------------------------------
>>>>
>>> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>