Igor, Are you saying that PCEP doesn't have any authentication? If it doesn't it will have!
No way it will get through IESG review without that. Adrian ----- Original Message ----- From: "Igor Bryskin" <[EMAIL PROTECTED]> To: "Rich Bradford (rbradfor)" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, March 07, 2006 3:21 PM 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) To: Igor Bryskin ; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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 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 ----- From: Rich Bradford (rbradfor) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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 protected] 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: 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 PROTECTED] 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 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 [email protected] https://www1.ietf.org/mailman/listinfo/i-d-announce -------------------------------------------------------------------------- -- _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce -------------------------------------------------------------------------- ------ > _______________________________________________ > Pce mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
