Hi Qin, I didn't see any response to this email, so I thought I should chip in with some (old, old, old) memories and context.
tl;dr I am generally supportive of this work, but I think a little fine-tuning is needed. If I recall correctly, the situation when 5088 and 5089 were produced was that there was mission creep. The initial idea was to discover the existence of PCE-capable routers in the network, but it was quickly realised a specific address might be preferable for reaching the PCE, so there was need for the PCE Discovery TLV to contain an address, and it was decided to encode it as a TLV. Then the rot set in and we determined there were some other useful pieces of information to encode. And then we thought that it would be helpful to have an array of capability bits. At this point the IGP working groups started to get worried. As Les and Acee noted, the concern was that we would be carrying "large" amounts of data in the IGP that was not directly related to the primary purpose of the IGP (packet routing) or even the secondary purpose (TE). We had a bit of a fight on our hands at this stage because the PCE implementers had already built stuff, and the IGP "purists" were digging in. So we agreed to stabilise with "this far and no further" and the lines in 5088/9 that say: 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. The idea was that it would be OK to define new capability bits, but not to add more TLVs. I don't recall being delighted by this outcome at the time, but it certainly allowed us to move forward. It seemed to me that PCEs were not the only devices exchanging non-routing information in the IGP, and if there was a concern about volume of data or convergence time, then this seemed a bigger problem that needed a more general resolution. On the other hand, IETF consensus is what it is. The approach that others have taken in this situation is to add flags as needed, but to put the additional discovery information in the PCEP Open message. Thus, at a high level, a PCC can decide whether there is any point in opening a PCEP session with a PCE, but may have to try the session to find out exactly what options are available and might, at that time, discover that the PCE is not suitable. Looking at your draft, the addition of the two bit flags is easy and uncontroversial. It is the addition of the Key-ID and Key-Chain-Name sub-TLVs that cause you to want to change the RFCs. And I think you have a special case here because using the TCP security mechanism, the PCEP Open message would come too late to exchange the relevant information. That is, you need the security information to set up the secure TCP session before the PCEP Open messages can be exchanged. This point could usefully be made more clear in the document. That is, why you cannot use the alternate mechanism for exchanging PCE characteristics and capabilities. After that has been done, I think that it would be reasonable to allow the approach you are describing subject to LSR WG consensus. (The alternative, which is perfectly acceptable within the architecture and within some operational environments, is configuration. But configuration doesn't work in the larger use cases, and another mechanism would constitute a third way of exchanging PCE information, and that sounds ridiculous.) However, while I think that you should be allowed through the doorway, I don't think you should leave the door open behind you. That means that you should update 5088/9 to allow your new sub-TLVs, but you should leave in place the ruling that no more new sub-TLVs are allowed. I *think* that is what you're trying to do, but I don't think your Section 4 is the right way to do that - it is not necessary to make edits to the old documents to make this change, you can simply say... 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 RFC 5088 by allowing the two new sub-TLVs defined in this document to be carried in the PCED TLV of the for use 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 RFC 5089 by allowing the two new sub-TLVs defined in this document to be carried in the PCED TLV of the for use in the Router CAPABILITY TLV. Along the way, we're also going to need to do some work on Section 7. The whole point of your draft is to exchange information about security features, and that makes it highly sensitive if it can be attacked. For example, just toggling the two new capability bits can be a downgrade attack. And tweaking the content of the new TLVs would, I imagine, enable man-in-the-middle attacks. At the least, I think you have to use "MUST" to insist that the IGP is protected for authentication and integrity of the PCED TLV if the mechanism described in your draft is used. And I think you should try to describe some of the risks. I'm not sure how sensitive the new TLVs are to snooping, but you should note that section 8 of RFC 5088/9 points out that "OSPF/IS-IS provides no encryption mechanism for protecting the privacy of LSAs" and that if access to this information can make the secure TCP session any less secure then the approach is at risk. Best, Adrian -----Original Message----- From: Lsr <lsr-boun...@ietf.org> On Behalf Of Qin Wu Sent: 04 June 2019 05:18 To: pce@ietf.org; l...@ietf.org Subject: [Lsr] Solicit feeback on draft-ietf-lsr-pce-discovery-security-support-01 Hi, Folks: Draft-ietf-lsr-pce-discovery-security-support was adopted by LSR WG in December 2018 due to security importance for routing protocol. Julien shared his comments and also help look for comments and feedback from PCE WG on this draft during poll adoption call in LSR WG. Recently we made a quick update to draft-ietf-lsr-pce-discovery-security-support without technical content changes. We would like to solicit comments and feedback again on this draft. Thanks in advance! -Qin _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
