draft-ietf-ccamp-lmp-09.txt   draft-ietf-ccamp-lmp-10.txt 
Network Working Group J. Lang, Editor Network Working Group J. Lang, Editor
Internet Draft (Rincon Networks) Internet Draft (Rincon Networks)
Category: Standards Track Category: Standards Track
Expires: December 2003 June 2003 Expires: April 2004 October 2003
Link Management Protocol (LMP) Link Management Protocol (LMP)
draft-ietf-ccamp-lmp-09.txt draft-ietf-ccamp-lmp-10.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 51 skipping to change at page 2, line 51
11.3 Data Link FSM .......................................... 33 11.3 Data Link FSM .......................................... 33
11.3.1 Data Link States ................................ 33 11.3.1 Data Link States ................................ 33
11.3.2 Data Link Events ................................ 33 11.3.2 Data Link Events ................................ 33
11.3.3 Active Data Link FSM Description ................ 35 11.3.3 Active Data Link FSM Description ................ 35
11.3.4 Passive Data Link FSM Description ............... 35 11.3.4 Passive Data Link FSM Description ............... 35
12 LMP Message Formats ......................................... 36 12 LMP Message Formats ......................................... 36
12.1 Common Header .......................................... 36 12.1 Common Header .......................................... 36
12.2 LMP Object Format ...................................... 38 12.2 LMP Object Format ...................................... 38
12.3 Parameter Negotiation Messages ......................... 39 12.3 Parameter Negotiation Messages ......................... 39
12.4 Hello Message .......................................... 40 12.4 Hello Message .......................................... 40
12.5 Link Verification Messages ............................. 40 12.5 Link Verification Messages ............................. 41
12.6 Link Summary Messages .................................. 44 12.6 Link Summary Messages .................................. 44
12.7 Fault Management Messages .............................. 46 12.7 Fault Management Messages .............................. 46
13 LMP Object Definitions ...................................... 48 13 LMP Object Definitions ...................................... 47
14 Intellectual Property Considerations ........................ 65 14 Intellectual Property Considerations ........................ 64
15 References .................................................. 65 15 References .................................................. 65
16 Security Considerations ..................................... 66 16 Security Considerations ..................................... 66
16.1 Security Requirements .................................. 67 16.1 Security Requirements .................................. 66
16.2 Security Mechanisms .................................... 67 16.2 Security Mechanisms .................................... 67
17 IANA Considerations ......................................... 69 17 IANA Considerations ......................................... 69
18 Acknowledgements ............................................ 74 18 Acknowledgements ............................................ 75
19 Contributors ................................................ 75 19 Contributors ................................................ 75
20 Contact Address ............................................. 75 20 Contact Address ............................................. 75
21 Full Copyright Statement .................................... 77 21 Full Copyright Statement .................................... 77
[Editor's note: "Changes from previous version" notes can be removed [Editor's note: "Changes from previous version" notes can be removed
prior to publication as an RFC.] prior to publication as an RFC.]
Changes from previous version: Changes from previous version:
o Editorial changes resulting from AD review. o Editorial changes resulting from IESG review.
o The following changes were made to the Security Considerations
section:
- Removed stale text about channel identifier.
- Made changes to ensure manual keying is a SHOULD and dynamic
keying is a MUST. For dynamic key exchange protocols IKE MUST
be the key exchange protocol.
- Text was added to indicate a more specific selector can be used
by specifying the ports explicitly.
- Added text about the caveats of using manual keying.
- Made ESP Tunnel mode a MUST.
1. Introduction 1. Introduction
Networks are being developed with routers, switches, crossconnects, Networks are being developed with routers, switches, crossconnects,
dense wavelength division multiplexed (DWDM) systems, and add-drop dense wavelength division multiplexed (DWDM) systems, and add-drop
multiplexors (ADMs) that use a common control plane [e.g., multiplexors (ADMs) that use a common control plane [e.g.,
Generalized MPLS (GMPLS)] to dynamically allocate resources and to Generalized MPLS (GMPLS)] to dynamically allocate resources and to
provide network survivability using protection and restoration provide network survivability using protection and restoration
techniques. A pair of nodes may have thousands of interconnects, techniques. A pair of nodes may have thousands of interconnects,
where each interconnect may consist of multiple data links when where each interconnect may consist of multiple data links when
multiplexing (e.g., Frame Relay DLCIs at Layer 2, or time division multiplexing (e.g., Frame Relay DLCIs at Layer 2, time division
multiplexed (TDM) slots or wavelength division multiplexed (WDM) multiplexed (TDM) slots or wavelength division multiplexed (WDM)
wavelengths at Layer 1) is used. For scalability purposes, multiple wavelengths at Layer 1) is used. For scalability purposes, multiple
data links may be combined into a single traffic-engineering (TE) data links may be combined into a single traffic-engineering (TE)
link. link.
To enable communication between nodes for routing, signaling, and To enable communication between nodes for routing, signaling, and
link management, there must be a pair of IP interfaces that are link management, there must be a pair of IP interfaces that are
mutually reachable. We call such a pair of interfaces a control mutually reachable. We call such a pair of interfaces a control
channel. Note that "mutually reachable" does not imply that these channel. Note that "mutually reachable" does not imply that these
two interfaces are (directly) connected by an IP link; there may be two interfaces are (directly) connected by an IP link; there may be
skipping to change at page 27, line 53 skipping to change at page 27, line 53
use of the described exponential back-off procedures in the Config use of the described exponential back-off procedures in the Config
or LinkSummary messages. or LinkSummary messages.
11. LMP Finite State Machines 11. LMP Finite State Machines
11.1. Control Channel FSM 11.1. Control Channel FSM
The control channel FSM defines the states and logics of operation The control channel FSM defines the states and logics of operation
of an LMP control channel. of an LMP control channel.
11.1.1. Control Channel States 11.1.1.
Control Channel States
A control channel can be in one of the states described below. A control channel can be in one of the states described below.
Every state corresponds to a certain condition of the control Every state corresponds to a certain condition of the control
channel and is usually associated with a specific type of LMP channel and is usually associated with a specific type of LMP
message that is periodically transmitted to the far end. message that is periodically transmitted to the far end.
Down: This is the initial control channel state. In this Down: This is the initial control channel state. In this
state, no attempt is being made to bring the control state, no attempt is being made to bring the control
channel up and no LMP messages are sent. The control channel up and no LMP messages are sent. The control
channel parameters should be set to the initial values. channel parameters should be set to the initial values.
skipping to change at page 28, line 38 skipping to change at page 28, line 38
message. Once a valid Hello message is received, it can message. Once a valid Hello message is received, it can
transition to the up state. transition to the up state.
Up: The CC is in an operational state. The node receives Up: The CC is in an operational state. The node receives
valid Hello messages and sends Hello messages. valid Hello messages and sends Hello messages.
GoingDown: A CC may go into this state because of administrative GoingDown: A CC may go into this state because of administrative
action. While a CC is in this state, the node sets the action. While a CC is in this state, the node sets the
ControlChannelDown bit in all the messages it sends. ControlChannelDown bit in all the messages it sends.
11.1.2. Control Channel Events 11.1.2.
Control Channel Events
Operation of the LMP control channel is described in terms of FSM Operation of the LMP control channel is described in terms of FSM
states and events. Control channel events are generated by the states and events. Control channel events are generated by the
underlying protocols and software modules, as well as by the packet underlying protocols and software modules, as well as by the packet
processing routines and FSMs of associated TE links. Every event has processing routines and FSMs of associated TE links. Every event has
its number and a symbolic name. Description of possible control its number and a symbolic name. Description of possible control
channel events is given below. channel events is given below.
1 : evBringUp: This is an externally triggered event indicating 1 : evBringUp: This is an externally triggered event indicating
that the control channel negotiation should begin. that the control channel negotiation should begin.
skipping to change at page 30, line 17 skipping to change at page 30, line 17
15: evConfRet: A retransmission timer has expired and a Config 15: evConfRet: A retransmission timer has expired and a Config
message is resent. message is resent.
16: evHelloRet: The HelloInterval timer has expired and a Hello 16: evHelloRet: The HelloInterval timer has expired and a Hello
packet is sent. packet is sent.
17: evDownTimer: A timer has expired and no messages have been 17: evDownTimer: A timer has expired and no messages have been
received with the ControlChannelDown flag set. received with the ControlChannelDown flag set.
11.1.3. Control Channel FSM Description 11.1.3.
Control Channel FSM Description
Figure 3 illustrates operation of the control channel FSM in a form Figure 3 illustrates operation of the control channel FSM in a form
of FSM state transition diagram. of FSM state transition diagram.
+--------+ +--------+
+----------------->| |<--------------+ +----------------->| |<--------------+
| +--------->| Down |<----------+ | | +--------->| Down |<----------+ |
| |+---------| |<-------+ | | | |+---------| |<-------+ | |
| || +--------+ | | | | || +--------+ | | |
| || | ^ 2,9| 2| 2| | || | ^ 2,9| 2| 2|
skipping to change at page 31, line 24 skipping to change at page 31, line 24
Event evCCDn always forces the FSM to the down state. Events Event evCCDn always forces the FSM to the down state. Events
evHoldTimer evReconfig always force the FSM to the Negotiation state evHoldTimer evReconfig always force the FSM to the Negotiation state
(either ConfSnd or ConfRcv). (either ConfSnd or ConfRcv).
11.2. TE Link FSM 11.2. TE Link FSM
The TE Link FSM defines the states and logics of operation of the The TE Link FSM defines the states and logics of operation of the
LMP TE Link. LMP TE Link.
11.2.1. TE Link States 11.2.1.
TE Link States
An LMP TE link can be in one of the states described below. Every An LMP TE link can be in one of the states described below. Every
state corresponds to a certain condition of the TE link and is state corresponds to a certain condition of the TE link and is
usually associated with a specific type of LMP message that is usually associated with a specific type of LMP message that is
periodically transmitted to the far end via the associated control periodically transmitted to the far end via the associated control
channel or in-band via the data links. channel or in-band via the data links.
Down: There are no data links allocated to the TE link. Down: There are no data links allocated to the TE link.
Init: Data links have been allocated to the TE link, but the Init: Data links have been allocated to the TE link, but the
configuration has not yet been synchronized with the LMP configuration has not yet been synchronized with the LMP
neighbor. neighbor. The LinkSummary message is periodically
transmitted to the LMP neighbor.
Up: This is the normal operational state of the TE link. At Up: This is the normal operational state of the TE link. At
least one LMP control channel is required to be least one LMP control channel is required to be
operational between the nodes sharing the TE link. operational between the nodes sharing the TE link. As
part of normal operation, the LinkSummary message may be
periodically transmitted to the LMP neighbor or
generated by an external request.
Degraded: In this state, all LMP control channels are down, but Degraded: In this state, all LMP control channels are down, but
the TE link still includes some data links that are the TE link still includes some data links that are
allocated to user traffic. allocated to user traffic.
11.2.2. TE Link Events 11.2.2.
TE Link Events
Operation of the LMP TE link is described in terms of FSM states and Operation of the LMP TE link is described in terms of FSM states and
events. TE Link events are generated by the packet processing events. TE Link events are generated by the packet processing
routines and by the FSMs of the associated control channel(s) and routines and by the FSMs of the associated control channel(s) and
the data links. Every event has its number and a symbolic name. the data links. Every event has its number and a symbolic name.
Description of possible events is given below. Description of possible events is given below.
1 : evDCUp: One or more data channels have been enabled and 1 : evDCUp: One or more data channels have been enabled and
assigned to the TE Link. assigned to the TE Link.
skipping to change at page 32, line 28 skipping to change at page 32, line 31
6 : evSumRet: Retransmission timer has expired and LinkSummary 6 : evSumRet: Retransmission timer has expired and LinkSummary
message is resent. message is resent.
7 : evCCUp: First active control channel goes up. 7 : evCCUp: First active control channel goes up.
8 : evCCDown: Last active control channel goes down. 8 : evCCDown: Last active control channel goes down.
9 : evDCDown: Last data channel of TE Link has been removed. 9 : evDCDown: Last data channel of TE Link has been removed.
11.2.3. TE Link FSM Description 11.2.3.
TE Link FSM Description
Figure 4 illustrates operation of the LMP TE Link FSM in a form of Figure 4 illustrates operation of the LMP TE Link FSM in a form of
FSM state transition diagram. FSM state transition diagram.
3,7,8 3,7,8
+--+ +--+
| | | |
| v | v
+--------+ +--------+
| | | |
skipping to change at page 33, line 26 skipping to change at page 33, line 30
The data link FSM defines the states and logics of operation of a The data link FSM defines the states and logics of operation of a
data link within an LMP TE link. Operation of a data link is data link within an LMP TE link. Operation of a data link is
described in terms of FSM states and events. Data links can either described in terms of FSM states and events. Data links can either
be in the active (transmitting) mode, where Test messages are be in the active (transmitting) mode, where Test messages are
transmitted from them, or the passive (receiving) mode, where Test transmitted from them, or the passive (receiving) mode, where Test
messages are received through them. For clarity, separate FSMs are messages are received through them. For clarity, separate FSMs are
defined for the active/passive data links; however, a single set of defined for the active/passive data links; however, a single set of
data link states and events are defined. data link states and events are defined.
11.3.1. Data Link States 11.3.1.
Data Link States
Any data link can be in one of the states described below. Every Any data link can be in one of the states described below. Every
state corresponds to a certain condition of the data link. state corresponds to a certain condition of the data link.
Down: The data link has not been put in the resource pool Down: The data link has not been put in the resource pool
(i.e., the link is not 'in service') (i.e., the link is not 'in service')
Test: The data link is being tested. An LMP Test message is Test: The data link is being tested. An LMP Test message is
periodically sent through the link. periodically sent through the link.
PasvTest: The data link is being checked for incoming test PasvTest: The data link is being checked for incoming test
messages. messages.
Up/Free: The link has been successfully tested and is now put Up/Free: The link has been successfully tested and is now put
in the pool of resources (in-service). The link has in the pool of resources (in-service). The link has
not yet been allocated to data traffic. not yet been allocated to data traffic.
Up/Alloc: The link is up and has been allocated for data Up/Alloc: The link is up and has been allocated for data
traffic. traffic.
11.3.2. Data Link Events 11.3.2.
Data Link Events
Data link events are generated by the packet processing routines and Data link events are generated by the packet processing routines and
by the FSMs of the associated control channel and the TE link. by the FSMs of the associated control channel and the TE link.
Every event has its number and a symbolic name. Description of Every event has its number and a symbolic name. Description of
possible data link events is given below: possible data link events is given below:
1 :evCCUp: First active control channel goes up. 1 :evCCUp: First active control channel goes up.
2 :evCCDown: LMP neighbor connectivity is lost. This indicates 2 :evCCDown: LMP neighbor connectivity is lost. This indicates
the last LMP control channel has failed between the last LMP control channel has failed between
neighboring nodes. neighboring nodes.
3 :evStartTst: This is an external event that triggers the sending 3 :evStartTst: This is an external event that triggers the sending
skipping to change at page 35, line 5 skipping to change at page 35, line 11
11:evTestRet: A retransmission timer has expired and the Test 11:evTestRet: A retransmission timer has expired and the Test
message is resent. message is resent.
12:evSummaryFail: The LinkSummary did not match for this data port. 12:evSummaryFail: The LinkSummary did not match for this data port.
13:evLocalizeFail: A Failure has been localized to this data link. 13:evLocalizeFail: A Failure has been localized to this data link.
14:evdcDown: The data channel is no longer available. 14:evdcDown: The data channel is no longer available.
11.3.3. Active Data Link FSM Description 11.3.3.
Active Data Link FSM Description
Figure 5 illustrates operation of the LMP active data link FSM in a Figure 5 illustrates operation of the LMP active data link FSM in a
form of FSM state transition diagram form of FSM state transition diagram.
+------+ +------+
| |<-------+ | |<-------+
+--------->| Down | | +--------->| Down | |
| +----| |<-----+ | | +----| |<-----+ |
| | +------+ | | | | +------+ | |
| |5b 3| ^ | | | |5b 3| ^ | |
| | | |7 | | | | | |7 | |
| | v | | | | | v | | |
| | +------+ | | | | +------+ | |
skipping to change at page 35, line 42 skipping to change at page 35, line 49
| | | | | |
v |10 | v |10 |
+---------+ | +---------+ |
| |13 | | |13 |
|Up/Alloc |------+ |Up/Alloc |------+
| | | |
+---------+ +---------+
Figure 5: Active LMP Data Link FSM Figure 5: Active LMP Data Link FSM
11.3.4. Passive Data Link FSM Description 11.3.4.
Passive Data Link FSM Description
Figure 6 illustrates operation of the LMP passive data link FSM in a Figure 6 illustrates operation of the LMP passive data link FSM in a
form of FSM state transition diagram. form of FSM state transition diagram.
+------+ +------+
| |<------+ | |<------+
+---------->| Down | | +---------->| Down | |
| +-----| |<----+ | | +-----| |<----+ |
| | +------+ | | | | +------+ | |
| |5b 4| ^ | | | |5b 4| ^ | |
skipping to change at page 39, line 14 skipping to change at page 39, line 24
The Class indicates the object type. Each object has a name, The Class indicates the object type. Each object has a name,
which is always capitalized in this document. which is always capitalized in this document.
Length: 16 bits Length: 16 bits
The Length field indicates the length of the object in bytes, The Length field indicates the length of the object in bytes,
including the N, C-Type, Class, and Length fields. including the N, C-Type, Class, and Length fields.
12.3. Parameter Negotiation Messages 12.3. Parameter Negotiation Messages
12.3.1. Config Message (Msg Type = 1) 12.3.1.
Config Message (Msg Type = 1)
The Config message is used in the control channel negotiation phase The Config message is used in the control channel negotiation phase
of LMP. The contents of the Config message are built using LMP of LMP. The contents of the Config message are built using LMP
objects. The format of the Config message is as follows: objects. The format of the Config message is as follows:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG> <LOCAL_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The MESSAGE_ID object is within the scope of the LOCAL_CCID object. The MESSAGE_ID object is within the scope of the LOCAL_CCID object.
The Config message MUST be periodically transmitted until (1) it The Config message MUST be periodically transmitted until (1) it
receives a ConfigAck or ConfigNack message, (2) a retry limit has receives a ConfigAck or ConfigNack message, (2) a retry limit has
been reached and no ConfigAck or ConfigNack message has been been reached and no ConfigAck or ConfigNack message has been
received, or (3) it receives a Config message from the remote node received, or (3) it receives a Config message from the remote node
and has lost the contention (e.g., the Node_Id of the remote node is and has lost the contention (e.g., the Node_Id of the remote node is
higher than the Node_Id of the local node). Both the retransmission higher than the Node_Id of the local node). Both the retransmission
interval and the retry limit are local configuration parameters. interval and the retry limit are local configuration parameters.
12.3.2. ConfigAck Message (Msg Type = 2) 12.3.2.
ConfigAck Message (Msg Type = 2)
The ConfigAck message is used to acknowledge receipt of the Config The ConfigAck message is used to acknowledge receipt of the Config
message and indicate agreement on all parameters. message and indicate agreement on all parameters.
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> <ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID> <REMOTE_NODE_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being acknowledged. objects MUST be obtained from the Config message being acknowledged.
12.3.3. ConfigNack Message (Msg Type = 3) 12.3.3.
ConfigNack Message (Msg Type = 3)
The ConfigNack message is used to acknowledge receipt of the Config The ConfigNack message is used to acknowledge receipt of the Config
message and indicate disagreement on non-negotiable parameters or message and indicate disagreement on non-negotiable parameters or
propose other values for negotiable parameters. Parameters where propose other values for negotiable parameters. Parameters where
agreement was reached MUST NOT be included in the ConfigNack agreement was reached MUST NOT be included in the ConfigNack
Message. The format of the ConfigNack message is as follows: Message. The format of the ConfigNack message is as follows:
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID> <ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID> <LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG> <MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>
skipping to change at page 40, line 49 skipping to change at page 41, line 7
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO> <Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The Hello message MUST be periodically transmitted at least once The Hello message MUST be periodically transmitted at least once
every HelloInterval msec. If no Hello message is received within the every HelloInterval msec. If no Hello message is received within the
HelloDeadInterval, the control channel is assumed to have failed. HelloDeadInterval, the control channel is assumed to have failed.
12.5. Link Verification Messages 12.5. Link Verification Messages
12.5.1. BeginVerify Message (Msg Type = 5) 12.5.1.
BeginVerify Message (Msg Type = 5)
The BeginVerify message is sent over the control channel and is used The BeginVerify message is sent over the control channel and is used
to initiate the link verification process. The format is as follows: to initiate the link verification process. The format is as follows:
<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID> <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> [<REMOTE_LINK_ID>] <MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY> <BEGIN_VERIFY>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
skipping to change at page 41, line 33 skipping to change at page 41, line 41
The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if
included. included.
The BeginVerify message MUST be periodically transmitted until (1) The BeginVerify message MUST be periodically transmitted until (1)
the node receives either a BeginVerifyAck or BeginVerifyNack message the node receives either a BeginVerifyAck or BeginVerifyNack message
to accept or reject the verify process or (2) a retry limit has been to accept or reject the verify process or (2) a retry limit has been
reached and no BeginVerifyAck or BeginVerifyNack message has been reached and no BeginVerifyAck or BeginVerifyNack message has been
received. Both the retransmission interval and the retry limit are received. Both the retransmission interval and the retry limit are
local configuration parameters. local configuration parameters.
12.5.2. BeginVerifyAck Message (Msg Type = 6) 12.5.2.
BeginVerifyAck Message (Msg Type = 6)
When a BeginVerify message is received and Test messages are ready When a BeginVerify message is received and Test messages are ready
to be processed, a BeginVerifyAck message MUST be transmitted. to be processed, a BeginVerifyAck message MUST be transmitted.
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>] <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK> <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
skipping to change at page 42, line 5 skipping to change at page 42, line 14
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being acknowledged. BeginVerify message being acknowledged.
The VERIFY_ID object contains a node-unique value that is assigned The VERIFY_ID object contains a node-unique value that is assigned
by the generator of the BeginVerifyAck message. This value is used by the generator of the BeginVerifyAck message. This value is used
to uniquely identify the Verification process from multiple LMP to uniquely identify the Verification process from multiple LMP
neighbors and/or parallel Test procedures between the same LMP neighbors and/or parallel Test procedures between the same LMP
neighbors. neighbors.
12.5.3. BeginVerifyNack Message (Msg Type = 7) 12.5.3.
BeginVerifyNack Message (Msg Type = 7)
If a BeginVerify message is received and a node is unwilling or If a BeginVerify message is received and a node is unwilling or
unable to begin the Verification procedure, a BeginVerifyNack unable to begin the Verification procedure, a BeginVerifyNack
message MUST be transmitted. message MUST be transmitted.
<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>] <BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <ERROR_CODE> <MESSAGE_ID_ACK> <ERROR_CODE>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
skipping to change at page 42, line 42 skipping to change at page 42, line 52
If remote configuration of the Link_Id is not supported and the If remote configuration of the Link_Id is not supported and the
content of the REMOTE_LINK_ID object (included in the BeginVerify content of the REMOTE_LINK_ID object (included in the BeginVerify
message) does not match any configured values, the ERROR_CODE MUST message) does not match any configured values, the ERROR_CODE MUST
indicate "Link_Id configuration error". indicate "Link_Id configuration error".
If a node receives a BeginVerify message and recognizes the If a node receives a BeginVerify message and recognizes the
BEGIN_VERIFY object but does not recognize the C-Type, the BEGIN_VERIFY object but does not recognize the C-Type, the
ERROR_CODE MUST indicate, "Unknown object C-Type". ERROR_CODE MUST indicate, "Unknown object C-Type".
12.5.4. EndVerify Message (Msg Type = 8) 12.5.4.
EndVerify Message (Msg Type = 8)
The EndVerify message is sent over the control channel and is used The EndVerify message is sent over the control channel and is used
to terminate the link verification process. The EndVerify message to terminate the link verification process. The EndVerify message
may be sent at any time the initiating node desires to end the may be sent at any time the initiating node desires to end the
Verify procedure. The format is as follows: Verify procedure. The format is as follows:
<EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID> <EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The EndVerify message will be periodically transmitted until (1) an The EndVerify message will be periodically transmitted until (1) an
EndVerifyAck message has been received or (2) a retry limit has been EndVerifyAck message has been received or (2) a retry limit has been
reached and no EndVerifyAck message has been received. Both the reached and no EndVerifyAck message has been received. Both the
retransmission interval and the retry limit are local configuration retransmission interval and the retry limit are local configuration
parameters. parameters.
12.5.5. EndVerifyAck Message (Msg Type =9) 12.5.5.
EndVerifyAck Message (Msg Type =9)
The EndVerifyAck message is sent over the control channel and is The EndVerifyAck message is sent over the control channel and is
used to acknowledge the termination of the link verification used to acknowledge the termination of the link verification
process. The format is as follows: process. The format is as follows:
<EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
EndVerify message being acknowledged. EndVerify message being acknowledged.
12.5.6. Test Message (Msg Type = 10) 12.5.6.
Test Message (Msg Type = 10)
The Test message is transmitted over the data link and is used to The Test message is transmitted over the data link and is used to
verify its physical connectivity. Unless explicitly stated, these verify its physical connectivity. Unless explicitly stated, these
messages MUST be transmitted over UDP like all other LMP messages. messages MUST be transmitted over UDP like all other LMP messages.
The format of the Test messages is as follows: The format of the Test messages is as follows:
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID> <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
skipping to change at page 43, line 48 skipping to change at page 44, line 7
The local (transmitting) node sends a given Test message The local (transmitting) node sends a given Test message
periodically (at least once every VerifyInterval ms) on the periodically (at least once every VerifyInterval ms) on the
corresponding data link until (1) it receives a correlating corresponding data link until (1) it receives a correlating
TestStatusSuccess or TestStatusFailure message on the control TestStatusSuccess or TestStatusFailure message on the control
channel from the remote (receiving) node or (2) all active control channel from the remote (receiving) node or (2) all active control
channels between the two nodes have failed. The remote node will channels between the two nodes have failed. The remote node will
send a given TestStatus message periodically over the control send a given TestStatus message periodically over the control
channel until it receives either a correlating TestStatusAck message channel until it receives either a correlating TestStatusAck message
or an EndVerify message is received over the control channel. or an EndVerify message is received over the control channel.
12.5.7. TestStatusSuccess Message (Msg Type = 11) 12.5.7.
TestStatusSuccess Message (Msg Type = 11)
The TestStatusSuccess message is transmitted over the control The TestStatusSuccess message is transmitted over the control
channel and is used to transmit the mapping between the local channel and is used to transmit the mapping between the local
Interface_Id and the Interface_Id that was received in the Test Interface_Id and the Interface_Id that was received in the Test
message. message.
<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID> <TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID> <MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID> <REMOTE_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the REMOTE_INTERFACE_ID object MUST be obtained from The contents of the REMOTE_INTERFACE_ID object MUST be obtained from
the corresponding Test message being positively acknowledged. the corresponding Test message being positively acknowledged.
12.5.8. TestStatusFailure Message (Msg Type = 12) 12.5.8.
TestStatusFailure Message (Msg Type = 12)
The TestStatusFailure message is transmitted over the control The TestStatusFailure message is transmitted over the control
channel and is used to indicate that the Test message was not channel and is used to indicate that the Test message was not
received. received.
<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID> <TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
12.5.9. TestStatusAck Message (Msg Type = 13) 12.5.9.
TestStatusAck Message (Msg Type = 13)
The TestStatusAck message is used to acknowledge receipt of the The TestStatusAck message is used to acknowledge receipt of the
TestStatusSuccess or TestStatusFailure messages. TestStatusSuccess or TestStatusFailure messages.
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
TestStatusSuccess or TestStatusFailure message being acknowledged. TestStatusSuccess or TestStatusFailure message being acknowledged.
12.6. Link Summary Messages 12.6. Link Summary Messages
12.6.1. LinkSummary Message (Msg Type = 14) 12.6.1.
LinkSummary Message (Msg Type = 14)
The LinkSummary message is used to synchronize the Interface_Ids and The LinkSummary message is used to synchronize the Interface_Ids and
correlate the properties of the TE link. The format of the correlate the properties of the TE link. The format of the
LinkSummary message is as follows: LinkSummary message is as follows:
<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK> <LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...] <DATA_LINK> [<DATA_LINK>...]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The LinkSummary message can be exchanged at any time a link is not The LinkSummary message can be exchanged at any time a link is not
in the Verification process. The LinkSummary message MUST be in the Verification process. The LinkSummary message MUST be
periodically transmitted until (1) the node receives a periodically transmitted until (1) the node receives a
LinkSummaryAck or LinkSummaryNack message or (2) a retry limit has LinkSummaryAck or LinkSummaryNack message or (2) a retry limit has
been reached and no LinkSummaryAck or LinkSummaryNack message has been reached and no LinkSummaryAck or LinkSummaryNack message has
been received. Both the retransmission interval and the retry limit been received. Both the retransmission interval and the retry limit
are local configuration parameters. are local configuration parameters.
12.6.2. LinkSummaryAck Message (Msg Type = 15) 12.6.2.
LinkSummaryAck Message (Msg Type = 15)
The LinkSummaryAck message is used to indicate agreement on the The LinkSummaryAck message is used to indicate agreement on the
Interface_Id synchronization and acceptance/agreement on all the Interface_Id synchronization and acceptance/agreement on all the
link parameters. It is on the reception of this message that the link parameters. It is on the reception of this message that the
local node makes the Link_Id associations. local node makes the Link_Id associations.
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
12.6.3. LinkSummaryNack Message (Msg Type = 16) 12.6.3.
LinkSummaryNack Message (Msg Type = 16)
The LinkSummaryNack message is used to indicate disagreement on non- The LinkSummaryNack message is used to indicate disagreement on non-
negotiated parameters or propose other values for negotiable negotiated parameters or propose other values for negotiable
parameters. Parameters where agreement was reached MUST NOT be parameters. Parameters where agreement was reached MUST NOT be
included in the LinkSummaryNack message. included in the LinkSummaryNack message.
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK> <LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...] <ERROR_CODE> [<DATA_LINK>...]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
skipping to change at page 46, line 14 skipping to change at page 46, line 24
If the LinkSummary message is received with a TE_LINK object but the If the LinkSummary message is received with a TE_LINK object but the
C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown TE_LINK C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown TE_LINK
object C-Type." object C-Type."
If the LinkSummary message is received with a DATA_LINK object but If the LinkSummary message is received with a DATA_LINK object but
the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown
DATA_LINK object C-Type." DATA_LINK object C-Type."
12.7. Fault Management Messages 12.7. Fault Management Messages
12.7.1. ChannelStatus Message (Msg Type = 17) 12.7.1.
ChannelStatus Message (Msg Type = 17)
The ChannelStatus message is sent over the control channel and is The ChannelStatus message is sent over the control channel and is
used to notify an LMP neighbor of the status of a data link. A node used to notify an LMP neighbor of the status of a data link. A node
that receives a ChannelStatus message MUST respond with a that receives a ChannelStatus message MUST respond with a
ChannelStatusAck message. The format is as follows: ChannelStatusAck message. The format is as follows:
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID> <ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS> <MESSAGE_ID> <CHANNEL_STATUS>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
If the CHANNEL_STATUS object does not include any Interface_Ids, If the CHANNEL_STATUS object does not include any Interface_Ids,
then this indicates the entire TE Link has failed. then this indicates the entire TE Link has failed.
12.7.2. ChannelStatusAck Message (Msg Type = 18) 12.7.2.
ChannelStatusAck Message (Msg Type = 18)
The ChannelStatusAck message is used to acknowledge receipt of the The ChannelStatusAck message is used to acknowledge receipt of the
ChannelStatus Message. The format is as follows: ChannelStatus Message. The format is as follows:
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
ChannelStatus message being acknowledged. ChannelStatus message being acknowledged.
12.7.3. ChannelStatusRequest Message (Msg Type = 19) 12.7.3.
ChannelStatusRequest Message (Msg Type = 19)
The ChannelStatusRequest message is sent over the control channel The ChannelStatusRequest message is sent over the control channel
and is used to request the status of one or more data link(s). A and is used to request the status of one or more data link(s). A
node that receives a ChannelStatusRequest message MUST respond with node that receives a ChannelStatusRequest message MUST respond with
a ChannelStatusResponse message. The format is as follows: a ChannelStatusResponse message. The format is as follows:
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID> <ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>] [<CHANNEL_STATUS_REQUEST>]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
If the CHANNEL_STATUS_REQUEST object is not included, then the If the CHANNEL_STATUS_REQUEST object is not included, then the
ChannelStatusRequest is being used to request the status of ALL of ChannelStatusRequest is being used to request the status of ALL of
the data link(s) of the TE Link. the data link(s) of the TE Link.
12.7.4. ChannelStatusResponse Message (Msg Type = 20) 12.7.4.
ChannelStatusResponse Message (Msg Type = 20)
The ChannelStatusResponse message is used to acknowledge receipt of The ChannelStatusResponse message is used to acknowledge receipt of
the ChannelStatusRequest Message and notify the LMP neighbor of the the ChannelStatusRequest Message and notify the LMP neighbor of the
status of the data channel(s). The format is as follows: status of the data channel(s). The format is as follows:
<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK> <ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
<CHANNEL_STATUS> <CHANNEL_STATUS>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
skipping to change at page 66, line 45 skipping to change at page 66, line 14
[RFC3209] Awduche, D. O., Berger, L, et al, "Extensions to RSVP [RFC3209] Awduche, D. O., Berger, L, et al, "Extensions to RSVP
for LSP Tunnels," Internet Draft, RFC 3209, December for LSP Tunnels," Internet Draft, RFC 3209, December
2001. 2001.
16. Security Considerations 16. Security Considerations
There are number of attacks that an LMP protocol session can There are number of attacks that an LMP protocol session can
potentially experience. Some examples include: potentially experience. Some examples include:
o an adversary may spoof control packets o an adversary may spoof control packets;
o an adversary may modify the control packets in transit o an adversary may modify the control packets in transit;
o an adversary may replay control packets o an adversary may replay control packets;
o an adversary may study a number of control packets and try to o an adversary may study a number of control packets and try to
break the key using cryptographic tools. If the break the key using cryptographic tools. If the
hash/encryption algorithm used has known weaknesses than it hash/encryption algorithm used has known weaknesses than it
becomes easy for the adversary to discover the key using becomes easy for the adversary to discover the key using
simple tools. simple tools.
This section specifies an IPsec-based security mechanism for LMP. This section specifies an IPsec-based security mechanism for LMP.
16.1. Security Requirements 16.1. Security Requirements
The following requirements are applied to the mechanism described in The following requirements are applied to the mechanism described in
this section. this section.
o LMP security MUST be able to provide authentication, o LMP security MUST be able to provide authentication,
integrity and replay protection. integrity, and replay protection.
o For LMP traffic, confidentiality is not needed. Only o For LMP traffic, confidentiality is not needed. Only
authentication is needed to ensure the control packets authentication is needed to ensure the control packets
(packets sent along the LMP Control Channel) are originating (packets sent along the LMP Control Channel) are originating
from the right place and have not been modified in transit. from the right place and have not been modified in transit.
LMP Test packets exchanged through the data links do not need LMP Test packets exchanged through the data links do not need
to be protected. to be protected.
o For LMP traffic, protecting the identity of LMP end-points is
not commonly required.
o Security mechanism should provide for well defined key o Security mechanism should provide for well defined key
management schemes. The key management schemes should be well management schemes. The key management schemes should be well
analyzed to be cryptographically secure. The key management analyzed to be cryptographically secure. The key management
schemes should be scalable. In addition, the key management schemes should be scalable. In addition, the key management
system should be automatic. system should be automatic.
o The algorithms used for authentication MUST be o The algorithms used for authentication MUST be
cryptographically sound. Also the security protocol MUST cryptographically sound. Also the security protocol MUST
allow for negotiating and using different authentication allow for negotiating and using different authentication
algorithms. algorithms.
skipping to change at page 67, line 46 skipping to change at page 67, line 18
the network layer between two peers. This protocol is comprised of the network layer between two peers. This protocol is comprised of
IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH
[RFC2402], and IPsec ESP [RFC2406]. IKE is the key management [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management
protocol for IP networks while AH and ESP are used to protect IP protocol for IP networks while AH and ESP are used to protect IP
traffic. IKE is defined specific to IP domain of interpretation. traffic. IKE is defined specific to IP domain of interpretation.
Considering the requirements described in Section 16.1, it is Considering the requirements described in Section 16.1, it is
recommended that where security is needed for LMP, implementations recommended that where security is needed for LMP, implementations
use IPsec as described below: use IPsec as described below:
1. IPsec ESP with integrity-only security association, tunnel mode 1. Implementations of LMP over IPsec protocol SHOULD support manual
SHOULD be used for packet authentication. keying mode.
2. IKE [RFC2409] SHOULD be used as the key exchange mechanism. Manual keying mode provides an easy way to set up and diagnose
IPsec functionality.
Implementations of LMP over IPsec protocol MUST support manual However, note that manual keying mode can not effectively support
keying mode and dynamic key exchange protocol using IKE. IKE features such as replay protection and automatic re-keying. An
implementation SHOULD use the IPsec DOI [RFC2407]. implementer using manual keys must be aware of these limits.
For IKE protocol, the identities of the SAs negotiated in Quick Mode It is recommended that an implementer use manual keying only for
represent the traffic that the peers agree to protect and are diagnostic purpose and use dynamic keying protocol to make use of
comprised of address space, protocol and port information. For LMP features such as replay protection and automatic re-keying.
over IPsec, it is recommended that the identity payload contain the
following information. The identities SHOULD be of type IP addresses
and the value of the identities SHOULD be the IP addresses of the
communicating peers. The protocol field SHOULD be IP protocol UDP
(17). The port field SHOULD be set to zero to indicate port fields
should be ignored. In LMP exchanges, the channel identifier user by
the peer is not known beforehand, and hence cannot be used in the
SA. This restriction implies that LMP authentication is performed on
a per LMP neighbor basis rather than on a per LMP control channel
basis between two neighbors.
All LMP messages are expected to be sent over the IPsec tunnel. 2. IPsec ESP with trailer authentication in tunnel mode MUST be
However, all LMP messages should be sent through the IPsec tunnel, supported.
which will have been established earlier or on an as-needed basis.
3. Implementations MUST support authenticated key exchange
protocols. IKE [RFC2409] MUST be used as the key exchange
protocol if keys are dynamically negotiated between peers.
4. Implementation MUST use the IPsec DOI [RFC2407].
5. For IKE protocol, the identities of the SAs negotiated in Quick
Mode represent the traffic that the peers agree to protect and
are comprised of address space, protocol, and port information.
For LMP over IPsec, it is recommended that the identity payload
for Quick mode contain the following information:
The identities MUST be of type IP addresses and the value of the
identities SHOULD be the IP addresses of the communicating peers.
The protocol field MUST be UDP. The port field SHOULD be set to
zero to indicate port fields should be ignored. This implies all
UDP traffic between the peers must be sent through the IPsec
tunnel. If an implementation supports port based selectors it can
opt for a finer grained selector by specifying the port field to
LMP port. If, however, the peer does not use port based
selectors, the implementation MUST fall back to using port
selector value of 0.
6. Aggressive mode of IKE negotiation MUST be supported.
When IPsec is configured to be used with a peer, all LMP messages
are expected to be sent over the IPsec tunnel (crypto channel).
Similarly a LMP receiver configured to use Ipsec with a peer, should
reject any LMP traffic not coming through the crypto channel.
The crypto channel can be pre-setup with the LMP neighbor or the
first LMP message message sent to the peer could trigger the
creation of the IPsec tunnel.
A set of control channels can share the same crypto channel. When A set of control channels can share the same crypto channel. When
LMP Hellos are used to monitor the status of the control channel, it LMP Hellos are used to monitor the status of the control channel, it
is important to keep in mind that the keep-alive failure in a is important to keep in mind that the keep-alive failure in a
control channel may also be due to failure in the crypto channel. control channel may also be due to a failure in the crypto channel.
The following method is recommended to ensure LMP communication path The following method is recommended to ensure an LMP communication
between two peers is working properly. path between two peers is working properly.
- If LMP Hellos detect a failure on a control channel, switch to o If LMP Hellos detect a failure on a control channel, switch to
an alternate (backup) control channel and/or try to bring up a an alternate control channel and/or try to establish a new
new control channel. control channel.
- Ensure the health of the control channels using LMP Hellos. If o Ensure the health of the control channels using LMP Hellos. If
all control channels indicate a failure and it is not possible to all control channels indicate a failure and it is not possible
bring up a new control channel, tear down all existing control to bring up a new control channel, tear down all existing
channels. Also tear down the crypto channel (both the IKE SA and control channels. Also tear down the crypto channel (both the
IPsec SAs). IKE SA and IPsec SAs).
- Reestablish the crypto channel. Failure to establish a crypto o Reestablish the crypto channel. Failure to establish a crypto
channel indicates a fatal failure for LMP communication. channel indicates a fatal failure for LMP communication.
- Bring up the control channel. Failure to bring up the control o Bring up the control channel. Failure to bring up the control
channel indicates a fatal failure for LMP communication. channel indicates a fatal failure for LMP communication.
o When LMP peers are dynamically discovered (particularly the When LMP peers are dynamically discovered (particularly the
initiator), the following points should be noted if pre- initiator), the following points should be noted:
shared key based authentication is used for setting up the
crypto channels. When using pre-shared key based When using pre-shared key authentication in identity protection
authentication, the pre-shared key is required to compute the mode (main mode), the pre-shared key is required to compute the
value of SKEYID (used for deriving keys to encrypt messages value of SKEYID (used for deriving keys to encrypt messages
during key exchange). In main mode, pre-shared key to be used during key exchange). In main mode of IKE, the pre-shared key to
has to be identified from information in the IP header since be used has to be identified before receiving the peerĂs identity
SKEYID is calculated prior to the receipt of identification payload. The pre-shared key is required for calculating SKEYID.
payloads. This is not possible if the IP addresses of the The only information available about the peer at this point is
peer are discovered dynamically. Aggressive mode of key its IP address from which the negotiation came from. Keying off
exchange can be used since identification payloads are sent the IP address of a peer to get the pre-shared key is not
in the first message. possible since the addresses are dynamic and not known
beforehand.
Note however that aggressive mode is prone to passive denial of Aggressive mode key exchange can be used since identification
service attacks. We also strongly discourage using a shared secret payloads are sent in the first message.
(group shared secret) among a number of peers as this opens up the
solution to man-in-the-middle attacks. Note, however, that aggressive mode is prone to passive denial of
service attacks. Using a shared secret (group shared secret)
among a number of peers is strongly discourages as this opens up
the solution to man-in-the-middle attacks.
Digital signature based authentication is not prone to such Digital signature based authentication is not prone to such
problems. It is RECOMMENDED using digital signature based problems. It is RECOMMENDED to use digital signature based
authentication mechanism where possible. If pre-shared key based authentication mechanism where possible.
authentication is required, then aggressive mode SHOULD be used.
IKE pre-shared authentication key values SHOULD be protected in a If pre-shared key based authentication is required, then
manner similar to the user's account password. aggressive mode SHOULD be used. IKE pre-shared authentication key
values SHOULD be protected in a manner similar to the user's
account password.
17. IANA Considerations 17. IANA Considerations
LMP requires that a UDP port number be assigned. LMP requires that a UDP port number be assigned.
In the following, guidelines are given for IANA assignment for each In the following, guidelines are given for IANA assignment for each
LMP name space. Ranges are specified ˘for Private Use÷, ˘to be LMP name space. Ranges are specified ˘for Private Use÷, ˘to be
assigned by Expert Review÷, and ˘to be assigned by Standards Action÷ assigned by Expert Review÷, and ˘to be assigned by Standards Action÷
(as defined in [RFC2434]. (as defined in [RFC2434].
skipping to change at page 75, line 16 skipping to change at page 75, line 20
Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Dimitri Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Dimitri
Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful
comments and suggestions. We would also like to thank John Yu, comments and suggestions. We would also like to thank John Yu,
Suresh Katukam, and Greg Bernstein for their helpful suggestions for Suresh Katukam, and Greg Bernstein for their helpful suggestions for
the in-band control channel applicability. the in-band control channel applicability.
19. Contributors 19. Contributors
Jonathan P. Lang Krishna Mitra Jonathan P. Lang Krishna Mitra
Rincon Networks Independent Consultant Rincon Networks Independent Consultant
110 El Paseo email: kmitra@earthlink.net 829 De La Vina, Suite 220 email: kmitra@earthlink.net
Santa Barbara, CA 93101 Santa Barbara, CA 93101
Email: jplang@ieee.org Email: jplang@ieee.org
John Drake Kireeti Kompella John Drake Kireeti Kompella
Calient Networks Juniper Networks, Inc. Calient Networks Juniper Networks, Inc.
5853 Rue Ferrari 1194 North Mathilda Avenue 5853 Rue Ferrari 1194 North Mathilda Avenue
San Jose, CA 95138 Sunnyvale, CA 94089 San Jose, CA 95138 Sunnyvale, CA 94089
email: jdrake@calient.net email: kireeti@juniper.net email: jdrake@calient.net email: kireeti@juniper.net
Yakov Rekhter Lou Berger Yakov Rekhter Lou Berger
skipping to change at page 75, line 51 skipping to change at page 76, line 4
Durham, NC 27705 Durham, NC 27705
email: sandick@nc.rr.com email: sandick@nc.rr.com
Bala Rajagopalan Sankar Ramamoorthi Bala Rajagopalan Sankar Ramamoorthi
Tellium Optical Systems Juniper Networks, Inc. Tellium Optical Systems Juniper Networks, Inc.
2 Crescent Place 1194 North Mathilda Avenue 2 Crescent Place 1194 North Mathilda Avenue
Oceanport, NJ 07757-0901 Sunnyvale, CA 94089 Oceanport, NJ 07757-0901 Sunnyvale, CA 94089
email: braja@tellium.com email: sankarr@juniper.net email: braja@tellium.com email: sankarr@juniper.net
20. Contact Address 20. Contact Address
Jonathan P. Lang Jonathan P. Lang
Rincon Networks Rincon Networks
110, El Paseo 829 De La Vina, Suite 220
Goleta, CA 93101 Goleta, CA 93101
Email: jplang@ieee.org Email: jplang@ieee.org
21. Full Copyright Statement 21. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/