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 <bill.wu@xxxxxxxxxx> > Sent: Monday, August 9, 2021 6:13 PM > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; Yaron Sheffer > <yaronf.ietf@xxxxxxxxx>; secdir@xxxxxxxx > Cc: draft-ietf-lsr-pce-discovery-security-support.all@xxxxxxxx; last- > call@xxxxxxxx; lsr@xxxxxxxx > 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:ginsberg@xxxxxxxxx] > 发送时间: 2021年8月9日 23:36 > 收件人: Yaron Sheffer <yaronf.ietf@xxxxxxxxx>; Qin Wu > <bill.wu@xxxxxxxxxx>; secdir@xxxxxxxx > 抄送: draft-ietf-lsr-pce-discovery-security-support.all@xxxxxxxx; last- > call@xxxxxxxx; lsr@xxxxxxxx > 主题: 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 <lsr-bounces@xxxxxxxx> On Behalf Of Yaron Sheffer > > Sent: Monday, August 9, 2021 6:44 AM > > To: Qin Wu <bill.wu@xxxxxxxxxx>; secdir@xxxxxxxx > > Cc: draft-ietf-lsr-pce-discovery-security-support.all@xxxxxxxx; last- > > call@xxxxxxxx; lsr@xxxxxxxx > > 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" <bill.wu@xxxxxxxxxx> wrote: > > > > Thanks Yaron for valuable comments, please see my reply inline below. > > -----邮件原件----- > > >发件人: Yaron Sheffer via Datatracker [mailto:noreply@xxxxxxxx] > > >发送时间: 2021年8月6日 3:25 > > >收件人: secdir@xxxxxxxx > > >抄送: draft-ietf-lsr-pce-discovery-security-support.all@xxxxxxxx; > > last- call@xxxxxxxx; lsr@xxxxxxxx > > >主题: 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 described in this document is used. > > " > > NEW 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 with > > mechanisms defined in [RFC3567][RFC2154] if the > > mechanism described in this document is used. > > " > > >* Also, a possibly unintended consequence of this requirement is > > that if the IGP cannot be protected in a particular > > deployment/product, this mechanism would not be used. Please consider > > if this is likely to happen and whether we want to forego PCEP > > transport >security in such cases. My gut feel (not based on > > experience in such networks) is that the threat models are different > > enough that we should decouple the security of IGP from that of PCEP. > > > > [Qin] I agree IGP security should be separated from PCEP security. > > IGP extension defined in this document is used by the PCC to select > > PCE server with appropriate security mechanism. On the other hand, > > Operator can either use IGP advertisement for PCEP security capability > > or rely on local policy to select PCE. If operator feels IGP > > advertisement is not secure, he can fall back to local policy or rely on > manual configuration. Hope this clarifies. > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/lsr -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
