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

[Jean-Michel Combes <[e-mail]>]

Hi,

At first, thanks for your reply.
All your answers work for me.

Thanks again for your replies.

Best regards,

JMC.


Le jeu. 2 avr. 2026 à 12:26, Tal Mizrahi <[e-mail]> a
écrit :

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