[spring] Re: [SRv6OPS] Second WG Last Call: draft-ietf-spring-srv6-security-14 (Ends 2026-06-02)

[Tom Hill <[e-mail]>]

Hi Weiqiang, Nick,

On 2026-05-29 22:47, Nick Buraglio wrote:
> On Tue, May 19, 2026 at 11:53 PM Weiqiang Cheng <
> [e-mail]> wrote:
>> Two minor comments to help define scope earlier:
>> 
>>    1.
>> 
>>    Section 2 could note that inter-SR-domain scenarios are out of 
>> scope
>>    (as already stated in Section 4).
>>    2.
>> 
>>    The point that SRv6 inherits IPv6 vulnerabilities but that this is 
>> out
>>    of scope (currently in Section 6.2.4) could also be mentioned in 
>> Section 2
>>    or the introduction.
>> 
> How does this sound?
> OLD:
> We note that SRv6 is under active development and, as such, the above
> documents might not cover all protocols employed in an SRv6 deployment.
> 
> NEW:
> Inter-Domain Segment Routing scenarios are out of scope for this 
> document
> as are existing and future protocol specific IPv6 vulnerabilities.
> Additionally, we note that SRv6 is under active development and, as 
> such,
> the above documents might not cover all protocols employed in an SRv6
> deployment.
> 
> 
> We can leave the existing statements further in the document unless the 
> WG
> feels that they are unnecessary.

Per RFC8402 S8, if you take that a 'domain' is the "trusted domain", 
e.g. "By default, SR operates within a trusted domain.  Traffic MUST be 
filtered at the domain boundaries." then by that assumption there is no 
such definition of 'Inter-domain SRv6', because it violates Section 8 of 
RFC8402 as written.

If you take "inter-domain" to mean any EPE boundary (per RFC8402, S4.2) 
then I don't think should be out of scope of this document, as it is 
entirely valid for an operator to have multiple eBGP boundaries within 
their trusted domain (for reasons of acquisition, blast radius, etc.) 
and for us to be concerned about the security of those deployments.

Irrespective of the assumption made, I do not believe that it is for 
this document to define "inter-domain SRv6", and thus we should not do 
so (especially at this late stage). Detailing the security 
considerations of SRv6 domains that exceed the trusted domains of the 
operator would be nebulous, and there-in lies one of the reasons that 
this document exists; it builds upon the clear statement made in S4.2 of 
RFC8402.

I do not support this proposed change to the document.

Tom