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

From: "Rich Bradford \(rbradfor\)" <[email-masked]>
Date: Tue, 7 Mar 2006 11:37:50 -0500

Igor, 

Thanks for the clarification.

The authentication called out in section 12 of PCEP could be used to
address this concern. If this restriction were enabled, a PCE would only
expand a PKS for authenticated clients, making MD5 (or its equivalent
from PCEP) required for this extension. The downside of requiring
authentication is called out in section 12.1 of PCEP, which describes
the operator overhead of implementing these keys as onerous. However,
these keys would only need to be configured on the AS-border LSRs (and
the PCEs), since those would be the only nodes where the expansion would
be needed. Perhaps use of authentication in this situation could be
suggested or recommended. Would that address the issue adequately?

Sincerely,

Rich

________________________________

From: Igor Bryskin [mailto:[email-masked]] 
Sent: Tuesday, March 07, 2006 10:22 AM
To: Rich Bradford (rbradfor); [email-masked]
Cc: [email-masked]
Subject: 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-se
gment-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

---

From: "Igor Bryskin" <[email-masked]>
Date: Tue, 7 Mar 2006 12:00:10 -0500

Rich,

Yes, I think PCEP needs some strong authentication mechanism, I'd say similar to one used in HTTP. It is not just about resolving of PKSs. For example, two PCCs may request from a PCE a TE path between two ASBRs across an AS. Suppose, PCC1 belongs to the AS, and PCC2 does not. How can the PCE return an explicit path to PCC1 without authenticating it first?

Igor 
  ----- Original Message ----- 
  From: Rich Bradford (rbradfor) 
  To: Igor Bryskin ; [email-masked] 
  Cc: [email-masked] 
  Sent: Tuesday, March 07, 2006 11:37 AM
  Subject: RE: [Pce] RE: I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt 

  Igor, 

  The authentication called out in section 12 of PCEP could be used to address this concern. If this restriction were enabled, a PCE would only expand a PKS for authenticated clients, making MD5 (or its equivalent from PCEP) required for this extension. The downside of requiring authentication is called out in section 12.1 of PCEP, which describes the operator overhead of implementing these keys as onerous. However, these keys would only need to be configured on the AS-border LSRs (and the PCEs), since those would be the only nodes where the expansion would be needed. Perhaps use of authentication in this situation could be suggested or recommended. Would that address the issue adequately?

  Sincerely,

  Rich

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

  From: Igor Bryskin [mailto:[email-masked]] 
  Sent: Tuesday, March 07, 2006 10:22 AM
  To: Rich Bradford (rbradfor); [email-masked]
  Cc: [email-masked]
  Subject: 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