Hi SPRING WG, Authors I support publication of the document. It's well-written and an easy read, and I appreciate how tricky it must have been to balance scoping the document to SRv6 without bleeding into other technology security considerations.
Some minor non-blocking comments and feedback: Introduction: The list of segments is in the SRH and may not be processed at each hop in the case of non-SR capable hops. So Perhaps: OLD "list of segments that are processed at each hop along the signaled path" NEW "list of segments that are processed at each SR capable hop along the signaled path" (or replace /capable/supporting/supported/aware etc. or equivalent) Section 6.3.4.1 Not sure I fully agree with this statement of "single point of failure" depending on the definition of single point of failure. PCE/PCECC can be designed with its own logical distribution/redundancy/ha. So, while it's logically one attack surface from a PCE component perspective, the implementation doesn't necessarily mean "one box" or single-point failure nore does it mean the attack on the single instance is an attack on the entire network (RFC4655). Likewise, not all PCCs in a SR domain may be talking to the same PCE instance. I absolutely do agree however that it is a centralized, focal point for many network element(s) and thus is a key attack vector. Perhaps an adjustment to the text such as.... OLD Centralized control plane architectures, such as those based on the Path Computation Element (PCE) [RFC4655] and PCE as a Central Controller (PCECC) [RFC8283], inherently introduce a single point of failure. This centralization may present a security vulnerability, particularly with respect to denial-of-service (DoS) attacks targeting the controller. Furthermore, the central controller becomes a focal point for potential interception or manipulation of control messages exchanged with individual Network Elements (NEs), thereby increasing the risk of compromise to the overall network control infrastructure. NEW Centralized control plane architectures, such as those based on the Path Computation Element (PCE) [RFC4655] and PCE as a Central Controller (PCECC) [RFC8283], inherently introduce a focal point for attacks against the controller, such as denial-of-service (DoS), or attacks against one or many network element(s) under control of the PCE/PCCC in an SR domain, thereby increasing the risk of compromise to the overall network control infrastructure. Section 7.4: reference I-D.ietf-pce-segment-routing-policy-cp can be updated to RFC9862 Thanks Andrew From: Alvaro Retana via Datatracker <[email protected]> Date: Monday, May 18, 2026 at 3:45 PM To: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [SRv6OPS] Second WG Last Call: draft-ietf-spring-srv6-security-14 (Ends 2026-06-02) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. This message starts a Second WG Last Call for: draft-ietf-spring-srv6-security-14 This Working Group Last Call ends on 2026-06-02 Abstract: SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. File can be retrieved from: Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping [email protected] in copy. Objections should be explained and suggestions to resolve them are highly appreciated. Authors, and WG participants in general, are reminded of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ [2] https://datatracker.ietf.org/doc/bcp79/ [3] https://datatracker.ietf.org/doc/rfc6701/ The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-spring-srv6-security-14.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-srv6-security-14 _______________________________________________ SRv6OPS mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
