Re: [Pce] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Yaron Sheffer <[e-mail]>]

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" <[e-mail]> wrote:

    Hi, Yaron
    -----邮件原件-----
    >发件人: Yaron Sheffer [mailto:[e-mail]] 
    >发送时间: 2021年8月9日 21:44
    >收件人: Qin Wu <[e-mail]>; [e-mail]
    >抄送: [e-mail]; [e-mail]; [e-mail]
    >主题: 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)" <[e-mail]> 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" <[e-mail]> wrote:

      >   Thanks Yaron for valuable comments, please see my reply inline below.
        -----邮件原件-----
        >发件人: Yaron Sheffer via Datatracker [mailto:[e-mail]] 
        >发送时间: 2021年8月6日 3:25
        >收件人: [e-mail]
        >抄送: [e-mail]; [e-mail]; [e-mail]
        >主题: 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