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

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Aug 2017 16:41:44 -0700

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 31 Aug 2017 06:36:58 +0000

Hi Eric, 

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Eric Rescorla
> Sent: 31 August 2017 05:12
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-rfc6006bis-03:
> (with DISCUSS)
> 
> The Security Considerations is worrisome, as it points to RFC 5440;
> Section 10.2, which basically recommends TCP-MD5:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Aug 2017 06:47:05 -0600

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

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 31 Aug 2017 16:16:17 +0000

Hi Eric, 

Let me take one more stab at it - 

   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].

      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:[email-masked]] 
Sent: 31 August 2017 18:17
To: Dhruv Dhody <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]> wrote:
Hi Eric,

OLD:

Thanks,
Dhruv