Networking Working Group Rich Bradford (Ed)
IETF Internet Draft JP Vasseur (Ed)
Cisco Systems, Inc.
Adrian Farrel
Old Dog Consulting
Proposed Status: Standard
Expires: August 2006
February 2006
draft-rbradfor-ccamp-confidential-segment-00.txt
Protocol Extensions for Signaling Confidential Path Segments in
Multiprotocol Label Switching Traffic Engineering.
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Bradford, Vasseur et al. 1
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
Abstract
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.
Table of contents
To be Added
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
1. Note
It must be noted that this document proposes RSVP-TE and PCEP
protocol extensions and will eventually result in two separate
documents to be discussed in the CCAMP and PCE Working Groups
respectively.
2. Terminology
ASBR Routers: border routers used to connect to another AS of a
different or the same Service Provider via one or more links inter-
connecting between ASs.
Bradford, Vasseur, and Farrel 2
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
CPS: Confidential Path Segment. A segment of a calculated path which
contains nodes and links internal to an AS and which the AS policy
requires not to be disclosed outside the AS.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
LSR: Label Switching Router.
LSP: Label Switched Path.
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
TE LSP: Traffic Engineering Label Switched Path
3. Introduction
Path computation techniques using the Path Computation Element (PCE)
have been described in [PCE-ARCH] and allow for optimal path
computation of inter-domain Multiprotocol (MPLS) traffic engineering
(TE) Label Switched Paths (LSPs).
An important element of inter-domain TE is that TE information is not
shared between domains for scalability and confidentiality reasons.
Therefore, a single PCE is unlikely to be able to compute a full
inter-domain path.
Two routing scenarios can be used for inter-domain TE LSPs: one using
per-domain path computation (defined in [PD-PATH-COMP]), and the
other using a PCE-based path computation technique with cooperation
between PCEs (as described in [PCE-ARCH]). In this second case, paths
for inter-domain LSPs are computed by cooperation between PCEs each
of which computes a segment of the path across one domain.
If confidentiality is required between domains (such as would very
likely be the case between ASs) then cooperating PCEs cannot exchange
path segments or else the PCE and the Path Computation Client (PCC)
will be able to see the individual hops through another domain. We
define the part of the path which we wish to keep confidential as the
Confidential Path Segment (CPS).
One mechanism for preserving the confidentiality of the CPS is for
the PCE to return a path consisting of loose hops for the segment
internal to a domain. The concept of loose hops for the route of an
LSP is described in [RFC3209]. The Path Computation Element
Bradford, Vasseur, and Farrel 3
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
Communication Protocol (PCEP) supports the use of paths with loose
hops and it is a local policy decision at a PCE whether it returns a
full explicit path or uses loose hops.
If loose hops are used, the TE LSPs are signaled as normal [RFC3209]
and when a loose hop is encountered in the explicit route it is
resolved by performing a secondary path computation. Given the nature
of the cooperation between PCEs in computing the original path, this
secondary computation occurs at a Label Switching Router (LSR) at a
domain boundary and the route is expanded as described in [PD-PATH-
COMP].
The PCE-based computation model is particularly useful for
determining mutually disjoint inter-domain paths such as might be
required for service protection. A single path computation request is
used. However, if loose hops are returned, the path of each LSP must
be recomputed at the domain boundaries as the LSPs are signaled, and
since the LSP signaling proceeds independently for each LSP, disjoint
paths cannot be guaranteed.
Therefore, using existing techniques, confidentiality and path
diversity are mutually incompatible requirements.
This document defines two solutions, each extending the Explicit
Route Object defined in [RFC3209] with a new sub-object. The first
solution preserves confidentiality by encrypting the path for the CPS
into a Private Route sub-object (PRS). The second solution preserves
confidentiality by replacing the CPS segment with a Path Key sub-
object (PKS), which is used to retrieve the computed path segment.
The next sections provide the details for the PKS and PRS solutions.
4. Path-Key Solution
The Path-Key solution applies exclusively to the PCE-based path
computation context. A PCE computes a path segment and replaces it in
the path reported to the PCC (or another PCE) by a single sub-object
referred to as the PKS. The entry and exit boundary LSRs of each CPS
MUST be specified as strict nodes in the returned path - only the
path segments strictly between these boundary routers are replaced by
the PKS.
4.1. Mode of Operation
Bradford, Vasseur, and Farrel 4
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
During path computation, when local policy dictates that
confidentiality must be preserved, the PCE associates a path-key with
the computed path for the CPS, inserts its PCE-ID along with the
path-key in a PKS, and inserts the PKS in between the sub-objects
that identify the start and end points of the CPS in the path
returned to the PCC. The PCE MUST store the computed path segment and
the path-key for later retrieval. A local policy SHOULD be used to
determine for how long to retain such stored information and whether
to discard the information after it has been queried using the
procedures described below.
A head-end LSR that is a PCC converts the path returned by a PCE into
an explicit route object (ERO) that it includes in the Resource
Reservation Protocol (RSVP) Path message. If the path returned by the
PCE contains PKSs these are included in the ERO. Like any other sub-
objects, the PKS is passed transparently from hop to hop, until it
becomes the first sub-object in the ERO. This will occur at the
domain boundary. The PKS MUST be preceded by an ERO sub-object that
identifies the start of the CPS and so the PKS will not be
encountered in ERO processing until the LSR at the start of the CPS
attempts to evaluate the next hop along the path of the LSP.
An LSR that encounters a PKS when trying to identify the next-hop
retrieves the PCE-ID from the PKS and sends the path-key to the PCE
in a PCEP query.
Upon receiving the path computation request, the PCE identifies the
computed path segment using the supplied path-key, and returns the
previously computed path segment in the form of explicit hops to the
requesting node. The requesting node inserts the explicit hops into
the ERO and continues to process the LSP setup as per [RFC3209].
Note that if a PCE fails to expand a PKS, the requesting LSR MUST
fail the LSP setup and SHOULD use the procedures associated with
loose hop expansion failure [RFC3209].
5. Encrypted Path Segment Solution
This section describes the mechanism where the LSR or PCE encrypts
path of a CPS(s) in order to preserve confidentiality.
Following the complete route calculation for a given domain, the PCE
encrypts the path for the CPS using a locally configured encryption
technique and places the resulting information into a PRS. The path
returned to the PCC contains sub-objects identifying the start and
end of the CPS, but the path between these points is replaced by the
PRS.
Bradford, Vasseur, and Farrel 5
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
The head-end LSR (PCC) includes the path supplied by the PCE in its
signaling message encoded as an ERO just as normal. When an LSR
encounters a PRS in the ERO during next hop resolution, the LSR
attempts to extract the CPS from the PRS by decrypting the
information.
If an ingress node fails to expand a PRS, the LSP setup MUST be
rejected using a PathErr message carrying the Error Code PRS object
supported but unknown key.
Each domain could be configured to use its own encryption method, so
that if a route spans several domains, each encrypted CPS could be
encrypted using a different algorithm as well as a different key.
Decryption could be available on domain boundary LSRs or could
require the consultation of a PCE according to domain policy. Since
the PCE is aware of the LSR that will attempt decryption, it MAY
select a key that is known by that LSR. Indeed, the PCE's choice of
encryption method and key is a matter of configurable policy on each
PCE and could allow:
- Using a single encryption method and key for an entire domain.
- Using an encryption method and key for a specific group of LSR
interfaces. For example, all the LSR interfaces that connect to
Customer A could use one key, and all those that connect to Customer
B could use a different key. This method would allow the encryption
to be disabled or for the keys to be made available to a third-party
for purposes of monitoring, debugging, or route validation, without
the information being made available about paths computed to other
customers.
- Use an encryption method and key specific to an LSR or group of
LSRs. This would allow, for example, every LSR that might be the
start of a CPS within the domain (nominally, every domain border
LSR) to share a unique public key with the PCE, providing every LSR
with independent encryption.
The PRS is defined to allow multiple encryption options, but as a
minimum MUST support AES with a 128-bit key as defined in the NIST
CBC definition from [CBC], along with the padding method defined in
Appendix A of that document. In addition, to provide adequate message
authentication, the encryption MUST also adhere to the AES CMAC as
described in [CMAC]:
6. PCEP/RSVP-TE Object extensions
Two extensions to the ERO are defined. Each requires the addition of
a new sub-object. Each sub-object is used to represent an entire CPS.
6.1. Path Key Sub-object
Bradford, Vasseur, and Farrel 6
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
The Path Key sub-object (PKS) is carried within the ERO of the PCEP
PCRep message [PCEP] and the ERO of the RSVP-TE Path message
[RFC3209]. The PKS is a fixed-length sub-object containing a Path-Key
and a PCE-ID. The Path Key is an identifier, or token used to
represent the CPS within the context of the PCE identified by the
PCE-ID. The PCE-ID identifies the PCE that encoded and can decode the
Path Key using an IPv4 or IPv6 address of the PCE. Because of the
IPv4 and IPv6 variants, two subobjects are defined as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
The L bit MUST NOT be set, so that the sub-object represents
a strict hop in the explicit route.
Type
TBD Path Key with IPv4 address
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is always 8.
IPv4 address
An IPv4 address of the PCE that can decode this key. The
address used SHOULD be an address of the PCE that is always
reachable, but MAY be an address that is restricted to the domain in
which the CPS lies.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bradford, Vasseur, and Farrel 7
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
L
The L bit MUST NOT be set, so that the sub-object represents
a strict hop in the explicit route.
Type
TBD Path Key with IPv6 address
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is always
20.
IPv6 address
An IPv6 address of the PCE that can decode this key. The
address used SHOULD be an address of the PCE that is always
reachable, but MAY be an address that is restricted to the domain in
which the CPS lies.
6.2. Private Route Sub-object
The Private Route Subobject (PRS) is carried within the ERO of the
PCEP PCRep message [PCEP] and the ERO of the RSVP-TE Path message
[RFC3209]. The PRS is a variable length sub-object containing an
encryption type field to specify the encryption algorithm configured
that was used and the encrypted path. The sub-object is padded with
trailing zeros as necessary to align it with a four-byte boundary.
The sub-object is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Encryption | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Encrypted Path ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
The L bit MUST NOT be set, so that the sub-object represents
a strict hop in the explicit route.
Type
Bradford, Vasseur, and Farrel 8
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
TBD Encrypted Path
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields, and including any
trailing zero pads.
Encrypted Path
The encrypted path segment. This field is padded with
trailing zeros to make the sub-object a multiple of four bytes long.
7. Security Considerations
This document proposes tunneling secure topology information across
an untrusted AS, so the considerations are many.
Issues include:
-
Security of the CPS.
-
Authenticity of the CPS (resilience to alteration by
intermediaries).
-
Resilience from DNS attacks.
8. IANA considerations
The IANA section will be detailed in further revision of this
document.
For RSVP, it will include code point requests for the three new ERO
sub-objects, and a new ErrorSpec Error Code.
For PCEP, it will include code point requests for the three new
computed path sub-objects.
Bradford, Vasseur, and Farrel 9
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
9. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E.,
Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element
(PCE) communication Protocol (PCEP)", draft-vasseur-pce-pcep,
work in progress.
10.2. Informational References
[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE) Architecture", draft-ietf-pce-architecture, work in
progress.
[PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation
method for establishing Inter-domain Traffic Engineering (TE) Label
Bradford, Vasseur, and Farrel 10
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path-comp,
work in progress.
[RBPC] Vasseur, J., et al "A Backward Recursive PCE-based Computation
(BRPC) procedure to compute shortest inter-domain Traffic Engineering
Label Switched Path", draft-vasseur-ccamp-brpc, work in progress.
[CBC] Morris Dworkin, "Recommendation for Block Cipher Modes of
Operation Methods and Techniques",
http://csrc.nist.gov/CryptoToolkit/modes/800-
38_Series_Publications/SP800-38A.pdf
[CMAC] Morris Dworkin, "Recommendation for Block Cipher Modes of
Operation: The CMAC Mode for Authentication",
http://csrc.nist.gov/CryptoToolkit/modes/800-
38_Series_Publications/SP800-38B.pdf
11. Authors' Addresses:
Rich Bradford (Editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough , MA - 01719
USA
Email: rbradfor@cisco.com
J.-P Vasseur (Editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Bradford, Vasseur, and Farrel 11
draft-rbradfor-ccamp-confidential-segment-00.txt February 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Bradford, Vasseur, and Farrel 12