On Thu, May 21, 2026 at 12:53 PM Andrew Stone (Nokia) < [email protected]> wrote:
> 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. > > Agreed, added. > > Section 7.4: > > reference I-D.ietf-pce-segment-routing-policy-cp can be updated to RFC9862 > Done. > > > 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]
