wait-ctl-reply Receive SCCCN Send StopCCN, idle
clean up
wait-ctl-conn Receive SCCCN, Send control-conn established
acceptable open event to
waiting sessions
wait-ctl-conn Receive SCCCN, Send StopCCN, idle
not acceptable clean up
wait-ctl-conn Receive SCCRQ, Send StopCCN, idle
SCCRP clean up
established Local open Send control-conn established
request open event to
(new call) waiting sessions
established Administrative Send StopCCN, idle
control-conn clean up
close event
established Receive SCCRQ, Send StopCCN, idle
SCCRP, SCCCN clean up
idle, Receive StopCCN Clean up idle
wait-ctl-reply,
wait-ctl-conn,
established
The states associated with an LCCE for control connection
establishment are as follows:
idle
Both initiator and recipient start from this state. An initiator
transmits an SCCRQ, while a recipient remains in the idle state
until receiving an SCCRQ.
wait-ctl-reply
The originator checks to see if another connection has been
requested from the same peer, and if so, handles the collision
situation described in Section 5.4.3.
wait-ctl-conn
Awaiting an SCCCN. If the SCCCN is valid, the control connection
is established; otherwise, it is torn down (sending a StopCCN with
the proper result and/or error code).
established
An established connection may be terminated by either a local
condition or the receipt of a StopCCN. In the event of a local
termination, the originator MUST send a StopCCN and clean up the
control connection. If the originator receives a StopCCN, it MUST
also clean up the control connection.
7.3. Incoming Calls
An ICRQ is generated by an LCCE, typically in response to an incoming
call or a local event. Once the LCCE sends the ICRQ, it waits for a
response from the peer. However, it may choose to postpone
establishment of the call (e.g., answering the call, bringing up the
circuit) until the peer has indicated with an ICRP that it will
accept the call. The peer may choose not to accept the call if, for
instance, there are insufficient resources to handle an additional
session.
If the peer chooses to accept the call, it responds with an ICRP.
When the local LCCE receives the ICRP, it attempts to establish the
call. A final call connected message, the ICCN, is sent from the
local LCCE to the peer to indicate that the call states for both
LCCEs should enter the established state. If the call is terminated
before the peer can accept it, a CDN is sent by the local LCCE to
indicate this condition.
When a call transitions to a "disconnected" or "down" state, the call
is cleared normally, and the local LCCE sends a CDN. Similarly, if
the peer wishes to clear a call, it sends a CDN and cleans up its
session.
7.3.1. ICRQ Sender States
State Event Action New State
----- ----- ------ ---------
idle Call signal or Initiate local wait-control-conn
ready to receive control-conn
incoming conn open
idle Receive ICCN, Clean up idle
ICRP, CDN
wait-control- Bearer line drop Clean up idle
conn or local close
request
wait-control- control-conn-open Send ICRQ wait-reply
conn
wait-reply Receive ICRP, Send ICCN established
acceptable
wait-reply Receive ICRP, Send CDN, idle
Not acceptable clean up
wait-reply Receive ICRQ, Process as idle
lose tie breaker ICRQ Recipient
(Section 7.3.2)
wait-reply Receive ICRQ, Send CDN wait-reply
win tie breaker for losing
session
wait-reply Receive CDN, Clean up idle
ICCN
wait-reply Local close Send CDN, idle
request clean up
established Receive CDN Clean up idle
established Receive ICRQ, Send CDN, idle
ICRP, ICCN clean up
established Local close Send CDN, idle
request clean up
The states associated with the ICRQ sender are as follows:
idle
The LCCE detects an incoming call on one of its interfaces (e.g.,
an analog PSTN line rings, or an ATM PVC is provisioned), or a
local event occurs. The LCCE initiates its control connection
establishment state machine and moves to a state waiting for
confirmation of the existence of a control connection.
wait-control-conn
In this state, the session is waiting for either the control
connection to be opened or for verification that the control
connection is already open. Once an indication that the control
connection has been opened is received, session control messages
may be exchanged. The first of these messages is the ICRQ.
wait-reply
The ICRQ sender receives either (1) a CDN indicating the peer is
not willing to accept the call (general error or do not accept)
and moves back into the idle state, or (2) an ICRP indicating the
call is accepted. In the latter case, the LCCE sends an ICCN and
enters the established state.
established
Data is exchanged over the session. The call may be cleared by
any of the following:
+ An event on the connected interface: The LCCE sends a CDN.
+ Receipt of a CDN: The LCCE cleans up, disconnecting the call.
+ A local reason: The LCCE sends a CDN.
7.3.2. ICRQ Recipient States
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
idle Receive ICRQ, Send CDN, idle
not acceptable clean up
idle Receive ICRP Send CDN idle
clean up
idle Receive ICCN Clean up idle
wait-connect Receive ICCN, Prepare for established
acceptable data
wait-connect Receive ICCN, Send CDN, idle
not acceptable clean up
wait-connect Receive ICRQ, Send CDN, idle
ICRP clean up
idle, Receive CDN Clean up idle
wait-connect,
established
wait-connect Local close Send CDN, idle
established request clean up
established Receive ICRQ, Send CDN, idle
ICRP, ICCN clean up
The states associated with the ICRQ recipient are as follows:
idle
An ICRQ is received. If the request is not acceptable, a CDN is
sent back to the peer LCCE, and the local LCCE remains in the idle
state. If the ICRQ is acceptable, an ICRP is sent. The session
moves to the wait-connect state.
wait-connect
The local LCCE is waiting for an ICCN from the peer. Upon receipt
of the ICCN, the local LCCE moves to established state.
established
The session is terminated either by sending a CDN or by receiving
a CDN from the peer. Clean up follows on both sides regardless of
the initiator.
7.4. Outgoing Calls
Outgoing calls instruct an LAC to place a call. There are three
messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first
sends an OCRQ to an LAC to request an outgoing call. The LAC MUST
respond to the OCRQ with an OCRP once it determines that the proper
facilities exist to place the call and that the call is
administratively authorized. Once the outbound call is connected,
the LAC sends an OCCN to the peer indicating the final result of the
call attempt.
7.4.1. OCRQ Sender States
State Event Action New State
----- ----- ------ ---------
idle Local open Initiate local wait-control-conn
request control-conn-open
idle Receive OCCN, Clean up idle
OCRP
wait-control- control-conn-open Send OCRQ wait-reply
conn
wait-reply Receive OCRP, none wait-connect
acceptable
wait-reply Receive OCRP, Send CDN, idle
not acceptable clean up
wait-reply Receive OCCN Send CDN, idle
clean up
wait-reply Receive OCRQ, Process as idle
lose tie breaker OCRQ Recipient
(Section 7.4.2)
wait-reply Receive OCRQ, Send CDN wait-reply
win tie breaker for losing
session
wait-connect Receive OCCN none established
wait-connect Receive OCRQ, Send CDN, idle
OCRP clean up
idle, Receive CDN Clean up idle
wait-reply,
wait-connect,
established
established Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
wait-reply, Local close Send CDN, idle
wait-connect, request clean up
established
wait-control- Local close Clean up idle
conn request
The states associated with the OCRQ sender are as follows:
idle, wait-control-conn
When an outgoing call request is initiated, a control connection
is created as described above, if not already present. Once the
control connection is established, an OCRQ is sent to the LAC, and
the session moves into the wait-reply state.
wait-reply
If a CDN is received, the session is cleaned up and returns to
idle state. If an OCRP is received, the call is in progress, and
the session moves to the wait-connect state.
wait-connect
If a CDN is received, the session is cleaned up and returns to
idle state. If an OCCN is received, the call has succeeded, and
the session may now exchange data.
established
If a CDN is received, the session is cleaned up and returns to
idle state. Alternatively, if the LCCE chooses to terminate the
session, it sends a CDN to the LAC, cleans up the session, and
moves the session to idle state.
7.4.2. OCRQ Recipient (LAC) States
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Place call
idle Receive OCRQ, Send CDN, idle
not acceptable clean up
idle Receive OCRP Send CDN, idle
clean up
idle Receive OCCN, Clean up idle
CDN
wait-cs-answer Call placement Send OCCN established
successful
wait-cs-answer Call placement Send CDN, idle
failed clean up
wait-cs-answer Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
established Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
wait-cs-answer, Receive CDN Clean up idle
established
wait-cs-answer, Local close Send CDN, idle
established request clean up
The states associated with the LAC for outgoing calls are as follows:
idle
If the OCRQ is received in error, respond with a CDN. Otherwise,
place the call, send an OCRP, and move to the wait-cs-answer
state.
wait-cs-answer
If the call is not completed or a timer expires while waiting for
the call to complete, send a CDN with the appropriate error
condition set, and go to idle state. If a circuit-switched
connection is established, send an OCCN indicating success, and go
to established state.
established
If the LAC receives a CDN from the peer, the call MUST be released
via appropriate mechanisms, and the session cleaned up. If the
call is disconnected because the circuit transitions to a
"disconnected" or "down" state, the LAC MUST send a CDN to the
peer and return to idle state.
7.5. Termination of a Control Connection
The termination of a control connection consists of either peer
issuing a StopCCN. The sender of this message SHOULD wait a full
control message retransmission cycle (e.g., 1 + 2 + 4 + 8 ...
seconds) for the acknowledgment of this message before releasing the
control information associated with the control connection. The
recipient of this message should send an acknowledgment of the
message to the peer, then release the associated control information.
When to release a control connection is an implementation issue and
is not specified in this document. A particular implementation may
use whatever policy is appropriate for determining when to release a
control connection. Some implementations may leave a control
connection open for a period of time or perhaps indefinitely after
the last session for that control connection is cleared. Others may
choose to disconnect the control connection immediately after the
last call on the control connection disconnects.
8. Security Considerations
This section addresses some of the security issues that L2TP
encounters in its operation.
8.1. Control Connection Endpoint and Message Security
If a shared secret (password) exists between two LCCEs, it may be
used to perform a mutual authentication between the two LCCEs, and
construct an authentication and integrity check of arriving L2TP
control messages. The mechanism provided by L2TPv3 is described in
Section 4.3 and in the definition of the Message Digest and Control
Message Authentication Nonce AVPs in Section 5.4.1.
This control message security mechanism provides for (1) mutual
endpoint authentication, and (2) individual control message integrity
and authenticity checking. Mutual endpoint authentication ensures
that an L2TPv3 control connection is only established between two
endpoints that are configured with the proper password. The
individual control message and integrity check guards against
accidental or intentional packet corruption (i.e., those caused by a
control message spoofing or man-in-the-middle attack).
The shared secret that is used for all control connection, control
message, and AVP security features defined in this document never
needs to be sent in the clear between L2TP tunnel endpoints.
8.2. Data Packet Spoofing
Packet spoofing for any type of Virtual Private Network (VPN)
protocol is of particular concern as insertion of carefully
constructed rogue packets into the VPN transit network could result
in a violation of VPN traffic separation, leaking data into a
customer VPN. This is complicated by the fact that it may be
particularly difficult for the operator of the VPN to even be aware
that it has become a point of transit into or between customer VPNs.
L2TPv3 provides traffic separation for its VPNs via a 32-bit Session
ID in the L2TPv3 data header. When present, the L2TPv3 Cookie
(described in Section 4.1), provides an additional check to ensure
that an arriving packet is intended for the identified session.
Thus, use of a Cookie with the Session ID provides an extra guarantee
that the Session ID lookup was performed properly and that the
Session ID itself was not corrupted in transit.
In the presence of a blind packet spoofing attack, the Cookie may
also provide security against inadvertent leaking of frames into a
customer VPN. To illustrate the type of security that it is provided
in this case, consider comparing the validation of a 64-bit Cookie in
the L2TPv3 header to the admission of packets that match a given
source and destination IP address pair. Both the source and
destination IP address pair validation and Cookie validation consist
of a fast check on cleartext header information on all arriving
packets. However, since L2TPv3 uses its own value, it removes the
requirement for one to maintain a list of (potentially several)
permitted or denied IP addresses, and moreover, to guard knowledge of
the permitted IP addresses from hackers who may obtain and spoof
them. Further, it is far easier to change a compromised L2TPv3
Cookie than a compromised IP address," and a cryptographically random
[RFC1750] value is far less likely to be discovered by brute-force
attacks compared to an IP address.
For protection against brute-force, blind, insertion attacks, a 64-
bit Cookie MUST be used with all sessions. A 32-bit Cookie is
vulnerable to brute-force guessing at high packet rates, and as such,
should not be considered an effective barrier to blind insertion
attacks (though it is still useful as an additional verification of a
successful Session ID lookup). The Cookie provides no protection
against a sophisticated man-in-the-middle attacker who can sniff and
correlate captured data between nodes for use in a coordinated
attack.
The Assigned Cookie AVP is used to signal the value and size of the
Cookie that must be present in all data packets for a given session.
Each Assigned Cookie MUST be selected in a cryptographically random
manner [RFC1750] such that a series of Assigned Cookies does not
provide any indication of what a future Cookie will be.
The L2TPv3 Cookie must not be regarded as a substitute for security
such as that provided by IPsec when operating over an open or
untrusted network where packets may be sniffed, decoded, and
correlated for use in a coordinated attack. See Section 4.1.3 for
more information on running L2TP over IPsec.
9. Internationalization Considerations
The Host Name and Vendor Name AVPs are not internationalized. The
Vendor Name AVP, although intended to be human-readable, would seem
to fit in the category of "globally visible names" [RFC2277] and so
is represented in US-ASCII.
If (1) an LCCE does not signify a language preference by the
inclusion of a Preferred Language AVP (see Section 5.4.3) in the