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

Mon, 06 Mar 2006 13:32:04 -0800

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 PROTECTED]
Sent: Monday, March 06, 2006 4:22 PM
To: Rich Bradford (rbradfor); [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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 -----

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

 

 

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

Reply-To: [EMAIL PROTECTED]

 

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:

 

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

[EMAIL PROTECTED] with the word unsubscribe in the body of the message.  

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

 

 

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

 

Send a message to:

          [EMAIL PROTECTED].

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

 

_______________________________________________

I-D-Announce mailing list

 

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

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

Reply via email to