Hi all, I'm going to say what I can remember before I read the thread. I was PCE co-chair as this work went through.
There was a feeling that using the IGPs for carrying "stuff" was not a wise idea. It was one thing to exchange information that all participants in the protocol needed to perform the functions of the IGP, another to use the IGP for information that most of the routers would need to know, and not great to use the IGP for sharing information only some of the routers need to know. The PCE capabilities exchange in the IGP was always a bit of a stretch. Learning of the existence of a PCE in a network of routers that all use the PCE function might be valuable thing (although there are many other ways to discover servers). And it may be helpful, when there are many PCEs available, to provide enough information to allow selection between servers. But that became a heavy load as more and more optional PCE features were added and the amount of information carried by the IGP was set to keep growing. The main worry was, of course, not the definition of a few additional bits, but the inclusion of additional TLVs. Since PCEP has a mechanism for PCEs to advertise and negotiate their capabilities, and since the main discovery issues were already covered by the IGP work, it seemed reasonable to draw a line. We could have asked to take the new capabilities one by one, but it seemed like everyone's favourite capability was going to be argued as a special case, so we drew a very solid line and said "no new sub-TLVs". This rule allowed new flags (since there were plenty of unused flags available) and you can see how this has been used in the registry with another 8 flags defined by 5 RFCs). Now, the question with this I-D is about whether the issues of protocol security are sufficiently special case to warrant allowing new TLVs in the IGP. And, in particular, if the capabilities exchange for security is left to the PCEP initialisation steps, are those steps secure enough to prevent downgrade attacks. Cheers, Adrian -----Original Message----- From: John Scudder <[email protected]> Sent: 04 October 2022 18:29 To: Lars Eggert <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; lsr <[email protected]>; Acee Lindem <[email protected]>; [email protected]; Hannes Gredler <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; [email protected]; [email protected]; Adrian Farrel <[email protected]> Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT) Hi Everyone, +Adrian since he appears to have been the shepherd for RFC 5088, which is the root of Lars’ DISCUSS. +Hannes, Les, JP, Meral as people who may have more context on the question Since I haven’t seen any replies to this DISCUSS yet I did a little digging. The text in question: No additional sub-TLVs will be added to the PCED TLV in the future. If a future application requires the advertisement of additional PCE information in OSPF, this will not be carried in the Router Information LSA. Was introduced in draft-ietf-pce-disco-proto-ospf-07, September 2007. Checking in the archives, I see one relevant mail thread: https://mailarchive.ietf.org/arch/msg/pce/UERk8vF5e7cFQoblkDAVA74Ojh0/ is the beginning, but then it seems to have been indexed wrong so you should continue from here: https://mailarchive.ietf.org/arch/msg/isis-wg/BpUVKsjr46ha9kbF3jwgKyymEBo/ to pick up Les’s reply as well. There are four relevant messages in total, from Meral Shirazipour, JP Vasseur, Hannes Gredler, and Les Ginsberg. Rather than try to summarize I’m going to ask people to go look at the short mail thread for themselves. Perhaps this will jog people’s memories enough to allow a discussion on why we’re opening a registry for new code points that was explicitly defined as being closed. Thanks, —John > On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker <[email protected]> > wrote: > > > Lars Eggert has entered the following ballot position for > draft-ietf-lsr-pce-discovery-security-support-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8J-BPa3$ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt2I779yk$ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > # GEN AD review of draft-ietf-lsr-pce-discovery-security-support-11 > > CC @larseggert > > ## Discuss > > ### Section 4, paragraph 3 > ``` > Section 4 of [RFC5088] states that no new sub-TLVs will be added to > the PCED TLV, and no new PCE information will be carried in the > Router Information LSA. This document updates [RFC5088] by allowing > the two sub-TLVs defined in this document to be carried in the PCED > TLV advertised in the Router Information LSA. > > Section 4 of [RFC5089] states that no new sub-TLVs will be added to > the PCED TLV, and no new PCE information will be carried in the > Router CAPABLITY TLV. This document updates [RFC5089] by allowing > the two sub-TLVs defined in this document to be carried in the PCED > TLV advertised in the Router CAPABILITY TLV. > > This introduction of additional sub-TLVs should be viewed as an > exception to the [RFC5088][RFC5089] policy, justified by the > requirement to discover the PCEP security support prior to > establishing a PCEP session. The restrictions defined in > [RFC5089][RFC5089] should still be considered to be in place. > ``` > (This is mostly for discussion on the telechat, and I expect to clear > during the call.) > > Why were 5088/89 so strict on not allowing new sub-TLVs? This seems > quite unusual for IETF specs. I'm not arguing that this document > can't update those earlier RFCs to allow these new sub-TLVs, but it > seems odd to do so and in the same sentence say "the restrictions > should still be considered in place." > > ### Section 8.2, paragraph 1 > ``` > The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they > did not create a registry for it. This document requests IANA to > create a new registry called "PCED sub-TLV type indicators" under the > "Interior Gateway Protocol (IGP) Parameters" grouping. The > registration policy for this registry is "IETF Review" [RFC8126]. > Values in this registry come from the range 0-65535. > ``` > Should the registration policy not be stricter (e.g., Standards > Action?) given that 5088/89 didn't even allow any new values? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ## Comments > > ### Inclusive language > > Found terminology that should be reviewed for inclusivity; see > https://urldefense.com/v3/__https://www.rfc-editor.org/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt1fwrlFS$ > for background and more > guidance: > > * Term `master`; alternatives might be `active`, `central`, `initiator`, > `leader`, `main`, `orchestrator`, `parent`, `primary`, `server` > * Term `man`; alternatives might be `individual`, `people`, `person` > > ## Nits > > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via > https://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxqHvOEf$ > ), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > ### URLs > > These URLs in the document can probably be converted to HTTPS: > > * > https://urldefense.com/v3/__http://www.unicode.org/unicode/reports/tr36/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt9o1UwDk$ > > ### Grammar/style > > #### "Abstract", paragraph 1 > ``` > for OSPF and IS-IS respectively. However these specifications lack a method > ^^^^^^^ > ``` > A comma may be missing after the conjunctive/linking adverb "However". > (Also elsewhere.) > > #### Section 1, paragraph 5 > ``` > ry" instead of the "IGP registry" where as [RFC8623] and [RFC9168] uses the > ^^^^^^^^ > ``` > Did you mean "whereas"? > > #### Section 3.2.2, paragraph 3 > ``` > string to be used to identify the key chain. It MUST be encoded using UTF-8. > ^^^^^^^^^ > ``` > This word is normally spelled as one. (Also elsewhere.) > > #### Section 5, paragraph 4 > ``` > enable a man-in-the-middle attack. Thus before advertising the PCEP security > ^^^^ > ``` > A comma may be missing after the conjunctive/linking adverb "Thus". > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. > > [ICMF]: > https://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8uPawyE$ > [ICT]: > https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxU9hxDt$ > [IRT]: > https://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxqHvOEf$ > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
