Subject: [secdir] Secdir last call review of draft-ietf-pce-pcep-extension-for-pce-controller-10

From: Yaron Sheffer via Datatracker <[email-masked]>
Date: Sat, 06 Feb 2021 11:34:44 -0800

Reviewer: Yaron Sheffer
Review result: Not Ready

This document defines PCEP extensions for the RFC 8283 architecture, where the
PCE acts as a central controller in an SDN. The document is focused on specific
use cases, referred to as "basic PCECC mode".

Let me state up front that I am not familiar with the PCE architecture other
than what I read up in order to review this document. Having said that, I
suspect that there would be significant value in a security analysis of the
architecture defined here. Having each connection "authenticated and encrypted"
is table stakes nowadays, but is it really enough for very large SDN
deployments that require this level of protocol sophistication?

Details

9.1: "authenticated and encrypted" TLS sessions are typically only
authenticated by the server. Please point out explicitly that mutual
authentication is required. Also, is there no authorization? I would assume a
peer PCE Controller is allowed to do different things than a PCC. Are all PCCs
allowed to issue the same commands/queries, targeted at the same resources?

- RFC 8283 which defines the architecture that is implemented by this draft
says:

[The] security implications of SDN have not been fully discussed or described. 
Therefore, protocol and applicability work-around solutions for this
architecture must take proper account of these concerns.

It is expected that each new document that is produced for a specific use case
will also include considerations of the security impacts of the use of a
PCE-based central controller on the network type and services being managed.

I don't think that the current document addresses this challenge.

In general, this looks like a very monolithic architecture, where everybody
trusts everybody else once they've been authenticated. Although Sec. 9.1
discusses the case of a malicious PCE (which would be rather catastrophic), I
would encourage the authors to consider whether a malicious PCC can also
disrupt the PCE's operations and cause "major impact to the network".

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 8 Feb 2021 06:58:27 +0000

Dear Yaron, 

Thank you for your comments! We have made an update based on your comments. Please suggest further text if required. The Security section is further expended and more details are provided, especially the new section on the Malicious PCC is added as below. 

	 	9.2.  Malicious PCC	
 		
 	   The PCECC mechanism described in this document requires the PCE to	
 	   keep labels (CCI) that it downloads and relies on the PCC responding	
 	   (with either an acknowledgment or an error message) to requests for	
 	   LSP instantiation.  This is an additional attack surface by placing a	
 	   requirement for the PCE to keep a CCI/label replica for each PCC.  It	
 	   is RECOMMENDED that PCE implementations provide a limit on resources	
 	   (in this case the CCI) a single PCC can occupy.  [RFC8231] provides a	
 	   notification mechanism when such threshold is reached.	
 	
Please also find the working copy and the diff. 

Working copy: https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-11.txt 
Diff: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-10&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-11.txt 

Best Regards, 
Shuping 

> -----Original Message-----
> From: Yaron Sheffer via Datatracker [mailto:[email-masked]]
> Sent: Sunday, February 7, 2021 3:35 AM
> To: [email-masked]
> Cc: [email-masked];
> [email-masked]; [email-masked]
> Subject: Secdir last call review of
> draft-ietf-pce-pcep-extension-for-pce-controller-10
> 
> Reviewer: Yaron Sheffer
> Review result: Not Ready
> 
> This document defines PCEP extensions for the RFC 8283 architecture, where
> the PCE acts as a central controller in an SDN. The document is focused on
> specific use cases, referred to as "basic PCECC mode".
> 
> It is expected that each new document that is produced for a specific use
> case will also include considerations of the security impacts of the use of a

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 08 Feb 2021 11:21:23 +0200

Hi Shuping,

Frankly I don't know if this addresses my comments, that is, if these are all the additional security considerations that apply to SDN, compared to a basic PCEP deployment. But thank you for the new text which does improve the Security Considerations significantly.

Thanks,
	Yaron

On 2/8/21, 08:58, "Pengshuping (Peng Shuping)" <[email-masked]> wrote:

    Dear Yaron, 

    	 	9.2.  Malicious PCC	

    Best Regards, 
    Shuping

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Feb 2021 15:48:22 -0800

Thanks for this review, Yaron!

In particular...

> Review result: Not Ready
[...]
> I don't think that the current document addresses this challenge.

... this point is something that I am *very* happy is being raised as soon
as possible.

Like you, I am not very satisfied with the initial email response (though I
did not open up the attached diff), so I hope that we will see more on this
front before the document advances to the IESG.

Thanks again,

Ben

> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call