PPPEXT Working Group Baiju Patel INTERNET-DRAFT Intel Category: Standards Track Bernard Aboba Microsoft 21 November 1997 Securing L2TP using IPSEC 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as and expires June 1, 1998. Please send comments to the authors. 2. Abstract This document discusses how L2TP may utilize IPSEC to provide for tun- nel authentication, privacy protection, integrity check and replay protection. Both the voluntary and compulsory tunneling cases are dis- cussed. 3. Requirements language This specification uses the same words as [6] for defining the signif- icance of each particular requirement. These words are: MUST This word, or the adjectives "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the speci- fication. MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- nition is an absolute prohibition of the specification. Patel & Aboba [Page 1] INTERNET-DRAFT 21 November 1997 SHOULD This word, or the adjective "RECOMMENDED", means that there MAY exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT This phrase means that there MAY exist valid reasons in par- ticular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before imple- menting any behavior described with this label. MAY This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interop- erate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another imple- mentation which does not include the option.(except, of course, for the feature the option provides) Silently Discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter. An implementation is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the protocols it implements. An implementation that satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT requirements for its protocols is said to be "uncondition- ally compliant"; one that satisfies all the MUST and MUST NOT require- ments but not all the SHOULD or SHOULD NOT requirements for its proto- cols is said to be "conditionally compliant." 4. Terminology Voluntary Tunneling In voluntary tunneling, a tunnel is created by the user, typically via use of a tunneling client. As a result, the user will send L2TP packets to the NAS which will forward them on to the LNS. Note that in voluntary tunneling, the NAS does not need to support L2TP, and the LAC effectively resides on the same machine as the dial-in user. Patel & Aboba [Page 2] INTERNET-DRAFT 21 November 1997 Compulsory Tunneling In compulsory tunneling, a tunnel is created without any action from the user and without allowing the user any choice. As a result, the user will send PPP packets to the NAS/LAC, which will encapsulate them in L2TP and tunnel them to the LNS. In the compulsory tunneling case, the NAS/LAC must be L2TP capable. 5. Introduction L2TP, described in [1], is a protocol that tunnels PPP traffic over variety of networks (e.g., IP, SONET, ATM). Since the protocol encap- sulates PPP, L2TP inherits PPP authentication, as well as the PPP Encryption Control Protocol (ECP) (described in [19]), and the Com- pression Control Protocol (CCP) (described in [18]). L2TP also includes support for tunnel authentication, which can be used to mutu- ally authenticate the tunnel endpoints. However, L2TP does not define tunnel protection mechanisms. IPSEC is a protocol suite defined by IETF working group on IP security to secure communication at the network layer between communicating peers. This protocol is comprised of three primary elements: ISAKMP/Oakley, described in [11], IPSEC AH, described in [7] and IPSEC ESP, described in [9]. ISAKMP/Oakley is the key management protocol while AH and ESP are used to protect IP traffic. This draft proposes use of IPSEC protocol suite for protecting L2TP traffic over IP and Non-IP networks, and discusses how IPSEC and L2TP should be used together. This document does not attempt to standardize end-to-end security. When end-to-end security is required, it is rec- ommended that additional security mechanisms (such as IPSEC or TLS) be used inside the tunnel, in addition to L2TP tunnel security. 5.1. L2TP security requirements L2TP tunnels PPP traffic over the IP and non-IP public networks. Therefore, both the control and data packets of L2TP protocol are vul- nerable to attack. Examples of attacks include: 1. The adversary may try to discover user identities by snooping data packets. 2. The adversary may try to modify packets (both control and data). 3. The adversary may try to hijack the L2TP tunnel or the PPP connec- tion inside the tunnel. 4. An adversary can launch denial of service attacks by terminating PPP connections, or L2TP tunnels. 5. An adversary may attempt to disrupt the PPP ECP negotiation in order to weaken or remove confidentiality protection. Alternatively, Patel & Aboba [Page 3] INTERNET-DRAFT 21 November 1997 an adversary may wish to disrupt the PPP LCP authentication negotia- tion so as to weaken the PPP authentication process or gain access to user passwords. To address threats outlined above, the L2TP security protocol MUST be able to provide authentication, integrity and replay protection for control packets. In addition, it SHOULD be able to protect confiden- tiality of control packets. It MUST be able to provide integrity and replay protection of data packets, and MAY be able to protect confi- dentiality of data packets. An L2TP security protocol MUST also pro- vide a scalable approach to key management. The L2TP protocol, and PPP authentication and encryption do not meet the security requirements for L2TP. L2TP authentication typically mutually authenticates LAC to LNS at tunnel origination and may peri- odically re-authenticate. Therefore, it does not protect control and data traffic on a per packet basis. Thus, L2TP tunnel authentication leaves L2TP tunnel vulnerable to the attacks outlined above. PPP authenticates the client to the LNS, but also does not provide per- packet authentication, integrity, or replay protection. PPP encryption meets confidentiality requirements for PPP traffic but does not address authentication, integrity and key management requirements. Therefore, PPP encryption provides a weak security solution, and in addition does not assist in securing L2TP control channel. Key management facilities are not provided by the L2TP protocol. How- ever, where L2TP tunnel authentication is desired, it is necessary to distribute keys. Where manual key distribution is not feasible, a key management protocol is required. Since secure key management protocols are difficult to design, protocols designed for another purpose (such as RADIUS) MUST NOT be used for L2TP key management. Note that several of the attacks outlined above may be carried out on PPP packets sent over the link between the dial-up client and the NAS/LAC, prior to encapsulation of the packets within an L2TP tunnel. While strictly speaking these attacks are outside the scope of L2TP security, in order to protect against them, the user MUST provide for confidentiality, authentication and integrity protection for PPP pack- ets sent over the dial-up link. Authentication and integrity protec- tion are not currently supported by the PPP encryption methods out- lined in [20]-[22], and PPP ECP, outlined in [19] does not provide for a protected ciphersuite negotiation. 5.2. L2TP Security Protocol Where security is required, L2TP tunnels MUST be secured using IPSEC, both for IP and non-IP networks. IPSEC AH or ESP MUST be used to pro- vide for authentication, integrity and replay protection, and ESP MAY be used to provide for confidentiality. ISAKMP/Oakley MUST used for authentication, security association negotiation and key management. The L2TP tunnel is secured between either LAC and LNS, or between LAC and a firewall (when a firewall is present and is trusted by LAC). Patel & Aboba [Page 4] INTERNET-DRAFT 21 November 1997 Both LAC and LNS must meet L2TP security requirements. All compliant implementations MUST implement IPSEC ESP for securing control packets. Replay protection, the compulsory cipher suite for IPSEC ESP, and NULL encryption MUST be implemented. Optionally, IPSEC AH MAY also be supported. All compliant implementations MUST also implement IPSEC ESP for protection of data packets. Replay prevention and integrity protection using IPSEC ESP mandated cipher suit MUST be implemented. NULL encryption also MUST be supported. Other IPSEC ESP required ciphers MAY also be supported. ISAKMP/Oakley MUST be supported in for authentication, security asso- ciation negotiation, and key management using IPSEC DOI. 5.2.1. Implementation considerations for L2TP over Non-IP networks L2TP requires that a non-IP network supports packet transport, so that the non-IP network should be able to carry L2TP control and data pack- ets. Since ESP functions are defined on the IP payload (excluding the IP header), the presence of an IP header is not a requirement for use of ESP. Therefore, L2TP implemented on non-IP networks MUST be able to transport IPSEC ESP packets. The next payload field of the ESP header MUST be set to zero. ISAKMP/Oakley messages use UDP transport. Therefore, in order to be compliant with the ISAKMP/Oakley protocol on non-IP media, the non-IP media (which is capable of transporting packets) MUST support trans- port of UDP datagrams. Since the IP header is not present in the UDP datagram over non-IP media, the UDP checksum MUST be set to zero by the source and ignored by the destination. The exact mechanisms for enabling transport of ESP and UDP packets over non-IP media MUST be addressed in appropriate standards for L2TP over specific non-IP networks. 5.3. L2TP/IPSEC interoperability guidelines The following guidelines are established to meet L2TP security requirements using IPSEC in practical situations. Note that this sec- tion is not a requirement for an implementation to be L2TP security compliant. Its purpose to make the implementors aware of certain efficiency and security considerations. In the design of an L2TP/IPSEC interoperability guidelines, the fol- lowing goals were identified: Elimination of redundant operations If possible, it is desirable that compression/encryption only be applied at a single layer in the protocol stack. Patel & Aboba [Page 5] INTERNET-DRAFT 21 November 1997 Stateless compression and encryption For reasons described below, it is desirable that L2TP over IP utilize stateless compression and encryption. Maximal coverage Along its travel path, an L2TP packet may be handled by the dial- in user, NAS/LAC, LNS, and endstation. It is desirable that secu- rity services be applied over the largest possible portion of the travel path. 5.3.1. Elimination of duplicate encryption/compression Given that L2TP over IP consists of an results IP packet encapsulated in PPP encapsulated in L2TP encapsulated in IP running over a link layer, many opportunities exist for duplication of encryption and com- pression services. In general such duplication is undesirable since it is ineffective and wastes CPU cycles. However, avoiding such duplica- tion is not a simple task, since it may require communication between non-adjacent layers of the protocol stack, as well as ensuring that IP and link layers be capable of turning off/on compression/encryption services on a per-packet basis. Current PPP compression/encryption implementations are not capable of doing this, and achieving this in IPSEC may require negotiation of two security associations, with mul- tiplexing of packets between them. As noted in [16], elimination of duplicate compression/encryption may require changes to wire protocols and/or sockets APIs. 5.3.2. Stateless compression and encryption Stateless encryption and/or compression is highly desirable when L2TP is run over IP. Thus IPSEC encryption and IP compression (stateless) are to be preferred over PPP encryption/compression (stateful) wher- ever possible. Since L2TP is a connection-oriented protocol, use of stateful compression/encryption is feasible, but when run over IP, this is not desirable. While providing better compression, and some- what more secure encryption, when used without an underlying reliable delivery mechanism stateful methods magnify packet losses, and thus are problematic when used over the Internet where packet loss can be significant. In addition, although L2TP is connection oriented, the L2TP specification does not mandate packet ordering, which can create difficulties in implementation of stateful compression/encryption schemes. However, these considerations are not as important when L2TP is run over non-IP media such as ATM, X.25, or Frame Relay, since these media guarantee ordering, and packet losses are typically low. 5.3.3. Maximal coverage If it is desired to apply security services when communicating between a client and an endstation, then maximal coverage can be achieved by having security services negotiated at the application layer. However, Patel & Aboba [Page 6] INTERNET-DRAFT 21 November 1997 in practice the problem is not so simple since the absence of applica- tion-layer security does not necessarily imply that security is unde- sirable at lower layers. Similarly, where there are multiple parties involved in processing of packets (as there are in compulsory and vol- untary tunneling scenarios), the negotiation of security services can become quite complex since the parties may have different objectives and may not trust each other. The problem is also complicated by the presence of legacy hosts. As a result, it may be difficult to achieve maximal coverage without some degree of duplication in encryption/compression services, unless per-packet turn off/on can be achieved. 5.4. L2TP/IPSEC Interoperability scenarios In the scenarios that follow, it is assumed that both L2TP clients and servers are able to set and get the properties of IPSEC security asso- ciations, as well as to influence the IPSEC security services negoti- ated. Furthermore, it is assumed that L2TP clients and servers are able to influence the negotiation process for PPP encryption and com- pression. These and other API-related questions are addressed in [31]. 5.4.1. Scenario 1: Compulsory tunnel In the case of a compulsory tunnel, the dial-in user will be sending PPP packets to the LAC, and will typically not be aware that its pack- ets are being tunneled. From the LNS's point of view, it will note a PPP packet encapsulated in L2TP, which is itself encapsulated in an IP frame. Assuming that the LNS is able to retrieve the properties of the Security Association set up between itself and the LAC, it will have knowledge of the security services in place between the LAC and itself. Thus in the compulsory tunneling case, there is asymmetric knowledge between the dial-in user and the LNS. Since the LNS is capable of knowing whether confidentiality, authenti- cation, integrity and replay protection is in place between the LAC and itself, it is able to use this knowledge to modify the PPP ECP and CCP negotiation. If IPSEC confidentiality is in place, the LNS may behave as though a "Require Encryption" directive had been fulfilled, and will not mandate use of PPP encryption or compression. Note how- ever that the LNS should not insist that PPP encryption/compression be turned off, instead leaving this decision to the dial-in user. Since the dial-in user has no knowledge of the security services in place between the LAC and the LNS, and since it does not necessarily trust the LAC or the wire between itself and the LAC, it SHOULD either rely on end-to-end IPSEC or should request that PPP encryption/com- pression be negotiated. This behavior would not even be modified if it had knowledge of the security services in place between the LAC and the LNS, since the dial-in user needs to negotiate confidentiality services in order to provide privacy on the portion of the path between itself and the LAC, and between the LNS and the endstation. Patel & Aboba [Page 7] INTERNET-DRAFT 21 November 1997 Given that the dial-in user will typically not trust the LAC and will negotiate confidentiality and compression services on its own, the LAC MAY only negotiate IPSEC AH (authentication + integrity check) with the LNS, and the LNS will request replay protection. This will ensure that confidentiality and compression services will not be duplicated over the path between the LAC and the LNS. It also will typically result in better scalability for the LAC, since encryption will be handled by the dial-in user and the LNS. The dial-in user can satisfy its desire for confidentiality services in one of two ways. If it knows that all endstations that it will com- municate with are IPSEC-capable (or if it refuses to talk to non-IPSEC capable endstations), then it can refuse to negotiate PPP encryp- tion/compression and negotiate IPSEC ESP with the endstations instead. If the client does not know that all endstations it will contact are IPSEC capable (the most likely case), then it will negotiate PPP encryption/compression. This may result in duplicate compres- sion/encryption which can only be eliminated if PPP compres- sion/encryption can be turned off on a per-packet basis. 5.4.1.1. Scenario 1a: Endstation not IPSEC capable In the case that the client is communicating with a non-IPSEC capable endstation, the protocol stack will appear as follows: Dial-in User LAC LNS End Station <--------------------------IP-------------------------> <-----------PPP Enc + Comp------------> <-------L2TP--------> <----IPSEC AH-------> 5.4.1.2. Scenario 1b: All Endstations IPSEC capable In the case where the client only communicates with IPSEC-capable end- stations, Dial-in User LAC LNS End Station <----------------------IPSEC ESP----------------------> <------------------PPP----------------> <-------L2TP--------> <----IPSEC AH-------> 5.4.1.3. Scenario 1c: Some endstations IPSEC-capable, some not, no duplication In the case where the client communicates with a mixture of IPSEC- capable and non-capable endstations, and it is desired to eliminate duplicate compression/encryption, it is necessary to allow PPP Encryp- tion and Compression to be turned off on a per-packet basis. In this case, scenario 1c degenerates to scenario 1b when the endstation is IPSEC-capable, and scenario 1a when it is not. Dial-in User LAC LNS End Station Patel & Aboba [Page 8] INTERNET-DRAFT 21 November 1997 <--------------IP (1) or IPSEC ESP (2)----------------> <-----PPP Enc + Comp (1) or PPP (2)---> <-------L2TP--------> <----IPSEC AH-------> 5.4.2. Scenario 2: Voluntary tunnel In the case of a voluntary tunnel, the dial-in user will be sending L2TP packets to the NAS, which will route them to the LNS. Note that over a dialup link, these L2TP packets will be encapsulated in IP and PPP. Assuming that it is possible for the dial-in user to retrieve the properties of the Security Association between itself and the LNS, the dial-in user will have knowledge of any security services negoti- ated between itself and the LNS. It will also have knowledge of PPP encryption/compression services negotiated between itself and the NAS. From the LNS's point of view, it will note a PPP packet encapsulated in L2TP, which is itself encapsulated in an IP frame. This situation is identical to that given in scenario 1. Assuming that the LNS is able to retrieve the properties of the Security Association set up between itself and the dial-in user, it will have knowledge of the security services in place between the dial-in user and itself. Thus in the voluntary tunneling case, the dial-in user and the LNS have symmetric knowledge. Since the LNS is capable of knowing whether confidentiality, authenti- cation, integrity check or replay protection is in place between the dial-in user and itself, it is able to use this knowledge to modify its PPP ECP and CCP negotiation stance. If IPSEC confidentiality is in place, the LNS will behave as though a "Require Encryption" directive had been fulfilled, and will not mandate use of PPP encryption or com- pression. Note however that the LNS will not insist that PPP encryp- tion/compression be turned off, instead leaving this decision to the dial-in user. Since the dial-in user has knowledge of the security services in place between itself and the LNS, it will act as though a "Require Encryp- tion" directive had been fulfilled if IPSEC ESP was already in place between itself and the LNS. Thus, it will request that PPP encryption and compression not be negotiated. Note that turning off PPP compres- sion should occur even if IP Compression services could not be negoti- ated, due to the undesirable effects of PPP stateful compression. In this case, we recommend that the dial-in user and LNS negotiate IPSEC Confidentiality, Authentication, and Integrity protection ser- vices, as well as IP Compression if available, and that the LNS request replay protection. PPP encryption and compression should not be negotiated between the dial-in user and the LNS. Note that this may result in duplicate encryption if the dial-in user is communicating with an IPSEC-capable endstation. In order to avoid duplicate encryption/compression, the dial-in user may negotiate two Security Associations with the LNS, one with AH, and one with Patel & Aboba [Page 9] INTERNET-DRAFT 21 November 1997 confidentiality/compression. Packets going to an IPSEC-capable endsta- tion would run over the AH security association, and packets to a non- IPSEC capable endstation would run over the other security associa- tion. Note that many IPSEC implementations cannot support this without allowing L2TP packets on the same tunnel to be originated from multi- ple UDP ports. This will require modification of the L2TP specifica- tion. Also note that the dial-in user may wish to put confidentiality ser- vices in place for non-tunneled packets travelling between itself and the NAS. This will protect the dial-in user against eavesdropping on the wire between itself and the NAS. As a result, it may wish to nego- tiate PPP encryption and compression with the NAS. As in scenario 1, this will result in duplicate encryption and possibly compression unless PPP compression/encryption can be turned off on a per-packet basis. In the figures below, this possible use of PPP encryption/com- pression is not shown since it is desirable that it be turned off when transporting L2TP packets that have already been compressed/encrypted. 5.4.2.1. Scenario 2a: Endstation not IPSEC capable In the case that the dial-in user is communicating with non-IPSEC capable endstations, it will wish to negotiate IPSEC ESP with the LNS. This will provide confidentiality, authentication, and integrity ser- vices between the dial-in user and LNS. Dial-in User NAS LNS End Station <--------------------------IP-------------------------> <----------------PPP------------------> <---------------L2TP------------------> <------------IPSEC ESP----------------> <--------PPP------> 5.4.2.2. Scenario 2b: All Endstations IPSEC capable In the case where the dial-in user only communicates with IPSEC-capa- ble endstations, the dial-in user may wish to only require IPSEC AH between itself and the LNS. Note that negotiating IPSEC AH between the dial-in user and LNS is only possible if the LNS does not require ESP. Dial-in User NAS LNS End Station <----------------------IPSEC ESP----------------------> <----------------PPP------------------> <---------------L2TP------------------> <------------IPSEC AH-----------------> <--------PPP------> 5.4.2.3. Scenario 2c: Some endstations IPSEC-capable In the case where the dial-in user communicates with a mixture of IPSEC-capable and non-capable endstations, duplicate encryption is possible. This can be avoided if packets are multiplexed over two Security Associations, one with AH, and the other with ESP. This would Patel & Aboba [Page 10] INTERNET-DRAFT 21 November 1997 allow encryption to be turned off on a per-packet basis. In this case, scenario 2c would revert to scenario 2a when the endstation is not IPSEC-capable, and to scenario 2b when it is IPSEC-capable. Again, note that negotiating IPSEC AH between the dial-in user and LNS is only possible if the tunnel server does not require ESP. Dial-in User NAS LNS End Station <----------------IP (1) or IPSEC ESP (2)--------------> <----------------PPP------------------> <---------------L2TP------------------> <------IPSEC ESP (1) or AH (2)--------> <--------PPP------> 6. Security considerations This draft defines a security protocol. 7. Acknowledgements Thanks to Gurdeep Singh Pall, David Eitelbach, William Dixon, Peter Ford, and Sanjay Anand of Microsoft, John Richardson of Intel and Rob Adams of Cisco for many useful discussions of this problem space. 8. References [1] K. Hamzeh, A. Rubens, T. Kolar, M. Littlewood, B. Palter, A. Valencia, G. S. Pall, J. Taarud, W. M. Townsley, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." Internet draft (work in progress), draft-ietf-pppext-l2tp-07.txt, Ascend Communications, Cisco Systems, Microsoft, Copper Mountain Networks, IBM, 3Com, October 1997. [2] P. R. Calhoun, W. M. Townsley. "Layer Two Tunneling Protocol "L2TP" Security Extensions for Non-IP Networks." Internet draft (work in progress), draft-ietf-pppext-l2tp-sec-02.txt, 3Com, IBM, October 1997. [3] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little. "Point-to-Point Tunneling Protocol -- PPTP." Internet draft (work in progress), draft-ietf-pppext-pptp-02.txt, Ascend Communications, Microsoft, Copper Mountain Networks, U.S. Robotics, July 1997. [4] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." Inter- net draft (work in progress), draft-ietf-radius-tunnel-auth-02.txt, Microsoft, July 1997. [5] B. Aboba, G. Zorn. "Implementation of PPTP/L2TP Compulsory Tun- neling via RADIUS." Internet draft (work in progress), draft-ietf- radius-tunnel-imp-03.txt, Microsoft, July 1997. [6] S. Bradner. "Key words for use in RFCs to Indicate Requirement Patel & Aboba [Page 11] INTERNET-DRAFT 21 November 1997 Levels." RFC 2119, Harvard University, March 1997. [7] S. Kent, R. Atkinson. "IP Authentication Header." Internet draft (work in progress), draft-ietf-ipsec-auth-header-02.txt, BBN Corp, @Home Network, October 1997. [8] R. Thayer, N. Doraswamy, R. Glen. "IP Security Document Roadmap." Internet draft (work in progress), draft-ietf-ipsec-doc- roadmap-01.txt, Sable, Bay Networks, NIST, July 1997. [9] S. Kent, R. Atkinson. "IP Encapsulating Security Payload (ESP)." Internet draft (work in progress), draft-ietf-ipsec-esp-v2-01.txt, BBN Corp, @Home Network, October 1997. [10] D. Piper. "The Internet IP Security Domain of Interpretation of ISAKMP." Internet draft (work in progress), draft-ietf-ipsec-ipsec- doi-05.txt, Cisco Systems, October 1997. [11] D. Maughan, M. Schertler, M. Schneider, J. Turner. "Internet Security Association and Key Management Protocol (ISAKMP)." Internet draft (work in progress), draft-ietf-ipsec-isakmp-08.txt, NSA, Terisa Systems, July 1997. [12] D. Harkins, D. Carrel. "The resolution of ISAKMP with Oakley." Internet draft (work in progress), draft-ietf-ipsec-isakmp-oak- ley-04.txt, Cisco Systems, July 1997. [13] N. Doraswamy. "Implementation of Virtual Private Networks (VPNs) with IP Security." Internet draft (work in progress), draft-ietf- ipsec-vpn-00.txt, FTP Software, March 1997. [14] R. Moskowitz. "Network Address Translation issues with IPsec." Internet draft (work in progress), draft-moskowitz-ipsec-vpn- nat-00.txt, Chrysler, August 1997. [15] H. K. Orman. "The OAKLEY Key Determination Protocol." Internet draft (work in progress), draft-ietf-ipsec-oakley-02.txt, University of Arizona, August 1997. [16] R. Monsour, M. Sabin, A. Shacham, S. Anand, R. Thayer. "Compres- sion in IP Security." Internet draft (work in progress), draft-mon- sour-compr-ipsec-00.txt, Hi/fn Inc.,Cisco, Microsoft, Sable Technol- ogy, March 1997. [17] W. Simpson. "The Point-to-Point Protocol (PPP)". RFC 1661, Day- dreamer, July 1994. [18] D. Rand. "The PPP Compression Control Protocol (CCP)". RFC 1962, Novell, June 1996. [19] G. Meyer. "The PPP Encryption Control Protocol (ECP)". RFC 1968, Spider Systems, June 1996. [20] K. Sklower, G. Meyer. "The PPP DES Encryption Protocol (DESE)". Patel & Aboba [Page 12] INTERNET-DRAFT 21 November 1997 RFC 1969, UCB, Spider Systems, June 1996. [21] K. Sklower, G. Meyer. "The PPP DES Encryption Protocol, Version 2 (DESE-bis)". Internet draft (work in progress), draft-ietf-pppext- des-encrypt-v2-00.txt, UCB, Shiva, July 1997. [22] H. Kummert. "The PPP Triple-DES Encryption Protocol (3DESE)". Internet draft (work in progress), draft-ietf-pppext-3des- encrypt-00.txt, Nentec GmbH, July 1997. [23] R. Friend. "PPP Stac LZS Compression Protocol". Internet draft (work in progress), RFC 1974, Stac Electronics, DayDreamer, August 1996. [24] R. Friend. "PPP Stac LZS Compression Protocol". RFC 1974, Stac Electronics, DayDreamer, August 1996. [25] D. Schremp, J. Black, J. Weiss. "PPP Magnalink Variable Resource Compression". RFC 1975, Magnalink, August 1996. [26] K. Schneider, S. Venters. "PPP for Data Compression in Data Cir- cuit-Terminating Equipment (DCE)". RFC 1976, ADTRAN, Inc., August 1996. [27] V. Schryver. "PPP BSD Compression Protocol". RFC 1977, SGI, August 1996. [28] D. Rand. "PPP Predictor Compression Protocol". RFC 1978, Novell, August 1996. [29] J. Woods. "PPP Deflate Protocol". RFC 1979, Proteon, Inc., August 1996. [30] G. Pall. "Microsoft Point-to-Point Compression (MPPC) Protocol". RFC 2118, Microsoft, March 1997. [31] D. L. McDonald. "A Simple IP Security API Extension to BSD Sock- ets". Internet draft (work in progress), draft-mcdonald-simple-ipsec- api-01.txt, Sun Microsystems, March 1997. 9. Authors' Addresses Baiju V. Patel Intel Corp 2511 NE 25th Ave Hillsboro, OR 97124 Phone: 503-264-2422 Email: baiju@mailbox.jf.intel.com Bernard Aboba Microsoft Corporation One Microsoft Way Patel & Aboba [Page 13] INTERNET-DRAFT 21 November 1997 Redmond, WA 98052 Phone: 425-936-6605 EMail: bernarda@microsoft.com Patel & Aboba [Page 14]