Hi, An updated version has been uploaded, implementing the text suggestions below, including Joel's suggestion. We believe that this version addresses all the issues raised: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/13
Thanks, Tal. On Fri, Mar 27, 2026 at 6:32 PM Joel Halpern <[email protected]> wrote: > > Regarding one item: > > On 3/27/2026 4:53 AM, Tal Mizrahi wrote: > > 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: > >> <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. > > Personally, I would recommend stronger text about the putative > inter-domain usage. > > Instead of: > > "While inter-SR-domain scenarios are generally out of scope for this > document's threat model" > > I would suggest > > "While inter-SR-domain scenarios are a violation of the trust model > described above" > > and then continue with the text about not gratuitously breaking things. > > Yours, > > Joel > > > > >> Hope that helps. > >> > >> Thanks in advance for your reply. > >> > >> Best regards, > >> > >> JMC. > >> > >> > >> _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
