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 <[email protected]> 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. _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
