Hi Acee, Indeed the mechanism for key rollover is well documented and widely implemented via configuration/provisioning methods.
My question was regarding how the specific steps/procedures as described in https://datatracker.ietf.org/doc/html/rfc8177#section-2.2 are going to get realized in this proposal where we have an IGP and PCEP protocols in operation. To me the use of this mechanism in such dynamic and distributed routing protocol operations seems to be under-specified for a standards track document – not good enough for ensuring interoperable implementations. Hope that clarifies and I’ll rest my case with that. Thanks, Ketan From: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> Sent: 23 July 2021 22:24 To: Ketan Talaulikar (ketant) <ket...@cisco.com>; l...@ietf.org Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; pce@ietf.org Subject: Re: WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05 Hi Ketan, From: "Ketan Talaulikar (ketant)" <ketant=40cisco....@dmarc.ietf.org<mailto:ketant=40cisco....@dmarc.ietf.org>> Date: Friday, July 23, 2021 at 11:20 AM To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "l...@ietf.org<mailto:l...@ietf.org>" <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>" <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>" <pce@ietf.org<mailto:pce@ietf.org>> Subject: RE: WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05 Hi Acee, Agree about the keychain provisioning part. The distribution via IGP for the key selections and the handling of the same in PCEP sounded new to me. Is there any precedent for this? How does it all work actually and what is needed on the PCE and PCC to handle the change/transitions – this is all missing – probably needs a PCEP spec? This is many PCCs trying to connect to a PCE. I was trying to understand this better and how all that weighs against a potential for attack/disruption by someone doing a M-i-M or replay attack. Roll-over of keys with key-chains is well-understood. https://datatracker.ietf.org/doc/html/rfc8177#section-2.2 As is TCP-AO and TLS authentication. The only further specification required would the configuration in the PCE YANG model(s). Thanks, Acee Just some questions … as this seemed something new to me and the spec does not provide any pointers. Thanks, Ketan From: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>> Sent: 23 July 2021 18:52 To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; 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>; pce@ietf.org<mailto:pce@ietf.org> Subject: Re: WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05 Hi Ketan, From: "Ketan Talaulikar (ketant)" <ketant=40cisco....@dmarc.ietf.org<mailto:ketant=40cisco....@dmarc.ietf.org>> Date: Friday, July 23, 2021 at 9:10 AM To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "l...@ietf.org<mailto:l...@ietf.org>" <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>" <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>" <pce@ietf.org<mailto:pce@ietf.org>> Subject: RE: 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. The key-chain mechanism was standardized in RFC 8177 and is referenced by all the routing protocol YANG models. While key-chains, as well as, pre-shared keys need to be configured, having multiple configured key-chains that are selectable via discovery is obviously more operationally secure than having a single one. 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. 3) RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in the text of this document. 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 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). 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. 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
