Hi Tim, I don't disagree with your intent and motivation on this aspect. The question is whether this document that introduces a very specific extension is the place to do this.
The PCE WG is on this thread and I hope they get this message. AFAIK the progress on "PCEPS" implementations has been slow but I now see some movement that gives me some optimism. Thanks, Ketan On Fri, Mar 13, 2026 at 11:47 PM Tim Hollebeek <[email protected]> wrote: > Actually, that would put a Requirement in the Considerations section, > which is generally a bad idea. But I think you get my gist, if TLS is a > requirement for doing this securely, I would like to see a way found to put > that MUST requirement into the draft, so that people MUST do the right > thing. > > -Tim > ------------------------------ > *From:* Tim Hollebeek <[email protected]> > *Sent:* Friday, March 13, 2026 1:10 PM > *To:* Samuel Sidor (ssidor) <[email protected]>; [email protected] < > [email protected]> > *Cc:* [email protected] < > [email protected]>; > [email protected] <[email protected]>; [email protected] <[email protected]> > *Subject:* [secdir] Re: draft-ietf-pce-circuit-style-pcep-extensions-15 > ietf last call Secdir review > > 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]
