draft-ietf-pce-pcep-01.txt   draft-ietf-pce-pcep-02.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Expires: August 28, 2006 JL. Le Roux Expires: December 24, 2006 JL. Le Roux
France Telecom France Telecom
A. Ayyangar A. Ayyangar
Juniper Networks Juniper Networks
E. Oki E. Oki
NTT NTT
A. Atlas A. Atlas
Google Google
A. Dolganow A. Dolganow
Alcatel Alcatel
Y. Ikejiri Y. Ikejiri
NTT Communications Corporation NTT Communications Corporation
K. Kumaki K. Kumaki
KDDI Corporation KDDI Corporation
February 24, 2006 June 22, 2006
Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 Path Computation Element (PCE) communication Protocol (PCEP) - Version 1
draft-ietf-pce-pcep-02.txt
draft-ietf-pce-pcep-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 48 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2006. This Internet-Draft will expire on December 24, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies the Path Computation Element communication This document specifies the Path Computation Element communication
Protocol (PCEP) for communications between a Path Computation Client Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between two PCEs. (PCC) and a Path Computation Element (PCE), or between two PCEs.
Such interactions include path computation requests and path Such interactions include path computation requests and path
skipping to change at page 3, line 42 skipping to change at page 3, line 42
7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24 7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24
7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26 7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26
7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 27 7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 27
7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 28 7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 28
7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 29 7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 29
7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 30 7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 30
7.8. ERO Object . . . . . . . . . . . . . . . . . . . . . . . . 32 7.8. ERO Object . . . . . . . . . . . . . . . . . . . . . . . . 32
7.9. RRO Object . . . . . . . . . . . . . . . . . . . . . . . . 33 7.9. RRO Object . . . . . . . . . . . . . . . . . . . . . . . . 33
7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 33 7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 33
7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 35 7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 35
7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 35 7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 36
7.12.1. Independent versus synchronized path computation 7.12.1. Independent versus synchronized path computation
requests . . . . . . . . . . . . . . . . . . . . . . . 35 requests . . . . . . . . . . . . . . . . . . . . . . . 36
7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 37 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 37
7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 38 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 38
7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 39 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 39
7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 42 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 42
7.15. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 44 7.15. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 44
8. Manageability Considerations . . . . . . . . . . . . . . . . . 45 8. Manageability Considerations . . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 45 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 45 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 45
9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 46 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 46
9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 47 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 47
9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 48 9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 49
10.1. PCEP Authentication and Integrity . . . . . . . . . . . . 50 11. Security Considerations . . . . . . . . . . . . . . . . . . . 54
10.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 50 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 55
10.3. Protection against Denial of Service attacks . . . . . . . 50 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 55
10.4. Request input shaping/policing . . . . . . . . . . . . . . 51 11.3. Protection against Denial of Service attacks . . . . . . . 55
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 11.4. Request input shaping/policing . . . . . . . . . . . . . . 56
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.2. Informative References . . . . . . . . . . . . . . . . . . 52 13.1. Normative References . . . . . . . . . . . . . . . . . . . 56
13.2. Informative References . . . . . . . . . . . . . . . . . . 57
Appendix A. Proposed Status and Discussion [To Be Removed Appendix A. Proposed Status and Discussion [To Be Removed
Upon Publication] . . . . . . . . . . . . . . . . . . 53 Upon Publication] . . . . . . . . . . . . . . . . . . 58
Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 53 Appendix B. Compliance with the PCECP Requirement Document . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Appendix C. PCEP Variables . . . . . . . . . . . . . . . . . . . 59
Intellectual Property and Copyright Statements . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . . . . 62
1. Terminology 1. Terminology
Terminology used in this document Terminology used in this document
Explicit path: full explicit path from start to destination made of a Explicit path: full explicit path from start to destination made of a
list of strict hops where a hop may be an abstract node such as an list of strict hops where a hop may be an abstract node such as an
AS. AS.
IGP Area: OSPF Area or IS-IS level. IGP Area: OSPF Area or IS-IS level.
skipping to change at page 21, line 27 skipping to change at page 21, line 27
The procedure upon the reception of a PCErr message is defined in The procedure upon the reception of a PCErr message is defined in
Section 7.14. Section 7.14.
6.8. Close message 6.8. Close message
The Close message is a PCEP message sent by either a PCC to a PCE or The Close message is a PCEP message sent by either a PCC to a PCE or
by a PCE to a PCC in order to close a PCEP session. The Message-Type by a PCE to a PCC in order to close a PCEP session. The Message-Type
field of the PCEP common header for the Open message is set to 7 (To field of the PCEP common header for the Open message is set to 7 (To
be confirmed by IANA). be confirmed by IANA).
Open message Close message
<Close Message>::= <Common Header> <Close Message>::= <Common Header>
<CLOSE> <CLOSE>
The Close message MUST contain exactly one CLOSE object (see The Close message MUST contain exactly one CLOSE object (see
Section 6.8). Section 6.8).
Upon the receipt of a Close message, the receiving PCEP peer MUST Upon the receipt of a Close message, the receiving PCEP peer MUST
cancel all pending requests and MUST close the TCP connection. cancel all pending requests and MUST close the TCP connection.
7. Object Formats 7. Object Formats
skipping to change at page 25, line 8 skipping to change at page 25, line 8
7.3.1. Object definition 7.3.1. Object definition
RP Object-Class is to be assigned by IANA (recommended value=2) RP Object-Class is to be assigned by IANA (recommended value=2)
RP Object-Type is to be assigned by IANA (recommended value=1) RP Object-Type is to be assigned by IANA (recommended value=1)
The format of the RP object body is as follows: The format of the RP object body is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |O|B|R| Pri | | Reserved | Flags |N|O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number | | Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: RP object body format Figure 10: RP object body format
skipping to change at page 26, line 23 skipping to change at page 26, line 23
latency and jitter) in each direction. When cleared, the TE LSP is latency and jitter) in each direction. When cleared, the TE LSP is
unidirectional. unidirectional.
O (strict/lOose - 1 bit): when set, in a PCReq message, this O (strict/lOose - 1 bit): when set, in a PCReq message, this
indicates that a strict/loose path is acceptable. Otherwise, when indicates that a strict/loose path is acceptable. Otherwise, when
cleared, this indicates to the PCE that an explicit path is required. cleared, this indicates to the PCE that an explicit path is required.
In a PCRep message, when the O bit is set this indicates that the In a PCRep message, when the O bit is set this indicates that the
returned path is strict/loose, otherwise (the O bit is cleared), the returned path is strict/loose, otherwise (the O bit is cleared), the
returned path is explicit. returned path is explicit.
F (new - 1 bit): when set, the requesting PCC requires the
computation of a new path for a TE LSP that has failed in which case
the path of the existing TE LSP MUST be provided in the PCReq (except
of 0-bandwidth TE LSP) message by means of an RRO object defined in
Section 7.9. This is to avoid double bandwidth booking should the
TED not be yet updated or the corresponding resources not be yet
released.
Request-ID-number (32 bits). The Request-ID-number value combined Request-ID-number (32 bits). The Request-ID-number value combined
with the source IP address of the PCC and the PCE address uniquely with the source IP address of the PCC and the PCE address uniquely
identify the path computation request context. The Request-ID-number identify the path computation request context. The Request-ID-number
MUST be incremented each time a new request is sent to the PCE. If MUST be incremented each time a new request is sent to the PCE. If
no path computation reply is received from the PCE, and the PCC no path computation reply is received from the PCE, and the PCC
wishes to resend its request, the same Request-ID-number MUST be wishes to resend its request, the same Request-ID-number MUST be
used. Conversely, different Request-ID-number MUST be used for used. Conversely, different Request-ID-number MUST be used for
different requests sent to a PCE. The same Request-ID-number may be different requests sent to a PCE. The same Request-ID-number may be
used for path computation requests sent to different PCEs. The path used for path computation requests sent to different PCEs. The path
computation reply is unambiguously identified by the IP source computation reply is unambiguously identified by the IP source
skipping to change at page 49, line 48 skipping to change at page 49, line 48
1 1
8 Unacceptable PCEP session characteristics 8 Unacceptable PCEP session characteristics
Error-value Error-value
1 1
9 Deadtimer expiration 9 Deadtimer expiration
Error-value Error-value
1 1
10. Security Considerations 10. PCEP Finite State Machine (FSM)
The section describes the PCEP Finite State Machine (FSM).
PCEP Finite State Machine
+-+-+-+-+-+-+<------+
+------| SessionUP |<---+ |
| +-+-+-+-+-+-+ | |
| | |
| +->+-+-+-+-+-+-+ | |
| | | KeepWait |----+ |
| +--| |<---+ |
|+-----+-+-+-+-+-+-+ | |
|| | | |
|| | | |
|| V | |
|| +->+-+-+-+-+-+-+----+ |
|| | | OpenWait |-------+
|| +--| |<------+
||+----+-+-+-+-+-+-+<---+ |
||| | | |
||| | | |
||| V | |
||| +->+-+-+-+-+-+-+ | |
||| | |TCPPending |----+ |
||| +--| | |
|||+---+-+-+-+-+-+-+<---+ |
|||| | | |
|||| | | |
|||| V | |
|||+--->+-+-+-+-+ | |
||+---->| Idle |-------+ |
|+----->| |----------+
+------>+-+-+-+-+
Figure 15: PCEP Finite State Machine for the PCC
PCEP defines the following set of variables:
TCPConnect: timer (in seconds) started after having initialized a TCP
connection using the PCEP well-known TCP port. The value of the
TCPConnect timer is 60 seconds. TCPRetry: specifies the number of
times the system has tried to establish a TCP connection with a PCEP
peer without success. TCPMaxRetry: Maximum number of times the
system tries to establish a TCP connection using the PCEP well-known
TCP port before going back to the Idle state. The value of the
TCPMaxRetry is 5. OpenWait: timer (in seconds) that corresponds to
the amount of time a PCEP peer will wait to receive an Open message
from the PCEP peer after the expiration of which the system releases
the PCEP resource and go back to the Idle state. KeepWait: timer (in
seconds) that corresponds to the amount of time a PCEP peer will wait
to receive a KeepAlive or a PCErr message from the PCEP peer after
the expiration of which the system releases the PCEP resource and go
back to the Idle state. OpenRetry: specifies the number of times the
system has received an Open message with unacceptable PCEP session
characteristics. OpenMaxRetry: Maximum number of times the system
can receive an Open message with unacceptable PCEP sessions
characteristics before releasing the PCEP session with that peer and
go back to Idle state. The value of the OpenMaxRetry is 3. The
following two states variable are defined:
RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system
has received an acceptable Open message. LocalOK: the LocalOK
variable is a Boolean set to 1 if the system has received a Keepalive
message acknowledging that the Open message sent to the peer was
valid.
Idle State:
The idle state is the initial PCEP state where PCEP (also referred to
as "the system") waits for an initialization event that can either be
manually triggered by the user (configuration) or automatically
triggered by various events. In Idle state, PCEP resources are
allocated (memory, potential process, ...) but no PCEP messages are
accepted from any PCEP peer. The system listens the well-known PCEP
TCP port.
The following set of variable are initialized:
TCPRetry=0,
LocalOK=0,
RemoteOK=0,
Upon detection of a local initialization event (e.g. user
configuration to establish a PCEP session with a particular PCEP
peer, local event triggering the establishment of a PCEP session with
a PCEP peer, ...), the system:
o Starts the TCPConnect timer,
o Initiates of a TCP connection with the PCEP peer,
o Increments the TCPRetry variable,
o Moves to the TCPPending state.
Upon receiving a TCP connection on the well-known PCEP TCP port, if
the TCP connection establishment succeeds, the system:
o Sends an Open message
o Starts the OpenWait timer
o Moves to the OpenWait state
It is expected that an implementation will use an exponentially
increase timer between automatically generated Initialization events
and between retrials of TCP connection establishments.
TCPPending State
If the TCP connection establishment succeeds, the system:
o Sends an Open message,
o Starts the OpenWait timer,
o Starts the KeepWait timer,
o Moves to the OpenWait state.
If the TCP connection establishement fails (an error is detected
during the TCP connection establishment) or the TCPConnectTimer
expires:
If TCPRetry =TCPMaxRetry the system moves to the Idle State
If TCPRetry variable < TCPMaxRetry the system:
o Starts the TCPConnect timer,
o Initiates of a TCP connection with the PCEP peer,
o Increments the TCPRetry variable.
If the system detects that the PCEP peer tries to simultaneously
establish a TCP connection, it stops the TCP connection establishment
if and only if the PCEP peer has a higher IP address and moves to the
Idle state. This guarantees that in case of "collision" a single TCP
connection is established.
OpenWait State:
In the OpenWait state, the system waits for an Open message from its
PCEP peer.
If the system receives an Open message from the PCEP peer before the
expiration of the OpenWait timer, PCEP checks the PCEP session
attributes (Keepalive frequency, DeadTimer, ...).
If an error is detected (malformed Open message, unsupported PCEP
session characteristics), PCEP generates an error notification,
release the PCEP resources for the PCEP peer, closes the TCP
connection and moves to the Idle state.
If no Open message is received before the expiration of the OpenWait
timer, the system releases the PCEP resources for the PCEP peer,
closes the TCP connection and moves to the Idle state.
If no errors are detected and the session characteristics are
acceptable to the local system, the system:
o Sends a Keepalive message to the PCEP peer,
o Starts the Keepalive timer,
o Sets the RemoteOK variable to 1.
If LocalOK=1 the system moves to the UP state
If LocalOK=0 the system moves to the KeepWait state.
If no errors are detected but there is a disagreement on the session
characteristics (such as the Keepalive frequency or the DeadTimer), a
PCErr message is sent to the peer (reporting the values for which a
disagreement exists).
If OpenRetry=OpenMaxRetry the system releases the PCEP resources for
that peer amd moves back to the Idle state.
If OpenRetry < OpenMaxRetry the system:
o sends a PCErr message containing proposed acceptable session
characteristics,
o Increments the OpenRetry variable.
KeepWait State
In the Keepwait state, the system waits for the receipt of a
Keepalive from its PCEP peer acknowledging its Open message or a
PCErr message in response to unacceptable PCEP session
characteristics proposed in the Open message.
If a Keepalive message is received before the expiration of the
KeepWait timer, LocalOK=1
If RemoteOK=1, the system moves to the UP state.
If RemoteOK=0, the system moves to the OpenWait State.
If a PCErr message is received before the expiration of the KeepWait
timer:
1. If the proposed values are unacceptable, the sytem releases the
PCEP resources for that PCEP peer, closes the TCP connection and
moves to the Idle state.
2. If the proposed values are acceptable, the sytem adjusts its PCEP
session characteristics according to the proposed values received
in the PCErr message restarts the KeepWait timer and sends a new
Open message. If RemoteOK=1, the system stays in the KeepWait
state. If RemoteOK=0, the system moves to the OpenWait state.
If neither a Keepalive nor a PCErr is received after the expiration
of the KeepWait timer, the system releases the PCEP resources for
that PCEP peer, closes the TCP connection and moves to the Idle
State.
UP State
In the UP state, the PCEP peer starts exchanging PCEP messages
according to the session characteristics.
If the Keepalive timer expires, the systens sends a Keepalive
message.
If no Keepalive message is received from the PCEP peer after the
expiration of the DeadTimer, the systems sends a PCEP CLOSE message,
releases the PCEP resources for that PCEP peer, closes the TCP
connection and moves to the Idle State.
In a malformed PCEP message is received or the TCP connection fails,
the systems sends a PCEP CLOSE message, the system releases the PCEP
resources for that PCEP peer, closes the TCP connection and moves to
the Idle State.
11. Security Considerations
The PCEP protocol could be the target of the following attacks: The PCEP protocol could be the target of the following attacks:
o Spoofing (PCC or PCE impersonation) o Spoofing (PCC or PCE impersonation)
o Snooping (message interception) o Snooping (message interception)
o Falsification o Falsification
o Denial of Service o Denial of Service
A PCEP attack may have significant impact, particularly in an A PCEP attack may have significant impact, particularly in an
inter-AS context as PCEP facilitates inter-AS path establishment. inter-AS context as PCEP facilitates inter-AS path establishment.
Several mechanisms are proposed below, so as to ensure Several mechanisms are proposed below, so as to ensure
authentication, integrity and privacy of PCEP Communications, and authentication, integrity and privacy of PCEP Communications, and
also to protect against DoS attacks. also to protect against DoS attacks.
10.1. PCEP Authentication and Integrity 11.1. PCEP Authentication and Integrity
It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to
provide for the authenticity and integrity of PCEP messages. This provide for the authenticity and integrity of PCEP messages. This
will allow protecting against PCE or PCC impersonation and also will allow protecting against PCE or PCC impersonation and also
against message content falsification. against message content falsification.
This requires the maintenance, exchange and configuration of MD-5 This requires the maintenance, exchange and configuration of MD-5
keys on PCCs and PCEs. Note that such maintenance may be especially keys on PCCs and PCEs. Note that such maintenance may be especially
onerous to the operators as pointed out in [I-D.ietf-rpsec- onerous to the operators as pointed out in [I-D.ietf-rpsec-
bgpsecrec]. Hence it is important to limit the number of keys while bgpsecrec]. Hence it is important to limit the number of keys while
ensuring the required level of security. ensuring the required level of security.
MD-5 signature faces some limitations, as per explained in [RFC2385]. MD-5 signature faces some limitations, as per explained in [RFC2385].
Note that when one digest technique stronger than MD5 is specified Note that when one digest technique stronger than MD5 is specified
and implemented, PCEP could be easily upgraded to use it. and implemented, PCEP could be easily upgraded to use it.
10.2. PCEP Privacy 11.2. PCEP Privacy
Ensuring PCEP communication privacy is of key importance, especially Ensuring PCEP communication privacy is of key importance, especially
in an inter-AS context, where PCEP communication end-points do not in an inter-AS context, where PCEP communication end-points do not
reside in the same AS, as an attacker that intercept a PCE message reside in the same AS, as an attacker that intercept a PCE message
could obtain sensitive information related to computed paths and could obtain sensitive information related to computed paths and
resources. Privacy can be ensured thanks to encryption. To ensure resources. Privacy can be ensured thanks to encryption. To ensure
privacy of PCEP communication, IPSec [RFC2406] tunnels MAY be used privacy of PCEP communication, IPSec [RFC2406] tunnels MAY be used
between PCC and PCEs or between PCEs. Note that this could also be between PCC and PCEs or between PCEs. Note that this could also be
used to ensure Authentication and Integrity, in which case, TCP MD-5 used to ensure Authentication and Integrity, in which case, TCP MD-5
option would not be required. option would not be required.
10.3. Protection against Denial of Service attacks 11.3. Protection against Denial of Service attacks
PCEP can be the target of TCP DoS attacks, such as for instance SYN PCEP can be the target of TCP DoS attacks, such as for instance SYN
attacks, as all protocols running on top of TCP. PCEP can use the attacks, as all protocols running on top of TCP. PCEP can use the
same mechanisms as defined in [RFC3036] to mitigate the threat of same mechanisms as defined in [RFC3036] to mitigate the threat of
such attacks: such attacks:
o A PCE should avoid promiscuous TCP listens for PCEP TCP session o A PCE should avoid promiscuous TCP listens for PCEP TCP session
establishment. It should use only listens that are specific to establishment. It should use only listens that are specific to
authorized PCCs. authorized PCCs.
o The use of the MD5 option helps somewhat since it prevents a SYN o The use of the MD5 option helps somewhat since it prevents a SYN
from being accepted unless the MD5 segment checksum is valid. from being accepted unless the MD5 segment checksum is valid.
However, the receiver must compute the checksum before it can However, the receiver must compute the checksum before it can
decide to discard an otherwise acceptable SYN segment. decide to discard an otherwise acceptable SYN segment.
o The use of access-list on the PCE so as to restrict access to o The use of access-list on the PCE so as to restrict access to
authorized PCCs. authorized PCCs.
10.4. Request input shaping/policing 11.4. Request input shaping/policing
A PCEP implementation may be subject to Denial Of Service attacks A PCEP implementation may be subject to Denial Of Service attacks
consisting of sending a very large number of PCEP messages (e.g. consisting of sending a very large number of PCEP messages (e.g.
PCReq messages). Thus, especially in multi-Service Providers PCReq messages). Thus, especially in multi-Service Providers
environments, a PCE implementation should implement request input environments, a PCE implementation should implement request input
shaping/policing so as to throttle the amount of received PCEP shaping/policing so as to throttle the amount of received PCEP
messages without compromising the implementation behavior. messages without compromising the implementation behavior.
11. Acknowledgements 12. Acknowledgements
The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash,
Igor Bryskin for their very valuable input. Special thank to Adrian Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard
Douville for their very valuable input. Special thank to Adrian
Farrel for his very valuable suggestions. Farrel for his very valuable suggestions.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
skipping to change at page 52, line 14 skipping to change at page 57, line 17
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
12.2. Informative References 13.2. Informative References
[I-D.ietf-ccamp-inter-domain-rsvp-te] [I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions", Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-02 (work in draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in
progress), October 2005. progress), March 2006.
[I-D.ietf-pce-architecture] [I-D.ietf-pce-architecture]
Farrel, A., "A Path Computation Element (PCE) Based Farrel, A., "A Path Computation Element (PCE) Based
Architecture", draft-ietf-pce-architecture-04 (work in Architecture", draft-ietf-pce-architecture-05 (work in
progress), January 2006. progress), April 2006.
[I-D.ietf-pce-comm-protocol-gen-reqs] [I-D.ietf-pce-comm-protocol-gen-reqs]
Roux, J. and J. Ash, "PCE Communication Protocol Generic Roux, J. and J. Ash, "PCE Communication Protocol Generic
Requirements", draft-ietf-pce-comm-protocol-gen-reqs-04 Requirements", draft-ietf-pce-comm-protocol-gen-reqs-06
(work in progress), February 2006. (work in progress), May 2006.
[I-D.ietf-pce-disco-proto-igp] [I-D.ietf-pce-disco-proto-igp]
Roux, J., "IGP protocol extensions for Path Computation Roux, J., "IGP protocol extensions for Path Computation
Element (PCE) Discovery", Element (PCE) Discovery",
draft-ietf-pce-disco-proto-igp-00 (work in progress), draft-ietf-pce-disco-proto-igp-01 (work in progress),
November 2005. March 2006.
[I-D.ietf-pce-discovery-reqs] [I-D.ietf-pce-discovery-reqs]
Roux, J., "Requirements for Path Computation Element (PCE) Roux, J., "Requirements for Path Computation Element (PCE)
Discovery", draft-ietf-pce-discovery-reqs-03 (work in Discovery", draft-ietf-pce-discovery-reqs-05 (work in
progress), February 2006. progress), June 2006.
[I-D.ietf-pce-inter-layer-req] [I-D.ietf-pce-inter-layer-req]
Oki, E., "PCC-PCE Communication Requirements for Inter- Oki, E., "PCC-PCE Communication Requirements for Inter-
Layer Traffic Engineering", Layer Traffic Engineering",
draft-ietf-pce-inter-layer-req-01 (work in progress), draft-ietf-pce-inter-layer-req-01 (work in progress),
March 2006. March 2006.
[I-D.ietf-pce-pcecp-interarea-reqs] [I-D.ietf-pce-pcecp-interarea-reqs]
Roux, J., "PCE Communication Protocol (PCECP) Specific Roux, J., "PCE Communication Protocol (PCECP) Specific
Requirements for Inter-Area (G)MPLS Traffic Engineering", Requirements for Inter-Area (G)MPLS Traffic Engineering",
draft-ietf-pce-pcecp-interarea-reqs-01 (work in progress), draft-ietf-pce-pcecp-interarea-reqs-01 (work in progress),
February 2006. February 2006.
[I-D.ietf-rpsec-bgpsecrec] [I-D.ietf-rpsec-bgpsecrec]
Christian, B. and T. Tauber, "BGP Security Requirements", Christian, B. and T. Tauber, "BGP Security Requirements",
draft-ietf-rpsec-bgpsecrec-03 (work in progress), draft-ietf-rpsec-bgpsecrec-06 (work in progress),
October 2005. June 2006.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
skipping to change at page 53, line 39 skipping to change at page 58, line 41
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
June 2005. June 2005.
Appendix A. Proposed Status and Discussion [To Be Removed Upon Appendix A. Proposed Status and Discussion [To Be Removed Upon
Publication] Publication]
This Internet-Draft is being submitted for eventual publication as an This Internet-Draft is being submitted for eventual publication as an
RFC with a proposed status of Standard. Discussion of this proposal RFC with a proposed status of Standard. Discussion of this proposal
should take place on the following mailing list: pce@ietf.org. should take place on the following mailing list: pce@ietf.org.
Appendix B. PCEP Variables Appendix B. Compliance with the PCECP Requirement Document
The aim of this section is to list the set of requirements set forth
in [I-D.ietf-pce-comm-protocol-gen-reqs] that are not satisfied by
the current revision of this document. This only concerns the
requirements listed as MUST according to [RFC2119].
Here is the list of currently unsatisfied requirements:
o Allow to select/prefer from advertised list of standard objective
functions/options
o Allow to customize objective function/options
o Allow indicating if load-balancing is allowed
o Support "unsynchronized" & "synchronized" objective functions
o Protocol recovery support resynchronization of information &
requests between sender & receiver.
Appendix C. PCEP Variables
PCEP defines variable that can be configured. The following PCEP PCEP defines variable that can be configured. The following PCEP
variables are defined. variables are defined.
KeepAlive timer: minimum period of time between the sending of PCEP KeepAlive timer: minimum period of time between the sending of PCEP
messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A
suggested value for the Keepalive timer is 30 seconds. suggested value for the Keepalive timer is 30 seconds.
DeadTimer: period of timer after the expiration of which a PCEP peer DeadTimer: period of timer after the expiration of which a PCEP peer
declared the session down if no PCEP message has been received. declared the session down if no PCEP message has been received.
 End of changes. 29 change blocks. 
45 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/