RFC 3104

RSIP Support for End-to-end IPsec

📅 published October 2001, from ietf

RSIP Support for End-to-end IPsec 🎀

okay bestie, so this is RFC 3104, from the Network Working Group, and it's called "RSIP Support for End-to-end IPsec" 🧚 It was written by G. Montenegro (Sun Microsystems, Inc.) and M. Borella (CommWorks). It's in the Experimental category and it dropped in October 2001. The title block doesn't list anything it obsoletes or updates, so no drama there 💅

Status of This Memo

this memo defines an Experimental Protocol for the Internet community 🦋 it does not specify an Internet standard of any kind. they're literally asking for discussion and suggestions for improvement 💜 and distribution of this memo is unlimited ✨

Copyright (C) The Internet Society (2001). All Rights Reserved. 🌸

IESG Note

okay so the IESG is flagging something important 🚩 the set of documents describing the RSIP technology implies significant host and gateway changes for a complete implementation. 😭 the floating of port numbers can also cause problems for some applications, which means an RSIP-enabled host might not interoperate transparently with existing applications in some cases (e.g., IPsec) 🙈 and there may be significant operational complexities with using RSIP too.

some of these complications are outlined in section 6 of the RFC 3102, plus in the Appendices of RFC 3104. so the costs and benefits of using RSIP should be carefully weighed against other means of relieving address shortage. no shortcuts, bestie 🫶

Abstract

this document proposes mechanisms that let Realm Specific IP (RSIP) handle end-to-end IPsec (IP Security) 🔥

Table of Contents

1. Introduction ..................................................  2
2. Model .........................................................  2
3. Implementation Notes ..........................................  3
4. IKE Handling and Demultiplexing ...............................  4
5. IPsec Handling and Demultiplexing .............................  5
6. RSIP Protocol Extensions ......................................  6
   6.1 IKE Support in RSIP .......................................  6
   6.2 IPsec Support in RSIP .....................................  7
7. IANA Considerations ........................................... 10
8. Security Considerations ....................................... 10
9. Acknowledgements .............................................. 10
References ....................................................... 11
Authors' Addresses ............................................... 12
Appendix A: On Optional Port Allocation to RSIP Clients .......... 13
Appendix B: RSIP Error Numbers for IKE and IPsec Support ......... 14
Appendix C: Message Type Values for IPsec Support ................ 14
Appendix D: A Note on Flow Policy Enforcement .................... 14
Appendix E: Remote Host Rekeying ................................. 14
Appendix F: Example Application Scenarios ........................ 15
Appendix G: Thoughts on Supporting Incoming Connections .......... 17
Full Copyright Statement ......................................... 19

1. Introduction ✨

okay so this document specifies RSIP extensions to enable end-to-end IPsec 🦋 it assumes the RSIP framework as presented in [RSIP-FW], and it specifies extensions to the RSIP protocol defined in [RSIP-P]. other terminology follows [NAT-TERMS].

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 💅

2. Model 🧚

for clarity, the discussion below assumes this model:

   RSIP client              RSIP server                   Host

      Xa                    Na   Nb                       Yb
            +------------+       Nb1  +------------+
   [X]------| Addr space |----[N]-----| Addr space |-------[Y]
            |  A         |       Nb2  |  B         |
            +------------+       ...  +------------+

so hosts X and Y belong to different address spaces A and B, respectively, and N is an RSIP server 👑 N has two addresses: Na on address space A, and Nb on address space B. for example, A could be a private address space, and B the public address space of the general Internet 🌈 also, N may have a pool of addresses in address space B which it can assign to or lend to X.

this document proposes RSIP extensions and mechanisms so an RSIP client X can initiate IKE and IPsec sessions to a legacy IKE and IPsec node Y. to do that, X exchanges RSIP protocol messages with the RSIP server N. this document does not yet address IKE/IPsec session initiation from Y to an RSIP client X 🙈 for some thoughts on that, see Appendix G.

the discussion below assumes that the RSIP server N is examining a packet sent by Y, destined for X. this means "source" refers to Y and "destination" refers to Y's peer, namely, X's presence at N 💖

this document assumes the use of the RSAP-IP flavor of RSIP (except that port number assignments are optional), and on top of that, SPI values are used for demultiplexing. because of this, more than one RSIP client may share the same global IP address 🍓

3. Implementation Notes 📝

the RSIP server N is not required to have more than one address on address space B. RSIP allows X (and any other hosts on address space A) to reuse Nb. because of this, Y's SPD SHOULD NOT be configured to support address-based keying 🙅‍♀️ address-based keying implies that only one RSIP client may, at any given point in time, use address Nb when exchanging IPsec packets with Y. instead, Y's SPD SHOULD be configured to support session-oriented keying, or user-oriented keying [Kent98c]. in addition to user-oriented keying, other types of identifications within the IKE Identification Payload are equally effective at disambiguating who the real client is behind the single address Nb [Piper98] 🔥

because it cannot rely on address-based keying, RSIP support for IPsec is similar to the application of IPsec for remote access using dynamically assigned addresses. both cases impose additional requirements which are not met by minimally compliant IPsec implementations [Gupta]:

Note that a minimally-compliant IKE implementation (which only implements Main mode with Pre-shared keys for Phase I authentication) cannot be used on a remote host with a dynamically assigned address. The IKE responder (gateway) needs to look up the initiator's (mobile node's) pre-shared key before it can decrypt the latter's third main mode message (fifth overall in Phase I). Since the initiator's identity is contained in the encrypted message, only its IP address is available for lookup and must be predictable. Other options, such as Main mode with digital signatures/RSA encryption and Aggressive mode, can accommodate IKE peers with dynamically assigned addresses.

IKE packets are typically carried on UDP port 500 for both source and destination, although the use of ephemeral source ports is not precluded [ISAKMP]. IKE implementations for use with RSIP SHOULD employ ephemeral ports, and should handle them as follows [IPSEC-MSG]:

IKE implementations MUST support UDP port 500 for both source and destination, but other port numbers are also allowed. If an implementation allows other-than-port-500 for IKE, it sets the value of the port numbers as reported in the ID payload to 0 (meaning "any port"), instead of 500. UDP port numbers (500 or not) are handled by the common "swap src/dst port and reply" method.

it's important to note that IPsec implementations MUST be aware of RSIP, at least in some peripheral sense, so they can receive assigned SPIs and perhaps other parameters from an RSIP client 🫶 therefore, bump-in-the-stack (BITS) implementations of IPsec are not expected to work "out of the box" with RSIP 💀

4. IKE Handling and Demultiplexing 🦋

if an RSIP client requires the use of port 500 as its IKE source, this stops that field from being used for demultiplexing 😭 instead, the "Initiator Cookie" field in the IKE header fields must be used for this purpose. this field is a great pick because it's guaranteed to be present in every IKE exchange (Phase 1 and Phase 2), and it's guaranteed to be in the clear (even if subsequent IKE payloads are encrypted) ✨ however, it is protected by the Hash payload in IKE [IKE]. because of this, an RSIP client and server must agree upon a valid value for the Initiator Cookie 🤝

once X and N arrive at a mutually agreeable value for the Initiator Cookie, X uses it to create an IKE packet and tunnels it to the RSIP server N. N decapsulates the IKE packet and sends it on address space B 🧚

the minimum tuple negotiated via RSIP, which is used for demultiplexing incoming IKE responses from Y at the RSIP server N, is:

  • IKE destination port number
  • Initiator Cookie
  • Destination IP address

one problem still remains: how does Y know that it's supposed to send packets to X via Nb? Y is not RSIP-aware, but it is definitely IKE-aware 🧠 Y sees IKE packets coming from address Nb. to stop Y from mistakenly deriving the identity of its IKE peer based on the source address of the packets (Nb), X MUST exchange client identifiers with Y:

  • IDii, IDir if in Phase 1, and
  • IDci, IDcr if in Phase 2.

the proper use of identifiers gives a clear separation between those identities and the source IP address of the packets 👑

5. IPsec Handling and Demultiplexing 🔐

the RSIP client X and server N must arrive at an SPI value to denote the incoming IPsec security association from Y to X. once N and X make sure the SPI is unique within both of their SPI spaces, X communicates its value to Y as part of the IPsec security association establishment process, namely, Quick Mode in IKE [IKE] or manual assignment 💖

this ensures that Y sends IPsec packets (protocols 51 and 50 for AH and ESP, respectively) [Kent98a,Kent98b] to X via address Nb using the negotiated SPI 🌸

IPsec packets from Y destined for X arrive at RSIP server N. they are demultiplexed based on the following minimum tuple of demultiplexing fields:

  • protocol (50 or 51)
  • SPI
  • destination IP address

if N is able to find a matching mapping, it tunnels the packet to X according to the tunneling mode in effect. if N cannot find an appropriate mapping, it MUST discard the packet 🗑️

6. RSIP Protocol Extensions 🌈

the next two sections specify how the RSIP protocol [RSIP-P] is extended to support both IKE (a UDP application) and the IPsec-defined AH and ESP headers (layered directly over IP with their own protocol numbers) 🎀

if a server implements RSIP support for IKE and IPsec as defined in this document, it MAY include the RSIP Method parameter for RSIP with IPsec in the REGISTER_RESPONSE method sent to the client. this method is assigned a value of 3:

   3   RSIP with IPsec (RSIPSEC)

unless otherwise specified, requirements of micro and macro flow-based policy are handled according to [RSIP-P] ⭐

6.1 IKE Support in RSIP

okay so, if X's IPsec implementation can use an ephemeral source port for IKE (we covered this above 🎀), then N can sort incoming IKE traffic by the destination address and port tuple. this is the simplest and most iconic option, so IPsec implementations that work with RSIP SHOULD allow it 💖✨

but if X has to use source port 500 for IKE, there are two ways X and N can end up with a mutually unique Initiator Cookie 🦋

  • Trial and error.
  • Negotiation via an extension of the RSIP protocol.

the trial and error method goes like this 💅 X first grabs the resources it needs to use IPsec (via ASSIGN_REQUEST_RSIPSEC, defined below), then randomly picks an Initiator Cookie and sends the first packet to Y. when it lands at N, the RSIP server checks that the cookie is unique for X's assigned address (Nb). if it's unique, N lets that cookie be used for this and all subsequent packets between X and Y on this RSIP binding 🌸 if it's not unique, N drops the packet 😭

when an IKE packet is determined to be lost, the IKE client will try to retransmit at least three times [IKE]. an RSIP-aware IKE client SHOULD use a different Initiator Cookie for each of those retransmissions 🌈

the chance of an Initiator Cookie collision at N, and then in the retransmissions by X, is basically zero given the 64-bit cookie space 🙈 the birthday paradox says that in a population of 640 million RSIP clients going through the same RSIP server, the chance of a first collision is just 1%. so the trial and error method is preferred over negotiation for these reasons:

  • Simpler implementation requirements
  • It is highly unlikely that more than one round trip between X and N will be necessary.

6.2 IPsec Support in RSIP

this section defines the protocol extensions RSIP needs to support AH and ESP 🧚 the required message types are ASSIGN_REQUEST_RSIPSEC and ASSIGN_RESPONSE_RSIPSEC:

ASSIGN_REQUEST_RSIPSEC

the ASSIGN_REQUEST_RSIPSEC message is how an RSIP client asks for IPsec parameter assignments. an RSIP client MUST request an IP address and SPIs in one message 🎀

if the RSIP client wants to use IPsec to protect a TCP or UDP application, it MUST use the port range parameter (see Appendix A). otherwise, it MUST set the port parameters to the "don't need" value. to do that, it sets the length field to 0 and leaves out both the number field and the port field. this tells the server the client doesn't actually need any port assignments 💖

the client can set the SPI parameter to the "don't care" value (see below). in that case it's asking the server to assign it a valid SPI value to use ✨

or the client can set the SPI parameter to a value it thinks is valid. in that case it's suggesting that value to the server. the server is free to reject the suggestion and send back an appropriate error message, so no drama if that happens 🫶

the format of this message is:

<ASSIGN_REQUEST_RSIPSEC> ::= <Version>
                             <Message Type>
                             <Overall Length>
                             <Client ID>
                             <Address (local)>
                             <Ports (local)>
                             <Address (remote)>
                             <Ports (remote)>
                             <SPI>
                             [Message Counter]
                             [Lease Time]
                             [Tunnel Type]

these are the message-specific error conditions 🙈 the error behavior of ASSIGN_REQUEST_RSIP_IPSEC follows that of ASSIGN_REQUEST_RSAP-IP for all non-IPsec errors.

  • if the client isn't allowed to use IPsec through the server, the server MUST respond with an ERROR_RESPONSE containing the IPSEC_UNALLOWED parameter 💀
  • if the SPI parameter is a "don't care" value and the RSIP server can't allocate ANY SPIs, the RSIP server MUST respond with an ERROR_RESPONSE containing the IPSEC_SPI_UNAVAILABLE error.
  • if an SPI parameter is not a "don't care" value and the RSIP server can't allocate it because the requested address and SPI tuple is already in use, the RSIP server MUST respond with an ERROR_RESPONSE containing the IPSEC_SPI_INUSE error.

ASSIGN_RESPONSE_RSIPSEC

the ASSIGN_RESPONSE_RSIPSEC message is how an RSIP server hands out parameters to an IPsec-enabled RSIP client 🦋

the format of this message is:

<ASSIGN_RESPONSE_RSIPSEC> ::= <Version>
                              <Message Type>
                              <Overall Length>
                              <Client ID>
                              <Bind ID>
                              <Address (local)>
                              <Ports (local)>
                              <Address (remote)>
                              <Ports (remote)>
                              <SPI>
                              <Lease Time>
                              <Tunnel Type>
                              [Address (tunnel endpoint)]
                              [Message Counter]

if the port parameters were set to the "don't need" value in the request (see above), the RSIP server must do the same in the response 🍓

also, RSIP support for IPsec needs this new parameter:

SPI

 Code   Length    Number    SPI             SPI
+------+--------+---------+---------+     +---------+
|  22  |    2   | 2 bytes | 4 bytes | ... | 4 bytes |
+------+--------+---------+---------+     +---------+

the RSIP client sends this in ASSIGN_REQUEST_RSIPSEC messages to ask for a particular number of SPIs to be assigned. the RSIP server also sends it to the client in ASSIGN_RESPONSE_RSIPSEC messages 👑

the "SPI" fields encode one or more SPIs. when a single SPI is specified, the number field is 1 and one SPI field follows the number field. when more than one SPI is specified, the number field shows the total number of SPIs in there, and the parameter can take one of two forms 🌈 if there's one SPI field, the SPIs are considered contiguous, starting at the SPI number given in that field. or there can be a number of SPI fields equal to the value of the number field. the number of SPI fields can be worked out from the value of the length field 🧠

sometimes you need to specify a "don't care" value for one or more SPIs. to do that, set the length field to 2 (to account for the 2 bytes in the Number field), set the number field to the number of SPIs you need, and leave out all the SPI fields. the value of the number field MUST be greater than or equal to one 🫶

7. IANA Considerations

all of the designations below are tentative 🧚

  • RSIP IPsec error codes (see below).
  • ASSIGN_REQUEST_RSIP_IPSEC message type code.
  • SPI parameter code.

8. Security Considerations

okay this section is serious, bestie 🚨 this document doesn't add any security issues to the ones already posed by NAT or normal routing operations. current routing decisions are typically based on a tuple with only one element: the destination IP address. this document just adds more elements to the tuple 💅

also, by allowing an end-to-end mode of operation and by introducing a negotiation phase to address reuse, the mechanisms described here are more secure and less arbitrary than NAT 👑

now the word of caution 🙈 SPI values are meant to be semi-random, so they also work as anti-clogging tokens that reduce off-the-path denial-of-service attacks. however, RSIP support for IPsec makes SPIs a negotiated item. in addition to being unique values at the receiver X, they must also be unique at the RSIP server, N. limiting the range of SPI values available to RSIP clients reduces their entropy slightly 😭

9. Acknowledgements

many thanks to Bernard Aboba, Vipul Gupta, Jeffrey Lo, Dan Nessett, Gary Jaszewski and Prakash Iyer for the helpful discussions 🫶💖

References

  • [Gupta] Gupta, V., "Secure Remote Access over the Internet using IPSec", Work in Progress.
  • [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
  • [ISAKMP] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
  • [IPSEC-MSG] Ted Ts'o, message to the IETF's IPsec mailing list, Message-Id:<199911232216.RAA01932@trampoline.thunk.org>, November 23, 1999.
  • [Jenkins] Jenkins, T., "IPsec Rekeying Issues", Work in Progress.
  • [Kent98a] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406, November 1998.
  • [Kent98b] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
  • [Kent98c] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [Piper98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
  • [NAPT] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
  • [NAT-TERMS] Srisuresh, P. and M. Holdredge, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
  • [RSIP-FW] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: A Framework", RFC 3102, October 2001.
  • [RSIP-P] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.

Authors' Addresses

Gabriel E. Montenegro
Sun Microsystems
Laboratories, Europe
29, chemin du Vieux Chene
38240 Meylan
FRANCE

Phone: +33 476 18 80 45
EMail: gab@sun.com


Michael Borella
CommWorks
3800 Golf Rd.
Rolling Meadows IL 60008

Phone: (847) 262-3083
EMail: mike_borella@commworks.com

Appendix A: On Optional Port Allocation to RSIP Clients 🎀

Okay so, even though SPIs (not ports) are what the RSIP server uses to sort packets, the server can still hand out mutually exclusive port numbers to its RSIP clients 💅. If it doesn't, two RSIP clients behind the same IP address could try an IPsec session with the same server using the same source ports, and that's a whole mess 😭.

+-------------+
| RSIP client |
|      X1     +--+
|             |  |         +-------------+
+-------------+  |         |             |Nb
                 +---------+ RSIP server +----------------
+-------------+  |         |      N      |
| RSIP client |  |         +-------------+
|      X2     +--+ private                     public
|             |  | network                     network
+-------------+  |
                 |
                 |

Say we've got hosts X1 and X2 from the diagram above 👀. They're both using the public address Nb, and they're both trying to reach an external server Y on port 80. If they're using IPsec but nobody gave them mutually exclusive port numbers, they could both pick the same ephemeral port to talk to Y on port 80. Let's say X1 goes first. It finishes its IKE negotiation and starts chatting with the public server over IPsec 🦋.

Then X2 starts its own IKE session and sends its identification to the public server. The server's SPD requires that different identities use different flows (port numbers), so X2's IKE negotiation fails 😤. X2 then has to keep guessing ephemeral ports until it finds one that isn't already in use by any security association between the public server and any of the RSIP clients in the private network. Main character struggle, honestly 💀.

Every one of those retries costs round-trip times and CPU usage 🥲. So, as a nice favour to its RSIP clients, an RSIP server may also assign mutually exclusive port numbers to its IPsec RSIP clients 🎀.

Even with proper port allocation, an RSIP server can't stop them from being misused, because it can't look at the port fields in packets the RSIP clients have encrypted 🙈. Presumably, if the RSIP clients went through the trouble of negotiating port numbers, it's in their best interest to stick to those assignments 🫶.

Appendix B: RSIP Error Numbers for IKE and IPsec Support 💜

This section gives descriptions for the error values in the RSIP error parameter, beyond the ones already defined in [RSIP-P] ✨.

401: IPSEC_UNALLOWED.  The server will not allow the client
     to use end-to-end IPsec.

402: IPSEC_SPI_UNAVAILABLE.  The server does not have an SPI
     available for client use.

403: IPSEC_SPI_INUSE.  The client has requested an SPI that
     another client is currently using.

Appendix C: Message Type Values for IPsec Support 🦋

This section defines the values given to RSIP message types beyond the ones defined in [RSIP-P] 🌸.

22  ASSIGN_REQUEST_RSIPSEC

23  ASSIGN_RESPONSE_RSIPSEC

Appendix D: A Note on Flow Policy Enforcement 🔥

An RSIP server might not be able to enforce local or remote micro-flow policy when a client uses ESP for end-to-end encryption 🔐, because all the TCP/UDP port numbers get encrypted. Lowkey tragic. However, if AH without ESP is used, micro-flow policy is enforceable 🙌. Macro-flow policy will always be enforceable ✨.

Appendix E: Remote Host Rekeying 🌈

Every so often, a remote host that an RSIP client has set up an IPsec security association (SA) with will rekey [Jenkins] 🔄. SA rekeying is only a problem for RSIP when the client uses IKE port 500 and the rekey is for ISAKMP phase 1 (the ISAKMP SA) 😬. The issue is that the remote host sends IKE packets to port 500 with a brand-new initiator cookie. The RSIP server won't have a mapping for that cookie, so it SHOULD drop the packets 💀. That deletes the ISAKMP SA between the RSIP client and the remote host, and things can get undefined, since current implementations handle rekeying in a bunch of different ways 🙈.

If the RSIP client uses an ephemeral source port, rekeying isn't a problem for RSIP 🙌. If that isn't possible, there are a few RSIP client behaviours that might cut down on how often this happens, but they can't guarantee it goes away 🥺.

  • The RSIP client's IKE implementation gets a shorter ISAKMP SA lifetime than is typical. That will probably make the RSIP client rekey the ISAKMP SA before the remote host does 🕰️. Since the RSIP client picks the Initiator Cookie, there's no trouble routing incoming traffic at the RSIP server 🎀.
  • The RSIP client ends the ISAKMP SA as soon as the first IPsec SA is up ⚡. This might help a bit if the SA is coarse-grained. On the flip side, it makes things worse if the SA is fine-grained (so other application-level connections can't reuse it) and the remote host needs to open sockets back to the RSIP client 😤.

Note that UDP is unreliable, so the ephemeral source approach is basically the only robust solution 💖.

Appendix F: Example Application Scenarios 🧚

This section quickly walks through some examples of how RSIP can be used to enable IPsec applications that otherwise wouldn't be possible 🌟.

The SOHO (small office, home office) scenario 🏠

+----------+
|RSIP      |
|client X1 +--+
|          |  |  +-------------+            +-------+
+----------+  |  |NAPT gateway |            |public |
              +--+ and         +--.......---+IPsec  |
+----------+  |  |RSIP server  |            |peer Y |
|RSIP      |  |  +-------------+            +-------+
|client X2 +--+ private             public
|          |  | "home"             Internet
+----------+  | network
              |
              |

Picture a small private "home" network in somebody's house, where the RSIP clients X1 and X2 have to go through the RSIP server N to reach the outside world 🏡. N is hooked up to an ISP and gets a single address that all its clients have to share, so N has NAPT functionality 🔀. Now X1 wants to set up an IPsec SA with peer Y. That works because N is also an RSIP server with the IPsec support defined in this document 🎉. Y is IPsec-capable but isn't RSIP aware 🤷‍♀️. This is probably the most typical application scenario, bestie 💅.

The same thing applies to the ROBO (remote office, branch office) scenario 💼.

The Roadwarrior scenario 🏍️

+---------+              +------------+   +----------+
|RSIP     |              |Corporate   |   | IPsec    |
|client X +--..........--+Firewall    +---+ peer Y   |
|         |    public    | and        |   | (user's  |
+---------+   Internet   |RSIP server |   | desktop) |
                         | N          |   |          |
                         +------------+   +----------+
                               private corporate
                               network

In this one, a remote user with a laptop gets onto the Internet, maybe through PPP or DHCP 💻. They want to reach their corporation's private network 😮‍💨. Using mechanisms not specified in this document, the RSIP client on the laptop runs an RSIP authentication and authorization phase with the RSIP server at the firewall 🔐. Once that's done, the IPsec extensions to RSIP defined here set up an IPsec session with a peer, Y, which lives inside the corporate network 🏢. Y could be, for example, the user's usual desktop back at the office 🖥️. The corporate firewall complex uses RSIP to selectively enable IPsec traffic between internal and external systems 🛡️.

Note that this could also be flipped, so an internal system (Y) starts and sets up an IPsec session with an external IPsec peer (X) 🔄.

Appendix G: Thoughts on Supporting Incoming Connections 🌷

Incoming IKE connections are way easier to support when the peer Y can start IKE exchanges to a port other than 500 🎯. In that case, the RSIP client would allocate that port at the RSIP server using ASSIGN_REQUEST_RSAP-IP. Alternatively, if the RSIP client can allocate an IP address at the RSIP server using ASSIGN_REQUEST_RSA-IP, then Y can just start the IKE exchange by going to port 500 at that address 🥳.

Now, if there's only one address Nb that has to be shared by the RSIP server and all its clients, and Y can only send to port 500, things get way harder 😩. At any given time, the combo of address Nb and UDP port 500 can only be registered and used by one RSIP system (clients and server included) 🚧.

Fixing this would mean demultiplexing the incoming IKE connection request based on something other than the port and address combo 🧩. One idea is to register an identity first, using a new RSIP command called LISTEN_RSIP_IKE. Note that the identity can't be the IKE responder's (the RSIP client's) but has to be the initiator's (Y's) 🎀. The reason is that IKE Phase 1 only lets the sender include its own identity, not the intended recipient's (both are allowed in Phase 2, FYI 💅). On top of that, the identity has to be in the clear in the first incoming packet so the RSIP server can use it to demultiplex. That rules out all the variants of Main Mode and Aggressive Mode with Public Key Encryption (and Revised Mode of Public Key Encryption), since they encrypt the ID payload 🔒.

The only Phase 1 variants that allow incoming IKE sessions are Aggressive Mode with signatures or with pre-shared keys 🗝️. Because this scheme has the RSIP server demultiplexing based on the identity of the IKE initiator, it's conceivable that only one RSIP client at a time can register interest in handling requests from any given peer Y 😬. It also means there can't be more than one RSIP client available to any unspecified peer Y 🙃.

Once the IKE session is up, IPsec gets set up the way discussed in this document 🔧. That means the RSIP client and the RSIP server agree on an incoming SPI value, which then gets communicated to the peer Y as part of Quick Mode ✨.

The alternate address and port combo has to be discovered by the remote peer using methods like manual configuration, or the use of KX (RFC2230) or SRV (RFC2052) records 🔍. It might even be possible for the DNS query itself to trigger the above mechanisms, so everything's ready for the incoming IKE session that's about to start 🌸. That kind of mechanism would let more than one RSIP client be available at any given time, and each one could respond to IKE initiations from unspecified peers 🎉. But the DNS query isn't guaranteed to happen 🥲. For example, the result of the query could get cached and reused after the RSIP server has stopped listening for a given IKE peer's identity 🙈.

Because of the limits that come with relying on the identity of the IKE initiator, the only practical way to support incoming connections is for the peer Y to start the IKE session on a port other than 500 💖.

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

Okay bestie, here's the legal bit 💅 You're allowed to copy this document and share it with others, and you can make derivative works that comment on or explain it or help people implement it, and publish and distribute those too, in whole or in part, with no restrictions at all. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work. ✨ The document itself can't be modified in any way, so no removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you're developing Internet standards (then the copyright procedures in the Internet Standards process must be followed) or when you're translating it into a language other than English. 🌈

These permissions are forever 🦋 The Internet Society and its successors or assigns will never take them back.

This document and the information in it 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. 🙈 Translation: no guarantees, no promises, just vibes.

Acknowledgement 🎀

Funding for the RFC Editor function is currently provided by the Internet Society. 🫶

📦 where this page comes from