RFC 3457

Requirements for IPsec Remote Access Scenarios 🎀

(part 1 of 7, more coming bestie 🫶)

okay so this is RFC 3457, called Requirements for IPsec Remote Access Scenarios 💖 It came out of the Network Working Group in January 2003 and is marked Informational. The writers are S. Kelly from Airespace and S. Ramamoorthi from Juniper Networks, two people who clearly knew their stuff. The header doesn't list anything it obsoletes or updates, so it's just doing its own thing 💅

---

Status of this Memo ✨

this doc is for info only, bestie. it's not a standard, not even a little. it's giving "here's some good info for the internet community" 🧚 distribution is totally unlimited, so share it with everyone 🍓

Copyright Notice 💜

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🦋

IPsec is literally such a big deal for secure remote access 😭 but there are a bunch of different remote access scenarios, and each one has some requirements that overlap and some that are totally its own vibe. you need to really get these requirements to figure out whether a certain set of mechanisms is a good fit for a specific scenario. this doc lists out the requirements for a bunch of the most common remote access scenarios 🌈

Table of Contents 📋

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
      1.1 Requirements Terminology . . . . . . . . . . . . . . . .  3
      1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . .  3
      1.3 General Terminology  . . . . . . . . . . . . . . . . . .  4
      1.4 Document Content and Organization  . . . . . . . . . . .  4
   2. Overview  . . . . . . . . . . . . . . . . . . . . . . . . .   5
      2.1 Endpoint Authentication . . . . . . . . . . . . . . . .   6
         2.1.1 Machine-Level Authentication . . . . . . . . . . .   7
         2.1.2 User-Level Authentication  . . . . . . . . . . . .   7
         2.1.3 Combined User/Machine Authentication . . . . . . .   8
         2.1.4 Remote Access Authentication . . . . . . . . . . .   8
         2.1.5 Compatibility With Legacy Remote Access Mechanisms   9
      2.2 Remote Host Configuration  . . . . . . . . . . . . . . . 10
      2.3 Security Policy Configuration  . . . . . . . . . . . . . 11
      2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . 12
      2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . 13

   3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . .  13
      3.1 Telecommuters (Dialup/DSL/Cablemodem)  . . . . . . . . . 14
         3.1.1 Endpoint Authentication Requirements . . . . . . .  15
         3.1.2 Device Configuration Requirements  . . . . . . . .  16
         3.1.3 Policy Configuration Requirements  . . . . . . . .  17
         3.1.4 Auditing Requirements  . . . . . . . . . . . . . .  18
         3.1.5 Intermediary Traversal Requirements  . . . . . . .  18
      3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . 19
         3.2.1 Authentication Requirements  . . . . . . . . . . .  19
         3.2.2 Device Configuration Requirements  . . . . . . . .  20
         3.2.3 Policy Configuration Requirements  . . . . . . . .  21
         3.2.4 Auditing Requirements  . . . . . . . . . . . . . .  21
         3.2.5 Intermediary Traversal Requirements  . . . . . . .  21
      3.3 Extranet Laptop to Home Corporate Net . . . . . . . . .  22
         3.3.1 Authentication Requirements  . . . . . . . . . . .  22
         3.3.2 Device Configuration Requirements  . . . . . . . .  23
         3.3.3 Policy Configuration Requirements  . . . . . . . .  23
         3.3.4 Auditing Requirements  . . . . . . . . . . . . . .  24
         3.3.5 Intermediary Traversal Requirements  . . . . . . .  24
      3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . 25
         3.4.1 Authentication Requirements  . . . . . . . . . . .  25
         3.4.2 Device Configuration Requirements  . . . . . . . .  26
         3.4.3 Policy Configuration Requirements  . . . . . . . .  26
         3.4.4 Auditing Requirements  . . . . . . . . . . . . . .  26
         3.4.5 Intermediary Traversal Requirements  . . . . . . .  26
      3.5 Public System to Target Network . . . . . . . . . . . .  27
         3.5.1 Authentication Requirements  . . . . . . . . . . .  27
         3.5.2 Device Configuration Requirements  . . . . . . . .  28
         3.5.3 Policy  Configuration Requirements . . . . . . . .  28
         3.5.4 Auditing Requirements  . . . . . . . . . . . . . .  29
         3.5.5 Intermediary Traversal Requirements  . . . . . . .  29
   4. Scenario Commonalities  . . . . . . . . . . . . . . . . . .  29
   5. Security Considerations . . . . . . . . . . . . . . . . . .  30
   6. References  . . . . . . . . . . . . . . . . . . . . . . . .  30
   7. Acknowledgements  . . . . . . . . . . . . . . . . . . . . .  30
   8. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . .  30
   9. Full Copyright Statement  . . . . . . . . . . . . . . . . .  31

1. Introduction 💅

okay so, up until pretty recently, remote access meant dial-up users calling in over the Public Switched Telephone Network (PSTN), with the call landing on a Network Access Server (NAS) inside the target domain 📞 the protocols were mostly PPP-based, and the access control, authorization, and accounting stuff was handled by a bunch of different mechanisms, including RADIUS [RADIUS] 🌸

ngl, people used to just assume the phone network was pretty secure and that nobody was messing with the integrity or confidentiality of those calls 🙈 so connection security was basically just the NAS checking a username and passphrase pair. but real talk, PSTN dial-up has never been impervious to a determined attacker 💀

then broadband came along and everybody wanted to stop paying for long-distance toll calls, so Internet-based remote access took off 🚀 sometimes a dial user would first hop onto a local ISP account, then tunnel a second PPP connection over the Internet into the target network. broadband users just tunnel straight over the Internet. these setups weren't exactly security queens, but IPsec is getting more available, which makes it possible to give remote resources way more secure access over the Internet 🔐

remote access over the Internet has tons of perks, money and otherwise 🤑 but security is everything, so there's a super strong push to move from the old dial-up model to a more secure, IPsec-based remote access model. getting the security requirements right for all the different kinds of remote users is genuinely a lot of work 😮‍💨 so the goal of this doc is to explore and list out the requirements for various IPsec remote access scenarios, without picking any particular solutions for them 🧚

1.1 Requirements Terminology ✨

the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are the ones that show up in this doc, and they're meant to be read the way [3] describes 🫶

1.2 Reader Prerequisites 📚

you need to be familiar with RFCs 2401-2412 to even start understanding the stuff in here, that's the minimum 😤 you should also know about PKI concepts. knowing RADIUS, PPP, PPTP, L2F, L2TP, and other remote access support protocols isn't strictly required, but it'll definitely help 🌈

1.3 General Terminology 🎀

• Remote Access: this term covers the case where the remote user doesn't necessarily sit in one fixed spot, meaning the user's IP address isn't fixed and usually isn't known before the connection gets set up.
• Secure Remote Access: this is remote access that's protected using pieces of the IPsec protocol suite.
• IPsec Remote Access Client (IRAC): this is the remote access user's system.
• IPsec Remote Access Server (IRAS): this is the device that gives access to the target network. another name for it is "Security Gateway".
• Security GateWay (SGW): this is the device that gives access to the target network. another name for it is IRAS.
• Virtual IP address (VIP): this is an address from a subnet that's local to the target network, assigned to a remote client so it looks like that client is actually sitting on the target network 🦋
• Machine-Level Authentication: this is when a machine's identity gets verified because the machine has and uses some combination of authenticators. section 2 has the full definition.
• User-Level Authentication: this is when a user's identity (not a machine's) gets verified because the user has and uses some combination of authenticators. section 2 has the full definition too.
• NAPT: Network Address/Port Translation 💜

1.4 Document Content and Organization 🍓

so this doc started out as just a way to outline requirements for different remote access scenarios, but it grew into something a little bigger 🌱 it came out of discussions in the IPsec Remote Access (IPSRA) working group, so it kind of documents how that thinking evolved over time. that's a departure from the usual requirements doc format, but the historical context is really useful for understanding the conclusions the IPSRA working group reached 🫶

the rest of the doc is laid out like this: first there's a general overview of the basic requirements categories, including the definitions for those categories ✨ after that, every remote access scenario gets its own section. inside each scenario section there are subsections covering endpoint authentication, remote host configuration, policy configuration, auditing, and intermediary traversal 💖

2. Overview ✨

okay so, the big picture 🦋 Every secure remote access setup kinda has the same high-level look, like this:

                                         target network
                                              |
                                              |   +---+
   +-------------+             +-----------+  |---|   |
   |remote access|  Internet   | security  |  |   +---+
   |   client    |=============| gateway   |--|
   |   (IRAC)    |             |(SGW/IRAS) |  |   +---+
   +-------------+             +-----------+  |---|   |
                                              |   +---+

In every case, a remote client wants to securely access resources either behind a SGW or on an IPsec-protected host, and/or wants to give other (specific) systems secure access to the client's own resources. 💖 There are loads of details that can change depending on the scenario. For example, the IRAC might be inside another corporate network, or connected to an ISP via dialup, DSL, or CATV media. There may also be extra intermediaries between the remote client and the security gateway, but honestly, all of these setups can be viewed kinda equivalently from a high level. 💅

There are several basic categories of requirements for secure remote access, including endpoint authentication, remote host configuration, security policy configuration, auditing, and intermediary traversal. 🌸 Endpoint authentication is about verifying the identities of the communication partners (e.g., the IRAC and the IRAS). Remote host configuration is about the device configuration parameters of the IRAC system. Security policy configuration is about the IPsec policy configuration of both the security gateway and the remote host, and it might also be termed "access control and authorization configuration" 👑 Auditing covers generating and collecting connection status information, which is required to keep the overall security and integrity of the connected networks intact. And intermediary traversal is the ability to pass secured traffic across intermediaries, some of which may modify the packets in some manner. Those intermediaries include NAPT and firewall devices. 🧚 We'll go through each of these categories in more detail below.

2.1. Endpoint Authentication

Before we talk about endpoint authentication for remote access, it's super important to tell apart data source authentication and end user authentication 🎀 Data source authentication, in the IPsec context, means giving assurance that a network packet comes from a specific endpoint, which is typically a user, host, or application. IPsec offers mechanisms for this via AH or ESP. End user authentication, in the IPsec context, means giving assurance that the endpoint is what or who it claims to be. IPsec currently offers mechanisms for this as part of IKE [IKE].

Okay, these two are different, but they're not unrelated 🫶 Data source authentication actually relies on endpoint authentication, because it's possible to inject packets with a particular IP address into the Internet from many arbitrary locations. In lots of cases we can't be certain a packet really comes from a particular host, or even from the network that host lives on. 😭 So to fix that, you first have to authenticate the particular endpoint somehow, and then bind the addressing information (e.g., IP address, protocol, port) of that endpoint into the trust relationship the authentication process set up.

In the context of secure remote access, the authenticated entity may be a machine, a user (application), or both. The authentication methods IPsec supports range from preshared secrets to various signature and encryption schemes that use private keys and their matching public key certificates. ✨ These mechanisms may be used to authenticate the end user alone, the device alone, or both the end user and the device. We'll dig into each of these below.

2.1.1. Machine-Level Authentication

Here, no user input is needed for an authentication credential to be used. So the entity being authenticated is mainly the device where the credential is stored, and how much assurance you get depends on how securely that machine's credential is kept during both storage and use. 🍓 A shared secret, or a private key tied to a public key certificate, can either be stored inside the device or sit in another device that the device can securely access (e.g., a smartcard). But if the knowledge needed to use the credential is entirely inside the subject device (i.e., no user input is required), then it's problematic to say that using that credential authenticates anything other than the subject device. 🙈

Sometimes a user has to meet certain criteria before they can get access to stored credentials. In those cases, the level of user authentication you get from using those credentials is kinda hard to pin down. If the system holding the credential has strong enough access controls, there may be a strong binding between the authorized system user and the credential. 🔥 But when the credential is actually presented, the IRAS itself has no such assurance. So the IRAS on its own might have some level of assurance that a particular device (the one holding the credential) is where access is coming from, but there's no explicit assurance about who the user of that system is. To get extra assurance about the user's identity, the IRAS would need an additional user credential of some sort. This gets discussed further below.

2.1.2. User-Level Authentication

Sometimes the user has an authentication token (preshared key, private key, passphrase, etc.), and they may provide it, or some derivative of it, whenever authentication is needed. 🦋 If this token or derivative goes straight to the other endpoint without being modified by the IRAC system, and if the IRAC system doesn't provide any further credentials of its own, then it's the user alone who has been authenticated. There may be some assurance about the network address the user's packets come from, but there's no assurance about the particular machine the user is trying to access from. 💀

2.1.3. Combined User/Machine Authentication

To authenticate both the user and the system, you need some sort of user input in addition to a credential that's securely stored on the device. 🌈 Sometimes that user input is used to "complete" the credential stored on the device (e.g., a private key that's password-encrypted), and other times the user's input is supplied independently of the stored credential. When the passphrase gets applied to the credential before use, how much assurance you get from successfully using the credential depends on your viewpoint 👀

From the perspective of a whole system made up of the user, IRAC, IRAS, and a collection of system protections and security procedures, you could say the user has been authenticated to an extent that depends on how strong those security procedures and system protections are. ✨ But from the perspective of the IRAS alone, there's very little assurance about user identity. So when stored credentials have to be modified by user input before use, they can only be said to provide user-level authentication within the context of the larger system. And then the level of assurance you get is directly proportional to the weakest security attribute of the entire system. Yikes 😭

When you're thinking about remote access in general, assumptions about the overall system are likely to turn out wrong. That's because the IRAS and the IRAC may not be in the same domain of control. Extranet scenarios are a good example of this. 🧚 So the most desirable joint user/machine authentication mechanisms here are the ones that give a high level of assurance to both the IRAS and the IRAC, independently of the larger system the user, IRAS, and IRAC are part of. Iconic behaviour, honestly 👑

2.1.4. Remote Access Authentication

In the general case for remote access, authentication requirements are typically asymmetric. 💜 From the IRAC's point of view, it's important to make sure the IRAS on the other end of the connection is really what it seems to be, and not some rogue system masquerading as the SGW. So the IRAC needs machine-level authentication for the IRAS. This is pretty straightforward, given the authentication mechanisms IKE and IPsec support. And this kind of authentication tends to persist over time, though how long depends on the mechanism chosen. 🌸

Machine-level authentication is enough for the IRAS, but it's not enough for the IRAC. Here, it's often important to know that the entity on the other end of the connection is someone authorized to access local resources. Not someone who just stumbled upon an unoccupied but otherwise authorized system, or a malicious Trojan horse application on that user's system, or some other unauthorized entity. 🙈 Authenticating the user has different requirements than authenticating the user's machine. It needs some form of user input, and the authentication often has to be renewed periodically.

Where there isn't a high level of physical security, it's common to require a user-input secret as part of the authentication process, and then to renew the authentication periodically. Also, since these circumstances can include the possibility of a Trojan horse application on the IRAC system, one-time passphrase mechanisms are often advisable. 🔥 Picking passphrase mechanisms and renewal intervals that give an acceptable level of risk without annoying the user too much can be super challenging. And it should be obvious that even this approach offers limited assurance in many cases 😅

Clearly, the various endpoint authentication techniques can reach different assurance levels, and none of the techniques discussed offer absolute assurance. There are also variations in authentication requirements among different remote access scenarios. So there's no "cookie cutter" solution for this problem, and each individual scenario has to be carefully examined to derive its specific requirements. 🎀 We'll look at these case by case in the detailed scenario descriptions below. 🦋

2.1.5 Compatibility With Legacy Remote Access Mechanisms ✨

okay so bestie, there are a bunch of remote access setups already out in the wild that were installed before IPsec even showed up 🕰️💅 usually they're dialup systems that lean on RADIUS for user authentication and accounting, but there are other mechanisms too 🌸 the ideal IPsec remote access solution would use the pieces of the underlying framework without changing them, and that's the goal wherever it's possible 🎀 BUT ngl there might be cases where that just can't happen because of security and/or other considerations 😭 in those cases, the IPsec remote access framework should be designed so that migrating away from the legacy stuff is as painless as it can possibly be 🫶

so in general, proposed IPsec remote access mechanisms should hit these goals 👑

- should provide direct support for legacy user authentication and accounting systems such as RADIUS

- should encourage migration from existing low-entropy password-based systems to more secure authentication systems

- if legacy user authentication support cannot be provided without some sort of migration, the impact of such migration should be minimized

- user authentication information must be protected against eavesdropping and replay (including the user identity)

- single sign-on capability should be provided in configurations employing load-balancing and/or redundancy

- n-factor authentication mechanisms should be supported

---

2.2 Remote Host Configuration 🎀

Remote host configuration is all about the network-related device configuration of the client system 💻 this config can be fixed or dynamic 🦋 it might be provided completely by the administrator of the network the remote user is currently on (like the ISP), or partially by that admin, with the rest coming from an entity on the remote corporate network the client is reaching into 🌈 generally, this configuration may include the following:

• IP address(es)
• Subnet mask(s)
• Broadcast address(es)
• Host name
• Domain name
• Time offset
• Servers (e.g., SMTP, POP, WWW, DNS/NIS, LPR, syslog, WINS, NTP, etc. )
• Router(s)
• Router discovery options
• Static routes
• MTU
• Default TTL
• Source routing options
• IP Forwarding enable/disable
• PMTU options
• ARP cache timeout
• X Windows options
• NIS options
• NetBIOS options
• Vendor-specific options
• (other options)

fixed config is honestly kinda boring 🙄 the cases we actually care about are the ones where specific IRAC configuration happens because of remote access 👀 for example, sometimes the IRAC gets assigned a "virtual address", so it looks like it's sitting right on the target network 🧚

                                      target net
+------------------+                      |
|  Remote Access   |        +--------+    |   ( ~ ~ ~ ~ ~ )
|+-------+ Client  |        |        |    |   (   IRAC    )
||virtual|         |        |security|    |~~~(  virtual  )
|| host  |         |--------|gateway |    |   (  presence )
||       |<================>|        |----|     ~ ~ ~ ~ ~
|+-------+         |--------|        |    |
+------------------+   ^    +--------+    |   +--------+
                       |                  |---|  local |
                     IPsec tunnel         |   |   host |
                     with encapsulated    |   +--------+
                     traffic inside

so the IRAC starts out with an externally routable address 🌍 then an extra target network address gets assigned to it, and packets carrying that assigned address get encapsulated, with the outer headers holding the IRAC's routable address, and forwarded to the IRAS through the tunnel 🚇 this gives the IRAC a virtual presence on the target network through an IPsec tunnel, and it's giving main character energy ✨ note that the IRAC now has two active addresses: the ISP-assigned address, and the VIP 💜

now that it has that virtual presence on the corporate network, the IRAC might need other topology-related config, like default routers, DNS server(s), etc., just like a dynamically configured host physically sitting on the target network would 🙌 that's the kind of config this requirements category is about 💖

---

2.3 Security Policy Configuration 🔥

Security policy configuration is about IPsec access policies for both the remote access client and the security gateway 🛡️ it can be useful to configure access policies on connecting IRAC systems to protect the target network 🏰 for example, since a client has access to the Internet (via its routable address), other systems on the Internet also have some level of reciprocal access to the client 😳 sometimes it's desirable to block that Internet access (or force it to go through the tunnel) while the client has a tunneled connection to the target network 🚫 that's a matter of client security policy configuration 💅

for the security gateway, it may also be desirable to dynamically adjust policies based on the user the connection was established with 🎯 say there are two remote users, Alice and Bob 👯‍♀️ we want to give Alice unrestricted access to the target network, while restricting Bob's access to specific segments 🔐 one way to do that would be to statically assign internal "virtual" addresses to each user in a one-to-one mapping, so each user always gets the same address 📌 then a particular user's access could be controlled with policies based on that address 🙃 but ugh, this does not scale well 😩

a more scalable solution for remote client access control would be to dynamically assign IP addresses from a specific pool based on the authenticated endpoint identity 🌷 access to specific resources is then controlled by address-based policies in the SGW 🧱 this is very similar to the static mapping above, except that a given group of users (those with identical access controls) would share a given pool of IP addresses (those granted the required access), instead of a given user always mapping to a given address 🫧 however, this also has scaling issues, though not as pronounced as with the static mapping 🤏

alternatively, an arbitrary address could be assigned to a user, with the security gateway's policy being dynamically updated based on the identity of the remote client (and its assigned virtual address) to permit access to particular resources 🪄 in these cases, the relevant security policy configuration is specific to the IRAS, rather than the IRAC 🏢 both IRAS and IRAC security policy configuration are covered by this requirements category 💜

---

2.4 Auditing 📋

Auditing here refers to the collection and reporting of connection status information by the IRAS, for the purpose of maintaining the security and integrity of the IRAS protected network 🕵️‍♀️ for remote access, the following auditing information is useful from a security perspective 🔍

• connection start time
• connection end time

okay the connection-end-time thing is a big deal 🚨 it implies the need for a connection heartbeat mechanism of some sort, so the IRAS can accurately figure out that quantity in cases where the IRAC doesn't explicitly terminate the connection 💓 also, the heartbeat mechanism in this case is always directed from the IRAC to the IRAS ➡️

but heads up, using a heartbeat can sometimes negatively influence a connection 😬 for example, if the heartbeat interval is very short, and the connection gets reset after losing only a few heartbeat packets, network congestion could lead to unnecessary connection resets 💀 so the heartbeat interval and reset threshold should be chosen with this in mind, and it should be possible to adjust these quantities through configuration or negotiation 🎛️

---

2.5 Intermediary Traversal 🚧

Intermediary traversal here refers to passing a secured data stream through an intermediary such as a firewall or NAPT device 🧱 with firewalls, a lot of deployed products don't recognize the IPsec protocol suite, which makes it hard (sometimes impossible) to configure them to let it through 😤 in those cases, a mechanism is required to make the data stream look like a type the firewall is able to manage 🎭

NAPT devices come with their own drama 🎬 there are a bunch of issues with trying to pass an encrypted or authenticated data stream through them 😵 for example, NAPT devices typically modify the source IP address and UDP/TCP port of outgoing packets, and the destination IP address and UDP/TCP port of incoming packets, and in some cases they modify additional fields in the data portion of the packet ✂️ those modifications make the use of the AH protocol impossible 🚫 with ESP, the UDP/TCP port fields are sometimes unreadable and always unmodifiable, so meaningful translation by the NAPT device is impossible 💔 there are plenty of other protocol-field combinations that suffer similarly 🌀 this requirements category is concerned with all of these issues 🫶

---

3. Scenarios 🗺️

there are tons of remote access scenarios possible using IPsec 🌏 this section is a brief summary enumeration of them, followed by a subsection devoted to each one that explores the various requirements in terms of the categories defined above 📚

the following scenarios are discussed:

• dialup/dsl/cablemodem telecommuters using their systems to access remote resources 🏠
• extranet users using local corporate systems to access the remote company network of a business partner 🤝
• extranet users using their own system within another company's network to access their home corporate network 💼
• extranet users using a business partner's system (located on that partner's network) to access their home corporate network 🔁
• remote users using a borrowed system (e.g., an airport kiosk) to access target network resources ✈️

3.1 Telecommuters (Dialup/DSL/Cablemodem) 🏠💻

okay so the telecommuter scenario is one of the most common remote access setups, and it's easy to see why 🌸 Internet access is everywhere now, so it's a super attractive option. Users can connect from the comfort of their homes or hotel rooms and then use that Internet connection to reach the resources of a target network. Sometimes a dialup account provides the initial Internet access, and other times it's some kind of "always-on" connection, like a DSL or CATV modem. ✨

The dialup and always-on cases are very similar, but there are two big differences: how the address gets assigned and how long the connection lasts. 🦋 With most dialup, the IRAC's IP address is dynamically assigned as part of connection setup, and it's pretty likely to be different every time the IRAC connects. DSL/CATV users often get static IP addresses, although dynamic assignment is becoming more common. As for connection duration, dialup remote access connections are typically short-lived, while always-on connections may stay up for significantly longer periods of time. 💅

The general configuration in either case looks like this: 🧚

                                        corporate net
                                               |  +----+
  +-----+   +-----+      /---/ Internet +---+  |--|    |
  |IRAC |---|modem|------|ISP|==========|SGW|--|  +----+
  +-----+   +-----+      /---/          +---+  |
                                               |

There's also an alternative where you put a security gateway between the user's system and the modem. In that case, this added SGW becomes the IRAC. This is currently most common when DSL/CATV connections are used. 🌈

3.1.1 Endpoint Authentication Requirements

okay this part is giving serious security vibes 🔐 The authentication requirements for this scenario depend partly on the general security requirements of the network the access is being provided to. Assuming the corporate SGW is physically secure, machine authentication for the SGW is sufficient. But if that assumption about physical security is wrong, it isn't clear that stronger authentication for the SGW could be guaranteed, and figuring out an effective mechanism for that case is beyond the scope of this document. 😭

For the IRAC, there are lots of threats to the integrity of the user authentication process. Common consumer operating systems are super open, so some of these threats are really hard to protect against. For example, it's very difficult to say with any real certainty that a single user system which allows downloading and running arbitrary applications from the Internet hasn't been compromised, or that a covert application isn't monitoring and interacting with the user's data at any point in time. 💀

That said, there are 2 general threats we might realistically hope to mitigate with appropriate authentication mechanisms, if we can assume the system hasn't been compromised in that way. 👑 The first is the possibility that a secure connection is established for a particular user, but someone other than the intended user is currently using that connection. The second is the possibility that the user's credential (password, hardware token, etc.) has been compromised somehow and is being used by someone other than the authorized user to gain access. 🙈

Mitigating the first threat, which is someone other than the authorized user using the connection, requires periodic renewal of user authentication. It should be clear that machine authentication won't suffice here. Requiring periodic re-entry of an unchanging user password (which might be written on a post-it note stuck to the user's monitor) will have limited effectiveness. Convincing verification of the continued presence of the authorized user will, in many cases, require periodic application of a time-variant credential. 🍓

Mitigating the second threat, credential compromise, is tricky and depends on a bunch of factors. If the IRAC system is running a highly secure operating system, then a time-variant credential may again offer some value. A static password is clearly deficient in this scenario, since it may be subject to either online or offline guessing and eventually get compromised, which is exactly the threat we're trying to mitigate. However, if the IRAC operating system is not hardened, a time-variant credential is only effective if simultaneous access from more than one location is forbidden, and the credential generation mechanism isn't easily compromised. 🫶

A second approach to the credential compromise problem is using a PKI-based credential stored within some kind of secure container, which requires some user interaction before it can operate (for example, a smartcard). If such a credential requires periodic user interaction to keep operating (like pin re-entry), this may help limit the access of an unauthorized user who happens upon a connected but unattended system. Still, choosing an acceptable refresh interval is a difficult problem, and if the pin isn't time-variant, this provides limited additional assurance. ✨

To summarize, here are the authentication requirements for the IRAS and IRAC: 🎀

IRAS

• machine authentication MUST be provided.

IRAC

• support for user authentication SHOULD be provided
• support for either user or machine authentication MUST be provided
• support for user authentication MUST be provided if protection from unauthorized connection use is desired.
• if user authentication is provided for short-lived dialup connections, periodic renewal MAY occur
• if user authentication is provided for always-on connections, periodic renewal SHOULD occur

3.1.2 Device Configuration Requirements

there are 2 possibilities for device configuration in the telecommuter scenario 🧁 Either access to the target network is permitted for the native ISP-assigned address of the telecommuter's system, or the telecommuter's system gets assigned a virtual address from inside the target address space. In the first case, there are no device configuration requirements that aren't already satisfied by the ISP. But honestly, this case is the exception, not the rule. 🙃

The second case is way more common because of the many benefits of giving the IRAC a virtual presence on the target network. For example, the virtual presence lets the client receive subnet broadcasts, which means it can use WINS on the target network. Also, if the IRAC tunnels all traffic to the target network, then the target policy can be applied to Internet traffic to and from the IRAC. 🌸

In this case, the IRAC requires, at minimum, an IP address assigned from the target network. Typically, the IRAC needs anywhere from several to many more elements of configuration information, depending on how topologically complex the corporate network is. For a pretty complete list, see section 2.2. 📋

To summarize, here are the device configuration requirements for the IRAC: 💖

• support for a virtual IP (VIP) address MAY be provided
• if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be provided
• support for address assignment based upon authenticated identity MAY be provided
• if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported.

3.1.3 Policy Configuration Requirements

for IRAC policy configuration, the most important issue is whether the IRAC has direct Internet access enabled (for browsing, etc.) while a connection to the target network exists. This matters because the fact that the IRAC can reach sites on the Internet implies those sites have some level of reciprocal access to the IRAC. It may be desirable to completely eliminate this type of access while a tunnel is active. 🚫🌐

Alternatively, the risks can be somewhat mitigated by forcing all Internet-bound packets leaving the IRAC to first traverse the tunnel to the target network, where they can be subjected to target network policy. A second approach, which carries a bit less overhead, is modifying the IRAC's policy configuration to reflect that of the target network during the time the IRAC is connected. In this case, traffic isn't forced to loop through the target site before exiting or entering the IRAC. This requires some sort of policy download (or modification) capability as part of the SA establishment process. A third approach is to provide a configuration variable for the IRAC that permits specifying "tunnel-all", or "block all traffic not destined for the target network while the SA is up". 🦋

For IRAS configuration, it may be necessary to dynamically update the security policy database (SPD) when the remote user connects. That's because transit selectors must be based on network address parameters, but those can't be known a priori in the remote access case. As noted above, this can be avoided by providing a mechanism that permits address assignment based upon authenticated identity. 🧠

To summarize, here are the policy configuration requirements for the IRAS and IRAC: 🍭

IRAS

• dynamic policy update mechanism based upon identity and assigned address MAY be supported.
• if address assignment-based policy update mechanism is not supported, address assignment based upon authenticated identity SHOULD be supported.

IRAC

• IRAC SHOULD provide ability to configure for "tunnel-all" and/or "block-all" for traffic not destined for the remote network to which IPsec remote access is being provided.
• support for dynamic IRAS update of IRAC policy MAY be provided.

3.1.4 Auditing Requirements

for telecommuter sessions, session start and end times must be collected 📝 Reliably working out the session end time requires that the IRAC somehow periodically signal that the connection is still active. This is implied if the IRAS receives data from the IRAC over the connection, but if no data is sent for some period of time, a signaling mechanism is required so the IRAC can indicate that the connection remains in use. ⏰

3.1.5 Intermediary Traversal Requirements

if the address the ISP assigned to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements. 🌍 But if NAPT operations are performed on the data stream, some mechanism must be provided to make these modifications transparent to the IPsec implementation. 🙌

3.2 Corporate to Remote Extranet ✨

Okay bestie, extranets are getting SO common, especially now that IPsec is everywhere 🌐💖 In this scenario, a user from one corporation uses a local corporate system to reach resources on another corporation's network. These companies are usually cooperating a little, but not enough that totally unbridled access between the two networks would be okay 🙈 So this scenario is all about limited access 🔒 The general layout looks like this:

       CORP A                                CORP B
          |                                      |
 +----+   |                                      |  +-----+
 |USER|---|                                      |--| S1  |
 +----+   |   +------++              ++------+   |  +-----+
          |---|SGW/FW||===Internet===||SGW/FW|---|
          |   +------++              ++------+   |  +-----+
          |     SGW-A                   SGW-B    |--| S2  |
          |                                      |  +-----+

This is intentionally simplified so we can see the basics without drowning in details 🫶 At the edge of each network sits a combined security gateway and firewall device, labeled "SGW-A" and "SGW-B". In this picture, corporation B wants to give a user from corporation A access to servers S1 and/or S2 💅 There are a few ways to make that happen:

1. an end-to-end SA is formed from USER to S1 or S2
2. a tunnel-mode SA is formed between SGW-A and SGW-B which only permits traffic between S1/S2 and USER.
3. a tunnel-mode SA is formed between USER and SGW-B which only permits traffic between S1/S2 and USER.

We'll look at each of these cases separately for every requirements category below 🧚

3.2.1 Authentication Requirements

For the corporate extranet scenario, the authentication requirements shift a bit depending on how the connection is set up 🎀 If only one particular user is allowed to reach S1/S2, then user-level authentication is required. If connection types (1) or (3) are used, this can be done the same way it would be for a telecommuter. If connection type (2) is used, one of two things has to happen: either SGW-A has to provide some local mechanism for authenticating USER and SGW-B has to trust that mechanism, or SGW-B needs its own way of authenticating USER independently of SGW-A 😭

If access is open to anyone in corporation A, then machine authentication will be enough. ngl, this is highly unlikely 💀 A slightly more realistic situation is when access is open to anyone within a particular organizational unit in corporation A. This is very similar to the single-user case we just discussed, and it basically has the same requirements for the mechanism needed on SGW-A, although machine authentication might be enough if that organizational unit has a sufficient level of physical security 🔐 Again, this means corporation B has to trust corporation A on this point 🫶

So, to sum it all up, here are the authentication requirements for the IRAS and IRAC:

IRAS

• machine authentication MUST be provided.

IRAC

• support for either user or machine authentication MUST be provided
• support for a combination of user and machine authentication SHOULD be provided
• if user authentication is used, periodic renewal SHOULD occur

3.2.2 Device Configuration Requirements

It's possible corporation B would want to give USER a virtual address for the length of the connection 🦋 The only way that could work is if USER were a tunnel endpoint (for example, in cases (1) and (3)). It isn't clear what benefits this would offer, if any 🤷‍♀️

So, the device configuration requirements for the IRAC are:

• support for a virtual address MAY be provided
• if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be supported
• support for address assignment based upon authenticated identity SHOULD be supported
• if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported.

3.2.3 Policy Configuration Requirements

Every case we talked about has some static policy configuration requirements 📋 Case (1) needs SGW-A and SGW-B to let IPsec traffic pass between USER and S1/S2. Case (3) has similar requirements, except the IPsec traffic runs between USER and SGW-B. Case (2) needs the appropriate transit traffic to be secured between USER and S1/S2 ✨

Good news: none of these cases require dynamic policy configuration 🥳

3.2.4 Auditing Requirements

For cases (1) and (3), session start/end times must be collected 🗂️ Getting a reliable session end time means the IRAC has to somehow signal periodically that the connection is still active. This happens automatically if the IRAS is receiving data from the IRAC over the connection, but if no data gets sent for a while, a signaling mechanism is required so the IRAC can say the connection is still in use 💜

For case (2), the kind of auditing data you need depends on whether traffic from multiple users is aggregated inside a single tunnel. If it is, then individual connection start/stop times are lost, and that's just how it goes 🙃 If those measures are still wanted, per-user tunnels have to be set up between SGW-A and SGW-B, and some sort of timeout interval is needed so the tunnel gets torn down when no traffic flows for a while ⏱️

3.2.5 Intermediary Traversal Requirements

If the address the host network assigns to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS do NAPT operations on the data stream, then there are no extra requirements here 🌍 If NAPT operations are happening on the data stream, some mechanism must be provided to make those modifications transparent to the IPsec implementation 👀

If a firewall at the edge of the host network can't be configured to pass protocols in the IPsec suite, then some mechanism must be provided that converts the data stream into one the firewall can be configured to pass 🔥 If the firewall can be set up to pass IPsec protocols, then this conversion has to be done before the connection gets established ✨

---

3.3 Extranet Laptop to Home Corporate Net

Using a laptop while visiting another corporation is another extranet scenario that's getting more and more common 💻🌸 In this case, a user works temporarily inside another corporation, maybe as part of some service agreement. The user brings along a CORP-A laptop that gets a CORP-B address, either statically or dynamically, and they want to securely reach resources on CORP-A's network using that laptop 🦋 It looks like this:

       CORP A                                CORP B
          |                                      |
 +----+   |                                      |  +--------+
 |POP |---|                                      |--| CORP-A |
 +----+   |   +------++              ++------+   |  | laptop |
          |---|SGW/FW||===Internet===||SGW/FW|---|  +--------+
          |   +------++              ++------+   |
 +----+   |     SGW-A                   SGW-B    |
 |FTP |---|                                      |
 +----+   |                                      |

This is a lot like the telecommuter scenario, but it's different in a few important ways 🍓 First, there's often a SGW and/or firewall at the edge of CORP-B's site. Second, there may be a much higher risk that a long-lived connection could become reachable by someone other than the intended user 😬

3.3.1 Authentication Requirements

In most cases, the only acceptable connections from CORP-A's point of view are between the laptop and either SGW-A or the CORP-A servers the laptop wants to reach 🔒 Most of what applied to the telecommuter applies here too, and user-level authentication is required to make sure the user who started the connection is still the active user 🫣 As an extra precaution, a combination of user-level and machine-level authentication may be warranted in some cases. Also, in either case this authentication should be renewed frequently 🔄

So, here are the authentication requirements for the IRAS and IRAC:

IRAS

• machine authentication MUST be provided.

IRAC

• support for machine authentication SHOULD be provided
• support for user authentication MUST be provided
• support for a combination of user and machine authentication SHOULD be provided
• periodic renewal of user authentication MUST occur

3.3.2 Device Configuration Requirements

The device configuration requirements here are the same as for the telecommuter 💅 That means the laptop may be given a virtual presence on the corporate network, and if it is, it will need full infrastructure configuration 🧚

So, the device configuration requirements for the IRAC are:

• support for a virtual address MAY be provided
• if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be supported
• support for address assignment based upon authenticated identity SHOULD be supported
• if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported.

3.3.3 Policy Configuration Requirements

The policy configuration requirements here are different from the telecommuter's, and this is the big plot twist 😱 The laptop can't be given a policy that forces all traffic to go to CORP-A through the tunnel. Why? Because the laptop has a CORP-B address, so it might have traffic destined for CORP-B too. If that traffic got tunneled to CORP-A, there might be no return path to CORP-B except through the laptop 🤯 On the flip side, Internet-bound traffic could be subjected to that restriction if you want, and/or all traffic other than the traffic between CORP-A and the laptop could be blocked for the whole connection 🚫

IRAC

• support for IRAS update of IRAC policy MAY be provided.
• if IRAS update of IRAC policy is not supported, IRAC MAY support IRAS directives to "block-all" for non-tunneled traffic.
• IRAC SHOULD provide ability to configure for "tunnel-all" and/or "block-all" for traffic not destined for the remote network to which IPsec remote access is being provided.

3.3.4 Auditing Requirements 🦋

okay so the auditing stuff in this one is literally the same as the telecommuter scenario 💅 bestie, you still have to collect session start and end times ⏰. the tricky part is getting a reliable end time, which means the IRAC has to somehow keep signaling that the connection is still alive 🫶. if the IRAS is getting data from the IRAC over the connection, that already counts as the signal ✨. but if no data goes through for a while, there needs to be a signaling mechanism where the IRAC says "hey, I'm still using this" 📡

3.3.5 Intermediary Traversal Requirements 🌸

if the address the host network gave the IRAC is globally routable, and nothing between the IRAC and the IRAS does NAPT on the data stream, then there are no extra requirements here 🙌 but if NAPT is happening, some mechanism must be provided to make those changes transparent to the IPsec implementation 🫠

also, if a firewall at the edge of the host network can't be configured to pass IPsec-suite protocols, then some mechanism must be provided that converts the data stream into one the firewall can be set up to pass 🧱 and if the firewall can be configured to pass IPsec protocols, that has to be done before the connection gets established 🔥

3.4 Extranet Desktop to Home Corporate Net 💜

this is super similar to the extranet laptop scenario we just went over, except CORP-A has to have a higher degree of trust for CORP-B 👑 here's how it looks:

        CORP A                                CORP B
          |                                      |
 +----+   |                                      |  +--------+
 |POP |---|                                      |--| CORP-B |
 +----+   |   +------++              ++------+   |  |desktop |
          |---|SGW/FW||===Internet===||SGW/FW|---|  +--------+
          |   +------++              ++------+   |
 +----+   |     SGW-A                   SGW-B    |
 |FTP |---|                                      |
 +----+   |                                      |

3.4.1 Authentication Requirements 🔐

the authentication requirements for the desktop extranet scenario are very similar to the extranet laptop ones 🥰 the main difference is which authentication types can be used. with a laptop, CORP-A can get some assurance that the connection is coming from one of its own systems if a securely stored machine credential lives on the laptop and gets used 💻 with a desktop that's not possible, because CORP-A doesn't own the IRAC system 🙈

so, to sum it up, here are the authentication requirements for the IRAS and IRAC:

IRAS

• machine authentication MUST be provided.

IRAC

• support for machine authentication MAY be provided
• support for user authentication MUST be provided
• support for a combination of user and machine authentication MAY be provided
• periodic renewal of user authentication MUST occur

3.4.2 Device Configuration Requirements 🎀

the device configuration requirements here are the same as the laptop extranet scenario 🧚 so the desktop may be given a virtual presence on the corporate network, and if it is, it'll need full infrastructure configuration. honestly though, this seems way less likely than with the laptop, since CORP-A has zero control over the software configuration on CORP-B's desktop 🤷‍♀️

3.4.3 Policy Configuration Requirements 🍓

the policy configuration requirements are pretty similar to the extranet laptop ones, except there's even less control over CORP-B's desktop than there would be over a laptop 😬 which means it might not be possible to restrict traffic in any way at the desktop system 🚫

3.4.4 Auditing Requirements 🕰️

same energy as the telecommuter scenario again 💅 session start and end times must be collected. reliable session end times need the IRAC to somehow periodically signify that the connection remains active 📶 this is implied if the IRAS receives data from the IRAC over the connection, but when no data is sent for a while, a signaling mechanism is required so the IRAC can indicate the connection is still in use 🫶

3.4.5 Intermediary Traversal Requirements 🌈

same vibes as 3.3.5 🫶 if the IRAC's assigned address is globally routable and nothing between the IRAC and the IRAS does NAPT on the data stream, then there are no additional requirements here ✨ if NAPT is performed, some mechanism must be provided to make those modifications transparent to the IPsec implementation 🛠️

if a firewall at the edge of the host network can't be configured to pass IPsec-suite protocols, a mechanism must be provided that converts the data stream into one the firewall can pass 🧱 and if the firewall can be set up to pass IPsec protocols, that has to happen prior to connection establishment 🔥

3.5 Public System to Target Network 🏨

this one's about a traveling user connecting to the target network from a public system that somebody else owns ✈️ the classic example is an airport kiosk 🛄 it looks a lot like the extranet desktop scenario, except in the extranet case CORP-A might have a trust relationship with CORP-B, whereas here CORP-A may not trust a publicly accessible system at all 🙅‍♀️ a trust relationship between CORP-A and the owner of the public system might exist, but in lots of cases it just won't 💀

3.5.1 Authentication Requirements 🔑

there are two variations of this scenario 👯 in the first, there's no trust relationship between the target network and the borrowed system. in the second, some trust relationship does exist. if there's no trust relationship, machine authentication is out of the question, since it's meaningless in this context 🤖 and because a system like that could easily capture a passphrase, using a static passphrase from it seems super ill-advised 😭

a one-time passphrase would help mitigate the risk of the public system capturing it 🙌 but if you admit that capture is a real threat (aka the system itself is malicious), then you also have to accept that any data sent and received in that session wouldn't be confidential or reliable with respect to that malicious system 😱 and it couldn't be trusted to actually disconnect when the user walks away 🚶‍♀️ so accessing anything non-trivial from a system like that would be imprudent 🙅‍♀️

smartcards are another user authentication option 💳 but a lot of them need a pin or passphrase to "unlock" them, and that means you have to trust the kiosk not to record the pin 👀 so this approach has drawbacks similar to the static passphrase here. the main difference is that the pin or passphrase couldn't be used alone for access in the smartcard case 🔐

where a trust relationship with the owner of the public system does exist, the trust level changes how much risk we're talking about above 📊 for example, if the system owner is trusted enough, using a static passphrase might carry no more risk than it would from a system owned by the target 🫶 but the biggest benefit of that trust relationship is being able to authenticate the machine the user is accessing from 💻 so a security policy requiring remote access only with combined user and machine authentication might be made to work, with extra control over which machines are allowed 🎯

another issue to handle in either case is verifying the identity of the IRAS 👀 if the IRAC were misdirected somehow, a man in the middle attack could happen, and the password it captured could then be used for malicious access to the real IRAS 😨 even a one-time password mechanism offers little protection here. to avert this kind of attack, the IRAC must have some certifiable or secret knowledge of the IRAS before it tries to connect 🔒 and in the case where no trust relationship exists, that just isn't possible 💔

so, to sum it up, here are the authentication requirements for the IRAS and IRAC:

IRAS

• machine authentication MUST be provided.

IRAC

• in cases where no trust relationship exists between the accessed network and the system owner, sensitive data SHOULD NOT be transmitted in either direction.
• in cases where a trust relationship exists between the accessed network and the system owner, machine authentication SHOULD be supported.
• in cases where a trust relationship exists between the accessed network and the system owner, a static passphrase MAY be used in conjunction with machine-level authentication of the IRAC system.
• frequent renewal of user authentication MUST occur

3.5.2 Device Configuration Requirements 🫧

None. 🌸 nothing to configure here, bestie

3.5.3 Policy Configuration Requirements 🫧

None. 🌸 nada, zero, zilch

3.5.4 Auditing Requirements ⏱️

the auditing requirements are the same as the telecommuter scenario, obviously 💅 session start and end times must be collected. reliable session end times need the IRAC to somehow periodically signify that the connection remains active 📶 that's implied if the IRAS gets data from the IRAC over the connection, but when no data is sent for some time, a signaling mechanism is required so the IRAC can say the connection is still in use 🫶

3.5.5 Intermediary Traversal Requirements 🦋

if the address of the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS do NAPT on the data stream, then there are no additional requirements here 🙌 but if NAPT is done on the data stream, some mechanism must be provided to make those modifications transparent to the IPsec implementation 🛠️

4. Scenario Commonalities 🌟

as we look at all these remote access scenarios, a general set of common requirements starts to show up 👑 here's the summary:

• Support for user authentication is required in almost all scenarios
• Machine authentication for the IRAS is required in all scenarios
• A mechanism for providing device configuration for the IRAC is required in most scenarios. Such a mechanism must be extensible.
• Machine authentication for IRAC is generally only useful when combined with user authentication. Combined user and machine authentication is useful in some scenarios.
• Dynamic IRAC policy configuration is useful in several scenarios.
• Most scenarios require auditing for session start/stop times.
• An intermediary traversal mechanism may be required in any of the scenarios.

5. Security Considerations 🔥

okay bestie, this part is SERIOUS 😤 the whole topic of this document is secure remote access 🔐 and security considerations are discussed throughout the document, so pay attention to every single one of them 💜

6. References ✨

okay bestie, here's the reading list 📚 Every source is listed exactly as cited, so you can go check the originals yourself.

[ARCH]      Kent, S. and R. Atkinson, "Security Architecture for the
            Internet Protocol", RFC 2401, November 1998.

[KEYWORDS]  Bradner, S., "Key Words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RADIUS]    Rigney, C., Rubens, A., Simpson, W. and S. Willens,
            "Remote Authentication Dial In User Service (RADIUS)",
            RFC 2865, June 2000.

[IKE]       Harkins, D. and D. Carrel, "The Internet Key Exchange
            (IKE)", RFC 2409, November 1998.

---

7. Acknowledgements 🫶

The editors want to give a massive shoutout to Sara Bitan, Steve Kent, Mark Townsley, Bernard Aboba, Mike Horn, and everyone else in the ipsra working group who dropped helpful comments on this work. you all made this so much better 💖

8. Editors' Addresses 💌

Here's how to reach the editors, exactly as listed:

Scott Kelly
Airespace
110 Nortech Pkwy
San Jose CA 95134 USA

Phone: +1 (408) 941-0500
EMail: scott@hyperthought.com


Sankar Ramamoorthi
Juniper Networks
1194 North Mathilda Ave
Sunnyvale CA 94089-1206 USA

Phone: +1 (408) 936-2630
EMail: sankarr@juniper.net

9. Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2003). All Rights Reserved. the legal bit, but make it cute 🎀

Anyone is allowed to copy and share this document, and to make derivative works that comment on or explain it or help people implement it. You can publish and distribute those copies and works, in whole or in part, with no restrictions of any kind, as long as the copyright notice and this paragraph stay on every copy and derivative work.

The document itself can't be modified in any way. That means you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's translated into a language other than English.

The permissions above are perpetual. The Internet Society and its successors or assigns will never revoke them.

This document and the information in it are 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. 💅

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. and that's the whole doc, bestie, we made it 🦋✨