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" <[email protected]> wrote:
Hi, Yaron
-----邮件原件-----
>发件人: Yaron Sheffer [mailto:[email protected]]
>发送时间: 2021年8月9日 21:44
>收件人: Qin Wu <[email protected]>; [email protected]
>抄送: [email protected];
[email protected]; [email protected]
>主题: 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)" <[email protected]> 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" <[email protected]> wrote:
> Thanks Yaron for valuable comments, please see my reply inline below.
-----邮件原件-----
>发件人: Yaron Sheffer via Datatracker [mailto:[email protected]]
>发送时间: 2021年8月6日 3:25
>收件人: [email protected]
>抄送: [email protected];
[email protected]; [email protected]
>主题: 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
