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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Jul 2021 16:45:45 +0000

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Jul 2021 18:06:30 +0000

I support progression of this document.

Regarding the new registry being requested in Section 8.2, given that the registry applies to both OSPF and IS-IS codepoints, I think it would make more sense to place the registry under Interior Gateway Protocol (IGP) Parameters rather than under OSPF.

   Les

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, July 21, 2021 9:46 AM
To: [email-masked]
Cc: [email-masked]
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

Thanks,
Acee

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 23 Jul 2021 13:09:46 +0000

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.
  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

Sent: 21 July 2021 22:16

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 23 Jul 2021 13:22:11 +0000

Hi Ketan,

From: "Ketan Talaulikar (ketant)" <ketant=[email-masked]>
Date: Friday, July 23, 2021 at 9:10 AM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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,

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

Thanks,
Acee

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 23 Jul 2021 15:19:21 +0000

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.

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=[email-masked]>
Sent: 23 July 2021 18:52
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
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=[email-masked]<mailto:ketant=[email-masked]>>
Date: Friday, July 23, 2021 at 9:10 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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,

Thanks,
Acee

Thanks,
Ketan

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
Sent: 21 July 2021 22:16
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 23 Jul 2021 16:53:50 +0000

Hi Ketan,

Date: Friday, July 23, 2021 at 11:20 AM

Hi Acee,

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

Thanks,
Ketan

Hi Ketan,

Hello All,

Thanks,
Acee

Thanks,
Ketan

Thanks,
Acee

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 23 Jul 2021 17:10:06 +0000

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

Sent: 23 July 2021 22:24

Hi Ketan,

Hi Acee,

Thanks,
Acee

Thanks,
Ketan

From: Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>
Sent: 23 July 2021 18:52
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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,

Hello All,

Thanks,
Acee

Thanks,
Ketan

Thanks,
Acee