Is there a reason why it can't continue ", and therefore TLS MUST be used in these situations." ?
If not, I agree your proposal is an improvement and support it. -Tim ________________________________ From: Samuel Sidor (ssidor) <[email protected]> Sent: Thursday, March 12, 2026 4:23 AM To: Tim Hollebeek <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: draft-ietf-pce-circuit-style-pcep-extensions-15 ietf last call Secdir review Hi Tim, Thanks for the review and for the comment raised. The security section structure follows the standard pattern used across other PCEP drafts/RFCs, e.g. RFC 8231, RFC 8281, RFC 8664, RFC 9357, … These use similar references to the base security considerations from existing RFCs. That is intentional: those documents, especially RFC 8253 and RFC 8231, already cover the security requirements for PCEP sessions in detail, and we don't want to duplicate or potentially contradict them. I think the valid part of your comment is the concern about the connection between the specific threat we described and the mitigation. The draft does both — paragraph 2 explicitly calls out the new vulnerability (an attacker could manipulate PATH-MODIFICATION flags to block path updates, causing a traffic drop), and paragraph 3 describes the mitigation (use TLS per RFC 8253/RFC 9325). But I can still make it more explicit: As per RFC 8231, it is RECOMMENDED that these PCEP extensions can only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253][I-D.ietf-pce-pceps-tls13] as per the recommendations and best current practices in [RFC9325]. In particular, the integrity protection provided by TLS mitigates the attack described above where an attacker could manipulate path modification constraints to cause a traffic disruption. Would that work for you? Thanks, Samuel From: Tim Hollebeek via Datatracker <[email protected]> Date: Wednesday, 11 March 2026 at 21:57 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: draft-ietf-pce-circuit-style-pcep-extensions-15 ietf last call Secdir review Document: draft-ietf-pce-circuit-style-pcep-extensions Title: Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies Reviewer: Tim Hollebeek Review result: Has Issues I'm not exactly an expert in routing, but I'm a bit concerned about the security considerations section. If my understanding of the descriptions of the security issues is correct, there are a variety of other complicated RFCs whose security considerations sections need to be read and considered carefully. There's a fair amount of subtlety, and it seems fairly easy to make mistakes with serious consequences. This is not entirely obvious without diving into the referenced security considerations. Perhaps the section could be expanded with better guidance about what choices implementers need to make to avoid introducing problems when implementing this RFC. I'm concerned that the existing RECOMMENDATION might be easily missed, with unfortunate consequences.
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
