L2TPv3 Control Channel
| L2TP has a reliable control channel and 15 different control message types. The major ones for the setup and teardown of the control channel itself are as follows:
The major control messages for session setup and teardown are as follows:
L2TP uses a three-way handshake to establish the control channel. The initiating endpoint sends an SCCRQ message to the remote peer. The peer replies with an SCCRP. The originator confirms the channel is open with an SCCCN. The peers can negotiate capabilities, such as a hello interval or window size. The two endpoints also advertise their respective control connection identifier, which is included in each control message and identifies the receiver. Tunnel teardown is a little more abrupt. One of the endpoints sends a StopCCN message. There is no reply. The peers simply wait for all outstanding message acknowledgments. The StopCCN clears all the sessions in the tunnel. Session setup also uses a three-way handshake. If a tunnel endpoint detects an incoming [L2] call, from a PPP client for example, it sends an ICRQ to its peer, which replies with an ICRP. The calling peer completes session negotiation with an ICCN message. Outgoing-call messages are used if the endpoint decides, for whatever reason, to originate a session. Just as with the tunnel itself, the peers can exchange capability information for the session during the negotiation phase. The most important of these are the session ID and cookie. The session ID is analogous to the control channel identifier and is a "shortcut" value that the receiver associates with the negotiated context for a particular session (for instance, payload type, cookie size). The cookie is an optional, variable-length field of up to 64 bits. The cookie is a cryptographically random number that extends the session identifier space so as to ensure there is little chance that a packet is misdirected because of a corrupt session ID. Because 264 is a large number (and as long as it is random), the cookie makes L2TPv3 impervious to brute-force spoofing attacks (that is, attacks in which the attacker tries to inject packets into an active session). The control messages contain two 16-bit sequence numbers, Ns and Nr which are used to provide reliable delivery. The Ns field contains the sequence number of the message being sent. The Nr field contains the sequence number the peer expects to receive next. Each peer has a queue of outgoing messages. When a message is sent with a certain value in the Ns outgoing field, it is held (in another queue) until the remote peer acknowledges the message in its Nr field. The sender will resend if it does not receive an acknowledgment after a certain time interval (the RFC suggests 1 second with exponential backoff). If still no acknowledgment is seen from the remote peer, all the sessions and the control channel itself are flushedbecause there is obviously a communication problem, there is no point sending more data to the peer under current conditions. When an L2TPv3 tunnel is closed, the peers wait for all message acknowledgments before tearing down the tunnel. The L2TPv3 control channel also has an authentication mechanism. At the least, this requires a shared secret used on both peers to calculate a hash, or checksum. If an endpoint wants to authenticate its peer, it includes a random value, called a nonce, in a control message. When the remote endpoint sees the nonce, it must start authenticating all subsequent control messages. Authentication cannot be half on, so the remote peer must also send a nonce so that it can authenticate the local peer. L2TP authentication is based on Challenge Handshake Authentication Protocol (CHAP, RFC 1994). An authenticated message contains a digest, or checksum, which can only be calculated by an endpoint that has certain information. The recipient of the message also calculates a digest, using the same information, and compares the result to the value it received. If they match, the message is genuine. If not, the message is discarded. An L2TP endpoint computes a message value by applying a one-way hash function using a shared secret, its own and its peers nonce, and the contents of the control message itself. Obviously, the security of this system depends on choosing a good shared secret (the name of your company probably does not qualify) and on the random values (and the strength of the hash algorithm itself, currently secure hash algorithm [SHA] or message digest algorithm 5 [MD5]). A third party would have to know both of these values to be able to modify the control message and compute a new, valid digest. The nonces themselves are sent to the remote tunnel endpoint as part of the control message. They are not encrypted. Figure A-3 shows the L2TP control message header. The header contains the control channel ID and the Nr and Ns fields for retransmission. The meaning of all these fields has already been covered. The control message payload, which is not included in Figure A-3, is a variable sequence of attribute-value pairs (AVPs). There are AVPs for Message Digest, Connection ID, Receive Window size, and so forth. Figure A-3. L2TP Control Message Header (from RFC 3931) Finally, the control channel has a keepalive message that is sent periodically (the interval is configurable) between endpoints. Thus, communication problems can be detected independently of call management or data traffic. |
EAN: 2147483647
Pages: 128