Subject: RE: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 8 Mar 2006 08:42:07 +0100

Hi Igor,
 
PCEP supports MD-5 authentication that prevents against impersonation
 
Regards
 
JL

________________________________

	De : Igor Bryskin [mailto:[email-masked]] 
	Envoyé : mardi 7 mars 2006 16:22
	À : Rich Bradford (rbradfor); [email-masked]
	Cc : [email-masked]
	Objet : Re: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt 

	Rich,
	 
	My point is that path(s) containing PKSs will also contain address of the ASBR, hence the PCC can issue a request to the PCC pretending that it is the ASBR and resolve PKSs into explicit path segments. Your draft says that this resolution is accomplished via a PCEP request, and my understanding is that PCEP does not have any protection from such impersonation.
	 
	Thanks,
	Igor

		----- Original Message ----- 
		From: Rich Bradford (rbradfor) <mailto:[email-masked]>  
		To: Igor Bryskin <mailto:[email-masked]>  ; [email-masked] 
		Cc: [email-masked] 
		Sent: Monday, March 06, 2006 4:31 PM
		Subject: RE: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt 

		Igor, thanks for the question.

		If I understand the question correctly, then a PCE which was configured to supply PKSs to any PCC outside the AS would also be configured not to decode the PKS for any PCC outside the AS.

		-- Rich

________________________________

		From: Igor Bryskin [mailto:[email-masked]] 
		Sent: Monday, March 06, 2006 4:22 PM
		To: Rich Bradford (rbradfor); [email-masked]
		Cc: [email-masked]
		Subject: Re: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt 

		Hi,

		I'd like to know what prevents a curious/malicious PCC after receiving form a PCE paths with PKSs to impersonate an ASBR and resolve the PKSs into explicit segments?

		Thanks,

		Igor Bryskin

			----- Original Message ----- 

			From: Rich Bradford (rbradfor) <mailto:[email-masked]>  

			To: [email-masked] 

			Cc: [email-masked] 

			Sent: Monday, March 06, 2006 3:06 PM

			Subject: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt 

			Dear WG,

			Just to let you know that a new ID has been posted proposing a simple extension to the ERO to allow path segments in separate ASs to remain confidential. There are indeed various circumstances that require "encoding" a path segment in some form. I've included the abstract below. Note that this ID may eventually be split to be discussed separately in CCAMP and PCE but we prefer to start with a single ID first to be discussed in CCAMP.

			Comments are very welcome.

			Thanks,

			Rich

			To: [email-masked]

			Subject: I-D ACTION:draft-rbradfor-ccamp-confidential-segment-00.txt 

			Reply-To: [email-masked]

			A New Internet-Draft is available from the on-line Internet-Drafts directories.

			          Title                  : Protocol Extensions for Signaling 

			                          Confidential Path Segments in Multiprotocol 

			                          Label Switching Traffic Engineering.

			          Author(s)          : R. Bradford, et al.

			          Filename           : draft-rbradfor-ccamp-confidential-segment-00.txt

			          Pages               : 

			          Date                 : 2006-3-1

			Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths 

			(LSPs) may be computed by Path Computation Elements (PCEs). Where the 

			LSP crosses multiple domains such as Autonomous Systems (ASs) the 

			path may be computed by multiple PCEs that cooperate, with each 

			responsible for computing a segment of the path. 

			However, in some cases such as when ASs are administered by separate 

			Service Providers, it would break confidentiality rules for a PCE to 

			supply a path segment to a PCE in another domain. This issue may be 

			circumvented by returning a loose hop and by invoking a new path 

			computation from the domain boundary LSR during LSP setup as the LSP 

			enters the second domain, but this technique has several issues 

			including the problem of maintaining path diversity. 

			This document allows a PCE to provide a full path, but to hide the 

			contents of a segment of that path called the Confidential Path 

			Segment (CPS). The CPS may be conveyed in the PCE Communication 

			Protocol (PCEP) and signaled in a Resource Reservation Protocol 

			(RSVP) explicit route either by replacing it with a path key or by 

			encrypting it. 

			A URL for this Internet-Draft is:

			http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt

			To remove yourself from the I-D Announcement list, send a message to 

			[email-masked] with the word unsubscribe in the body of the message.  

			You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 

			to change your subscription settings.

			Internet-Drafts are also available by anonymous FTP. Login with the username

			"anonymous" and a password of your e-mail address. After logging in,

			type "cd internet-drafts" and then

			          "get draft-rbradfor-ccamp-confidential-segment-00.txt".

			A list of Internet-Drafts directories can be found in

			http://www.ietf.org/shadow.html 

			or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

			Internet-Drafts can also be obtained by e-mail.

			Send a message to:

			          [email-masked].

			In the body type:

			          "FILE /internet-drafts/draft-rbradfor-ccamp-confidential-segment-00.txt".

			NOTE:           The mail server at ietf.org can return the document in

			          MIME-encoded form by using the "mpack" utility.  To use this

			          feature, insert the command "ENCODING mime" before the "FILE"

			          command.  To decode the response(s), you will need "munpack" or

			          a MIME-compliant mail reader.  Different MIME-compliant mail readers

			          exhibit different behavior, especially when dealing with

			          "multipart" MIME messages (i.e. documents which have been split

			          up into multiple messages), so check your local documentation on

			          how to manipulate these messages.

			Below is the data which will enable a MIME compliant mail reader

			implementation to automatically retrieve the ASCII version of the

			Internet-Draft.

			Content-Type: text/plain

			Content-ID: <[email-masked]>

			_______________________________________________

			I-D-Announce mailing list

			[email-masked]

			https://www1.ietf.org/mailman/listinfo/i-d-announce

________________________________

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

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