Home > Articles > Networking

This chapter is from the book

5.3 L2TP

L2TP has minimal built-in security. The LAC and LNS can authenticate each other during tunnel setup, and most AVPs can be encrypted, but L2TP, like PPTP, depends on PPP to protect the user data in the tunnel. This default security has several problems.

Let's put aside the problems with MPPE and MS-CHAP for the moment and assume that we have robust versions of CHAP and an encryption protocol installed in our PPP implementation. Unfortunately, we are still far from secure. Let's take a look at some of the problems that remain.

First, the control channel, once set up, is unprotected except for any AVPs that are encrypted. This means that an attacker can easily disrupt the tunnel by, for example, sending a forged StopCCN message to the LAC or LNS. The attacker will have to know the tunnel ID and proper sequence numbers, of course, but they are easily obtained by snooping the tunnel or even by informed trial and error.

A parallel weakness exists in PPP. Although packets carrying user data are encrypted, control packets, such as LCP, CHAP, and IPCP packets, are not. This means that PPP can leak information, such as the internal IP addresses of the enterprise network. It also means that active attacks, such as sending a forged packet pointing to a compromised DNS server, are possible. Because PPP packets are not authenticated—whether or not encryption is in use—these types of attacks are particularly easy.

This last point is an important one. Because neither PPP nor L2TP messages are authenticated, they are subject to various manipulations.

We must distinguish here between the endpoint authentication, which happens at L2TP tunnel setup and PPP session establishment, and message authentication. Endpoint authentication typically involves a CHAP-like mechanism to convince each side of the proposed connection that its peer is who he says he is. Message authentication, on the other hand, refers to providing each message with a message authentication code, such as one of the HMACs we discussed in Chapter 3, to guarantee that the message is from the peer, not a forged message injected into the message stream by an attacker, and that it has not been modified since the MAC was calculated. Message authentication is sometimes called message integrity to distinguish it from endpoint authentication. Similarly, MACs are sometimes called message integrity codes (MICs).

Those who are not well versed in security and cryptographic protocols often believe that encryption alone provides message authentication. After all, if the message is not from the peer, how did the attacker encrypt it? Similarly, how could an attacker alter a message's plaintext without knowing the encryption key? Unfortunately, even encrypted messages are subject to manipulation by an attacker. Data that is encrypted with a stream cipher is subject to bit-flipping attacks, as we noted in our discussion of PPTP. Data encrypted with block ciphers is subject to cut-and-paste attacks, as we'll see in Chapter 12. Thus, the lack of message authentication in L2TP is a serious security shortcoming.

As we mentioned in Chapter 4, the forthcoming L2TPv3 will provide optional authentication for all messages in the control channel.

A consequence of L2TP's lack of message authentication is that there is no replay protection. That is, an attacker can replay previous messages in order to confuse the protocol or end application. We would not, for example, want to allow a previous request for a bank fund transfer to be replayed. Replay attacks can easily be prevented by adding a sequence number to each message and then authenticating the message. Notice that the sequence number alone is insufficient, as the attacker could merely supply the expected sequence number of an unauthenticated message. It is the authentication that prevents such trivial attacks.

Another problem with L2TP and PPP encryption and endpoint authentication is that they are based on a single shared secret. There are two issues with this: First, this shared secret could be compromised in some manner outside of the protocol, and once compromised, all previous and future traffic can be read, and the enterprise network that it is protecting is subject to immediate attack. Second, the shared secret is long lived, allowing an attacker to accumulate a large amount of data encrypted with it. The more data that a cryptanalyst has, the easier it is to break the encryption and discover the key.

VPNs generally have more robust key-management protocols that change keys often and prevent the accumulation of data that a cryptanalyst can work with. MPPE does this to a limited extent—the session key can change with every packet or after 256 packets—but because these keys are derived from a single shared secret and information sent in the clear, their security is no better than that of the shared secret. If the shared secret is compromised, all messages—past and future—can be read.

The ideal key-management protocol has a property called perfect forward secrecy (PFS). This means that each session key is independent and that the compromise of one such key does not compromise any of the others. Thus, our complaint about MPPE in the previous paragraph is that although it does change keys frequently, thereby making brute-force attacks more difficult, it does not enjoy the PFS property. This is a problem with PPP in general; none of the encryption protocols defined for use with it enjoy PFS or have robust key-management protocols. Indeed, as of this writing, they all depend on a shared secret.

L2TP and IPsec

Because L2TP has such weak native security, many experts consider it a remote access technology rather than a VPN. On the other hand, users tend to think of it as a VPN technology and are interested primarily in protecting their communications. One way of reconciling these two views is to combine L2TP with an external security protocol. The most popular way of doing this is to run L2TP over IPsec (Part 3).

IPsec provides encryption, authentication, and other security services at the network layer. IPsec can run in several modes and provide differing security services, but for now, let us merely stipulate that IPsec can provide encryption and authentication for IP packets. In particular, we shall be interested in ESP transport mode (Chapter 12), in which the payload of IP datagrams is encrypted and authenticated while in transit between, in this case, the LAC and LNS. Figure 5.1 shows the encapsulation of the L2TP header and message within IPsec, UDP, and IP.

05fig01.gif

Figure 5.1 Encapsulation of L2TP Within IPsec

With this encapsulation, the UDP header, the L2TP header, the L2TP message, and parts of the IPsec header and trailers are encrypted and authenticated, giving complete protection for everything in the L2TP tunnel. That is, the control channel and all the data channels, including the PPP control protocols, such as LCP and IPCP, are protected from snooping and alteration. This solves the problem that we have with plain L2TP of leaving these protocols unprotected. Finally, ESP provides replay protection, so L2TP/IPsec is also safe from replay attacks.

Given a connection over an L2TP/IPsec tunnel from a remote host to a host on the enterprise network, it is important to understand what parts of the path between the two hosts are protected. In the most common case of the road warrior with a voluntary connection to the enterprise network, we have the situation shown in Figure 5.2. If we assume that the remote host is communicating with one of the servers on the enterprise network, we almost have an end-to-end VPN. The L2TP/IPsec tunnel ends at the LNS on the enterprise network, so the final hop to the server is unprotected, but this won't matter for most applications, because the LNS and the server are both on the enterprise network, which is presumably protected by firewalls and other means from outside interference. Notice though, that the connection is still subject to snooping or manipulation by a host inside the enterprise. If this is a concern, another VPN could be established between the LNS and the server.

05fig02.gif

Figure 5.2 An L2TP/IPsec VPN Between a Road Warrior and the Enterprise Network

Another typical application of an L2TP/IPsec VPN is shown in Figure 5.3. Here, a remote network, such as a branch office, is connected to the enterprise network through an L2TP/IPsec tunnel. We assume that a host on the remote network has a connection to a server on the enterprise network.

05fig03.gif

Figure 5.3 An L2TP/IPsec VPN Between Networks

The security situation at the enterprise network is exactly like that in Figure 5.2: The connection is unprotected from the LNS to the server. The situation at the remote network is a little more complicated. If we assume that the host is talking to the LAC over a PPP connection, we can arrange that the data between the host and LNS is encrypted by PPP. That means, of course, that the data is doubly encrypted over most of the path between the host and the server, but more important, there is limited protection for the conversation on the remote network. Thus, such a connection would be resistant to snooping by a host on the remote network.

Other configurations are possible, of course, so it is important to evaluate the security of each leg in any proposed L2TP/IPsec VPN topology. If we trust the hosts and servers on the private networks, we needn't be too concerned about the lack of security there. If we don't trust them, we must take steps to ensure that any sensitive data is protected from snooping or alteration from within the private networks.

Microsoft uses the combination of L2TP/IPsec as its VPN solution (replacing PPTP), so we can expect to see this topology frequently. Nonetheless, not everyone agrees that this is a good solution.

First, it reintroduces the NAT problem. Recall that L2TP uses UDP encapsulation rather than GRE, as PPTP does, and that the rationale for this was that it allowed L2TP to interoperate with NAT. When L2TP is combined with IPsec, the UDP header is encrypted and thus unavailable to NAT. This means that the most common NAT mode, PAT, cannot be used. Fortunately, this problem is being solved. The IETF is developing a standard for a technology, called NAT traversal (NAT-T), that allows IPsec to interoperate with NAT. The Microsoft implementation of L2TP/IPsec includes a version of NATT. We discuss NAT-T further in Chapter 14.

The other common complaint about L2TP/IPsec is that it's a solution in search of a problem. Critics complain that L2TP not only adds overhead and does not scale well, but also fails to solve any problems that IPsec alone can't solve. Microsoft and other L2TP adherents counter that L2TP enables the use of existing session authentication protocols, such as MS-CHAP, and makes use of PPP's ability to assign IP addresses and DNS servers to the remote host. [Messmer 2000] discusses the pros and cons of L2TP/IPsec deployment. Chapter 10 of [Shea 2000] has an excellent summary of L2TP security concerns and a discussion of L2TP/IPsec. RFC 3193 [Patel, Aboba, Dixon et al. 2001] discusses securing L2TP with IPsec in detail.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020