Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID.

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 27 Apr 2006 15:21:17 +0200

Hi Richard,
 
Please see inline,

________________________________

	De : Rich Bradford (rbradfor) [mailto:[email-masked]] 
	Envoyé : lundi 24 avril 2006 20:06
	À : LE ROUX Jean-Louis RD-CORE-LAN; Jean Philippe Vasseur (jvasseur)
	Cc : [email-masked]; [email-masked]
	Objet : RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID.

	JL,

	Thanks for the reply. It's always difficult to choose between multiple solutions when there are so many tradeoffs between the solutions.  

	Regarding the optimization where the PCE sends the LSR the unsolicited computed path segment.  It was a difficult choice whether or not to include a description of this in the original draft, since it is more complex. Which aspect of the optimization seemed most important? Was it that it's more efficient during LSP setup or because it could be used to shift the burden of maintaining state from the PCE to the LSR? 

	IMO the most important optimization is the gain in LSP setup time, which may be significant, and this is of particular  

	importance during end-to-end LSP restoration upon failure.

	Let's assume an inter-AS path computation with an AS-path length = N:

	-Without this optimization the LSP signaling time would be N* Intra-AS-RSVP-sig + N* LSR-PCE exchanges.

	-With this optimization the LSP signaling time would be N* Intra-AS-RSVP-sig

	Hence the gain in signaling time is N*LSR-PCE exchanges.

	And the good thing is that the path computation time would not be impacted at all by this procedure as the PCE-LSR unsolicited notification is done in // with the BRPC procedure.

	There may be one minor con: During the BRPC you don't know a priori which path segment will finally be selected, hence you need to send the path segment to all ASBR LSRs connected to the upstream AS...but this is a minor issue, because there are not so many ASBRs connected to the upstream AS (two or three). You will have to remove the information on the ASBR if no Path message is received after the expiration of a timer...

	Regards,

	JL

	 

	 

	Thanks once again for your opinion. 

	Best Regards,

	  Rich

________________________________

	From: LE ROUX Jean-Louis RD-CORE-LAN [mailto:[email-masked]] 
	Sent: Friday, April 21, 2006 12:51 PM
	To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor)
	Cc: [email-masked]; [email-masked]
	Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID.

	Hi JP, Richard

	Please see inline,

________________________________

		De : JP Vasseur [mailto:[email-masked]] 
		Envoyé : jeudi 6 avril 2006 14:52
		À : Rich Bradford
		Cc : [email-masked]; [email-masked]
		Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID.

		Hi, 

		Thanks for the summary Rich.

		PCE WG members: thanks to provide your feedback on whether:

		(1) You think that there is a need for such solution, 

		Yes definitely, confidentiality is a key requirements in an inter-provider context.

		(2) You would prefer one solution (which one and why ?) 

		(3) You think that there is a need for both 

		Answer to (2) and (3):

		It seems to me that we should end-up with a single solution so as to ease interworking.

		IMO in an inter-AS MPLS-TE environment without PCEs, the paths will be loose anyway, so there will not be any confidentiality issue. 

		If have some concerns regarding the cost of encryption, particularly for large paths (we need to think about future P2MP applications with a large number of hops...). By the way, encryption approaches are really vulnerable to DoS attacks.

		Hence I would strongly favor the PKS solution. The optimization suggested, which consists of sending the computed path segment to the LSR in an unsolicited manner, just after the computation, sounds relevant and should be further investigated.

		Best Regards,

		JL

		 

		Thanks.

		JP.

		On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote:

		Hi,

		As suggested in Dallas, I've described some of the tradeoffs between the two solutions described in draft-rbradfor-ccamp-confidential-segment-00.txt.

		-- Rich

		The Confidential Path Segment (CPS) ID provides two very different but equally valid solutions, the Path Key Subobject (PKS) solution and the Private Route Subobject (PRS) solution. This note examines a number of the advantages and disadvantages of each solution. 

		In short: The PKS solution allows a PCE to hide the CPS for an AS by saving it in a database and replacing it with a key in the ERO. During the LSP setup, the ingress LSR for that AS must query the PCE for an expansion.

		The PRS solution allows a CPS for an AS to be hidden by encrypting it, which may be done by a PCE or by the Head-End LSR. During the LSP setup, the ingress LSR for that AS must use a decryption key to obtain the expansion (implying an earlier exchange or configuration). 

		The major differences between the mechanisms involve (1) additional control messages, (2) performance issues expanding those objects, (3) the addition of state to the PCE, (4) the solution scope (i.e. applicability to various topologies of each solution.), and (5) the size of objects added to existing messages.

		(1) Additional Control Message Overhead:

		The PKS solution requires a mechanism to expand the Path Key upon receipt of the LSP setup request. Since the PCE which calculated the Path Key might not reside in the entry boundary LSR, the LSR must request the expansion from the PCE, requiring an additional message exchange before LSP setup can proceed. The Path Encryption solution does not require this extra exchange between the PCE and the ingress node for every LSP. Rather, the decryption key needs to be exchanged only when it is changed. The result is additional delay during every LSP setup for the PKS solution but no additional delay for the PRS solution.

		(2) PCE and LSR Performance:

		The PKS solution must maintain a (temporary) database of keys adding overhead to the PCE. The PRS solution requires the encryption of the CPS in the PCE and decryption of the CPS in the LSR, which could be CPU intensive. Note that in case of a burst of requests, encryption of large number of CPS may have an impact on the PCE response time.

		(3) Addition of State in the PCE:

		The PKS solution requires the addition of path-specific state and maintenance of a database in the PCE. The PRS solution requires no additional state.

		(4) Solution Scope:

		The PKS and PRS solutions both work well in conjunction with a PCE to encode and decode the CPS. However the PKS provides no direct solution without a PCE. This prevents the PKS solution for working in the case where A's network straddles B's network and where A wants to use an ERO for a segment of the LSP across the intervening network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS even if the path (and therefore the returned RRO) crosses multiple boundaries. Finally, a PRS solution could be adapted to return actual failure locations in PERRs and/or PATHTEARs, while keeping the failure location confidential from LSRs without a decryption key. Currently privacy of this source is maintained by returning the address of border nodes, which can be very misleading.

		(5) Message Object Overhead:

		The PKS solution provides a very compact key or token to identify a path segment, which generally allows for smaller EROs to be returned by the PCE and to be requested in the resulting PATH message. A PRS which contains a CPS must generally be at least as large as the unencrypted PATH through the AS and may be significantly larger if it is desirable to hide the number of hops within the network from external view by padding the PRS. The result is potentially larger PATH (and PCEP) messages for the PRS solution.

		Please note that the tradeoffs listed here are for the current I-D. Some of the shortcomings of each approach could be mitigated by implementation-specific optimizations. For example, a PCE could choose to signal the CPS expansion to the entry boundary LSR, shifting the burden of maintaining the PKS state to the LSR and eliminating the performance hit during LSP setup. A similar exchange could be performed for the PRS case, eliminating the need for a separate key exchange. These examples of extensions are beyond the scope of the ID, but might be useful when weighing the pros and cons of the two solutions.

		_______________________________________________

		Pce mailing list

		[email-masked]

		https://www1.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Thu, 27 Apr 2006 09:25:58 -0400

Hi Jean-Louis,

On Apr 27, 2006, at 9:21 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Thanks for the reply. It’s always difficult to choose between  
> multiple solutions when there are so many tradeoffs between the  
> solutions.
>
>
>
> Regarding the optimization where the PCE sends the LSR the  
> unsolicited computed path segment.  It was a difficult choice  
> whether or not to include a description of this in the original  
> draft, since it is more complex. Which aspect of the optimization  
> seemed most important? Was it that it’s more efficient during LSP  
> setup or because it could be used to shift the burden of  
> maintaining state from the PCE to the LSR?
>
>
> IMO the most important optimization is the gain in LSP setup time,  
> which may be significant, and this is of particular
>
> And the good thing is that the path computation time would not be  
> impacted at all by this procedure as the PCE-LSR unsolicited  
> notification is done in // with the BRPC procedure.
>
>
> There may be one minor con: During the BRPC you don't know a priori  
> which path segment will finally be selected, hence you need to send  
> the path segment to all ASBR LSRs connected to the upstream  
> AS...but this is a minor issue, because there are not so many ASBRs  
> connected to the upstream AS (two or three). You will have to  
> remove the information on the ASBR if no Path message is received  
> after the expiration of a timer...
Agree, this is a temporary state ... that would have been maintained  
by the PCE anyway.

Cheers.

JP.
> From: LE ROUX Jean-Louis RD-CORE-LAN  
> [mailto:[email-masked]]
> IMO in an inter-AS MPLS-TE environment without PCEs, the paths will  
> be loose anyway, so there will not be any confidentiality issue.
>
> If have some concerns regarding the cost of encryption,  
> particularly for large paths (we need to think about future P2MP  
> applications with a large number of hops...). By the way,  
> encryption approaches are really vulnerable to DoS attacks.
>
> Hence I would strongly favor the PKS solution. The optimization  
> suggested, which consists of sending the computed path segment to  
> the LSR in an unsolicited manner, just after the computation,  
> sounds relevant and should be further investigated.
>
>
>
> Best Regards,
>
>
>
> JL
>
>
>
>
>
>
>
>
>
> Thanks.
>
>
>
> JP.
>
>
>
> As suggested in Dallas, I’ve described some of the tradeoffs  
> between the two solutions described in draft-rbradfor-ccamp- 
> confidential-segment-00.txt.
>
> -- Rich
>
> The Confidential Path Segment (CPS) ID provides two very different  
> but equally valid solutions, the Path Key Subobject (PKS) solution  
> and the Private Route Subobject (PRS) solution. This note examines  
> a number of the advantages and disadvantages of each solution.
>
> In short: The PKS solution allows a PCE to hide the CPS for an AS  
> by saving it in a database and replacing it with a key in the ERO.  
> During the LSP setup, the ingress LSR for that AS must query the  
> PCE for an expansion.
>
> The PRS solution allows a CPS for an AS to be hidden by encrypting  
> it, which may be done by a PCE or by the Head-End LSR. During the  
> LSP setup, the ingress LSR for that AS must use a decryption key to  
> obtain the expansion (implying an earlier exchange or configuration).
>
> The major differences between the mechanisms involve (1) additional  
> control messages, (2) performance issues expanding those objects,  
> (3) the addition of state to the PCE, (4) the solution scope (i.e.  
> applicability to various topologies of each solution.), and (5) the  
> size of objects added to existing messages.
>
> The PKS solution requires a mechanism to expand the Path Key upon  
> receipt of the LSP setup request. Since the PCE which calculated  
> the Path Key might not reside in the entry boundary LSR, the LSR  
> must request the expansion from the PCE, requiring an additional  
> message exchange before LSP setup can proceed. The Path Encryption  
> solution does not require this extra exchange between the PCE and  
> the ingress node for every LSP. Rather, the decryption key needs to  
> be exchanged only when it is changed. The result is additional  
> delay during every LSP setup for the PKS solution but no additional  
> delay for the PRS solution.
>
> The PKS solution must maintain a (temporary) database of keys  
> adding overhead to the PCE. The PRS solution requires the  
> encryption of the CPS in the PCE and decryption of the CPS in the  
> LSR, which could be CPU intensive. Note that in case of a burst of  
> requests, encryption of large number of CPS may have an impact on  
> the PCE response time.
>
> The PKS solution requires the addition of path-specific state and  
> maintenance of a database in the PCE. The PRS solution requires no  
> additional state.
>
> (4) Solution Scope:
>
> The PKS and PRS solutions both work well in conjunction with a PCE  
> to encode and decode the CPS. However the PKS provides no direct  
> solution without a PCE. This prevents the PKS solution for working  
> in the case where A's network straddles B's network and where A  
> wants to use an ERO for a segment of the LSP across the intervening  
> network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be  
> used to record a CPS even if the path (and therefore the returned  
> RRO) crosses multiple boundaries. Finally, a PRS solution could be  
> adapted to return actual failure locations in PERRs and/or  
> PATHTEARs, while keeping the failure location confidential from  
> LSRs without a decryption key. Currently privacy of this source is  
> maintained by returning the address of border nodes, which can be  
> very misleading.
>
> The PKS solution provides a very compact key or token to identify a  
> path segment, which generally allows for smaller EROs to be  
> returned by the PCE and to be requested in the resulting PATH  
> message. A PRS which contains a CPS must generally be at least as  
> large as the unencrypted PATH through the AS and may be  
> significantly larger if it is desirable to hide the number of hops  
> within the network from external view by padding the PRS. The  
> result is potentially larger PATH (and PCEP) messages for the PRS  
> solution.
>
> Please note that the tradeoffs listed here are for the current I-D.  
> Some of the shortcomings of each approach could be mitigated by  
> implementation-specific optimizations. For example, a PCE could  
> choose to signal the CPS expansion to the entry boundary LSR,  
> shifting the burden of maintaining the PKS state to the LSR and  
> eliminating the performance hit during LSP setup. A similar  
> exchange could be performed for the PRS case, eliminating the need  
> for a separate key exchange. These examples of extensions are  
> beyond the scope of the ID, but might be useful when weighing the  
> pros and cons of the two solutions.
>