[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] New Version Notification for draft-wu-lsr-pce-discovery-security-support-00.txt
From: Jeff Tantsura <jefftant.ietf () gmail ! com>
Date: 2018-08-27 4:26:27
Message-ID: 3B2C11F9-EE5A-484F-926C-280A0C281405 () gmail ! com
[Download RAW message or body]
+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=40cisco.com@dmarc.ietf.org> \
> 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" <bill.wu@huawei.com> wrote:
>
> Hi, Acee:
> -----邮件原件-----
> 发件人: Acee Lindem (acee) [mailto:acee@cisco.com]
> 发送时间: 2018年8月24日 22:23
> 收件人: Qin Wu; lsr@ietf.org
> 主题: 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" <bill.wu@huawei.com> 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
> -----邮件原件-----
> 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> 发送时间: 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic