Re: [Lsr] New Version Notification for draft-wu-lsr-pce-discovery-security-support-00.txt

[Jeff Tantsura <[e-mail]>]

+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) <acee=[e-mail]> 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" <[e-mail]> wrote:
> 
>    Hi, Acee:
>    -----邮件原件-----
>    发件人: Acee Lindem (acee) [mailto:[e-mail]] 
>    发送时间: 2018年8月24日 22:23
>    收件人: Qin Wu; [e-mail]
>    主题: 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" <[e-mail]> 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
>        -----邮件原件-----
>        发件人: [e-mail] [mailto:[e-mail]] 
>        发送时间: 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr