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

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

Hi,

At first, thanks for your reply.
Please see my comments below.

Le ven. 27 mars 2026 à 09:54, Tal Mizrahi <[e-mail]> a
écrit :

> 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:
> >
> > Document: draft-ietf-spring-srv6-security
> > Title: Segment Routing IPv6 Security Considerations
> > Reviewer: Jean-Michel Combes
> > Review result: Not Ready
> >
> > Hi,
> >
> > I have been selected as the Operational Directorate (opsdir) reviewer
> for this
> > Internet-Draft.
> >
> > The Operational Directorate reviews all operational and
> management-related
> > Internet-Drafts to ensure alignment with operational best practices and
> that
> > adequate operational considerations are covered.
> >
> > A complete set of _"Guidelines for Considering Operations and Management
> in
> > IETF Specifications"_ can be found at
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.
> >
> > While these comments are primarily for the Operations and Management Area
> > Directors (Ops ADs), the authors should consider them alongside other
> feedback
> > received.
> >
> > - Document: Segment Routing IPv6 Security Considerations
> > (draft-ietf-spring-srv6-security-11)
> >
> > - Reviewer: Jean-Michel COMBES
> >
> > - Review Date: 2026-02-24
> >
> > - Intended Status: Informational
> >
> > ---
> >
> > ## Summary
> >
> > The document is covering a large scope - I really appreciate the work
> done by
> > the authors, but this document has major issues: Indeed, the main (and
> > required) security mechanism mentioned inside in this document - SRv6
> > architecture in fact, is traffic filtering but, IMHO, the information on
> how to
> > set-up it are not enough clear: precise information are needed so that
> such a
> > mandatory mechanism could be correctly deployed and operated.
> >
> > Please, find my review below:
> >
> >               Segment Routing IPv6 Security Considerations
> >                    draft-ietf-spring-srv6-security-11
> >
> > <snip>
> >
> > 4.  Threat Terminology
> >
>

<snip>


> >
> >    As defined in [RFC8402], SR operates within a "trusted domain".
> >
> > <JMC>
> > <Major issue>
> > No clear definition of “trusted domain” in RFC8402: what is the
> definition of
> > “trusted domain”, for SR use case, from a technical/operational point of
> view?
> > Is “trusted domain” only means “the traffic is filtered at the domain
> > boundaries”, as mentioned in Section 7.1.1? </Major issue> </JMC>
> >
> >    Therefore, in the current threat model the SR domain defines the
> >    boundary that distinguishes internal from external threats.
> >
> > <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>

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

Thanks in advance for your reply.

Best regards,

JMC.