+1 Having actual key in the protocol - similar issues as with BGP(see recent BGP discussion with Linda), would be a severe security risk.
Regards, Jeff > On Aug 25, 2018, at 10:41, Acee Lindem (acee) > <[email protected]> wrote: > > Hi Qin, > > I believe it is a significant security exposure to include the actual keys in > IGPs. What I was suggesting was to include an identifier of the key to be > used. > > Thanks, > Acee > > On 8/24/18, 10:56 PM, "Qin Wu" <[email protected]> wrote: > > Hi, Acee: > -----邮件原件----- > 发件人: Acee Lindem (acee) [mailto:[email protected]] > 发送时间: 2018年8月24日 22:23 > 收件人: Qin Wu; [email protected] > 主题: Re: New Version Notification for > draft-wu-lsr-pce-discovery-security-support-00.txt > > Hi Qin, > > On 8/23/18, 11:03 PM, "Qin Wu" <[email protected]> wrote: > > Hi, Folks: > draft-wu-pce-discovery-pceps-support-07 has been resubmitted to LSR as > draft-wu-lsr-pce-discovery-security-support-00 based on Chairs' suggestion. > > https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00 > This draft define IGP extension for PCEP security support, > 1.TCP AO which has been published as RFC5295. > 2.PCEP over TLS which has been published as RFC8253 recently. > > One issue raised by chair is shared key support for TCP-AO, how do you > get shared key? > > I guess my point was is that if you are distributing shared keys, you > probably know whether or not TCP-AO is supported. Having said that, possibly > the draft should include some sort of key-id for TCP-AO or TLS usage. For > example, the key-chain name from RFC 8177. We don't need to decide now. > > [Qin]: RFC5088 " OSPF Protocol Extensions for PCE discovery" said: > " > PCE discovery information is, by nature, fairly static and does not > change with PCE activity. Changes in PCE discovery information may > occur as a result of PCE configuration updates, PCE > deployment/activation, PCE deactivation/suppression, or PCE failure. > Hence, this information is not expected to change frequently. > " > So security capability as part of PCE discovery information should also be > static. > > RFC5926 section 3.1 said: > " > In TCP-AO's manual key mode, this is a key shared by both peers, entered > via some interface to their > respective configurations. The Master_Key is used as the seed for the KDF. > " > My impression TCP-AO relies on manual installation for shared key. But TLS > has key management protocol to exchange shared key,e.g., one defined in > RFC4279. > We can either negotiate shared key for TCP-AO in the PCE discovery phase > or during PCE configuration phase. For TLS usage, this is not needed, in my > opinion. > To support shared key negotiation during PCE discovery phase, we need to > define a IGP PCED Sub-TLV for TCP-AO, I am not sure this is allowed according > to RFC5088, > It looks this new IGP PCEP TLV is a companion Sub-TLV for PCE-CAP-FLAGS > Sub-TLV. > If adding a new Sub-TLV is allowed, we can add algorithm identifier and > key chain name,key identifier altogether. > > If negotiating shared key during PCE configuration phase, it is clearly > beyond scope of this draft. > Thanks, > Acee > > > we believe to support TCP-AO, RFC5296 should also be implemented, > which provide PSK and associated ciphersuit. > Let us know if you have any other opinion? > > -Qin > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] > 发送时间: 2018年8月24日 10:57 > 收件人: Daniel King; wangzitao; Dhruv Dhody; wangzitao; Diego R. Lopez; > Diego Lopez; Qin Wu > 主题: New Version Notification for > draft-wu-lsr-pce-discovery-security-support-00.txt > > > A new version of I-D, > draft-wu-lsr-pce-discovery-security-support-00.txt > has been successfully submitted by Qin Wu and posted to the IETF > repository. > > Name: draft-wu-lsr-pce-discovery-security-support > Revision: 00 > Title: IGP extension for PCEP security capability support in > the PCE discovery > Document date: 2018-08-23 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-wu-lsr-pce-discovery-security-support-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wu-lsr-pce-discovery-security-support/ > Htmlized: > https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-wu-lsr-pce-discovery-security-support > > > Abstract: > When a Path Computation Element (PCE) is a Label Switching Router > (LSR) participating in the Interior Gateway Protocol (IGP), or even > a > server participating in IGP, its presence and path computation > capabilities can be advertised using IGP flooding. The IGP > extensions for PCE discovery (RFC 5088 and RFC 5089) define a method > to advertise path computation capabilities using IGP flooding for > OSPF and IS-IS respectively. However these specifications lack a > method to advertise PCEP security (e.g., Transport Layer > Security(TLS),TCP Authentication Option (TCP-AO)) support > capability. > > This document proposes new capability flag bits for PCE-CAP-FLAGS > sub-TLV that can be announced as attribute in the IGP advertisement > to distribute PCEP security support information. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
