Adrian, I assume the authentication mechaisms will be described in furure revs of PCEP, as well as key distribution mechanisms to interpret encrypted EROs.
Ia my assumption correct? Thanks, Igor ----- Original Message ----- From: "Adrian Farrel" <[EMAIL PROTECTED]> To: "Igor Bryskin" <[EMAIL PROTECTED]>; "Rich Bradford (rbradfor)" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, March 07, 2006 12:01 PM Subject: Re: [Pce] RE:I-DACTION:draft-rbradfor-ccamp-confidential-segment-00.txt > 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
