Skip to main content

Early Review of draft-ietf-spring-srv6-security-11
review-ietf-spring-srv6-security-11-rtgdir-early-alston-2026-03-02-00

Request Review of draft-ietf-spring-srv6-security
Requested revision No specific revision (document currently at 16)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2026-02-24
Requested 2026-02-10
Requested by Alvaro Retana
Authors Nick Buraglio , Tal Mizrahi , tongtian , Luis M. Contreras , Fernando Gont
I-D last updated 2026-09-11 (Latest revision 2026-07-29)
Completed reviews Intdir Early review of -11 by Antoine Fressancourt (diff)
Secdir Early review of -11 by Christian Huitema (diff)
Rtgdir Early review of -11 by Andrew Alston (diff)
Opsdir Early review of -11 by Jean-Michel Combes (diff)
Assignment Reviewer Andrew Alston
State Completed
Request Early review on draft-ietf-spring-srv6-security by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/L7M7q4GOYn-O45p9Ni-XZyozvCE
Reviewed revision 11 (document currently at 16)
Result Ready
Completed 2026-03-02
review-ietf-spring-srv6-security-11-rtgdir-early-alston-2026-03-02-00
I have read through the srv6-security document carefully (and a number of
times) and by and large I believe this document to be ready.

What follows are comments for consideration - though I do not believe they will
necessarily prevent the document from moving forward.

Firstly - in section 7.1 it refers to a trusted domain.  I would prefer some
further wording to make it clear that the boundaries of a trusted domain must
be such that the trusted domain does not include, for example, servers
connected to the network that third parties have access to.  I have seen
several companies that have made the assumption that a trusted domain starts
and stops at the peering/transit interfaces and at the CPE.  Forgetting that
hosting servers that customers have access to inside the network create a
breach in the concept of the trusted domain. This is of particular importance
in the case of srv6 - since crafting and sending SRv6 packets from a server
into the network is a trivial exercise.

I would also like to see some text in this document about potential resource
exhausion caused by maintaining wide filter lists (if you have a few thousand
vlans hosting a few thousand servers - you are going to need to apply filtering
to each of them, and this can exhaust TCAM space on various devices, as such
the security mechanisms themselves can create its own issues)

Secondly - from my perspective I believe a document such as this should
probably be a BCP - but this may come later.  My question is why this document
is purely informational rather than a BCP?

Beyond that - I found the document well written and comprehensive, and my
thanks to the authors for all the work put into it.