Ballot for draft-ietf-spring-srv6-security
Discuss
Yes
No Objection
No Record
Ballot deferred by Deb Cooley on 2026-10-08.
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
** Sections 7.1.1 and 7.1.2. -- Section 7.1.1 says “the current document assumes that SRv6 is a trusted domain and that the traffic is filtered at the domain boundaries. Filtering at SR ingress nodes is intended to mitigate modification and insertion attacks, while filtering at SR egress nodes is intended to mitigate outbound leaks.” -- Section 7.1.2 says “A packet containing an SRH may not be destined to the SR domain, as it may be simply transiting the domain.” These sections appears to be providing conflicting guidance on what crosses the domain boundary of a trusted domain. Section 7.1.1 appears to suggest that SR traffic gets dropped on ingress and egress of the boundary. However, Section 7.1.2 suggests that SR domain might accept packets transiting from outside an SR domain which seems like the definition of an “insertion attack” (inconsistent with the guidance in Section 7.1.1). Likewise, it seems difficult for a node on the boundary of the trust domain to distinguish between SRH legitimately transiting the network from a leaked or forged SRH. Section 7.2 could be suggesting that this language in Section 7.1.2 applies to encapsulated traffic. Is that the only case? If so, the text could be clearer. ** Section 7.4 When the O-flag is used for Operations, Administration, and Maintenance (OAM) functions, as defined in [RFC9259], implementations should enforce rate limiting to mitigate potential denial-of-service (DoS) attacks triggered by excessive control plane signaling. The above guidance seems to be a weaker restated of Section 2.1.1 of RFC9259: The processing node MUST rate-limit the number of packets punted to the OAM process to a configurable rate. This is to avoid impacting the performance of the OAM and telemetry collection processes. Failure to implement the rate limit can lead to a denial-of-service attack, as detailed in Section 3. This document’s text suggests there is flexibility and RFC9259 seems very clear with mandatory guidance. ** Section 7.7, Figure 3 This section lists HMAC as a mitigation for replay attacks. It might be possible to construct a protocol design that makes this possible, but the HMAC TLV defined in RFC8754 doesn’t appear to do that alone. Section 7.3 of this document seems to acknowledge that with the following text: ==[ snip from Section 7.3 ]== * For the lifetime of the pre-shared key validity, an internal attacker who does not have access to the pre-shared key can capture legitimate packets, and later replay the SRH and HMAC from these recorded packets. ==[ snip ]==
Thanks for addressing my previous blocking DISCUSS-level issue and some of my non-blocking COMMENT-level suggestions. Thanks for the work done in this document.
Thank you for a readable and interesting document. I read this from a transport protocol perspective and have no additional comments. Thanks also to Colin Perkins for his TSV-ART review. Best wishes, Gorry
# Gunter Van de Velde, RTG AD, comments for review of draft-ietf-spring-srv6-security-17 # Many thanks to Henning Rogge and Andrew Alston for the RTGDIR review. # Thanks for the nice useful writeup. While reviewing i found two easy to resolve items to discuss and few observations you may want to comment upon. # Through the document please replace the reference to the "last SRH entry" with an explicit field expression. For an ordinary uncompressed SRH, the final policy segment is Segment List[0], not the entry indexed by Last Entry. Please also look into guidance for packets without an SRH and for compressed segment lists. A general instruction to read one SRH entry does not cover those cases, and that should be made explicit within the text. # Within Sections 1 and 3: Make SRH optionality clear from the introduction. Please describe SRv6 as "potentially" using an SRH. This will align the opening explanation with the later filtering discussion and avoid suggesting that SRH detection identifies all SRv6 traffic. # Section 2: Explain how the listed specifications were assessed. RFC 9491 and RFC 9524 are identified as part of the assessment, but their specific behaviors deserve a short explicit explanation of how the general analysis covers them. # Section 6.3.2: Cite the SRv6-specific MSD definitions. It is correct that RFC 8476 supplies the OSPF MSD advertisement framework, but it is insufficient as the sole reference for the SRv6 example. For completeness you could consider to add RFC 9352, Section 4, and RFC 9513, Section 4. They distinguish Maximum Segments Left, Maximum End Pop, Maximum H.Encaps, and Maximum End D MSD types. Brgds, Gunter Van de Velde Routing Area Director
Many thanks to the authors and the WG for this important work on SRv6
security considerations. This would be very helpful for everyone implementing
and deploying SRv6.
Note: This review is provided inline in the idnits output of v17 of this
document. Please look for the tag <EoRv17> at the end to ensure you have the
full review.
#Updated for v18: Thanks for taking care of the discussion points and several
of the comments/suggestions in my original ballot. I've only retained those
(NON-BLOCKING) points that were not updated or perhaps missed out and deleted
all the rest - I leave them to the authors' discretion.
The idnits extracts still refer to v17.
#new for v18 - please fix the warnings reported by idnits, especially the ones
related to references.
<editorial> Perhaps gather the practices for securing an SR domain, now spread
across Sections 7.1.1 to 7.2 and 8.2, into a short subsection, for example:
NEW (perhaps subsection after 7.2?)
The practices described in Sections 7.1 and 7.2 can be summarized as
follows:
* Allocate SIDs from a dedicated address block (Section 7.1.3,
[RFC9602]), separate from infrastructure and customer addresses.
* Use a hierarchical locator plan that summarizes into a few
prefixes [I-D.ietf-srv6ops-srv6addressing].
* Filter packets destined to the SID block at the SR domain
boundary and at SRv6 enabled nodes, together with ingress source
address validation (BCP 38, BCP 84) (Section 7.1.3; Section 5.1
of [RFC8754]).
* Encapsulate traffic at the SR ingress node (Section 7.2).
* Do not advertise locators, the SID block, or SR information in
BGP outside the SR domain ([RFC8402], Section 9.2 of [RFC9252]).
* Where hosts add an SRH, consider the HMAC TLV (Section 7.3;
Section 5.2 of [RFC8754]).
Again, just a suggestion for the authors' consideration.
<about references> Unless the analysis is extended to them, RFC 9020, RFC 9256,
RFC 9491 and RFC 9524 could move to the Informative References: nothing in the
document as written seems to depends on them?
Rest of the comments/suggestions are provide inline in the document text:
896 In order to apply such a filtering mechanism the SR domain needs to
897 have an infrastructure address range for SIDs and an infrastructure
898 address range for source addresses that can be detected and enforced.
<minor> Section 7.1.3 could align with draft-ietf-srv6ops-srv6addressing: SIDs
from a range separate from infrastructure and customer addressing (it calls
the SID range "infrastructure"), loopbacks optionally taken from the locator,
and a hierarchical plan that summarizes so the filters stay few. Now, that
draft is focussed on CSID, but the hierarchical and summarization aspects apply
for all of SRv6. Suggest:
CURRENT
In order to apply such a filtering mechanism the SR domain needs to
have an infrastructure address range for SIDs and an infrastructure
address range for source addresses that can be detected and enforced.
SUGGEST
In order to apply such a filtering mechanism the SR domain needs to
have an address range for SIDs, separate from the infrastructure and
customer address ranges, and an infrastructure address range for
source addresses, both of which can be detected and enforced.
CURRENT
Many operators reserve a /64 block for all loopback addresses and
allocate /128 for each loopback interface. This simplifies the
filtering of permitted source addresses.
SUGGEST
Many operators reserve a /64 block for all loopback addresses and
allocate /128 for each loopback interface. This simplifies the
filtering of permitted source addresses. Alternatively, loopback
addresses can be allocated from each node's locator
[I-D.ietf-srv6ops-srv6addressing], in which case the permitted source
addresses are covered by the SID address range. In either case, a
hierarchical addressing plan whose locators summarize at domain and
area boundaries [I-D.ietf-srv6ops-srv6addressing] keeps the filters
to a few stable prefixes.
920 Many operators reserve a /64 block for all loopback addresses and
921 allocate /128 for each loopback interface. This simplifies the
922 filtering of permitted source addresses.
<minor> Loopback addresses can alternatively be allocated from each node's
locator, and a hierarchical locator plan keeps the source-address filters to a
few stable prefixes. Please see my comments on line 896, which include
suggested text for this paragraph.
<EoRv17>
# IESG review of draft-ietf-spring-srv6-security-17 CC @MikeBishop ## Comments ### Section 2, paragraph 8 ``` * [RFC9256] : Segment Routing Policy Architecture * [RFC9491] : Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC) * [RFC9524] : Segment Routing Replication for Multipoint Service ``` These RFCs are never mentioned again in the document. If they're relevant, why not? RFC 9524 Section 4 has SRv6-specific threats this taxonomy should discuss: replication-segment loops that "create a storm until ... IPv6 Hop Limit ... decrements to zero", ICMPv6 Parameter Problem storms toward a spoofed source via a Replication-SID, the Hop Limit Threshold mitigation, and injection into a P2MP service. RFC 9256 Section 10 adds SR Policy endpoint spoofing / duplicate advertisement causing traffic diversion. ### Section 7.1.3, paragraph 11 ``` [RFC8754]'s description of packet filtering. There are no known limitations with filtering on infrastructure addresses, and [RFC9099] ``` ...other than the ones you point out in Section 7.1.1? ### Section 7.2, paragraph 1 ``` forwarding decisions within the domain never depend on header fields supplied by an untrusted source. Decapsulating and forwarding the ``` Is this true of flow labels / ECMP? ### Section 7.3, paragraph 7 ``` * For the lifetime of the pre-shared key validity, an internal attacker who does not have access to the pre-shared key can ``` Doesn't section 4 define an attacker without the keys to be external? "An internal attacker" who is external by definition seems inherently contradictory. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 5, paragraph 13 ``` - amplification by increasing the number hops that each packet is + amplification by increasing the number of hops that each packet is + +++ ``` #### Section 6.3.4.1, paragraph 1 ``` - PCE/PCCC in an SR domain, thereby increasing the risk of compromise + PCE/PCECC in an SR domain, thereby increasing the risk of compromise + + ``` #### Section 7.1.3, paragraph 8 ``` - making it more simple to filter traffic at the edge of the SR - ----- + making it simpler to filter traffic at the edge of the SR + + ``` #### Section 7.2, paragraph 1 ``` - directly from untrusted-facing interfaces.This is a specific case of + directly from untrusted-facing interfaces. This is a specific case of + + ``` ### Section 2, paragraph 9 Who is "we"? The IETF? The WG? The authors? In general, first person should be avoided. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Hi Nick, Tal, Tian , Luis, and Fernando,
Thank you for the effort put into this document.
Thanks also to Jean-Michel Combes for the OSPDIR review and the authors for engaging.
Several of the attacks in the document are also applicable to non-SR as an attacker that act from within a network can do a lot of damage, for example, this one:
- Causing packets to be discarded: an attacker may cause a packet
to be forwarded to a point in the network where it can no
longer be forwarded, causing the packet to be discarded.
..but that is OK.
Please find below some few comments:
# For authors convenience, I sent a PR with some suggestions: https://github.com/buraglio/draft-bdmgct-spring-srv6-security/pull/79.
# Steering is a TE function
CURRENT:
SRv6 is a traffic engineering, encapsulation and steering mechanism
utilizing
TE/steering is redundant. Please refer to TE components in RFC9522.
# The text can be simplified and avoid repetition. For example, the following can be simply deleted:
CURRENT:
SRv6 is
fundamentally bound to the IPv6 protocol and introduces the
aforementioned new extension header.
Or
* SRv6 may use the SRH which is a type of Routing Extension Header
defined by [RFC8754].
# Clarification
CURRENT:
* While SRv6 uses what appear to be typical IPv6 addresses, the
address space is processed differently by segment endpoints. A
typical IPv6 unicast address is comprised of a network prefix and
a host identifier.
and other SID list mention;
Check if e a reminder of the clarifications in draft-ietf-6man-sidlist-clarification is useful here.
# Not sure how this is used in the document
CURRENT:
The following IETF RFCs were selected for security assessment as part
of this effort:
* [RFC8402] : Segment Routing Architecture
* [RFC8754] : IPv6 Segment Routing Header (SRH)
* [RFC8986] : Segment Routing over IPv6 (SRv6) Network Programming
* [RFC9020] : YANG Data Model for Segment Routing
* [RFC9256] : Segment Routing Policy Architecture
* [RFC9491] : Integration of the Network Service Header (NSH) and
Segment Routing for Service Function Chaining (SFC)
* [RFC9524] : Segment Routing Replication for Multipoint Service
Delivery
* [RFC9800] : Compressed SRv6 Segment List Encoding
For example, how the SFC/NSH was used in the analysis?
# Source routing in general
CURRENT:
This may allow an attacker to perform a number
of attacks on the victim networks and hosts that would be mostly
unfeasible for a non-SRv6 environment.
I don’t think this is accurate as this would apply for any source routing approach.
# Billing bypass
CURRENT:
example in order to avoid the billing service or circumvent
access controls and security filters.
I don’t this one
# Idem for this one:
CURRENT:
This can result in
allowing various unauthorized services such as traffic
acceleration.
# Use RFC9907#section 3.7.1 boilerplate instead
CURRENT:
Management protocols such as NETCONF [RFC6241] and RESTCONF [RFC8040]
are commonly used to configure and monitor SRv6-enabled devices.
These protocols must be secured to prevent unauthorized access,
configuration tampering, or information leakage.
The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is TLS [RFC9846].
Cheers,
Med