Hi, At first, thanks for your reply. Please see my comments below.
Le ven. 27 mars 2026 à 09:54, Tal Mizrahi <[email protected]> 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 > <[email protected]> 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.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
