Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
Still waiting on this mail to the list. Thanks, Chris. > On Jul 21, 2021, at 6:18 PM, Christian Hopps wrote: > > The WGLC has ended. > > I may have missed it but I do not see any feedback from Xiaodong Duan for > IPR. That is still required to the list. > > Thanks, > Chris. > >> On Feb 17, 2021, at 10:30 AM, Christian Hopps wrote: >> >> Hi LSR and TEAS, >> >> This begins a joint WG last call for: >> >> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/ >> >> Please discuss any issues on the LSR mailing list. The WGLC will end March >> 3, 2021. >> >> Authors, please indicate wether you are aware of any IPR related to this >> document to the list. >> >> Thanks, >> Chris, Acee, (Lou and Pavan). >> ___ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
Speaking as a WG Member: In reviewing RFC 8919 and RFC 8920, it is clear that the ASLA mechanism was to be used for new link attributes and applications. While the documents do not mandate that there never could be a new way to advertise link attributes, this was clearly the intent. Indeed, it would be strange for an RFC to include a mandate that precluded future proposals. The advertisement enablement and deployment sections of these documents specifically cover future attributes and applications. Given that we have ASLAs as building blocks, I don’t really see a reason to introduce the generic metric. The proponents say it isn’t an alternative to ASLAs but their examples cite different applications using different metric types (i.e., application-specific metrics). Also, given that ASLA are used by the base Flex Algo draft, it would be inconsistent to diverge for Flex Algo BW constraints. Consequently, I would request that draft-ietf-lsr-flex-algo-bw-con-01 revert to using ASLAs. Based on the LSR Email discussion prior to IETF 111, this was definitely the consensus. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Rtgdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
Reviewer: Ron Bonica Review result: Ready Good idea! ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
From: Lsr on behalf of Yaron Sheffer Sent: 10 August 2021 14:57 So let me suggest: An offlist suggestion for you to consider OLD Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP protects the authentication and integrity of the PCED TLV using the mechanisms defined in [RFC5310] and [RFC5709], if the mechanism described in this document is used. Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not provide any encryption mechanisms to protect the secrecy of the PCED TLV, and the operator must ensure that no private data is carried in the TLV, for example that key names do not reveal sensitive information about the network. NEW Thus before advertising the PCE security parameters, using the mechanism described in this document, the IGP MUST be known to provide authentication and integrity for the PCED TLV using the mechanisms defined in [RFC5304], [RFC5310] or [RFC5709], Moreover, as stated in [RFC5088] and [RFC5089], if the IGP does not provide any encryption mechanisms to protect the secrecy of the PCED TLV, then the operator must ensure that no private data is carried in the TLV, e.g. that key names do not reveal sensitive information about the network. Tom Petch Thanks, Yaron On 8/10/21, 15:01, "Qin Wu" wrote: Yaron: Thank for clarification. I agree to keep the last sentence in the second paragraph of section 7 as is. But I prefer to add the addition references in the previous sentence as follows: " Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP is protected for authentication and integrity of the PCED TLV,, with the mechanisms defined in [RFC5310] and [RFC5709] if the mechanism described in this document is used. As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration. " If you better wording, please let me know. -Qin -邮件原件- 发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 发送时间: 2021年8月10日 19:26 收件人: Qin Wu ; sec...@ietf.org 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org 主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 Hi Qin, Sorry, but I find your latest proposed text very confusing, because we should be focusing on integrity protection and not privacy (=secrecy) of the TLV. So I would prefer to keep the text as-is, with the addition of a reference to the IS-IS and OSPF security mechanisms that were discussed on this thread. Thanks, Yaron On 8/10/21, 05:00, "Qin Wu" wrote: Hi, Yaron -邮件原件- >发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] >发送时间: 2021年8月9日 21:44 >收件人: Qin Wu ; sec...@ietf.org >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org >主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 >Hi Qin, >Thank you for your response. >* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 5304 still uses HMAC-MD5, which would be considered insecure nowadays. >* RFC 2154 is very old and Experimental (and only supports RSA-MD5 signatures). I'm not an OSPF expert by any means, but I'm willing to bet that there are no production implementations of this RFC. (I'm willing to be proven wrong). >Is there another RFC that define a protection mechanism for OSPF? >All in all, there appear to be no good options for the IGP. [Qin Wu]Yes, we do have alternatives, see Les's response in the separate email " On 8/9/21, 23:36,"Les Ginsberg (ginsberg)" wrote: For IS-IS security please also see RFC 5310. For OSPF security please see RFC 5709. " >To your last point, when I mentioned decoupling the mechanisms, I was suggesting to use the extension you define even if the IGP *cannot* be secured. If you think this is reasonable, please add such text to the Security Considerations. [Qin Wu] Okay, how about the following change OLD TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration . " NEW TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration
Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
Agree, thanks Les for additional suggestions. 发件人： Les Ginsberg (ginsberg)mailto:ginsb...@cisco.com>> 收件人： Qin Wumailto:bill...@huawei.com>>;Yaron Sheffermailto:yaronf.i...@gmail.com>>;secdirmailto:sec...@ietf.org>> 抄送： draft-ietf-lsr-pce-discovery-security-support.allmailto:draft-ietf-lsr-pce-discovery-security-support@ietf.org>>;last-callmailto:last-c...@ietf.org>>;lsrmailto:lsr@ietf.org>> 主题： RE: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 时间： 2021-08-10 22:47:05 Qin - Just to note that RFC 5310 does NOT replace or obsolete RFC 5304. Both RFC 's have their uses. Please be sure to reference both RFCs in your updated text. Thanx. Les > -Original Message- > From: Qin Wu > Sent: Monday, August 9, 2021 6:13 PM > To: Les Ginsberg (ginsberg) ; Yaron Sheffer > ; sec...@ietf.org > Cc: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last- > c...@ietf.org; lsr@ietf.org > Subject: RE: Secdir last call review of draft-ietf-lsr-pce-discovery-security- > support-05 > > Thanks Les for the pointer, I was looking into RFC6863 in KARP WG and found > RFC5709 for OSPF security as well. > Yes, I agree to use RFC5310 to replace RFC5304 for IS-IS security. > > Regarding the debate about MUST vs SHOULD, thanks for clarification. yes, > whether to choose IGP advertisement is implementation specific. Operator > will make their choice. > So I think I tend to agree to use SHOULD for client behavior. Thanks. > > -Qin > -邮件原件- > 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > 发送时间: 2021年8月9日 23:36 > 收件人: Yaron Sheffer ; Qin Wu > ; sec...@ietf.org > 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last- > c...@ietf.org; lsr@ietf.org > 主题: RE: Secdir last call review of draft-ietf-lsr-pce-discovery-security- > support-05 > > Yaron/Qin - > > For IS-IS security please also see RFC 5310. > For OSPF security please see RFC 5709. > > Regarding the debate about MUST vs SHOULD, as I see it advertisement of > this information is an option. The IGP might not have access to this > information in a given implementation/deployment - and I can easily imagine > that some customers might prefer NOT to advertise this information in an > IGP even if it were available. > > It is useful to check the wording used in https://www.rfc- > editor.org/rfc/rfc5089.html#section-4 . There, those sub-TLVs which are > necessary for the PCED sub-TLV to be useful at all are required - but other > sub-TLVs are optional. I think these new sub-TLVs fall into the latter > category. > >Les > > > -Original Message- > > From: Lsr On Behalf Of Yaron Sheffer > > Sent: Monday, August 9, 2021 6:44 AM > > To: Qin Wu ; sec...@ietf.org > > Cc: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last- > > c...@ietf.org; lsr@ietf.org > > Subject: Re: [Lsr] Secdir last call review of > > draft-ietf-lsr-pce-discovery- > > security-support-05 > > > > Hi Qin, > > > > Thank you for your response. > > > > * RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC > > 5304 still uses HMAC-MD5, which would be considered insecure nowadays. > > * RFC 2154 is very old and Experimental (and only supports RSA-MD5 > > signatures). I'm not an OSPF expert by any means, but I'm willing to > > bet that there are no production implementations of this RFC. (I'm > > willing to be proven wrong). Is there another RFC that defines a > > protection mechanism for OSPF? > > > > All in all, there appear to be no good options for the IGP. > > > > To your last point, when I mentioned decoupling the mechanisms, I was > > suggesting to use the extension you define even if the IGP *cannot* be > > secured. If you think this is reasonable, please add such text to the > > Security Considerations. > > > > Thanks, > > Yaron > > > > On 8/9/21, 16:09, "Qin Wu" wrote: > > > > Thanks Yaron for valuable comments, please see my reply inline below. > > -邮件原件- > > >发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org] > > >发送时间: 2021年8月6日 3:25 > > >收件人: sec...@ietf.org > > >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; > > last- c...@ietf.org; lsr@ietf.org > > >主题: Secdir last call review of > > draft-ietf-lsr-pce-discovery-security- > > support-05 > > > > >Reviewer: Yaron Sheffer > > >Review result: Not Ready > > > > >This document defines a mechanism (a TLV) to advertise the PCE > > Protocol security required (use of TCP-AO and its key ID, or > > alternatively use of TLS) within the routing protocol being used. > > > > >* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST. > > Especially given the strict client behavior defined later. > > [Qin]: I believe "SHOULD advertise" is consistent with client > > behavior defined later, i.e., we apply SHOULD NOT language to the client > behavior. > > I am not sure we should change it into strong language with MUST. > > Since if IGP advertisement doesn
Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
Qin - Just to note that RFC 5310 does NOT replace or obsolete RFC 5304. Both RFC 's have their uses. Please be sure to reference both RFCs in your updated text. Thanx. Les > -Original Message- > From: Qin Wu > Sent: Monday, August 9, 2021 6:13 PM > To: Les Ginsberg (ginsberg) ; Yaron Sheffer > ; sec...@ietf.org > Cc: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last- > c...@ietf.org; lsr@ietf.org > Subject: RE: Secdir last call review of draft-ietf-lsr-pce-discovery-security- > support-05 > > Thanks Les for the pointer, I was looking into RFC6863 in KARP WG and found > RFC5709 for OSPF security as well. > Yes, I agree to use RFC5310 to replace RFC5304 for IS-IS security. > > Regarding the debate about MUST vs SHOULD, thanks for clarification. yes, > whether to choose IGP advertisement is implementation specific. Operator > will make their choice. > So I think I tend to agree to use SHOULD for client behavior. Thanks. > > -Qin > -邮件原件- > 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > 发送时间: 2021年8月9日 23:36 > 收件人: Yaron Sheffer ; Qin Wu > ; sec...@ietf.org > 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last- > c...@ietf.org; lsr@ietf.org > 主题: RE: Secdir last call review of draft-ietf-lsr-pce-discovery-security- > support-05 > > Yaron/Qin - > > For IS-IS security please also see RFC 5310. > For OSPF security please see RFC 5709. > > Regarding the debate about MUST vs SHOULD, as I see it advertisement of > this information is an option. The IGP might not have access to this > information in a given implementation/deployment - and I can easily imagine > that some customers might prefer NOT to advertise this information in an > IGP even if it were available. > > It is useful to check the wording used in https://www.rfc- > editor.org/rfc/rfc5089.html#section-4 . There, those sub-TLVs which are > necessary for the PCED sub-TLV to be useful at all are required - but other > sub-TLVs are optional. I think these new sub-TLVs fall into the latter > category. > >Les > > > -Original Message- > > From: Lsr On Behalf Of Yaron Sheffer > > Sent: Monday, August 9, 2021 6:44 AM > > To: Qin Wu ; sec...@ietf.org > > Cc: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last- > > c...@ietf.org; lsr@ietf.org > > Subject: Re: [Lsr] Secdir last call review of > > draft-ietf-lsr-pce-discovery- > > security-support-05 > > > > Hi Qin, > > > > Thank you for your response. > > > > * RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC > > 5304 still uses HMAC-MD5, which would be considered insecure nowadays. > > * RFC 2154 is very old and Experimental (and only supports RSA-MD5 > > signatures). I'm not an OSPF expert by any means, but I'm willing to > > bet that there are no production implementations of this RFC. (I'm > > willing to be proven wrong). Is there another RFC that defines a > > protection mechanism for OSPF? > > > > All in all, there appear to be no good options for the IGP. > > > > To your last point, when I mentioned decoupling the mechanisms, I was > > suggesting to use the extension you define even if the IGP *cannot* be > > secured. If you think this is reasonable, please add such text to the > > Security Considerations. > > > > Thanks, > > Yaron > > > > On 8/9/21, 16:09, "Qin Wu" wrote: > > > > Thanks Yaron for valuable comments, please see my reply inline below. > > -邮件原件- > > >发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org] > > >发送时间: 2021年8月6日 3:25 > > >收件人: sec...@ietf.org > > >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; > > last- c...@ietf.org; lsr@ietf.org > > >主题: Secdir last call review of > > draft-ietf-lsr-pce-discovery-security- > > support-05 > > > > >Reviewer: Yaron Sheffer > > >Review result: Not Ready > > > > >This document defines a mechanism (a TLV) to advertise the PCE > > Protocol security required (use of TCP-AO and its key ID, or > > alternatively use of TLS) within the routing protocol being used. > > > > >* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST. > > Especially given the strict client behavior defined later. > > [Qin]: I believe "SHOULD advertise" is consistent with client > > behavior defined later, i.e., we apply SHOULD NOT language to the client > behavior. > > I am not sure we should change it into strong language with MUST. > > Since if IGP advertisement doesn't include TCP-AO > > support flag bit or TLS support flag bit, NMS may fall back to > > configure both PCC and PCE server to support TCP-AO or TLS. That's one > > of reason I think why we choose to use SHOULD language. > > > > >* Sec. 3.1: should we also say something about the case where > > both methods are advertised, and whether we recommend for the client > > to use one of them over the other? > > > > [Qin]: It is up to local policy, which has bee clarified in the > > end of sect
Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
The proposed change sounds good to me, Thanks Yaron. -Qin -邮件原件- 发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 发送时间: 2021年8月10日 21:58 收件人: Qin Wu ; sec...@ietf.org 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org 主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 So let me suggest: Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP protects the authentication and integrity of the PCED TLV using the mechanisms defined in [RFC5310] and [RFC5709], if the mechanism described in this document is used. Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not provide any encryption mechanisms to protect the secrecy of the PCED TLV, and the operator must ensure that no private data is carried in the TLV, for example that key names do not reveal sensitive information about the network. Thanks, Yaron On 8/10/21, 15:01, "Qin Wu" wrote: Yaron: Thank for clarification. I agree to keep the last sentence in the second paragraph of section 7 as is. But I prefer to add the addition references in the previous sentence as follows: " Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP is protected for authentication and integrity of the PCED TLV,, with the mechanisms defined in [RFC5310] and [RFC5709] if the mechanism described in this document is used. As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration. " If you better wording, please let me know. -Qin -邮件原件- 发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 发送时间: 2021年8月10日 19:26 收件人: Qin Wu ; sec...@ietf.org 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org 主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 Hi Qin, Sorry, but I find your latest proposed text very confusing, because we should be focusing on integrity protection and not privacy (=secrecy) of the TLV. So I would prefer to keep the text as-is, with the addition of a reference to the IS-IS and OSPF security mechanisms that were discussed on this thread. Thanks, Yaron On 8/10/21, 05:00, "Qin Wu" wrote: Hi, Yaron -邮件原件- >发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] >发送时间: 2021年8月9日 21:44 >收件人: Qin Wu ; sec...@ietf.org >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org >主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 >Hi Qin, >Thank you for your response. >* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 5304 still uses HMAC-MD5, which would be considered insecure nowadays. >* RFC 2154 is very old and Experimental (and only supports RSA-MD5 signatures). I'm not an OSPF expert by any means, but I'm willing to bet that there are no production implementations of this RFC. (I'm willing to be proven wrong). >Is there another RFC that define a protection mechanism for OSPF? >All in all, there appear to be no good options for the IGP. [Qin Wu]Yes, we do have alternatives, see Les's response in the separate email " On 8/9/21, 23:36,"Les Ginsberg (ginsberg)" wrote: For IS-IS security please also see RFC 5310. For OSPF security please see RFC 5709. " >To your last point, when I mentioned decoupling the mechanisms, I was suggesting to use the extension you define even if the IGP *cannot* be secured. If you think this is reasonable, please add such text to the Security Considerations. [Qin Wu] Okay, how about the following change OLD TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration . " NEW TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration when getting the mechanism described in this document deployed. " >Thanks, > Yaron >On 8/9/21, 16:09, "Qin Wu" wrote: > Thanks Yaron for valuable comments, please see my reply inline below. -邮件原件- >发件人: Yaron Sheffer via Dat
Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
So let me suggest: Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP protects the authentication and integrity of the PCED TLV using the mechanisms defined in [RFC5310] and [RFC5709], if the mechanism described in this document is used. Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not provide any encryption mechanisms to protect the secrecy of the PCED TLV, and the operator must ensure that no private data is carried in the TLV, for example that key names do not reveal sensitive information about the network. Thanks, Yaron On 8/10/21, 15:01, "Qin Wu" wrote: Yaron: Thank for clarification. I agree to keep the last sentence in the second paragraph of section 7 as is. But I prefer to add the addition references in the previous sentence as follows: " Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP is protected for authentication and integrity of the PCED TLV,, with the mechanisms defined in [RFC5310] and [RFC5709] if the mechanism described in this document is used. As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration. " If you better wording, please let me know. -Qin -邮件原件- 发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 发送时间: 2021年8月10日 19:26 收件人: Qin Wu ; sec...@ietf.org 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org 主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 Hi Qin, Sorry, but I find your latest proposed text very confusing, because we should be focusing on integrity protection and not privacy (=secrecy) of the TLV. So I would prefer to keep the text as-is, with the addition of a reference to the IS-IS and OSPF security mechanisms that were discussed on this thread. Thanks, Yaron On 8/10/21, 05:00, "Qin Wu" wrote: Hi, Yaron -邮件原件- >发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] >发送时间: 2021年8月9日 21:44 >收件人: Qin Wu ; sec...@ietf.org >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org >主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 >Hi Qin, >Thank you for your response. >* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 5304 still uses HMAC-MD5, which would be considered insecure nowadays. >* RFC 2154 is very old and Experimental (and only supports RSA-MD5 signatures). I'm not an OSPF expert by any means, but I'm willing to bet that there are no production implementations of this RFC. (I'm willing to be proven wrong). >Is there another RFC that define a protection mechanism for OSPF? >All in all, there appear to be no good options for the IGP. [Qin Wu]Yes, we do have alternatives, see Les's response in the separate email " On 8/9/21, 23:36,"Les Ginsberg (ginsberg)" wrote: For IS-IS security please also see RFC 5310. For OSPF security please see RFC 5709. " >To your last point, when I mentioned decoupling the mechanisms, I was suggesting to use the extension you define even if the IGP *cannot* be secured. If you think this is reasonable, please add such text to the Security Considerations. [Qin Wu] Okay, how about the following change OLD TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration . " NEW TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration when getting the mechanism described in this document deployed. " >Thanks, > Yaron >On 8/9/21, 16:09, "Qin Wu" wrote: > Thanks Yaron for valuable comments, please see my reply inline below. -邮件原件- >发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org] >发送时间: 2021年8月6日 3:25 >收件人: sec...@ietf.org >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org >主题: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 >Reviewer: Yaron Sheffer >Re
Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
Yaron: Thank for clarification. I agree to keep the last sentence in the second paragraph of section 7 as is. But I prefer to add the addition references in the previous sentence as follows: " Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP is protected for authentication and integrity of the PCED TLV,, with the mechanisms defined in [RFC5310] and [RFC5709] if the mechanism described in this document is used. As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration. " If you better wording, please let me know. -Qin -邮件原件- 发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 发送时间: 2021年8月10日 19:26 收件人: Qin Wu ; sec...@ietf.org 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org 主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 Hi Qin, Sorry, but I find your latest proposed text very confusing, because we should be focusing on integrity protection and not privacy (=secrecy) of the TLV. So I would prefer to keep the text as-is, with the addition of a reference to the IS-IS and OSPF security mechanisms that were discussed on this thread. Thanks, Yaron On 8/10/21, 05:00, "Qin Wu" wrote: Hi, Yaron -邮件原件- >发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] >发送时间: 2021年8月9日 21:44 >收件人: Qin Wu ; sec...@ietf.org >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org >主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 >Hi Qin, >Thank you for your response. >* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 5304 still uses HMAC-MD5, which would be considered insecure nowadays. >* RFC 2154 is very old and Experimental (and only supports RSA-MD5 signatures). I'm not an OSPF expert by any means, but I'm willing to bet that there are no production implementations of this RFC. (I'm willing to be proven wrong). >Is there another RFC that define a protection mechanism for OSPF? >All in all, there appear to be no good options for the IGP. [Qin Wu]Yes, we do have alternatives, see Les's response in the separate email " On 8/9/21, 23:36,"Les Ginsberg (ginsberg)" wrote: For IS-IS security please also see RFC 5310. For OSPF security please see RFC 5709. " >To your last point, when I mentioned decoupling the mechanisms, I was suggesting to use the extension you define even if the IGP *cannot* be secured. If you think this is reasonable, please add such text to the Security Considerations. [Qin Wu] Okay, how about the following change OLD TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration . " NEW TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration when getting the mechanism described in this document deployed. " >Thanks, > Yaron >On 8/9/21, 16:09, "Qin Wu" wrote: > Thanks Yaron for valuable comments, please see my reply inline below. -邮件原件- >发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org] >发送时间: 2021年8月6日 3:25 >收件人: sec...@ietf.org >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org >主题: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 >Reviewer: Yaron Sheffer >Review result: Not Ready >This document defines a mechanism (a TLV) to advertise the PCE Protocol security required (use of TCP-AO and its key ID, or alternatively use of TLS) within the routing protocol being used. >* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST. Especially given the strict client behavior defined later. [Qin]: I believe "SHOULD advertise" is consistent with client behavior defined later, i.e., we apply SHOULD NOT language to the client behavior. I am not sure we should change it into strong language with MUST. Since if IGP advertisement doesn't include TCP-AO support flag bit or TLS support flag bit, NMS may fall back to configure both PCC and PCE server to support TCP-AO or TLS. That's one of reason I think why we choose to use SHOULD language. >* Sec. 3.1: should we also say something about the case where both methods are advertise
Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
Hi Qin, Sorry, but I find your latest proposed text very confusing, because we should be focusing on integrity protection and not privacy (=secrecy) of the TLV. So I would prefer to keep the text as-is, with the addition of a reference to the IS-IS and OSPF security mechanisms that were discussed on this thread. Thanks, Yaron On 8/10/21, 05:00, "Qin Wu" wrote: Hi, Yaron -邮件原件- >发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] >发送时间: 2021年8月9日 21:44 >收件人: Qin Wu ; sec...@ietf.org >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org >主题: Re: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 >Hi Qin, >Thank you for your response. >* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 5304 still uses HMAC-MD5, which would be considered insecure nowadays. >* RFC 2154 is very old and Experimental (and only supports RSA-MD5 signatures). I'm not an OSPF expert by any means, but I'm willing to bet that there are no production implementations of this RFC. (I'm willing to be proven wrong). >Is there another RFC that define a protection mechanism for OSPF? >All in all, there appear to be no good options for the IGP. [Qin Wu]Yes, we do have alternatives, see Les's response in the separate email " On 8/9/21, 23:36,"Les Ginsberg (ginsberg)" wrote: For IS-IS security please also see RFC 5310. For OSPF security please see RFC 5709. " >To your last point, when I mentioned decoupling the mechanisms, I was suggesting to use the extension you define even if the IGP *cannot* be secured. If you think this is reasonable, please add such text to the Security Considerations. [Qin Wu] Okay, how about the following change OLD TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration . " NEW TEXT: " As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption mechanism to protect the privacy of the PCED TLV, if this information can make the PCEP session less secure then the operator should take that into consideration when getting the mechanism described in this document deployed. " >Thanks, > Yaron >On 8/9/21, 16:09, "Qin Wu" wrote: > Thanks Yaron for valuable comments, please see my reply inline below. -邮件原件- >发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org] >发送时间: 2021年8月6日 3:25 >收件人: sec...@ietf.org >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; lsr@ietf.org >主题: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05 >Reviewer: Yaron Sheffer >Review result: Not Ready >This document defines a mechanism (a TLV) to advertise the PCE Protocol security required (use of TCP-AO and its key ID, or alternatively use of TLS) within the routing protocol being used. >* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST. Especially given the strict client behavior defined later. [Qin]: I believe "SHOULD advertise" is consistent with client behavior defined later, i.e., we apply SHOULD NOT language to the client behavior. I am not sure we should change it into strong language with MUST. Since if IGP advertisement doesn't include TCP-AO support flag bit or TLS support flag bit, NMS may fall back to configure both PCC and PCE server to support TCP-AO or TLS. That's one of reason I think why we choose to use SHOULD language. >* Sec. 3.1: should we also say something about the case where both methods are advertised, and whether we recommend for the client to use one of them over the other? [Qin]: It is up to local policy, which has bee clarified in the end of section 3.1. Hope this clarify. >* Sec. 4: typo (appears twice) - "to be carried in the PCED TLV of the for use". [Qin]:Thanks, have fixed them in the local copy. >* Sec. 7: this phrase appears to be essential to security of this mechanism: "it MUST be insured that the IGP is protected for authentication and integrity of the PCED TLV". I would expect more guidance: how can this property be ensured in the relevant IGPs? [Qin]:I think mechanism defined in [RFC3567] and [RFC2154] can be used to ensure authenticity and integrity of OSPF LSAs or ISIS LSPs and their TLVs. Here is the proposed changes: OLD TEXT: " Thus before advertisement of the PCE security parameters, it MUST be insured that the IGP is protected for authentication and integrity of the PCED TLV if the mechanism describ
Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
Hi, all: I support adoption of both YANG related drafts. -Qin > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps > Sent: Thursday, July 22, 2021 6:48 PM > To: lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org > Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts > > > Hi Folks, > > This begins a 3 week WG Adoption Call for the following related YANG drafts: > > https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/ > https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/ > > Please indicate your support or objections by August 12th, 2021 > > Authors, please respond to the list indicating whether you are aware of any > IPR that applies to these drafts. > > Thanks, > Chris. > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
