Message-ID: <1d9e693a-d784-4e6d-805b-143f2079db6a@joelhalpern.com>
Date: Fri, 27 Mar 2026 11:32:02 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>,
 Jean-Michel Combes <jeanmichel.combes@gmail.com>
References: 
 <177195214360.2334629.133943892944994060@dt-datatracker-6ff7c68975-7k42g>
 <CABUE3X=s8UhZ6cFgijYPcf+fcLQCsyEipj5Ey24wiBrk3Qh-gA@mail.gmail.com>
Content-Language: en-US
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: 
 <CABUE3X=s8UhZ6cFgijYPcf+fcLQCsyEipj5Ey24wiBrk3Qh-gA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID-Hash: KJNPEDWVJ2NRDK2DQXMV6QC5CULLLMVD
CC: ops-dir@ietf.org, draft-ietf-spring-srv6-security.all@ietf.org,
 spring@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bspring=5D_Re=3A_draft-ietf-spring-srv6-security-11_early_Opsdir?=
	=?utf-8?q?_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/spring/UA5iwzxm2DL2Wh1OXRcovYERD0g>

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
> <noreply@ietf.org> 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.
>>
>>
>>