|
|
4.6. L2TPPPTP uses TCP for its control channel, restricting its use to IP networks. To overcome this limitation, Cisco developed a proprietary protocol called Layer Two Forwarding (L2F), which was similar to PPTP but could operate over any link-layer protocol. The IETF combined ideas from PPTP and L2F to produce a third protocol, called the Layer Two Tunneling Protocol (L2TP). Like PPTP, the goal of L2TP is to split the functions of the RAS shown in Figure 4.17 into two parts: an L2TP access concentrator (LAC) that handles the physical communication to the remote host, and an L2TP network server (LNS) that terminates the remote host's PPP session and acts as a gateway into the private network. As with PPTP, L2TP can operate in mandatory mode, in which the remote host connects to a stand-alone LAC, or in voluntary mode, in which the LAC resides on the remote host itself. Unlike PPTP, there is no separate control connection between the LAC and LNS. Rather, control information is sent through the tunnel itself. These features are illustrated in Figure 4.24. The similarity to Figure 4.23 is clear. Figure 4.24. L2TP Mandatory and Voluntary Modes
Although we focus on the use of L2TP in IP networks, it's important to be aware that L2TP can run on other types of networks as well. That, after all, is why the control connection was made to be independent of TCP. As with the other protocols we have studied in this chapter, we limit our discussion to the tunneling aspects of L2TP, but like PPTP, L2TP finds its main use as a VPN. Before looking at the operation of the protocol, let's examine its encapsulation in IP networks. Instead of using GRE to encapsulate the PPP frames as PPTP does, L2TP uses UDP datagrams, much as we did in Figure 4.2 and Figure 4.3. The encapsulation, shown in Figure 4.25, includes an L2TP header that contains session information used to demultiplex the PPP frames. Figure 4.25. L2TP in IP/UDP Encapsulation
Using UDP rather than GRE to encapsulate the L2TP messages makes it easier for L2TP to interoperate with NAT devices. Recall that the most popular mode of NAT is port address translation (PAT), where the port addresses are used to map datagrams to the proper hosts. The problem with using GRE, as PPTP does, is that the GRE header has no port addresses for PAT to use. With UDP, on the other hand, the port addresses are available, and NAT is able to interoperate with L2TP. The L2TP HeaderThere are two types of messages streams within an L2TP tunnel:
Both types of messages start with the common header shown in Figure 4.26. Figure 4.26. The L2TP Common Header
This header is extensible in two ways. First, several of the fields are optional. Second, additional fields are added to the common header, depending on what type of information the message is carrying. These additional fields are in the form of a type-length-value triplet called an attribute value pair (AVP). Functionally, AVPs are similar to IP or TCP options: A set of AVPs is appended to the common header to carry additional information specific to the particular type of message. As we shall see, there is a mechanism to allow proprietary extensions as well. We'll look at the general format of an AVP shortly. The T bit is used to distinguish control messages from session messages. The T bit is set for control messages and cleared for session messages. The L bit is used to signal the presence of the length field. The L bit is always set for control messages, and is optional for data messages. A sender who determines that a length field is not required can omit it and clear the L bit. The S bit signals the presence of the sequence number fields: Ns and Nr. These fields are always present for control messages, so the S bit is always set for control messages. Data messages can also use the sequence number fields to detect lost and out-of-order messages. If the data session does use sequence numbers, the peers will set the S bit. The O bit indicates whether the offset field is present. The O bit is always cleared for control messages. The P bit indicates that the message should be given priority for queuing and transmission on the local machine. The L2TP keep-alive messages, described later, are an example of a message that can make use of the P bit. The P bit is always cleared for control messages. The version field is always set to 2 for L2TP messages. The value 1 is used for L2F messages in order to provide backward compatibility with L2F. The length field, when present, specifies the total length of the message, including the header. When the length field is present, the maximum-length message, including the header, is 65,535 bytes. When the length field is not present, there is no maximum length for L2TP messages, but on IP networks, the 16-bit IP length field will limit the size of the message, whether or not the L2TP length field is present, to 65,527 bytes. The tunnel ID field identifies a particular tunnel. Each peer has its own value for this field. When peer A sends a message to peer B, A will set this field to B's value so that B can identify the tunnel instance. That is, the sender always uses the receiver's tunnel ID, not its own. The session ID field identifies the particular session that a data message belongs to. This field will be 0 for control messages and for the initial message in the session establishment handshake. As with the tunnel ID field, each peer will have its own value for the session ID of a particular session, and the sender will always use the receiver's value. The Ns and Nr fields play a role similar to that of the TCP sequence number and ACK fields. When sequence numbers are in use, each message that a peer sends has a sequence number in the Ns field. The first message has Ns set to 0, and each subsequent message increments its value by 1 (modulo 216). Because control messages always use sequencing, they will always have this field present. Data messages will have an Ns field if sequencing is in use, as indicated by the S bit. The Nr field acts exactly like the TCP ACK field: Its value is the sequence number of the next message the sender is expecting from its peer. Like the TCP ACK field, the Nr field implicitly acknowledges receipt of all messages with a lower sequence number. The Nr field is used only by control messages; receivers must ignore it if it is present in data messages.
The offset size and offset pad fields are used to pad the header for alignment purposes. When present, as indicated by the O bit, the offset size specifies the number of bytes after the offset-size field where the data starts. The contents of the pad field are undefined, and although it's not shown in Figure 4.26, it can extend beyond 2 bytes. Control messages never have either of these two fields present. Attribute Value PairsFields in control messages other than those in the common header of Figure 4.26 are carried as attribute value pairs that immediately follow the common header. AVPs have the form shown in Figure 4.27. Figure 4.27. L2TP Attribute Value Pair
The M bit field indicates that this AVP is mandatory. That is, the receiver must recognize this field or terminate the current operation. For messages associated with a data session, the session must be torn down. If the message is associated with the tunnel itself, the tunnel and all its sessions must be terminated. If the M bit is not set and the receiver does not recognize the AVP, the receiver must ignore the AVP and continue processing as if it had not received the AVP. The H bit, or hidden bit, is used to indicate that this AVP is encrypted. Hidden AVPs are useful for transmitting passwords and other sensitive parameters. We discuss how to perform this encryption shortly. The length field is the number of bytes in the AVP, including the bits and length field. The minimum length is thus 6 bytes when there is no attribute value. The vendor ID field is another mechanism to facilitate extensibility. When the vendor ID is 0, the attribute type values are those defined in the L2TP specification, RFC 2661 [Townsley, Valencia et al. 1999]. Vendors can obtain a vendor ID from the IETF and define their own proprietary attribute types. In this case, the vendor ID would be nonzero, and the interpretation of the attribute type field would depend on the vendor-defined values and associated semantics. The attribute type field is a 16-bit integer specifying what parameter this AVP is carrying. We discuss several of the attributes here. A complete list is available in RFC 2661. The value, if any, of the parameter is in the attribute value field. The value is l 6 bytes long, where l is the number in the length field. Encryption of AVPsIn order for encryption to take place, the LAC and LNS must have a shared secret. Next, a message that has a hidden AVP must also have a random vector AVP that precedes the hidden AVP. The random vector is used as part of the key for the encryption process. Once these two things are in place, we can begin the encryption. First, the AVP is encoded as shown in Figure 4.28. Figure 4.28. Hidden AVP Encoding
The original length field contains the length of the original value field, which will be obscured by the padding and encryption. An arbitrary amount of padding can be added to the original value to hide its original length. The original length field is used by the receiver to discard this padding. The final AVP is shown in Figure 4.29, with the encrypted portion shaded. Figure 4.29. A Hidden AVP
Only the encoding shown in Figure 4.28 is encrypted; the remainder of the AVP is in plaintext so that the receiver can process it correctly. The encryption is performed by concatenating
and taking an MD5 hash of the result. The MD5 operation yields 16 bytes that are exclusive-ORed into the encoding of Figure 4.28. If more than 16 bytes are required, additional key stream is generated by concatenating the shared secret with the result of the previous exclusive-OR operation and taking an MD5 hash of the result. This operation is repeated until enough key stream is generated to completely encrypt the original value and its length. If we let R be the random vector, S the shared secret, and T the attribute type, and if we think of the original value and its length as consisting of 16-byte blocks B0, . . . , Bn, we can summarize this as
where the If more than one hidden AVP is in a message, they may use the same random vector, or the sender can transmit multiple random vectors. If there is more than one random vector, a hidden AVP must use the nearest preceding random vector. Control MessagesFourteen control messages are used for the establishment and management of the L2TP tunnel and its sessions. These messages are listed in Figure 4.30.
The common header (Figure 4.26) does not have a message type field, so an AVP (attribute type 0) is used to identify the type of message. This 8-byte AVP must always be the first AVP in a control message. The message type (from Figure 4.30) is carried in the 2-byte value field, as shown in Figure 4.31. The message type AVP is mandatory and not hidden. Except in the case of a zero-length body (ZLB) message, which is used as an ACK, the message type AVP must always be present. Figure 4.31. The Message Type AVP
A Typical L2TP SessionSo that we will have a concrete example to discuss and analyze, let's capture a typical L2TP session with tcpdump. This session is between linuxlt, playing the part of the LAC, and linux, acting as the LNS. The network configuration is shown in Figure 4.32. Figure 4.32. Test Network for an L2TP Session
The L2TP tunnel, shown shaded in the figure, carries L2TP messages in UDP datagrams over the 172.30.0.0/24 network. The LNS acts as a gateway into the 192.168.122.0/24 network. Although linuxlt is not directly connected to the 192.168.122.0/24 network, the L2TP tunnel provides a virtual extension of that network to linuxlt, as shown by the dashed line. Here is a tcpdump of the session: 1 15:17:47.532030 172.30.0.15.1701 > 172.30.0.4.1701: l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(1680) *HOST_NAME(eriwan) VENDOR_NAME(l2tpd.org) *ASSND_TUN_ID(48224) *RECV_WIN_SIZE(4) (DF) 2 15:17:47.576801 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[TLS](48224/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *RANDOM_VECTOR(d3a7909125f5c53e58f869c079868059) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(1680) *HOST_NAME(eriwan) VENDOR_NAME(l2tpd.org) *ASSND_TUN_ID(52379) *RECV_WIN_SIZE(4) (DF) 3 15:17:47.578062 172.30.0.15.1701 > 172.30.0.4.1701: l2tp:[TLS](52379/0)Ns=1,Nr=1 *MSGTYPE(SCCCN) (DF) 4 15:17:47.583876 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[TLS](48224/0)Ns=1,Nr=2 ZLB (DF) 5 15:18:08.255780 172.30.0.15.1701 > 172.30.0.4.1701: l2tp:[TLS](52379/0)Ns=2,Nr=1 *MSGTYPE(ICRQ) *ASSND_SESS_ID(40607) *CALL_SER_NUM(3) *BEARER_TYPE() (DF) 6 15:18:08.259860 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[TLS](48224/40607)Ns=1,Nr=3 *MSGTYPE(ICRP) *RANDOM_VECTOR(4890def0d66a88ed4db0473642debca1) *ASSND_SESS_ID(20575) (DF) 7 15:18:08.260005 172.30.0.15.1701 > 172.30.0.4.1701: l2tp:[TLS](52379/20575)Ns=3,Nr=2 *MSGTYPE(ICCN) *TX_CONN_SPEED(10000000) *FRAMING_TYPE(S) *RX_CONN_SPEED(10000000) (DF) 8 15:18:08.266317 172.30.0.15.1701 > 172.30.0.4.1701: l2tp:[](52379/20575) {Conf-Req(1), ACCM=00000000, Magic-Num=c49a6f1e, PFC, ACFC} (DF) 9 15:18:08.294282 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[TLS](48224/0)Ns=2,Nr=3 ZLB (DF) 10 15:18:08.321691 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[TLS](48224/40607)Ns=2,Nr=4 ZLB (DF) 11 15:18:08.332097 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[L](48224/40607) {Conf-Req(1), ACCM=00000000, Magic-Num=c49a6f1e, PFC, ACFC} (DF) additional PPP negotiation deleted 12 15:18:47.603327 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[TLS](48224/0)Ns=2,Nr=5 *MSGTYPE(HELLO) (DF) 13 15:18:47.609330 172.30.0.15.1701 > 172.30.0.4.1701: l2tp:[TLS](52379/0)Ns=5,Nr=3 ZLB (DF) 14 15:19:07.189282 172.30.0.15.1701 > 172.30.0.4.1701: l2tp:[](52379/20575) {192.168.122.2 > 192.168.122.1: icmp: echo request (DF)} (DF) 15 15:19:07.193070 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[L](48224/40607) {192.168.122.1 > 192.168.122.2: icmp: echo reply} (DF) L2TP and PPP hellos deleted 16 15:19:55.713922 172.30.0.15.1701 > 172.30.0.4.1701: l2tp:[TLS](52379/20575)Ns=6,Nr=4 *MSGTYPE(CDN) *RESULT_CODE(1/0 Bad file descriptor) *ASSND_SESS_ID(40607) (DF) 17 15:19:55.717628 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[TLS](48224/40607)Ns=4,Nr=7 ZLB (DF) 18 15:20:16.441387 172.30.0.15.1701 > 172.30.0.4.1701: l2tp:[TLS](52379/0)Ns=7,Nr=4 *MSGTYPE(StopCCN) *ASSND_TUN_ID(48224) *RESULT_CODE(1/0 Goodbye!) (DF) 19 15:20:16.444907 172.30.0.4.1701 > 172.30.0.15.1701: l2tp:[TLS](48224/0)Ns=4,Nr=8 ZLB (DF) The session begins on lines 14 with linuxlt, acting as the LAC, establishing a tunnel to linux. After tunnel establishment, linuxlt initiates a data session on lines 57, followed by the PPP negotiation starting on line 8. In lines 1619, the data session and tunnel are torn down. We look at each of these phases in greater detail shortly. Tunnel EstablishmentAs with PPTP, either the LAC or the LNS can initiate a tunnel. If both sides attempt to initiate a tunnel at the same time, a tie-breaking mechanism lets one side proceed as the initiator and the other side take the role of the responder. Figure 4.33 shows the typical case of a LAC initiating a tunnel to the LNS. Figure 4.33. Tunnel-Initiation Handshake
The three-message process is reminiscent of the TCP's three-way connection establishment handshake. In the first message, the initiator sends a Start-Control-Connection-Request message. The SCCRQ message contains several AVPs, some of which are optional. The AVPs are shown in Figure 4.34.
Many of the AVPs in Figure 4.34 are self-explanatory. Recall that the length of the value field of an AVP is l 6, where l is the length given in the table. Note that the lengths are before any hiding. The meaning of the M bit is special for the message type AVP. Rather than indicating that the AVP itself must be recognized, the M bit indicates that the message must be recognized. If the M bit of message type AVP is set and the receiver does not recognize the message, the tunnel must be torn down. If the M bit is cleared and the receiver does not recognize the message, the receiver can ignore the message. Note that all the messages in Figure 4.30 will have the M bit of the message type AVP set. The protocol version value field comprises 2 bytes. The most significant byte is the version, which is set to 1. The low-order byte is the revision, which is set to 0. Note that this field is not the same as the version field in the common header. The framing capabilities AVP is a 32-bit mask. The lowest-order bit is set if the sender is capable of using synchronous framing. The next-lowest-order bit is set if the sender is capable of asynchronous framing. The bearer capabilities field is also a 32-bit mask. The lowest-order bit is set if the sender supports digital access. The second-lowest-order bit is set if the sender supports analog access. The tie breaker is a 64-bit random value used to resolve the conflict that arises when both the LAC and LNS try to initiate a tunnel at the same time. When one side receives an SCCRQ, that side must check whether it has also initiated a tunnel. If so, the receiver compares its tie-breaker value with that of its peer. The side with the lower value proceeds with its tunnel, and the other side abandons its tunnel. The assigned tunnel ID is used to demultiplex messages for multiple tunnels. The sender expects its peer to set the tunnel ID field of the common header to this value for all messages that the peer sends to it. The tunnel ID field in the common header will be 0 for the SCCRQ message. The receive window size AVP indicates how many unacknowledged control messages may be outstanding to the sender. If this AVP is missing, the peer must assume a value of 4. If the sender of the SCCRQ wishes to authenticate its peer with a CHAP-like mechanism (RFC 1994 [Simpson 1996]), it can include the challenge AVP. The value field of this AVP is an arbitrarily long sequence of random bytes. As we discussed previously, whenever a hidden AVP is included in a message, that AVP must be preceded by a random vector AVP that contains an arbitrarily long sequence of random bytes. The receiver of the SCCRQ message will respond with a Start-Control-Connection-Reply (SCCRP) message, indicating that it will accept the connection and specifying its connection parameters.
The AVPs in the SCCRP message are the same as those in the SCCRQ message (Figure 4.34), with the addition of a challenge response, as shown in Figure 4.35.
The value of the challenge response is computed by taking an MD5 hash of the message type (2 for SCCRP), the shared secret, and the challenge value: CR = MD5(T || S || C) where T is the message type, S is the shared secret, C is the challenge value, and CR is the challenge response. If the parameters in the SCCRP message are acceptable to the tunnel initiator, it will complete the tunnel establishment by sending its peer a Start-Control-Connection-Connected (SCCCN) message.
The SCCCN message has one required and two optional AVPs, as shown in Figure 4.36.
Once the responder receives the SCCCN message, the tunnel is established. At that point, either side can request that a PPP session between a remote host and the LNS be started. Either side can reject the connection by sending a StopCCN message. This message is also used to tear down the tunnel when one or both of the peers are finished with it. The StopCCN message has three required and one optional AVP, as shown in Figure 4.37.
The result code AVP is formatted as shown in Figure 4.38. Figure 4.38. The Result Code AVP
The length field indicates whether the optional fields are present. The 2-byte result code is always present. The values defined for the StopCCN message are shown in Figure 4.39.
The error code field contains additional information about the result code values. When the result code indicates a general error (1), the error code tells us what the particular error is. Its values are given in Figure 4.40.
The error message field contains a human-readable string that provides further information about the error code. This field is not present unless the error code field is. Thus the receiver can unambiguously determine which fields are present, by examining the AVP length field. Let's look again at our sample L2TP session to see these messages in action. Here, in greater detail, are the first four messages from the session: 1 15:17:47.532030 172.30.0.15.l2f > 172.30.0.4.l2f: l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(1680) *HOST_NAME(eriwan) VENDOR_NAME(l2tpd.org) *ASSND_TUN_ID(48224) *RECV_WIN_SIZE(4) (DF) 1.1 4500 007f 17f8 4000 4011 ca26 ac1e 000f E.....@.@..&.... 1.2 ac1e 0004 06a5 06a5 006b 74c4 c802 0063 .........kt....c 1.3 0000 0000 0000 0000 8008 0000 0000 0001 ................ 1.4 8008 0000 0002 0100 800a 0000 0003 0000 ................ 1.5 0003 800a 0000 0004 0000 0000 0008 0000 ................ 1.6 0006 0690 800c 0000 0007 6572 6977 616e ..........eriwan 1.7 000f 0000 0008 6c32 7470 642e 6f72 6780 ......l2tpd.org. 1.8 0800 0000 09bc 6080 0800 0000 0a00 04 ......'........ 2 15:17:47.576801 172.30.0.4.l2f > 172.30.0.15.l2f: l2tp:[TLS](48224/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *RANDOM_VECTOR(d3a7909125f5c53e58f869c079868059) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(1680) *HOST_NAME(eriwan) VENDOR_NAME(l2tpd.org) *ASSND_TUN_ID(52379) *RECV_WIN_SIZE(4) (DF) 2.1 4500 0095 aa5f 4000 4011 37a9 ac1e 0004 E...._@.@.7..... 2.2 ac1e 000f 06a5 06a5 0081 f0ce c802 0079 ...............y 2.3 bc60 0000 0000 0001 8008 0000 0000 0002 .'.............. 2.4 8016 0000 0024 d3a7 9091 25f5 c53e 58f8 .....$....%..>X. 2.5 69c0 7986 8059 8008 0000 0002 0100 800a i.y..Y.......... 2.6 0000 0003 0000 0003 800a 0000 0004 0000 ................ 2.7 0000 0008 0000 0006 0690 800c 0000 0007 ................ 2.8 6572 6977 616e 000f 0000 0008 6c32 7470 eriwan......l2tp 2.9 642e 6f72 6780 0800 0000 09cc 9b80 0800 d.org........... 2.10 0000 0a00 04 ..... 3 15:17:47.578062 172.30.0.15.l2f > 172.30.0.4.l2f: l2tp:[TLS](52379/0)Ns=1,Nr=1 *MSGTYPE(SCCCN) (DF) 3.1 4500 0030 17fb 4000 4011 ca72 ac1e 000f E..0..@.@..r.... 3.2 ac1e 0004 06a5 06a5 001c 855c Bc802 0014 ............... 3.3 cc9b 0000 0001 0001 8008 0000 0000 0003 ................ 4 15:17:47.583876 172.30.0.4.l2f > 172.30.0.15.l2f: l2tp:[TLS](48224/0)Ns=1,Nr=2 ZLB (DF) 4.1 4500 0028 aa60 4000 4011 3815 ac1e 0004 E..(.'@.@.8..... 4.2 ac1e 000f 06a5 06a5 0014 15ba c802 000c ................ 4.3 bc60 0000 0001 0002 0000 0000 0000 .'............ As we see, linuxlt initiates tunnel establishment with an SCCRQ message. The first 20 bytes are the IP header, which is followed by the 8 bytes of the UDP header. We see from these headers that the message is from 172.30.0.15 (0xac1e000f) to 172.30.0.4 (0xac1e0004) and that the source and destination ports are both 1705 (0x06a5). Next comes the L2TP header (Figure 4.26), shown in boldface on lines 1.2 and 1.3. The first 8 bits tell us that the T, L, and S flags are set. The L2TP version is 2, as expected. The next 2 bytes tell us that the length of the L2TP message is 99 (0x63) bytes long. No tunnel or session ID has been established yet, so these two fields are zeroed. Finally, we see that Ns and Nr are both 0 as well. The first AVP, the message type, immediately follows the header in the last 8 bytes of line 1.3. We see that the M bit is set, indicating that our peer must recognize this message type, and that the AVP is 8 bytes long. Because this is a standard AVP, the vendor ID field is 0. The attribute type is 0, indicating that this is the message type AVP (Figure 4.34), and the message type is 1, indicating an SCCRQ message (Figure 4.30). The next AVP starts 8 bytes after the first byte of the message type AVP. We see that its attribute type is 2, which, from Figure 4.34, specifies the protocol version. We can step through the remaining AVPs in a similar fashion to verify the information that tcpdump printed out in line 1.
Because tcpdump provides comprehensive information about L2TP messages, we needn't bother analyzing the remaining hex dumps in detail. It is an excellent exercise, however, to verify the details that tcpdump prints out for one or two of the other messages. Doing so results in a deeper understanding of how the protocol works and how its messages are formed. Before leaving the SCCRQ message, we should note an anomaly with the host name AVP. As shown on line 1, linuxlt sent a host name of eriwan. This is because of a bug in the L2TP software used for the session. Instead of using the configured name, it always uses the hard-coded name eriwan. The second message shows linux responding to the SCCRQ with an SCCRP. The tunnel ID field is filled in with 48224 because its value is known from the assigned tunnel ID AVP in the SCCRQ message. The session ID is still 0, of course, because no sessions are active. We note that linux sets its tunnel ID to 52379. This is the value that linuxlt will put in the tunnel ID field, as we'll see in the next message. We also see that Nr is set to 1. This indicates that linux expects the Ns value of the next message from linuxlt to be set to 1. Although it is not used, linux provides a random vector AVP. Sending this AVP when it's not needed is a peculiarity of this implementation. The rest of the AVPs are similar to those in the SCCRQ message. The tunnel establishment is completed with the next message, in which linuxlt sends an SCCCN message. Because it doesn't have a message pending for linuxlt, linux responds to the SCCCN with a ZLB. This corresponds to TCP's pure ACK message and is sent as part of the tunnel-reliability mechanism. The ZLB plays no part in tunnel establishment. Lines 18 and 19 from the sample session show what happens when the peers are finished with the tunnel: 18 15:20:16.441387 172.30.0.15.l2f > 172.30.0.4.l2f: l2tp:[TLS](52379/0)Ns=7,Nr=4 *MSGTYPE(StopCCN) *ASSND_TUN_ID(48224) *RESULT_CODE(1/0 Goodbye!) (DF) 18.1 4500 004a 1856 4000 4011 c9fd ac1e 000f E..J.V@.@....... 18.2 ac1e 0004 06a5 06a5 0036 4a0f c802 002e .........6J..... 18.3 cc9b 0000 0007 0004 8008 0000 0000 0004 ................ 18.4 8008 0000 0009 bc60 8012 0000 0001 0001 .......'........ 18.5 0000 476f 6f64 6279 6521 ..Goodbye! 19 15:20:16.444907 172.30.0.4.l2f > 172.30.0.15.l2f: l2tp:[TLS](48224/0)Ns=4,Nr=8 ZLB (DF) 19.1 4500 0028 aabb 4000 4011 37ba ac1e 0004 E..(..@.@.7..... 19.2 ac1e 000f 06a5 06a5 0014 15b1 c802 000c ................ 19.3 bc60 0000 0004 0008 0000 0000 0000 .'............ Tunnel teardown is initiated when linuxlt sends a StopCCN message. Notice that the tunnel ID in the L2TP header (52379) is the ID assigned by linux. As required by the protocol, linuxlt also sends its value of the tunnel ID (48224) as an AVP, making it unambiguous as to which tunnel is being torn down. The result code AVP (Figure 4.38) is shown in boldface on lines 18.4 and 18.5. It shows a result/error code (Figure 4.39 and Figure 4.40) of 1/0 (general request to clear control connection/no error) and the optional human-readable message (Goodbye!). The tunnel teardown is complete when linux responds with a ZLB, acknowledging that it received the StopCCN message. The Control ConnectionThe control connection is a reliable connection that largely duplicates the semantics of TCP reliability. As we've seen, each control connection has sequence number and ACK fields that help provide reliability in the same manner that the corresponding TCP fields do. Once a message is sent, a retransmission timer is started. If the message is not acknowledged by the other side before the timer expires, the message is retransmitted, and the timer is restarted with a larger timeout value. After several unsuccessful attempts, the tunnel is considered down and is abandoned. If the receiver of a control message has a response, it can acknowledge the control message in its response. If no response is necessary, the peer will respond with a common message header that contains no AVPs. This is the ZLB message. Its sole purpose is to acknowledge a previous message by indicating the next expected sequence number in its Nr field. Like TCP, the control channel guarantees that control messages will be delivered in order and that it will make a sustained effort to deliver each message. When IP is used as the transport, the UDP checksum provides the same protection from corruption that TCP enjoys. Other transports have their own checksum schemes for protection against corruption. RFC 2661 recommends that TCP-like congestion control also be implemented for the control channel, but [Carlson 2000] reports that most implementations fail to do this. If one of the tunnel endpoints has not received any messages from its peer for a certain amount of timeRFC 2661 recommends 60 secondsthe endpoint can send its peer a hello (HELLO) message. As we see from Figure 4.30, the HELLO is a control message, so after transmitting the HELLO, the sender can depend on the reliable-delivery mechanism of the control channel: either the HELLO will be delivered and acknowledged by the other side or will time out and cause the tunnel to be abandoned. Because HELLO messages are global to the tunnel, the session ID field is 0. An unacknowledged HELLO will cause all sessions in the tunnel to be terminated. The HELLO mechanism allows both peers to discover independently that the tunnel is no longer functioning. The HELLO message contains a single message type AVP, as shown in Figure 4.41.
Lines 12 and 13 of our sample session show an example of a HELLO sequence: 12 15:18:47.603327 172.30.0.4.l2f > 172.30.0.15.l2f: l2tp:[TLS](48224/0)Ns=2,Nr=5 *MSGTYPE(HELLO) (DF) 12.1 4500 0030 aa77 4000 4011 37f6 ac1e 0004 E..0.w@.@.7..... 12.2 ac1e 000f 06a5 06a5 001c 958f c802 0014 ................ 12.3 bc60 0000 0002 0005 8008 0000 0000 0006 .'.............. 13 15:18:47.609330 172.30.0.15.l2f > 172.30.0.4.l2f: l2tp:[TLS](52379/0)Ns=5,Nr=3 ZLB (DF) 13.1 4500 0028 1812 4000 4011 ca63 ac1e 000f E..(..@.@..c.... 13.2 ac1e 0004 06a5 06a5 0014 057a c802 000c ...........z.... 13.3 cc9b 0000 0005 0003 ........ Incoming Calls from a Remote HostWhen a remote host connects to a LAC, the LAC will initiate a session with the LNS. If a tunnel between the LAC and LNS does not already exist, the LAC will negotiate one before proceeding with the session establishment. The protocol that the LAC uses to establish a session is similar to the one used to establish the tunnel. As with tunnel establishment, there is a three-step handshake, as shown in Figure 4.42. Figure 4.42. Incoming Session Establishment
After receiving a call indication from the remote hosteither from the remote host connecting to the LAC in mandatory mode or internally in voluntary modethe LAC sends an ICRQ to the LNS with information about the call. The LAC can defer answering the call (in mandatory mode) until the LNS agrees to establish the session, or it can immediately answer the call and perform LCP negotiation and authentication before sending the ICRQ. In either case, the LAC sends the ICRQ message to begin the session-establishment handshake. The ICRQ has three required and six optional AVPs, as shown in Figure 4.43.
The assigned session ID AVP is this LAC's identification number for the session. The LNS will place this number in the session ID field of the common header. Because the LAC does not yet have the LNS's session ID, it puts a 0 in the session ID field of the ICRQ's common header. The call serial number AVP is a 32-bit counter that identifies a particular call. This AVP is used by system administrators at the LAC and LNS for troubleshooting. The bearer type AVP is similar to the bearer capabilities AVP; it consists of a 32-bit mask with the lowest-order bit indicating that the call is on a digital channel and the next-lowest-order bit indicating that the call is on an analog channel. In the case of a voluntary-mode connection, where the LAC is embedded in the remote host, both bits may be left unset. The called number, calling number, and subaddress AVPs are variable-length ASCII strings that contain information about the phone numbers of the called and calling parties. The subaddress contains additional dialing information. RFC 2661 remarks that the LAC and LNS may have to agree on the interpretation of these fields. The physical channel ID contains vendor-specific information about the physical channel of the call. This AVP is used only for logging purposes. If the LNS agrees to accept the call, it will reply to the ICRQ with an Incoming-Call-Reply (ICRP). If the LNS does not want to accept the call, it will reply with a Call-Disconnect-Notify (CDN) message. We'll look at the CDN message shortly. The ICRP has two required and one optional AVP, as shown in Figure 4.44.
We've already seen these AVPs in the ICRQ message. After receiving the ICRP, the LAC answers the call, if it hasn't already done so, and then completes the session establishment by sending an Incoming-Call-Connected (ICCN) message to the LNS. The ICCN informs the LNS that the remote host is connected and passes the LNS some parameters concerning the physical-connection characteristics. If the LAC has already performed the LCP and authentication phases of PPP, the ICCN message will also contain information about the PPP parameters negotiated and the results of the authentication. The ICCN message has 3 required and 12 optional AVPs, as shown in Figure 4.45.
The framing type AVP is a 32-bit mask that describes the type of framing the LAC is using. If the lowest-order bit is set, the connection is using synchronous framing. If the next-lowest-order bit is set, the connection is using asynchronous framing. The Tx connect speed AVP is a 4-byte value indicating the transmit speedfrom LAC to remote hostin bits per second. Similarly, the Rx connect speed is the speed of the connection from the remote host to the LAC. When the Rx connect speed AVP is missing, the receive speed is assumed to be the same as the transmit speed. If the LAC performs PPP LCP negotiation with the remote host, the initial received LCP CONFREQ, last received LCP CONFREQ, and last sent LCP CONFREQ AVPs help the LNS to understand what PPP parameters the remote host requested and what values the LAC and remote host finally agreed on. The LNS uses these values to set the corresponding parameters in its PPP implementation just as if it had negotiated them itself. If the LAC performs authentication of the remote host for the LNS, the proxy authen. type, proxy authen. name, proxy authen. challenge, proxy authen. ID, and proxy authen. response may be present. The proxy authen. type indicates the type of authentication that the LAC and remote host performed. The authentication types are shown in Figure 4.46.
If the LAC performs proxy authentication, the proxy authen. type AVP must be present. The other parameters may or may not be present, depending on the authentication method the LAC and remote host used. The private group AVP indicates that the LNS should treat this call as belonging to a particular customer group. The attribute value field is an arbitrary sequence of bytes. The sequencing required AVP indicates that sequence numbers must be used on data messages for this call. Recall that the LAC and LNS can use these sequence numbers to detect dropped or out-of-order messages. We see these messages in action in lines 57 of our sample session: 5 15:18:08.255780 172.30.0.15.l2f > 172.30.0.4.l2f: l2tp:[TLS](52379/0)Ns=2,Nr=1 *MSGTYPE(ICRQ) *ASSND_SESS_ID(40607) *CALL_SER_NUM(3) *BEARER_TYPE() (DF) 5.1 4500 004c 17fd 4000 4011 ca54 ac1e 000f E..L..@.@..T.... 5.2 ac1e 0004 06a5 06a5 0038 6611 c802 0030 .........8f....0 5.3 cc9b 0000 0002 0001 8008 0000 0000 000a ................ 5.4 8008 0000 000e 9e9f 800a 0000 000f 0000 ................ 5.5 0003 800a 0000 0012 0000 0000 ............ 6 15:18:08.259860 172.30.0.4.l2f > 172.30.0.15.l2f: l2tp:[TLS](48224/40607)Ns=1,Nr=3 *MSGTYPE(ICRP) *RANDOM_VECTOR(4890def0d66a88ed4db0473642debca1) *ASSND_SESS_ID(20575) (DF) 6.1 4500 004e aa62 4000 4011 37ed ac1e 0004 E..N.b@.@.7..... 6.2 ac1e 000f 06a5 06a5 003a 8aa3 c802 0032 .........:.....2 6.3 bc60 9e9f 0001 0003 8008 0000 0000 000b .'.............. 6.4 8016 0000 0024 4890 def0 d66a 88ed 4db0 .....$H....j..M. 6.5 4736 42de bca1 8008 0000 000e 505f G6B.........P_ 7 15:18:08.260005 172.30.0.15.l2f > 172.30.0.4.l2f: l2tp:[TLS](52379/20575)Ns=3,Nr=2 *MSGTYPE(ICCN) *TX_CONN_SPEED(10000000) *FRAMING_TYPE(S) *RX_CONN_SPEED(10000000) (DF) 7.1 4500 004e 17fe 4000 4011 ca51 ac1e 000f E..N..@.@..Q.... 7.2 ac1e 0004 06a5 06a5 003a 85f4 c802 0032 .........:.....2 7.3 cc9b 505f 0003 0002 8008 0000 0000 000c ..P_............ 7.4 800a 0000 0018 0098 9680 800a 0000 0013 ................ 7.5 0000 0001 800a 0000 0026 0098 9680 .........&.... On line 5, linuxlt initiates a session by sending linux an ICRQ message. As expected, the session ID field in the header is 0 because linux has not yet assigned an ID for this session. We see, however, that linuxlt has assigned session ID 40607. In line 6, linux responds with the ICRP message as expected. This time, the header's session ID field is filled in with the value that linuxlt sent in its ICRQ message. Just as with the tunnel ID, the sender places its peer's session ID in the header. The session is established when linuxlt sends the ICCN message. At this point, PPP can begin its negotiation. We can see this starting in line 8 of the sample session: 8 15:18:08.266317 172.30.0.15.l2f > 172.30.0.4.l2f: l2tp:[](52379/20575) {Conf-Req(1), ACCM=00000000, Magic-Num=c49a6f1e, PFC, ACFC} (DF) 8.1 4500 003a 17ff 4000 4011 ca64 ac1e 000f E..:..@.@..d.... 8.2 ac1e 0004 06a5 06a5 0026 7307 0002 cc9b .........&s..... 8.3 505f ff03 c021 0101 0014 0206 0000 0000 P_...!.......... 8.4 0506 c49a 6f1e 0702 0802 ....o..... As always, the L2TP message is encapsulated in a UDP datagram. The L2TP header, shown in boldface, has no flags set, so no optional fields are present (see Figure 4.26). After the header, we see the PPP packet starting with the address field. This is expected, as we are using synchronous framing as indicated in line 7. Once the session is established and PPP negotiation is finished, we can send data over the session connection. Here is the result of a single ping and reply: 14 15:19:07.189282 172.30.0.15.l2f > 172.30.0.4.l2f: l2tp:[](52379/20575) {192.168 .122.2 > 192.168.122.1: icmp: echo request (DF)} (DF) 14.1 4500 0077 1815 4000 4011 ca11 ac1e 000f E..w..@.@....... 14.2 ac1e 0004 06a5 06a5 0063 5b91 0002 cc9b .........c[..... 14.3 505f 2145 0000 5418 1440 0040 01ad 40c0 P_!E..T..@.@..@. 14.4 a87a 02c0 a87a 0108 0085 b8b6 0b00 013b .z...z.........; 14.5 16c1 3fd2 e102 0008 090a 0b0c 0d0e 0f10 ..?............. 14.6 1112 1314 1516 1718 191a 1b1c 1d1e 1f20 ................ 14.7 2122 2324 2526 2728 292a 2b2c 2d2e 2f30 !"#$%&'()*+,-./0 14.8 3132 3334 3536 37 1234567 15 15:19:07.193070 172.30.0.4.l2f > 172.30.0.15.l2f: l2tp:[L](48224/40607) {192.16 8.122.1 > 192.168.122.2: icmp: echo reply} (DF) 15.1 4500 0079 aa7a 4000 4011 37aa ac1e 0004 E..y.z@.@.7..... 15.2 ac1e 000f 06a5 06a5 0065 dd2a 4002 005d .........e.*@..] 15.3 bc60 9e9f 2145 0000 54aa 7900 0040 015a .'..!E..T.y..@.Z 15.4 dbc0 a87a 01c0 a87a 0200 008d b8b6 0b00 ...z...z........ 15.5 013b 16c1 3fd2 e102 0008 090a 0b0c 0d0e .;..?........... 15.6 0f10 1112 1314 1516 1718 191a 1b1c 1d1e ................ 15.7 1f20 2122 2324 2526 2728 292a 2b2c 2d2e ..!"#$%&'()*+,-. 15.8 2f30 3132 3334 3536 37 /01234567 The data portion of the hex dump does not appear to make sense, because PPP negotiated payload compression.
When the peers are finished with the data session, they can release its resources by tearing the connection down. In our sample session, linuxlt initiates the teardown by sending a CDN message, and linux ACKs the message with a ZLB, as shown on lines 16 and 17: 16 15:19:55.713922 172.30.0.15.l2f > 172.30.0.4.l2f: l2tp:[TLS](52379/20575)Ns=6,Nr=4 *MSGTYPE(CDN) *RESULT_CODE(1/0 Bad file descriptor) *ASSND_SESS_ID(40607) (DF) 16.1 4500 0055 184f 4000 4011 c9f9 ac1e 000f E..U.O@.@....... 16.2 ac1e 0004 06a5 06a5 0041 4bc2 c802 0039 .........AK....9 16.3 cc9b 505f 0006 0004 8008 0000 0000 000e ..P_............ 16.4 801d 0000 0001 0001 0000 4261 6420 6669 ..........Bad.fi 16.5 6c65 2064 6573 6372 6970 746f 7280 0800 le.descriptor... 16.6 0000 0e9e 9f ..... 17 15:19:55.717628 172.30.0.4.l2f > 172.30.0.15.l2f: l2tp:[TLS](48224/40607)Ns=4,Nr=7 ZLB (DF) 17.1 4500 0028 aab4 4000 4011 37c1 ac1e 0004 E..(..@.@.7..... 17.2 ac1e 000f 06a5 06a5 0014 7712 c802 000c ..........w..... 17.3 bc60 9e9f 0004 0007 0000 0000 0000 .'............ Outgoing Calls to a Remote HostJust as the remote host can initiate a call through the LAC to the LNS, the LNS can initiate a call through the LAC to the remote host. As with incoming call requests, the call is established with a three-step handshake, as shown in Figure 4.47. Figure 4.47. Outgoing Session Establishment
The first step in establishing an outgoing call is for the LNS to send an Outgoing-Call-Request (OCRQ) to the LAC. As we see from Figure 4.48, we have already encountered most of the AVPs in this message.
The minimum bps and maximum bps AVPs specify the minimum and maximum speed in bits per second required for the outgoing call. Both attribute value fields are 32-bit integers. If the LAC is able to honor the call request, it responds with an Outgoing-Call-Reply (OCRP) informing the LNS of the session ID and physical channel, as shown in Figure 4.49.
After it has connected to the remote host, the LAC sends the LNS an Outgoing-Call-Connected (OCCN) message that notifies the LNS that the session is ready to proceed and informs it of the connection parameters. The OCCN has three required and three optional AVPs, as shown in Figure 4.50.
If the LAC can't complete the call, it will send a Call-Disconnect-Notify (CDN) message to the LNS. Similarly, if the remote host disconnects or otherwise terminates the session, the LAC will send a CDN to the LNS. The LNS can also terminate the session by sending a CDN to the LAC. The CDN has three required and two optional AVPs, as shown in Figure 4.51.
Except for the Q.931 cause code, we've seen all these AVPs before. The Q.931 cause code is used to report the cause of an unsolicited Integrated Services Digital Network (ISDN) disconnection. Details about the format of this AVP are in RFC 2661. Other Control MessagesThere are two other control messages that we haven't yet explored. The first is the WAN-Error-Notify (WEN) message, used by the LAC to report WAN errors to the LNS. RFC 2661 specifies that this message be sent only when an error occurs and not more than once every 60 seconds. The WEN message has two required and one optional AVP, as shown in Figure 4.52. The attribute value field of the call errors AVP consists of six cumulative counters for various types of errors, as shown in Figure 4.53.
Figure 4.53. Call Errors Attribute Value Field
Our final control message is the Set-Link-Info (SLI) message. RFC 2661 describes the SLI message as a mechanism for the LNS to inform the LAC of negotiated PPP parameters, but its only use is for the LNS to inform the LAC of the asynchronous control character map (ACCM). Recall from Chapter 2 that each PPP peer can negotiate which bytes it requires its peer to escape. When it performs LCP negotiation, the LNS must inform the LAC of the ACCM, as it is the LAC that will perform the escaping. The SLI message has two required and one optional AVP, as shown in Figure 4.54.
The attribute value field for the ACCM AVP comprises two 32-bit character masks and a reserved field, as shown in Figure 4.55. Figure 4.55. ACCM Attribute Value Field
The L2TP specification is given in RFC 2661 [Townsley, Valencia et al. 1999]. [Shea 2000] gives an excellent and thorough exposition of the operation of L2TP. This is the place to look for an explanation of the various state machines and other internal L2TP mechanisms. L2TP FuturesAt the time of this writing, the IETF L2TP Extensions Working Group (see <http://www.ietf.org/html.charters/l2tpext-charter.html>) is developing the specifications for the next version (L2TPv3) of L2TP. Whereas L2TP is designed to carry PPP packets over various media, L2TPv3 generalizes this facility to the notion of a pseudowire that can transport many types of interface-layer packets, such as PPP, Ethernet, frame relay, and ATM. In the context of the TCP/IP, L2TPv3 will provide the pseudowire by tunneling the link-layer protocols over either UDP, as L2TP does, or directly over IP. Although tunneling over IP seems cleaner and imposes less overhead, there are advantages to using UDP. Tunneling directly over IP does not interoperate well with NAT or, more precisely, PAT, because no port numbers are available for NAT to remap. Thus, tunneling L2TPv3 packets over UDP can help with NAT traversal. In addition to separating the PPP functionality from L2TP proper and adding the capability to tunnel interface-layer protocols other than PPP, L2TPv3 adds additional AVPs and enhances some of the data structures. For example, the session and tunnel ID fields are 32 bits in L2TPv3. Finally, L2TPv3 optionally extends the CHAP-like tunnel authentication mechanism to cover all packets in the control channel. To enable authentication, the peers exchange nonces during the tunnel establishment protocol.
Each control message is authenticated by taking a cryptographic hashcurrently, HMAC-MD5 and HMAC-SHA-1 are definedof the concatenation of the two nonces, a shared key, and the message. That is, D = H(LN || RN || K || m) where D is the authentication digest, H is the hash function, LN is the local nonce, RN is the remote nonce, K is the shared key, and m is the message. The authentication digest is carried in an AVP attached to the message. As we saw in Chapter 3, these digests assure both sides that the message is from its peer and has not been altered. The addition of the two nonces ensures that the message is from this incarnation of the tunnel and prevents replay attacks using packets from previous tunnels. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
are the encrypted 16-byte blocks corresponding to the plaintext blocks 
