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

[Tal Mizrahi <[e-mail]>]

Hi Jean-Michel,

Thanks for reviewing the updated version.
Please see my responses below, marked [[TM]].

On Wed, Apr 1, 2026 at 6:25 PM Jean-Michel Combes
<[e-mail]> wrote:

[snip]

>> > <JMC>
>> > <Major issue>
>> > “Therefore,”: without definition of “trusted domain” (cf. above), I must admit
>> > it is hard for me to have such a conclusion. </Major issue> </JMC>
>>
>> [TM] Based on this comment and other comments from directorate
>> reviewers we have significantly revised the text about "SR domain" and
>> "trusted domain" in Section 4 (Threat Terminology). While the current
>> document is not intended to redefine these terms, we believe that the
>> current version is clearer about the meaning of these terms based on
>> RFC 8402.
>
>
> <JMC2>
> Sorry, but the new text doesn't clarify the "trusted domain" term for me.
> Option #1: a SR domain, where filtering policy at the domain boundaries - as defined in the document, is applied and so, is considered as a "trusted domain" => a SR domain where there is no/partial filtering policy at the domain boundaries is not considered as a "trusted domain"
> Option #2: the filtering policy at the domain boundaries - as defined in the document, is only an additional security feature for a "trusted domain" and so, there is/are security assumption(s)/feature(s) a SR domain MUST have to become a "trusted domain"
> Option #1 or Option #2?
> If Option #2, what is/are the security assumption(s)/feature(s)?
> </JMC2>

[[TM]] Please note that the text in version 13 says: "...the term
trusted domain denotes an SR domain for which the boundary-filtering
assumption of [RFC8402] is in force."
Thus, from the two options you suggested, Option #1 can clearly be
understood from this sentence.
In my opinion the text is clear about this point.


[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.
>
>
> <JMC2>
> Maybe I was not clear enough, sorry. You have merged my 2 previous comments inside one but:
> - the first one was about incoming packets (i.e., to the SR domain)
> You replied to my comment.
> - the second one was about outgoing packets - with a SRH (i.e., from the SR domain)
> You didn't reply to my comment.
> </JMC2>

[[TM]] I would suggest the following text update to explicitly explain
that this section refers to both ingress and egress filtering.

OLD:
       A packet containing an SRH may not be destined to the SR domain,
       as it may be simply transiting the domain.  This scenario is
       mitigated by encapsulating packets on the domain boundary, as
       discussed in Section 7.2.  While inter-SR-domain scenarios are a
       violation of the trust model described above, the operational
       practices recommended here aim to preserve interoperability and
       avoid blanket behaviors that would break SR when adjacent
       networks follow different practices.
NEW:
       A packet containing an SRH may not be destined to the SR domain,
       as it may be simply transiting the domain. Therefore, filtering solely
       based on the presence of an SRH, at either SR ingress or SR egress,
       is not necessarily recommended. Instead, this scenario is
       mitigated by encapsulating packets on the domain boundary, as
       discussed in Section 7.2.  While inter-SR-domain scenarios are a
       violation of the trust model described above, the operational
       practices recommended here aim to preserve interoperability and
       avoid blanket behaviors that would break SR when adjacent
       networks follow different practices.

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

Thanks,
Tal.