Hi, Ketan, Thanks for your comments. Please see my reply inline.
发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Ketan Talaulikar (ketant) 发送时间: 2021年7月23日 21:10 收件人: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>>; l...@ietf.org<mailto:l...@ietf.org> 抄送: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org<mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>; pce@ietf.org<mailto:pce@ietf.org> 主题: Re: [Pce] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05 Hello All, I have reviewed this draft and have the following comments for the authors to address and the WG to consider: 1) Is there any precedent for the advertisement of auth keychain info (ID/name) in such a manner that is flooded across the IGP domain? When the actual keychain anyway needs to be configured on all PCCs what is really the value in their advertisement other than possibly exposure to attack? I hope the security directorate reviewer looks at this closely and we get some early feedback specifically on this aspect. [Qiufang Ma] See Acee’s response, thanks Acee. 2) In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art pictures represent the OSPF TLVs. The ISIS TLV structure is different. While this will be obvious to most in this WG, I would request this to be clarified – perhaps by introducing separate diagrams for both protocols or skipping the art altogether. [Qiufang Ma] Good catch, I prefer to skip the art altogether. 3) RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in the text of this document. [Qiufang Ma] This draft is built on top of RFC 5088, therefore the extension defined in this draft is applied to both OSPFv2 and OSPFv3. I understand your confusion in the IANA and will fix this in the IANA. 4) Looks like RFC5088 asked for the PCE Capabilities Flags registry to be created as a top-level IANA OSPF registry - https://datatracker.ietf.org/doc/html/rfc5088#section-7.2 – so it should have been placed here : https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml. What seems to have happened is that it got created under OSPFv2 which is wrong - https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14. Since this draft updates RFC5088, it is necessary for this document to fix this error. I would support Les in that perhaps all of this (i.e. everything under/related to PCED TLV) ought to be moved under the IANA Common IGP registry here : https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml [Qiufang Ma] I tend to agree with you. but I am not sure how to move other existing created registry for Path Computation Element (PCE) Capability Flags available at https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14 to the new location you recommended. https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml I need to request the guidance from our chairs and AD for this. 5) The document needs to be more specific and clear about which IANA registries to be used to avoid errors that have happened in the past (see (3) above). [Qiufang Ma] Please see above. 6) Appendix A, I believe what the authors intended here was that whether to use MD5 auth or not was part of discovery but static configuration on the PCE and PCC? The keychain introduced in this document can also be used along with MD5. Honestly, I don’t see a strong reason to not include MD5 in the signalling except that it is deprecated (even if widely deployed). This document would not conflict or contradict with RFC5440 if it did include a bit for MD5 support as well. As follow-on, perhaps this document should also update RFC5440 – specifically for the security section? I see RFC8253 introducing TLS that updates RFC5440 but nothing that introduces TCP-AO?. In any case, these are aspects for PCE WG so I will leave those to the experts there. [Qiufang Ma] See Qin's reply to Acee. I hope your comment get addressed over there. My personally opinion is MD5 is weak and should be deprecated, thus it doesn't worth new protocol extension for TCP MD5 support. Best Regards, Qiufang Ma Thanks, Ketan From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) Sent: 21 July 2021 22:16 To: l...@ietf.org<mailto:l...@ietf.org> Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org<mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org> Subject: [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05 This begins a 3-week WG Last Call, ending on August 4th, 2021, for draft-ietf-lsr-pce-discovery-security-support. Please indicate your support or objection to this list before the end of the WG last call. The longer WG last call is to account for IETF week. https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ Thanks, Acee
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
