Looks good to me. Thank you!
Yaron
On 8/17/21, 03:17, "Qin Wu" <bill...@huawei.com> wrote:
Sorry for late followup, here is the update, the diff is
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-06
Yaron, let authors know if your comments are addressed in v-06.
Thanks!
-Qin
-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2021年8月17日 4:33
收件人: Qin Wu <bill...@huawei.com>; tom petch <ie...@btconnect.com>; Yaron
Sheffer <yaronf.i...@gmail.com>; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support....@ietf.org
主题: Re: Secdir last call review of
draft-ietf-lsr-pce-discovery-security-support-05
Hi Qin,
Can you publish a revision so that Yaron assure it satisfies his comments?
Thanks,
Acee
On 8/12/21, 9:21 PM, "Qin Wu" <bill...@huawei.com> wrote:
Thanks Acee and Tom for good suggestion, we will take them into account.
-Qin
-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2021年8月12日 1:18
收件人: tom petch <ie...@btconnect.com>; Yaron Sheffer
<yaronf.i...@gmail.com>; Qin Wu <bill...@huawei.com>; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support....@ietf.org
主题: Re: Secdir last call review of
draft-ietf-lsr-pce-discovery-security-support-05
I'd also recommend changing, "key names" to "key-ids or key-chain
names" since this is what is actually being advertised.
Thanks,
Acee
On 8/10/21, 11:53 AM, "tom petch" <ie...@btconnect.com> wrote:
From: Lsr <lsr-boun...@ietf.org> on behalf of Yaron Sheffer
<yaronf.i...@gmail.com>
Sent: 10 August 2021 14:57
So let me suggest:
<tp>
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
</tp>
Thanks,
Yaron
On 8/10/21, 15:01, "Qin Wu" <bill...@huawei.com> 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 <bill...@huawei.com>; 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" <bill...@huawei.com> wrote:
Hi, Yaron
-----邮件原件-----
>发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
>发送时间: 2021年8月9日 21:44
>收件人: Qin Wu <bill...@huawei.com>; 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)"
<ginsb...@cisco.com> 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" <bill...@huawei.com> 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 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@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
