On Fri, May 29, 2026 at 6:05 PM Nick Buraglio <[email protected]> wrote:
> > > 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) >> > Adjusted. > >> >> >> 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]
