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 <[email protected]> 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 > <[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]
