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]
