[spring] Re: draft-ietf-spring-srv6-security-11 early Opsdir review

[Joel Halpern <[e-mail]>]

Regarding one item:

On 3/27/2026 4:53 AM, Tal Mizrahi wrote:
> Dear Jean-Michel,
>
> Many thanks for a very thorough review.
> We have revised the document and we believe that the current version
> resolves almost all the issues:
> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/12
>
> Please see the replies below, marked [TM], along with a couple of text
> update suggestions that we would be happy to hear your opinion about.
>
> Thanks,
> Tal.
>
>
> On Tue, Feb 24, 2026 at 6:55 PM Jean-Michel Combes via Datatracker
> <[e-mail]> wrote:
>> <snip>
>>
>> 7.1.2.  SRH Filtering
>>
>>     Filtering can be performed based on the presence of an SRH.  More
>>     generally, [RFC9288] provides recommendations on the filtering of
>>     IPv6 packets containing IPv6 extension headers at transit routers.
>>     However, filtering based on the presence of an SRH is not necessarily
>>     useful for two reasons: 1.  The SRH is optional for SID processing as
>>     described in [RFC8754] section 3.1 and 4.1. 2.  A packet containing
>>     an SRH may not be destined to the SR domain, it may be simply
>>     transiting the domain.
>>
>> <JMC>
>> <Major issue>
>> “2.  A packet containing an SRH may not be destined to the SR domain”
>> IMHO, not consistent with Section 6.2.1.2, Section 6.2.2.2 and Section 6.2.3.2:
>> where does this packet come from? </Major issue> </JMC>
>>
>>     For these reasons SRH filtering is not necessarily a useful method of
>>     mitigation.
>>
>> <JMC>
>> <Major issue>
>> IMHO, not consistent with RFC 8402, Section 8.2:
>> “Therefore, by default, the explicit routing information MUST NOT be leaked
>> through the boundaries of the administered domain.” IMHO, not consistent also
>> with Section 6.2.1.2, Section 6.2.2.2 and Section 6.2.3.2 </Major issue> </JMC>
> [TM] Here is a proposal for updated text:
> OLD:
> A packet containing an SRH may not be destined to the SR domain.
> NEW:
> A packet containing an SRH may not be destined to the SR domain. This
> scenario is mitigated by encapsulating packets on the domain boundary,
> as discussed in Section 7.2. While inter‑SR‑domain scenarios are
> generally out of scope for this document’s threat model, the
> operational practices recommended here aim to preserve
> interoperability and avoid blanket behaviors that would break SR when
> adjacent networks follow different practices.

Personally, I would recommend stronger text about the putative 
inter-domain usage.

Instead of:

"While inter-SR-domain scenarios are generally out of scope for this 
document's threat model"

I would suggest

"While inter-SR-domain scenarios are a violation of the trust model 
described above"

and then continue with the text about not gratuitously breaking things.

Yours,

Joel

>
>> Hope that helps.
>>
>> Thanks in advance for your reply.
>>
>> Best regards,
>>
>> JMC.
>>
>>
>>