RFC 2888
Secure Remote Access with L2TP
RFC 2888: Secure Remote Access with L2TP 🎀
Okay bestie, here's the whole vibe check 💅
- Network Working Group: the group this one came from 🌸
- Request for Comments: 2888
- Author: P. Srisuresh, Campio Communications ✨
- Category: Informational (it's sharing info, not setting a standard) 📚
- Date: August 2000 🗓️
- Obsoletes or updates: none listed in the title block 🙅♀️
Status of this Memo 📜
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🦋
Okay so, L2TP is basically a virtual extension of PPP that runs across IP networks 🌐 It makes it possible for an access concentrator (LAC) to sit near the remote clients, while the PPP termination server (LNS) lives on the enterprise's premises 🏢 That setup lets an enterprise keep control of its RADIUS database, which is what handles Authentication, Authorization and Accountability (AAA) for dial-in users 🔐
The goal here is to bring IPsec's security to remote access users who dial in through the Internet 💜 And the best part? It does this without inventing any new protocols, just using the existing practices of Remote Access and IPsec 🙌 Specifically, the document proposes three new RADIUS parameters so the LNS, acting as a Secure Remote Access Server (SRAS), can mandate network level security between remote clients and the enterprise 🔥 It also talks through the limitations of the approach, because honesty is iconic 💅
1. Introduction and Overview ✨
Now-a-days, it's super common for employees to dial in to their enterprise over the PSTN (Public Switched Telephone Network) and get their day-to-day work done as if they were sitting in the office 💻 That includes people dialing in from home, and road warriors who literally can't be at the corporate premises 🧳 Since the Internet is everywhere now, dialing in through it is so appealing, because you save on phone charges and keep the dedicated voice lines from getting clogged with data traffic 📞🚫
This document suggests an approach that could make remote access over the Internet a reality 🌈 The approach is built on well-known techniques and protocols that are already in place. Remote Access extensions based on L2TP, combined with the security offered by IPSec, can make remote access over the Internet happen. And it doesn't require inventing new protocol(s) 🙌
The trust model in this document is looked at mainly from the enterprise's point of view, the place remote access clients dial in to 🏰 A remote access client may or may not want to enforce end-to-end IPsec from their end to the enterprise, and that's their call 🫶 But it's in the enterprise's interest to mandate security for every packet it accepts from the Internet into the enterprise 🔒 And separately, remote users can also pursue end-to-end IPsec if they want, on top of the security requirement the enterprise edge device imposes 💖
Section 2 covers the terminology used throughout the document, plus the limited scope in which some of those terms are used here 🧠 Section 3 gives a quick description of what counts as remote access 📡 Section 4 describes what counts as network security from the enterprise perspective 🛡️ Section 5 describes the secure remote access model as a viable solution for enterprises 🌸 The solution in section 5 has some limitations, and those are listed in section 6 🥲 Section 7 is all about the new RADIUS attributes that can be configured to turn a NAS device into a Secure Remote Access Server 🧚
2. Terminology and scope 🧠
Definitions of the terms used in this document can be found in one of these: (a) the L2TP Protocol document [Ref 1], (b) the IP security Architecture document [Ref 5], or (c) the Internet Key Exchange (IKE) document [Ref 8] 📚
Heads up, the terms Network Access Server (NAS) and Remote Access Server (RAS) are used interchangeably throughout the document 🔄 PPP can carry a variety of network layer packets, but the focus of this document is limited to carrying IP datagrams only 🎯
"Secure Remote Access Server" (SRAS), as defined in this document, refers to a NAS that supports tunnel-mode IPsec with its remote clients 🔐 Specifically, the NAS being referred to is the LNS. Also, involuntary tunneling is assumed for L2TP tunnel setup, meaning the remote clients initiating the PPP session and the LAC that tunnels those PPP sessions are presumed to be distinct physical entities 👯♀️
Lastly, there are a bunch of transport mediums that can tunnel PPP packets between a LAC and an LNS. Examples include a Frame Relay or ATM cloud, and IP network infrastructure 🌥️ For simplicity, this document assumes a public IP infrastructure as the medium for transporting PPP packets between LAC and LNS 🌍 Security of IP packets (embedded within PPP) in a trusted private transport medium is less of a concern for the purposes of this document 🤷♀️
3. Remote Access operation 🛰️
Okay, remote access is way more than just authenticating remote clients at a Network Access Server (NAS) 👀 Authentication, Authorization, Accounting and routing are all integral to it. A client must pass the authentication test before it gets granted link access to the network 🚪 Network level services (like IP) are granted based on the authorization characteristics specified for the user in RADIUS 📋 Network Access Servers use RADIUS to scale for large numbers of users, and the NAS also monitors the link status of the remote access clients 📶
There are a variety of techniques for connecting remote access users to their enterprise and the Internet 🔌 At the link level, access techniques include ISDN digital lines, analog plain-old-telephone-service lines, xDSL lines, cable and wireless, to name a few 📱 PPP is the most common Layer-2 (L2) protocol used for carrying network layer packets over these remote access links 💅 It can carry a variety of network layer datagrams, including IP, IPX and AppleTalk, but the focus of this document is limited to IP datagrams only 🎀
L2TP is a logical extension of PPP over an IP infrastructure 🧩 A LAC terminates the Layer 2 links, and the LNS provides the logical termination of PPP 🔚 That makes the LNS the focal point for (a) performing the AAA operations for remote users, (b) assigning IP addresses and monitoring the logical link status (meaning the status of the LAC-to-LNS tunnel and the link between the remote user and the LAC), and (c) maintaining a host-route to the remote user network and providing the routing infrastructure into the enterprise 🏰✨
L2TP uses control messages to establish, terminate and monitor the status of the logical PPP sessions (from remote user to LNS) 🎛️ These are independent of the data messages 🙅♀️ L2TP data messages contain an L2TP header, followed by PPP packets. The L2TP header identifies the PPP session (among other things) that a PPP packet belongs to 🪪 The IP packets exchanged from and to the remote user are carried within those PPP packets 📦 Here's how the L2TP data messages carrying end-to-end IP packets over an IP transport medium look. For the exact details of the L2TP protocol, check out [Ref 1] 👀
+----------------------+
| IP Header |
| (LAC <->LNS) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (Remote User<->LNS) |
+----------------------+
| End-to-end IP packet |
| (to/from Remote User)|
+----------------------+4. Requirements of an enterprise Security Gateway ✨
okay so bestie, enterprises are obsessed with the internet rn 💻 it's a huge source of info and a way to share stuff with the whole outside world 🌍 but ngl they also know that getting connected can seriously jeopardize the internal network 😭
so most enterprises restrict access to a pre-defined set of resources for external users 💅 usually they set up a firewall to lock down internal resources and park externally accessible servers in the DeMilitarized Zone (DMZ), sitting in front of the firewall, like in Figure 1 🏰
----------------
( )
( )
( Internet )
( )
(_______________ )
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
---------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server |
|
------------------
( )
( Internal Network )
( (private to the )
( enterprise) )
(_________________ )
Figure 1: Security model of an Enterprise using FirewallNetwork Access Servers that handle direct dial-in access (through the PSTN) for employees get tucked inside the private enterprise network 📞 so they dodge the access restrictions a firewall would put on them 🙃
with that model, private resources of an enterprise are locked out from the Internet 🔒 a firewall may be set up to let a certain resource or service through now and then, but it is not recommended on an operational basis, since that could be a security threat to the enterprise 🚨 and here's the tea: even when the firewall is set to allow access to internal resources from pre-defined external node(s), a lot of internal servers, like NFS, enforce address based authentication and won't cooperate when the IP address of the external node is not in the corporate IP address domain 💀 so basically, with this security model it becomes super difficult to let employees reach corporate resources over the Internet, even if you're willing to forgo security over the Internet 😭
now enter IPsec 🦋 with IPsec it's possible to secure corporate data across the Internet by using a Security Gateway inside the enterprise ✨ the firewall may be configured to allow IKE and IPsec packets directed to a specific Security Gateway behind the firewall 🎀 then it becomes the Security Gateway's job to employ the right access list for external connections trying to get into the enterprise 👑 essentially, the access control functionality for IPsec secure packets gets shifted to the Security Gateway, while the access control for clear packets stays with the firewall 🧚 the following figure shows the model where a combination of Firewall and Security Gateway controls access to internal resources 💖
------------
( )
( )
( Internet )
( )
(___________ )
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
------------------------------------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server etc. | LAN
|
------------------------------------
| |
+----------+ +------------------+
| LNS | | Security Gateway |
| Server | | (SGW) |
+----------+ +------------------+
|
------------------
( )
( Internal Network )
( (Private to the )
( enterprise) )
(_________________ )
Figure 2: Security Model based on Firewall and Security Gatewayso for employee dial-in over the Internet 🏠 an LNS may be placed behind a firewall, and the firewall may be configured to allow UDP access to the LNS from the Internet 🌐 the tricky part is that it may not be possible to know all the IP addresses of the LACs located on the Internet at configuration time 🤔 that's why UDP access has to be allowed from any node on the Internet 😬 the LNS may be configured to process only the L2TP packets and drop any UDP packets that are not L2TP 🗑️
this setup does allow remote access over the Internet ✅ but it's giving very vulnerable 😭 it's super easy for someone on the Internet to steal a remote access session and get into precious enterprise resources 💀 so it's important that all packets are protected with IPsec to a security Gateway (SGW) behind the LNS, so the Security Gateway won't let IP packets into the corporate network unless it can authenticate them 🛡️🫶
the trust model of secure remote access assumes the enterprise and the end user are trusted domains 👑 everything in between is not trusted 🙅♀️ any examination of the end-to-end packets by the nodes enroute would break this trust model 🚫 from this perspective, even the LAC node enroute must not be trusted with the end-to-end IP packets 🙈 so the location and operation of the LAC is not relevant for the security discussion 💅 but the location and operation of the LNS and the Security Gateway (SGW) are precisely the basis for the discussion 🍓
having security processing done on an independent Security gateway comes with some shortcomings 🥺
- given the trust model for remote access, the SGW must be configured with a set of security profiles, access control lists and IKE authentication parameters for each user 😩 this mandates an independent provisioning of security parameters on a per-user basis 📋 it may not be able to take advantage of the user-centric provisioning on RADIUS, which the LNS node uses 🙃
- unlike the LNS, the SGW may not be in the routing path of remote access packets 👀 I.e., there is no guarantee that the egress IP packets will go through the chain of SGW and LNS before they are delivered to the remote user 🫠 as a result, packets may be subject to IPSec in one direction, but not in the other 🚨 this can be a significant threat to the remote access trust model 💀
- lastly, the SGW node has no way to know when a remote user node(s) simply died or the LAC-LNS tunnel failed 👻 being unable to delete the SAs for users that no longer exist could drain the resources of the SGW 🪫 and the LNS can't even tell the SGW that the user is going away, because the SGW maintains its peer nodes based on IKE user ID, which could be different from the user IDs the LNS node uses 🥲
5. Secure Remote Access ✨
okay so combining the IPsec Security Gateway and the LNS into one single box is lowkey the move for secure remote access 🎀 bestie, remote access clients get ONE node that does both jobs: (a) it's the PPP termination point doing the NAS service, and (b) it's the Security Gateway into the enterprise. we're calling this node the "Secure Remote Access Server" (SRAS) 💅
the SRAS gets so much main character energy from having the PPP session endpoint and the IPsec tunnel endpoint in the same place 👑 L2TP's PPP session monitoring basically means you can monitor the IPsec tunnels too 🫶 and Radius-based user authorization can configure the security stuff for each IPsec tunnel. that includes access control filters and security preferences specific to each user 🦋 it can even extend to setting IKE authentication and other negotiation parameters, when automated key exchange is solicited. the security attributes that can be defined in Radius get the full breakdown in section 7 🧚 and honestly? centralized provisioning and the scalability of Radius make setting up IPsec so much easier 😭
now for the remote access part, the benefit is IPsec security that matches the trust model enterprises want for their end-to-end IP packets crossing the Internet 🌸 if there's no fear of external eaves-dropping and you just need to authenticate packet data (including where it came from), you can use AH 🍓 if you don't trust the network at all and you don't want anyone eaves-dropping on corporate activities, you can use ESP (including ESP-authentication) 🔥
the SRAS only works if the firewall is set up to permit UDP traffic into the SRAS node 🧱 then the SRAS processes just the L2TP packets and drops everything else 💀 it also requires all IP packets embedded within PPP to be AH or ESP packets that are directed to itself 🔒 on top of that, it permits IKE UDP packets (with source and destination ports both set to 500) directed to itself, so it can do IKE negotiation and generate IPsec keys dynamically 🗝️ every other IP packet embedded within PPP gets dropped 🚫 this is how the enterprise security policy gets enforced: only the secure remote access packets are allowed into the enterprise ✨
when a PPP session drops, the IPsec and ISAKMP SAs tied to that remote access user get dropped from the SRAS too 🧹 and all the shortcomings from the last section (the LNS and SGW on two separate systems) just disappear with the Secure Remote Access Server 🙌 here's Figure 3, which shows what a typical enterprise with remote access users using an SRAS looks like 🗺️
------------
Remote Access +-------------+ ( )
+--+______ Link | Local Access| ( )
|__| /___________| Concentrator|----( Internet )
/____\ | (LAC) | ( )
RA-Host +-------------+ (____________)
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
------------------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server etc. | LAN
|
------------------------------------
|
+---------------+
| Secure Remote |
| Access Server |
| (SRAS) |
+---------------+
|
---------------------
( )
+--+ ( Internal Network )
|__|------( (Private to the )
/____\ ( enterprise) )
Ent-Host (______________________)
Figure 3: Secure Remote Access Server operation in an Enterpriseokay now let's look at the data flow 👀 this shows what happens as end-to-end IP packets travel across the Internet and through the SRAS 🦋 it's an example of IP packet tunneling and IPsec transformation as packets get exchanged between a remote access host (RA-Host) and a host inside the enterprise (say, Ent-Host) 💖
quick heads up: the IP packets coming from or going to RA-Host are shown inside PPP encapsulation, while everything else is just shown as plain IP packets 🎀 this is so we can clearly see the PPP packets encapsulated in the L2TP tunnel 🧚 the PPP headers are labelled by their logical source and destination in parentheses, but the source and recipient info isn't actually part of the PPP header, it's just labelled for clarity 🙈 for the L2TP tunnel, the L2TP header carries the PPP session ID, which indirectly identifies the PPP endpoints to the LAC and the LNS 🫶 and lastly, the IPsec Headers section includes the tunneling overhead and the AH/ESP headers attached to the tunnel 🔥
RA-Host to Ent-Host Packet traversal:
RA-Host LAC SRAS Ent-Host
=====================================================================
+----------------------+
| PPP Header |
| (RA-Host ->SRAS) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(RA-Host->SRAS)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+
| IP Header |
| (LAC->SRAS) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (RA-Host ->SRAS) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(RA-Host->SRAS)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+
| End-to-end IP packet |
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->Ent-Host to RA-Host Packet traversal:
Ent-Host SRAS LAC RA-Host
=====================================================================
+----------------------+
| End-to-end IP packet |
| (Ent-Host->Ra-Host) |
+----------------------+
---------------------->
+----------------------+
| IP Header |
| (SRAS->LAC) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (SRAS->RA-Host) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(SRAS->RA-Host)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (Ent-Host->RA-Host) |
+----------------------+
---------------------->
+----------------------+
| PPP Header |
| (SRAS->RA-Host) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(SRAS->RA-Host)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (Ent-Host->RA-Host) |
+----------------------+
---------------------->6. Limitations to Secure Remote Access using L2TP ✨
okay so SRAS is iconic, but it's not perfect 💅 here's the list of limitations, bestie 🫶
- Tunneling overhead 🐢: there's a LOT of tunneling overhead on the end-to-end IP packet. Arguably there's overlap of info between the tunneling headers, which is kinda messy ngl. This overhead will undercut packet throughput.
The overhead is especially visible at the LAC and SRAS nodes. The SRAS has extra computational overhead from IPsec processing on every IP packet exchanged with remote users, and that can be a major bottleneck for how well SRAS scales to large numbers of remote users 😩
- Fragmentation and reassembly 💥: large IP packets may need fragmentation and reassembly at the LAC or the LNS because of the multiple tunnel overhead tagged onto the packet. Fragmentation and reassembly can absolutely wreck packet throughput and latency 😭 However, it is possible to avoid that overhead by reducing the MTU permitted within PPP frames.
- Multiple identity and authentication requirement 🔐: remote access users are required to authenticate themselves to the SRAS in order to get access to the link. Further, when they need IKE to automate IPsec key exchange, they'll have to authenticate once again, with the same or a different ID and a distinct authentication approach. The authentication requirements of IKE phase 1 [Ref 8] and LCP [Ref 3] are different.
However, it is possible to have a single authentication approach (i.e., a single ID and authentication mechanism) that can be shared between LCP and IKE phase 1. The Extended Authentication Protocol (EAP) [Ref 4] may be used as the base to transport the IKE authentication mechanism into PPP. Note, the configuration overhead is not a drag on the functionality per se 🧚
- Weak security of link level authentication 🕵️: as LCP packets traverse the Internet, the identity of the remote user and the password (if a password is used) are sent in the clear. That makes them a target for someone on the net to steal the info and masquerade as the remote user. Note, however, this type of password stealing will not jeopardize the security of the enterprise per se, but it could result in denial of service to remote users. An intruder can collect the password data and simply steal the link, but won't be able to run any IP applications afterwards, because the SRAS will fail non-IPsec packet data.
A better approach would be to employ EAP [Ref 4] and select an authentication technique that is not prone to being stolen over the Internet. Alternatively, the LAC and the SRAS may be independently configured to use IPsec to secure all LCP traffic exchanged between themselves 🔒
7. Configuring RADIUS to support Secure Remote Access 🎀
okay this part is giving database energy 🗄️ enterprises use a centralized RADIUS database to keep track of the authentication and authorization requirements of their dial-in users. It's also believed that direct dial-in access (e.g., through the PSTN network) is safe and trusted and doesn't need any scrutiny beyond the link level authentication enforced in LCP. This belief is definitely not shared with dial-in access through the Internet 🙈
So, while the same RADIUS database may be used for a user dialing in directly or dialing in through the Internet, the security requirements may vary. The following RADIUS attributes may be used to mandate IPsec for users dialing in through the Internet. The exact values for the attributes and their values may be obtained from IANA (refer Section 10) 🦋
7.1. Security mandate based on access method
A new RADIUS attribute IPSEC_MANDATE (91) may be defined for each user. This attribute may be given one of the following values:
NONE (=0) No IPsec mandated on the IP packets
embedded within PPP.
LNS_AS_SRAS (=1) Mandates Tunnel mode IPsec on the IP
packets embedded within PPP, only so
long as the PPP session terminates
at an LNS. LNS would be the tunnel
mode IPsec end point.
SRAS (=2) Mandates Tunnel mode IPsec on the IP
packets embedded within PPP,
irrespective of the NAS type the PPP
terminates in. I.e., the IPsec mandate
is not specific to LNS alone, and is
applicable to any NAS, terminating
PPP. NAS would be the tunnel mode
IPsec end point.When IPSEC_MANDATE is set to one of LNS_AS_SRAS or SRAS, that directs the NAS to drop any IP packets in PPP that are not associated with an AH or ESP protocol 🚫 As an exception, the NAS will keep processing IKE packets (UDP packets, with source and destination port set to 500) coming from remote users. Further, the security profile parameter, defined in the following section, may add additional criteria for which security is not mandatory.
7.2. Security profile for the user
A new SECURITY_PROFILE (92) parameter may be defined in RADIUS to describe the security access requirements for users 📋 The profile could contain info such as the access control security filters, security preferences, and the nature of keys (manual, or automatically generated via the IKE protocol) used for security purposes.
The SECURITY-PROFILE attribute can be assigned a filename, as a string of characters. The contents of the file could be vendor specific. But the contents should include (a) a prioritized list of access control security policies, and (b) Security Association security preferences associated with each security policy 💜
7.3. IKE negotiation profile for the user
If the security profile of a user requires dynamic generation of security keys, the parameters necessary for IKE negotiation may be configured separately using a new IKE_NEGOTIATION_PROFILE (93) parameter in RADIUS. The IKE-NEGOTIATION_PROFILE attribute may be assigned a filename, as a string of characters. The contents of the file could, however, be vendor specific. The contents would typically include (a) the IKE ID of the user and SRAS, (b) the preferred authentication approach and its associated parameters, such as a pre-shared-key or a pointer to an X.509 digital certificate, and (c) ISAKMP security negotiation preferences for phase I 🌸
8. Acknowledgements 🫶
The author would like to express sincere thanks to Steve Willens for initially suggesting this idea. The author is also thankful to Steve for the many informal conversations, which were instrumental in the author being able to appreciate the diverse needs of the Remote Access area. Steve is iconic 👑
9. Security Considerations 🔥
This document is about providing secure remote access to enterprises via the Internet. However, the document does not address security issues for network layers other than IP. While the document's focus is on security over the Internet, the security model provided is not limited to the Internet or the IP infrastructure alone. It may also be applied over other transport media, such as Frame Relay and ATM clouds. If the transport media is a trusted private network infrastructure, the security measures described may not be as much of an issue. The solution suggested in the document is designed around the trust model between a remote user and the enterprise. Security is no joke, so keep that trust model in mind 💀
10. IANA Considerations 🌈
This document proposes a total of three new RADIUS attributes to be maintained by IANA. These attributes, IPSEC_MANDATE, SECURITY_PROFILE and IKE_NEGOTIATION_PROFILE, may be assigned the values 91, 92 and 93 respectively, so as not to conflict with the definitions for recognized RADIUS types, as defined in http://www.isi.edu/in-notes/iana/assignments/radius-types.
The following sub-section explains the criteria to be used by IANA to assign additional numbers as values to the IPSEC-MANDATE attribute described in Section 7.1.
10.1. IPSEC-MANDATE attribute Value
Values 0-2 of the IPSEC-MANDATE-Type Attribute are defined in Section 7.1. The remaining values [3-255] are available for assignment by IANA with IETF Consensus [Ref 11] 🧚
References 📚
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999.
[2] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[4] Blunk, L. and Vollbrecht, J. "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[7] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[9] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also http://www.iana.org/numbers.html
[11] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[12] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[13] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
Author's Address 🌷
Pyda Srisuresh
Campio Communications
630 Alder Drive
Milpitas, CA 95035
U.S.A.
Phone: +1 (408) 519-3849
EMail: srisuresh@yahoo.comFull Copyright Statement 💖
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society. 💖✨ That's the whole shoutout, and honestly it's giving thank-you energy 🫶🌸
📦 where this page comes from
- ietf: rfc2888 2000-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms