Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: (with DISCUSS)

[Dhruv Dhody <[e-mail]>]

Hi Eric, 

Let me take one more stab at it - 

5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path computation request, or a denial of service
   attack, the subsequent PCEP requests and processing may be disruptive
   to the network.  Consequently, it is important that implementations
   conform to the relevant security requirements that specifically help
   to minimize or negate unauthorized P2MP path computation requests and
   denial of service attacks.  These mechanisms include:

   o  Securing the PCEP session requests and responses is RECOMMENDED
      using TCP security techniques such as TCP Authentication Option
      (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [I-
      D.ietf-pce-pceps], as per the recommendations and best current
      practices in [RFC7525].

   o  Authenticating the PCEP requests and responses to ensure the
      message is intact and sent from an authorized node using TCP-AO or
      TLS is RECOMMENDED.

   o  Providing policy control by explicitly defining which PCCs, via IP
      access-lists, are allowed to send P2MP path requests to the PCE.

   PCEP operates over TCP, so it is also important to secure the PCE and
   PCC against TCP denial of service attacks. 

   As stated in [RFC6952], PCEP implementations should support TCP-AO
   [RFC5925] and not use TCP-MD5 because of the known vulnerabilities
   and weakness.  


What do you think? 

Regards,
Dhruv

------------



From: Eric Rescorla [mailto:[e-mail]] 
Sent: 31 August 2017 18:17
To: Dhruv Dhody <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03: (with DISCUSS)

No, not really. You're still citing to 5440 which has the TCP-MD5 stuff, and there's no requirement to use AO. I think what's needed here is a normative requirement for something strong than TCP-MD5. I defer to the WG on what that should be, but it's really not OK to keep using TCP-MD5 as our basic security measure for TCP connections for routing protocols

-Ekr


On Thu, Aug 31, 2017 at 12:36 AM, Dhruv Dhody <[e-mail]> wrote:
Hi Eric,

> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of Eric Rescorla
> Sent: 31 August 2017 05:12
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03:
> (with DISCUSS)
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-pce-rfc6006bis-03: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-rfc6006bis/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> The Security Considerations is worrisome, as it points to RFC 5440;
> Section 10.2, which basically recommends TCP-MD5:
>
>    At the time of writing, TCP-MD5 [RFC2385] is the only available
>    security mechanism for securing the TCP connections that underly PCEP
>    sessions.
>
>    As explained in [RFC2385], the use of MD5 faces some limitations and
>    does not provide as high a level of security as was once believed.  A
>    PCEP implementation supporting TCP-MD5 SHOULD be designed so that
>    stronger security keying techniques or algorithms that may be
>    specified for TCP can be easily integrated in future releases.
>
>    The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new
>    security procedures for TCP, but is not yet complete.  Since it is
>    believed that [TCP-AUTH] will offer significantly improved security
>    for applications using TCP, implementers should expect to update
>    their implementation as soon as the TCP Authentication Option is
>    published as an RFC.
>
>    Implementations MUST support TCP-MD5 and should make the security
>    function available as a configuration option.
>
> TCP-AO has now been published as an RFC for quite some time, so it's
> probably not really appropriate to just point to a document which
> recommends TCP-MD5.
>
[[Dhruv Dhody]] Let me know if this change is okay -

OLD:
5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path computation request, or a denial of service
   attack, the subsequent PCEP requests and processing may be disruptive
   to the network.  Consequently, it is important that implementations
   conform to the relevant security requirements of [RFC5440] that
   specifically help to minimize or negate unauthorized P2MP path
   computation requests and denial of service attacks.  These mechanisms
   include:

   o  Securing the PCEP session requests and responses using TCP
      security techniques (Section 10.2 of [RFC5440]).

   o  Authenticating the PCEP requests and responses to ensure the
      message is intact and sent from an authorized node (Section 10.3
      of [RFC5440]).

   o  Providing policy control by explicitly defining which PCCs, via IP
      access-lists, are allowed to send P2MP path requests to the PCE
      (Section 10.6 of [RFC5440]).

   PCEP operates over TCP, so it is also important to secure the PCE and
   PCC against TCP denial of service attacks.  Section 10.7.1 of
   [RFC5440] outlines a number of mechanisms for minimizing the risk of
   TCP based denial of service attacks against PCEs and PCCs.

   PCEP implementations SHOULD consider the additional security provided
   by Transport Layer Security (TLS) [I-D.ietf-pce-pceps].
NEW:
5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path computation request, or a denial of service
   attack, the subsequent PCEP requests and processing may be disruptive
   to the network.  Consequently, it is important that implementations
   conform to the relevant security requirements that specifically help
   to minimize or negate unauthorized P2MP path computation requests and
   denial of service attacks.  These mechanisms include:

   o  Securing the PCEP session requests and responses using TCP
      security techniques such as TCP Authentication Option (TCP-AO)
      [RFC5925] or using Transport Layer Security (TLS) [I-D.ietf-pce-
      pceps], as per the recommendations and best current practices in
      [RFC7525].

   o  Authenticating the PCEP requests and responses to ensure the
      message is intact and sent from an authorized node using TCP-AO or
      TLS.

   o  Providing policy control by explicitly defining which PCCs, via IP
      access-lists, are allowed to send P2MP path requests to the PCE
      (Section 10.6 of [RFC5440]).

   PCEP operates over TCP, so it is also important to secure the PCE and
   PCC against TCP denial of service attacks.  Section 10.7.1 of
   [RFC5440] outlines a number of mechanisms for minimizing the risk of
   TCP based denial of service attacks against PCEs and PCCs.
END

Thanks,
Dhruv


>
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce