RFC 2356

RFC 2356: Sun's SKIP Firewall Traversal for Mobile IP 🎀 (Part 1 of 5)

Okay bestie, so this RFC is from June 1998, written by G. Montenegro and V. Gupta over at Sun Microsystems, Inc. It's filed under the Network Working Group as Informational, which means it's sharing info and is NOT an Internet standard 💅. The header doesn't list any RFCs it obsoletes or updates, so it's just doing its own thing 🦋.

---

Status of This Memo ✨

This memo gives information to the Internet community. It doesn't specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸.

Copyright Notice 🔐

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

Abstract 💜

Okay so the Mobile IP spec is what lets a mobile host keep using the same IP address even when it moves to a different point of attachment on the network. That's iconic 😭. But mobility comes with higher security risks than staying put, ngl, because your traffic might take totally unforeseen network paths with security characteristics nobody knows or can predict 💀. The Mobile IP spec doesn't make any provisions for securing data traffic, so this doc fills that gap 🫶.

The mechanisms here let a mobile node chilling on a public part of the internet negotiate access past a SKIP firewall, and build a secure channel back into its home network 🔥.

They also let the mobile node roam into regions that (1) impose ingress filtering, and (2) use a different address space. Main character energy, no cap ✨.

Table of Contents 📑

1. Introduction ...............................................    2
2. Mobility without a Firewall ................................    4
3. Restrictions imposed by a Firewall .........................    4
4. Two Firewall Options: Application relay and IP Security ....    5
4.1 SOCKS version 5 [4] .......................................    5
4.2 SKIP [3] ..................................................    6
5. Agents and Mobile Node Configurations ......................    8
6. Supporting Mobile IP: Secure Channel Configurations ........    9
6.1 I: Encryption only Outside of Private Network .............    9
6.2 II: End-to-End Encryption .................................   10
6.3 III: End-to-End Encryption, Intermediate Authentication ...   10
6.4 IV: Encryption Inside and Outside .........................   10
6.5 Choosing a Secure Channel Configuration ...................   11
7. Mobile IP Registration Procedure with a SKIP Firewall ......   11
7.1. Registration Request through the Firewall ................   12
7.1.1. On the Outside (Public) Network ........................   13
7.1.2. On the Inside (Private) Network ........................   14
7.2. Registration Reply through the Firewall ..................   14
7.2.1. On the Inside (Private) Network ........................   15
7.2.2. On the Outside (Public) Network ........................   15
7.3. Traversal Extension ......................................   16
8. Data Transfer ..............................................   18
8.1. Data Packet From the Mobile Node to a Correspondent Node .   18
8.2. Data Packet From a Correspondent Node to the Mobile Node .   19
8.2.1 Within the Inside (Private) Network .....................   20
8.2.2. On the Outside (Public) Network ........................   21
9. Security Considerations ....................................   21
Acknowledgements ..............................................   22
References ....................................................   22
Authors' Addresses ............................................   23
Full Copyright Statement ......................................   24

1. Introduction 🌈

This doc spells out what support is needed at the firewall, the Mobile IP [1] home agent, and the Mobile IP mobile node, so the mobile node can reach a private network from the Internet 🧚. For example, a company employee could plug their laptop into some Internet access point by:

1. Dialing into a PPP/SLIP account on an Internet service provider's network.
2. Connecting into a 10Base-T or similar LAN network available at, for example, an IETF terminal room, a local university, or another company's premises.

Notice that in these examples, the mobile node's interface (PPP or 10Base-T) is set up with an IP address that's different from the one it uses "normally" (i.e. at the office) 👀. And the IP address isn't necessarily a fixed assignment either. It might be given out temporarily and dynamically at the start of the session (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case) ✨.

The discussion below assumes a network setup with a private network separated by a firewall from the general Internet, aka the public network 🍓. The systems involved are:

• Private Network: A protected network that's separated from the Internet by hosts enforcing access restrictions (firewalls). A private network may use a private address space, and its addresses may not even be routable by the general internet 🔒.
• Public Network: The Internet at large. Hosts can communicate with each other throughout the public network without firewall-imposed restrictions 🌍.
• Mobile Node (MN): Its permanent address falls within the range of the private network. The user takes the system out of its home network and connects it to the Internet at another point. The mechanisms outlined here make this mobility transparent: the mobile node keeps accessing its home network and its resources exactly as if it were still inside it 🫶. Notice that when the mobile node leaves its home network, it may migrate both within and outside of the private network's boundaries. As defined by Mobile IP [1], a mobile node uses a care-of address while roaming 🦋.
• Home Agent (HA) for the mobile node: Serves as a location registry and router as described in the Mobile IP IETF draft 📍.
• Foreign Agent (FA): Serves as a registration relayer and care-of address for the mobile node as described in the Mobile IP IETF draft 🤝.
• Correspondent Node (CH): A system that's exchanging data packets with the mobile node 💌.
• Firewall (FW): The system (or collection of systems) that enforces access control between the private network and the general Internet. It may do this through a combination of functions such as application gatewaying, packet filtering, and cryptographic techniques 🔥.

The mechanisms in this doc let a mobile node out on a public part of the network negotiate access past a SKIP firewall, and build a secure channel into its home network. This lets it talk to correspondent nodes that belong to the private network, and, if bi-directional tunnels are used, to external hosts that are reachable when the mobile node is at home 🎀. The mobile node gets the same level of connectivity and privacy as it does when it's in its home network. Iconic 👑.

This doc does NOT address the scenario where the mobile node tries to access its private network while it's inside another private network 🙅‍♀️.

Sections 2 and 3 give an overview of the environment and the restrictions it imposes. Section 4 looks at firewall technologies. Section 5 discusses the best mode of operation for the participating entities from the point of view of Mobile IP. Section 6 covers possible configurations for the secure channel. Finally, packet formats are the topic of sections 7 and 8 💖.

2. Mobility without a Firewall 🏡

Say the mobile node is roaming around the general Internet, but its home network isn't protected by a firewall. That's typically found in academic environments, as opposed to corporate networks 🎓.

This works as Mobile IP [1] prescribes. The only catch is that the mobile node would most probably operate with a co-located address instead of using a separate foreign agent's care-of address. Why? At least in the near term, it's way more likely to be able to secure a temporary care-of address than to find a foreign agent already deployed at the site you're visiting 😭. For example:

• Internet Service Provider: pre-assigns customers IP addresses, or assigns them out dynamically via PPP's address negotiation.
• An IETF terminal room may pre-assign addresses for your use or offer DHCP services.
• Other locations probably would offer DHCP services.

3. Restrictions imposed by a Firewall 🚧

The firewall puts restrictions on packets entering or leaving the private network. Packets aren't allowed through unless they conform to a filtering specification, or unless there's a negotiation involving some sort of authentication 🔐.

There's another restriction, imposed by the separation between private addresses and general Internet addresses. Strictly speaking, this isn't imposed by a firewall, but by the characteristics of the private network 🙃. For example, if a packet destined to an internal address originates in the general Internet, it will probably not be delivered. It's not that the firewall drops it. Rather, the Internet's routing fabric is unable to process it. This triggers an ICMP host unreachable packet sent back to the originating node 💀.

Because of this, the firewall MUST be explicitly targeted as the destination node by outside packets seeking to enter the private network. The routing fabric in the general Internet will only see the public address of the firewall and route accordingly. Once the packet arrives at the firewall, the real packet destined to a private address is recovered 🦋.

4. Two Firewall Options: Application relay and IP Security 🛡️

Before we dive into any details, let's look at two technologies that may provide firewall support for mobile nodes:

• application relaying or proxying, or
• IP Security.

To understand the implications, let's examine two specific schemes that accomplish the above: SOCKS version 5 and SKIP 🧚‍♀️✨

4.1 SOCKS version 5 [4] ✨

okay bestie, first up is SOCKS version 5 [4] 💅 There's an effort in the authenticated firewall traversal WG (aft) at the IETF to create a common interface for application relays 🌸

The proposal is a revised spec of the SOCKS protocol. Version 5 has been extended to include UDP services too 🦋 With SOCKS, the mobile node (or another node acting on its behalf) has to set up a TCP session to exchange UDP traffic with the FW. It also has to use the SOCKS library to encapsulate the traffic meant for the FW. Here are the steps for a SOCKS solution:

• TCP connection established to port 1080 (1.5 round trips)
• version identifier/method selection negotiation (1 round trip)
  • method-dependent negotiation. For example, the Username/Password Authentication [5] takes 1 round trip:
    1. client sends a Username/Password request
    2. FW (server) responds
  • the GSS-API negotiation takes at least 3 round trips:
    1. client context establishment (at least 1 round trip)
    2. client initial token/server reply (1 round trip)
    3. message protection subnegotiation (at least 1 round trip)
• (finally) SOCKS request/reply (1 round trip)

So that's a minimum of 4 (6 with GSS-API) round trips before the client can pass data through the FW using this header 😩

   +----+------+------+----------+----------+----------+
   |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
   +----+------+------+----------+----------+----------+
   | 2  |  1   |  1   | Variable |    2     | Variable |
   +----+------+------+----------+----------+----------+

Bear in mind that all of the above has to be done each time the mobile registers a new care-of address. On top of that inefficiency, this scheme means we have to use UDP to encapsulate IP datagrams. There's at least one commercial network doing this, but it's not the best solution 🙈

Also, SOCKS defines how to establish authenticated connections, but right now it doesn't provide a clear solution for encrypting the traffic 🔒

This header carries the relay information that all parties need to reach the ones who aren't directly reachable 🧚

4.2 SKIP [3]

Alternatively, the traffic from the mobile node to the firewall could be encrypted and authenticated using a session-less IP security mechanism like SKIP ✨ That means no need to set up a session just to exchange UDP traffic with the firewall 🙌

A SKIP-based solution is very attractive here, because no round trip times get burned before the mobile node and the firewall achieve mutual trust. The firewall can start relaying packets for the mobile node as soon as it gets the first one 🚀 Of course, this implies SKIP is used with AH [7], so authentication info lives in each packet. Encryption with ESP [6] is also assumed, since the Internet at large is considered a hostile environment 💀 An ESP transform that gives both authentication and encryption could be used, in which case the AH header doesn't need to be included.

The firewall and the mobile node may already be configured with each other's authenticated Diffie-Hellman public components (also known as public values). Or they could swap them in real time using any of the mechanisms SKIP defines (an on-line certificate directory service or a certificate discovery protocol) 🎀 Home agents and the firewall also MUST have, be able to exchange or obtain each other's public components 👑

There are other proposals besides SKIP for IP layer security. But they're session-oriented key management solutions, and they typically need negotiations spanning several round-trip times before cryptographically secure communication is possible 😤 They raise similar concerns to the ones we covered for SOCKS-based solutions. Others have reached similar conclusions about how important session-less key management is for Mobile IP applications [8] 🦋

Another perk of SKIP is its support for nomadic applications 🧳 Normally, two hosts talking over a secure IP layer channel use the IP source and destination addresses on incoming packets to find the right security association. The SKIP header can easily supersede this default by including the key ID the recipient must use to get the right certificate.

The key ID is specified by two fields in the SKIP header:

1. a name space identifier (NSID) to indicate which of the possible name spaces is being used, and,
2. a master key identifier (MKID) that uniquely indicates (within the given name space) an id to use in fetching the proper certificate.

For example, if you set NSID to 1 and MKID to its home address, a mobile node is telling the receiver "ignore the IP source and use my home address instead to look up my public component" 🏠 Setting NSID to 8 enables using Unsigned Diffie-Hellman (UDH) certificates 🔑

In this case, the MKID is set to the MD5 hash of the DH public component [10].

On top of the NSID/MKID feature, Mobile IP is best supported by a proper policy at the SKIP firewall: a "nomadic" access control list entry 📜 This is an entry filtered by key ID instead of by IP source address, which is the usual case. It translates to "allow access from any IP source address for a given NSID/MKID combination" 💖 Plus, incoming packets MUST have an AH header. That way, after properly authenticating them, the firewall sets up a "current address" or "dynamic binding" for the nomadic host. The NSID/MKID combo determines which key gets used with the nomadic host [9] 🌈

This works for Mobile IP because the mobile node always initiates contact. So the SKIP firewall gets a chance to learn the mobile node's "current address" from an incoming packet before it tries to encrypt an outgoing one 🥰

However, this rules out simultaneous bindings by a mobile node. At the firewall, the last Registration Request sent by the mobile node replaces the association between its permanent address and any earlier care-of address. To support simultaneous bindings, the firewall has to be able to interpret Mobile IP registration messages 😭

Section 7.2.2 discusses another perk of making the firewall understand Mobile IP packet formats 👀

In what follows, we assume a SKIP-based solution. 💅

5. Agents and Mobile Node Configurations ✨

Depending on which address it uses as its tunnel endpoint, the Mobile IP protocol specifies two ways a mobile node can register a mobility binding with its home agent 🧭

• a) an address advertised for that purpose by the foreign agent
• b) an address belonging to one of the mobile node's interfaces (i.e. operation with a co-located address).

From the firewall's point of view, the main difference between these two cases comes down to which node prepares the outermost encrypting encapsulation 🎀 The firewall MUST be able to obtain the Diffie-Hellman public component of the node that creates the outermost SKIP header in an incoming packet. This is only possible to guarantee in case "b", because the mobile node and the firewall both belong to the same administrative domain. It gets even messier when the mobile node sends a Registration Request. Here, the foreign agent isn't just a relayer. It actually examines the packet the mobile node sent and modifies its agent services accordingly 🫠

Basically, assuming the current Mobile IP spec and the current lack of trust in the internet at large, only case "b" is possible. Case "a" would need an extension (e.g. a "relay" Registration Request) plus code changes at the home agent, the firewall and the foreign agent 🛠️

Assuming the firewall offers a secure relay service (i.e. decapsulation and forwarding of packets), the mobile node can reach addresses inside the private network by encapsulating its packets in a SKIP header and sending them to the firewall 🦋

So, it's simplest to assume the mobile node operates with a co-located address 💖

6. Supporting Mobile IP: Secure Channel Configurations 🌸

The mobile node takes part in two different types of traffic: the Mobile IP registration protocol and data. To keep things simple, the following discussion evaluates the different secure channel configurations by looking at the initial Registration Request the mobile node sends to its home agent 📨

Assuming the mobile node operates with a co-located address, it can talk directly to the firewall. The firewall is able to reach the home agent in the private network. Also, the firewall MUST be able to authenticate the mobile node 🔐

The channel configurations below all assume the mobile node operates with a co-located address. The region between the HA (home agent) and the FW (firewall) is a private network. The region between the FW and the MN (mobile node) is the outside or public network 🌍

6.1 I: Encryption only Outside of Private Network

   HA            FW                        MN
                  <=====================>  SKIP (AH + ESP)
    <----------------------------------->  Registration Request path

In this setup, the traffic is only encrypted between the mobile node out on the general Internet and the firewall's external interface. That's the minimum required 🙌 It's the most desirable configuration, since the more expensive encrypted channel is only used where it's necessary: on the public network 💅

6.2 II: End-to-End Encryption

Another possible configuration extends the encrypted tunnel through the firewall 🚇

   HA            FW                        MN
    <===================================>  SKIP (AH + ESP)
    <----------------------------------->  Registration Request path

This limits the firewall to a simple packet relay or gatewaying function. Even though this could be done by using the proper destination NSID in the packet, in practice it's probably unrealizable 😬 The reason is that this option probably isn't very popular with computer security personnel. Authentication isn't carried out by the firewall but by the home agent, and the home agent's security is potentially much weaker than the firewall's 🙈

6.3 III: End-to-End Encryption, Intermediate Authentication

A third alternative lets the firewall be party to the security association between the home agent and the mobile node 🤝 After verifying authentication (AH header), the firewall forwards the encrypted packet (ESP hdr) to the home agent.

   HA            FW                        MN
                  <+++++++++++++++++++++>  SKIP authentication
    <===================================>  SKIP encryption
    <----------------------------------->  Registration Request path

Here, SKIP provides intermediate authentication with end-to-end security. Although possible, this option means the participating entities have to disclose their pairwise long-term Diffie-Hellman shared secret to the intermediate node 😱

Whereas Option 2 above is probably not agreeable to security and system administration personnel, option 3 is unsavory to the end user 💀

6.4. IV: Encryption Inside and Outside 💖

HA            FW                        MN
 <============><=====================>  SKIP (AH + ESP)
 <----------------------------------->  Registration Request path

Okay, bestie, this one is giving full armor 🛡️✨ Traffic gets encrypted on the public internet AND on the private network. On the public side, the encryption is set by a security association between the mobile node and the firewall. On the private side, it's set by a security association between the home agent and the firewall. Double protection, no cap 🔐💅

6.5. Choosing a Secure Channel Configuration 🧩

Okay so there's a little problem with options 2 and 3 🥺 Their end-to-end channel pieces assume the mobile node and the home agent can just talk to each other directly. Usually that's not the case! The internet routing fabric might not have routes to addresses that belong to private networks, and the private routing fabric might ignore how to route to public addresses. Or doing so might be administratively restricted 🙃 So the packets have to be addressed directly to the firewall, and then indirectly (through some tunneling or relaying capability) to the real destination on the other side of the firewall. Main character energy for the firewall, honestly 🧱🌸

Options 1 and 4 are basically equivalent. Option 4 might feel like overkill, since it encrypts even inside the private network, and that's usually not necessary 🙈 But even inside the private network, the home agent does need to add an encapsulation (not necessarily encrypted) so it can direct datagrams to the mobile node through the firewall. The type of encapsulation is what makes options 1 and 4 different. Option 4 uses SKIP, while option 1 uses a cleartext encapsulation mechanism. You could get that by using IP in IP encapsulation [2], for example 🎀

Options 1 and 4 are mostly interchangeable. The big difference is that option 1 doesn't protect the data from eavesdroppers inside the private network itself. That might be a no-go in some situations 😬 For example, traffic from certain departments in a company (like payroll or legal) might need to stay encrypted while it travels through other parts of the company 🔒

Being conservative here, the rest of this document assumes option 4 (meaning traffic is encrypted on the general Internet, as well as within the private network. 💜

Since the firewall is part of the security associations that govern encryption on both the public and private networks, it can always inspect the traffic going between the home agent and the mobile node 👀 If that worries you, the home agent and mobile node could set up a bi-directional tunnel and encrypt it 🫶

7. Mobile IP Registration Procedure with a SKIP Firewall 🦋

When a mobile node is roaming inside a private network, it sends Registration Requests straight to its home agent 🏠 But on the public Internet, it MUST encapsulate the original Registration Request in a SKIP packet destined to the firewall. Also, the mobile node MUST distinguish between "inside" and "outside" addresses. One way to do that is with a set of rules that define the address ranges. Real installations can be tricky, though, because it can be really hard to say exactly what counts as a private address and what doesn't 😭

Direct human input is super effective here. The user may just know that the current point of attachment is outside their private network, and it should be possible to pass that knowledge along to the mobile node software 🙋‍♀️

The home agent also has to distinguish between "inside" and "outside" addresses, but it doesn't get the benefit of direct user input. So it should be possible for the mobile node to communicate that knowledge to the home agent. To make that happen, we define a Traversal Extension to the Registration Requests and Replies. Bonus: this extension is also useful when you're traversing multiple firewalls ✨

Even with all of the above, errors in judgement are expected 🤷‍♀️ So the firewall SHOULD be configured so it still performs its relaying duties even when a mobile node with an inside care-of address unnecessarily asks for them 🛟

When the mobile node arrives at a foreign net and acquires a care-of address, it must first (before any data transfer is possible) start a registration procedure. This is an authenticated exchange where the mobile node tells its home agent where it currently is (its current care-of address), and then gets an acknowledgement back. This first step is so convenient, because the SKIP firewall can use it to dynamically configure its packet filter 🧠💅

The rest of this section shows the packet formats used. Section 7.1 covers how a mobile node sends a Registration Request to its home agent through the SKIP firewall. Section 7.2 covers how the home agent sends the matching Registration Reply back to the mobile node. Section 7.3 defines the Traversal Extension for use with Registration Requests and Replies 📚

7.1. Registration Request through the Firewall 🚪

The mobile node arrives at a foreign net and, using the mechanisms Mobile IP defines, figures out that it has moved away from home 🧳 It acquires a local address at the foreign site and composes a Registration Request meant for its home agent. The mobile node must decide whether this packet needs to be processed by SKIP or not.

This isn't a simple rule that's triggered by one destination address 🙅‍♀️ It must be applied whenever the following conditions are met:

• a) the mobile node is using a care-of address that does not belong to the private network (i.e. the mobile node is currently "outside" its private network), and
• b) either of:
  • b1) the source address of the packet is the mobile node's home address (e.g. this packet's endpoints are dictated by a connection initiated while at home), or
  • b2) the source address of the packet is the care-of address and the destination address belongs to the private network

Since these conditions are all about mobility, it's best for the Mobile IP function in the node to evaluate them, and then request the appropriate security services from SKIP 🎯

7.1.1. On the Outside (Public) Network 🌍

The SKIP module must use the firewall destination address and the firewall's certificate to address and encrypt the packet. It encrypts it using SKIP combined with the ESP [6] protocol, and possibly the AH [7] protocol 🔐

The SKIP header's source NSID equals 1, which indicates that the Master Key-ID is the mobile node's home address. Notice that the IP packet's source address corresponds to the care-of address, which is an address whose corresponding public component is unknown to the firewall 👀

It's also possible to use Unsigned Diffie-Hellman public components [10]. This greatly reduces SKIP's infrastructure requirements, because there's no need for a Certificate Authority 🎉 Of course, for this to work, the principals' names MUST be securely communicated.

REGISTRATION REQUEST: BETWEEN THE MOBILE NODE AND THE FIREWALL
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+

  IP Hdr (SKIP):
     Source          mobile node's care-of address
     Destination     firewall's public (outside) address

  SKIP Hdr:
     Source          NSID = 1
                     Master Key-ID = IPv4 address of the mobile node
     Destination     NSID = 0
                     Master Key-ID = none
  Inner IP Hdr:
     Source          mobile node's care-of address
     Destination     home agent's address

7.1.2. On the Inside (Private) Network 🏡

The SKIP Firewall's dynamic packet filtering uses this information to set up a dynamic binding between the care-of address and the mobile node's permanent home address 🪄

The destination NSID field in the packet above is zero, which prompts the firewall to process the SKIP header and recover the internal packet. Then it delivers the original packet to another outbound interface, because it's addressed to the home agent (an address inside the private network). Assuming secure channel configuration number 4, the firewall encrypts the packet using SKIP before forwarding it to the home agent 💜

REGISTRATION REQUEST: BETWEEN THE FIREWALL AND THE HOME AGENT
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+

  IP Hdr (SKIP):
     Source          firewall's private (inside) address
     Destination     home agent's address

  SKIP Hdr:
     Source          NSID = 0
                     Master Key-ID = none
     Destination     NSID = 0
                     Master Key-ID = none
  Inner IP Hdr:
     Source          mobile node's care-of address
     Destination     home agent's address

7.2. Registration Reply through the Firewall 🔁

The home agent processes the Registration Request and composes a Registration Reply 📬 Before responding, it checks the care-of address the mobile node reported, and figures out whether or not it's an outside address. If it is, the home agent needs to send all traffic back through the firewall. To do that, the home agent can encapsulate the original Registration Reply in a SKIP packet destined to the firewall (i.e. we assume secure channel configuration number 4) 🫶

7.2.1. On the Inside (Private) Network 🏠

The packet from the home agent to the mobile node through the SKIP Firewall has the same format as shown above. The relevant fields are:

REGISTRATION REPLY: BETWEEN THE HOME AGENT AND THE FIREWALL
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+

  IP Hdr (SKIP):
     Source          home agent's address
     Destination     firewall's private (inside) address

  SKIP Hdr:
     Source          NSID = 0
                     Master Key-ID = none
     Destination     NSID = 0
                     Master Key-ID = none
  Inner IP Hdr:
     Source          home agent's address
     Destination     mobile node's care-of address

7.2.2. On the Outside (Public) Network ✨

Okay so the SKIP Firewall unwraps the original Registration Reply packet and checks the destination address, which is the mobile node's care-of address 👀

The SKIP Firewall's dynamic packet filtering used the initial Registration Request (Section 7.1) to build a dynamic mapping between the care-of address and the mobile node's Master Key-ID. So before it forwards the Registration Reply, it encrypts the reply using the mobile node's public component. Literally so cute 🫶

This dynamic binding and the use of tunneling mode ESP mean we don't need to extend Mobile IP with a "relay Registration Request" 🙅‍♀️. BUT (big but 😭) the Registration Reply has to leave the private network through the same firewall that forwarded the matching Registration Request.

Plot twist 🦋: a Mobile IP aware firewall could also grab the mobile node's permanent address straight from the Registration Reply itself, instead of from the dynamic binding. That makes the firewall stateless (no memory, iconic 💅), and it lets Registration Requests and Replies go through different firewalls at the edge of the private network.

REGISTRATION REPLY: BETWEEN THE FIREWALL AND THE MOBILE NODE
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+

  IP Hdr (SKIP):
     Source          firewall's public (outside) address
     Destination     mobile node's care-of address

  SKIP Hdr:
     Source          NSID = 0
                     Master Key-ID = none
     Destination     NSID = 1
                     Master Key-ID = IPv4 addr of the mobile node
  Inner IP Hdr:
     Source          home agent's address
     Destination     mobile node's care-of address

---

7.3. Traversal Extension 🧚

The Traversal Extension MAY be included by mobile nodes in Registration Requests, and by home agents in Registration Replies. As per Section 3.6.1.3 of [1], the Traversal Extension must appear before the Mobile-Home Authentication Extension. A Traversal Extension is an explicit notification that there are one or more traversal points (firewalls, fireridges, etc) between the mobile node and its home agent. Negotiating access past these systems may imply a new authentication header, and possibly a new encapsulating header (perhaps as part of tunnel-mode ESP) whose IP destination address is the traversal address.

Negotiating access past traversal points does not necessarily require cryptographic techniques. For example, systems at the boundary between separate IP address spaces must be explicitly targetted (perhaps using unencrypted IP in IP encapsulation).

A mobile node SHOULD include one Traversal Extension per traversal point in its Registration Requests. If present, their order MUST exactly match the order in which packets encounter them as they flow from the mobile node towards the home agent.

Notice that there may be additional firewalls along the way, but the list of traversal points SHOULD only include those systems with which an explicit negotiation is required 👀.

Similarly, the home agent SHOULD include one Traversal Extension per traversal point in its Registration Replies. If present, their order MUST exactly match the order in which packets encounter them as they flow from the home agent to the mobile node.

A Traversal Extension does not include any indication about how access is negotiated. Presumably, this information is obtained through separate means. This document does not attempt to solve the firewall discovery problem, that is, it does not specify how to discover the list of traversal points 🤷‍♀️.

As per section 1.9 of [1], the fact that the type value falls within the range 128 to 255 implies that if a home agent or a mobile node encounter a Traversal Extension in a Registration Request or Reply, they may silently ignore it. This is consistent with the fact that the Traversal Extension is essentially a hint 💜.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MN to HA Traversal Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 HA to MN Traversal Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the field breakdown 🎀:

Type
  129

Length
  10

Reserved
  0

MN to HA Traversal Address: The IP address of an intermediate system or firewall encountered by datagrams sent by the mobile node towards the home agent. Typically, this is the external address of a firewall or firewall complex.

This field MUST be initialized in Registration Requests. In Registration Replies, it is typically all 0's, otherwise, the mobile node SHOULD interpret it as a hint.

HA to MN Traversal Address: The IP address of an intermediate system or firewall encountered by datagrams sent by the home agent towards the mobile node. Typically, this is the internal address of a firewall or firewall complex.

This field MUST be initialized in Registration Replies. In Registration Requests, it is typically all 0's, otherwise, the home agent SHOULD interpret it as a hint.

---

8. Data Transfer 🌈

Data transfer goes along lines that are pretty similar to the Registration Request we just went over 💅. Section 8.1 covers data traffic sent by a mobile node to a correspondent node. Section 8.2 shows the packet formats for the reverse traffic, the stuff the home agent tunnels to the mobile node 🫶.

---

8.1. Data Packet From the Mobile Node to a Correspondent Node 📦

The mobile node composes a packet destined to a correspondent node located within the private network.

The Mobile IP function in the mobile node examines the Inner IP header, and determines that it satisfies conditions "a" and "b1" from Section 7.1. The mobile node requests the proper encryption and encapsulation services from SKIP.

So the mobile node with a co-located address sends encrypted traffic to the firewall, using this format:

DATA PACKET: FROM THE MOBILE NODE VIA THE FIREWALL
+---------------+----------+----+-----+--------------+------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP  |
+---------------+----------+----+-----+--------------+------+

  IP Hdr (SKIP):
     Source          mobile node's care-of address
     Destination     public (outside) address on the firewall

  SKIP Hdr:
     Source          NSID = 1
                     Master Key-ID = IPv4 address of the mobile node
     Destination     NSID = 0
                     Master Key-ID = none
  Inner IP Hdr:
     Source          mobile node's home address
     Destination     correspondent node's address

The SKIP Firewall intercepts this packet, decrypts the Inner IP Hdr and upper-layer payload (ULP), and checks the destination address. Since the packet is destined to a correspondent node in the private network, the "Inner" IP datagram is delivered internally. Once the SKIP firewall injects this packet into the private network, it is routed independently of its source address 🙌.

As this last assumption is not always true, the mobile node may construct a bi-directional tunnel with its home agent. Doing so guarantees that the "Inner IP Hdr" is:

  Inner IP Hdr:
     Source          care-of address
     Destination     home agent address

When the mobile node is at home, communication between it and certain external correspondent nodes may need to go through application-specific firewalls or proxies, which are different from the SKIP firewall 🧱. While on the public network, the mobile node's communication with these hosts MUST use a bi-directional tunnel 🔒.

---

8.2. Data Packet From a Correspondent Node to the Mobile Node 💌

The home agent intercepts a packet from a correspondent node to the mobile node. It encapsulates it so that the Mobile IP encapsulating IP header's source and destination addresses are the home agent and care-of addresses, respectively. That would be enough for delivery within the private network. Since the mobile node's current care-of address is not within the private network, this packet MUST be sent via the firewall. The home agent can do this by encapsulating the datagram in a SKIP packet destined to the firewall (i.e. we assume secure channel configuration number 4) 🦋.

8.2.1 Within the Inside (Private) Network 🏠

From the home agent to the private (inside) address of the firewall, the packet format is:

DATA PACKET: BETWEEN THE HOME AGENT AND THE FIREWALL
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip  | Inner  | ULP |
| (SKIP) | Hdr  |    |     | IP Hdr | IP Hdr |     |
+--------+------+----+-----+--------+--------+-----+

  IP Hdr (SKIP):
     Source          home agent's address
     Destination     private (inside) address on the firewall

  SKIP Hdr:
     Source          NSID = 0
                     Master Key-ID = none
     Destination     NSID = 0
                     Master Key-ID = none

  Mobile-IP IP Hdr:
     Source          home agent's address
     Destination     care-of address

  Inner IP Hdr:
     Source          correspondent node's address
     Destination     mobile node's address

  ULP:               upper-layer payload

The packet format above does not require the firewall to have a dynamic binding. The association between the mobile node's permanent address and its care-of address can be deduced from the contents of the "Mobile-IP IP Hdr" and the "Inner IP Hdr" 🧩.

Nevertheless, a nomadic binding is an assurance that the mobile node is, in fact, at the care-of address right now 💖.

8.2.2. On the Outside (Public) Network 🌍

The SKIP firewall intercepts the packet and recovers the Mobile IP encapsulated datagram. Before sending it out, the dynamic packet filter configured by the original Registration Request triggers encryption of this packet. This time the SKIP firewall does the encryption, so the mobile node can consume it. The resultant packet is:

DATA PACKET: BETWEEN THE FIREWALL AND THE MOBILE NODE
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip  | Inner  | ULP |
| (SKIP) | Hdr  |    |     | IP Hdr | IP Hdr |     |
+--------+------+----+-----+--------+--------+-----+

  IP Hdr (SKIP):
     Source          firewall's public (outside) address
     Destination     mobile node's care-of address

  SKIP Hdr:
     Source          NSID = 0
                     Master Key-ID = none
     Destination     NSID = 1
                     Master Key-ID = IPv4 address of the mobile node

  Mobile-IP IP Hdr:
     Source          home agent's address
     Destination     care-of address

  Inner IP Hdr:
     Source          correspondent node's address
     Destination     mobile node's address

  ULP:               upper-layer payload

At the mobile node, SKIP processes the packets sent by the firewall. Eventually, the inner IP header and the upper-layer packet (ULP) are retrieved and passed on 🎉.

9. Security Considerations 💀🔐

Okay bestie, this whole doc is about security, so let's get into the scary stuff 😭. Still, we absolutely have to call out the dangers of letting a flow of IP packets through a firewall. Basically, the mobile host itself MUST also take on responsibility for securing the private network, because it stretches the private network's edge out into the world 🚨. And no, that doesn't mean it stops swapping unencrypted IP packets with hosts on the public network. For example, it MAY have to do that to meet billing requirements from the foreign site, or to renew its DHCP lease 📡.

In that DHCP case, it might filter on more than just the IP source address, and also check protocol and port numbers 🧐.

So, it MUST have some firewall capabilities, or else any shady person who gets into the mobile host has also gotten into the private network too 😤🚫. Main character energy is protecting your whole network, not just your own laptop 👑.

---

Acknowledgements ✨

Ideas in this document have benefited from discussions with at least the following people: Bill Danielson, Martin Patterson, Tom Markson, Rich Skrenta, Atsushi Shimbo, Behfar Razavi, Avinash Agrawal, Tsutomu Shimomura and Don Hoffman. Jim Solomon has also provided many helpful comments on this document 🫶💜.

---

References 📚

• [1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
• [2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
• [3] A. Aziz and M. Patterson, Design and Implementation of SKIP, available on-line at http://skip.incog.com/inet-95.ps. A previous version of the paper was presented at INET '95 under the title Simple Key Management for Internet Protocols (SKIP), and appears in the conference proceedings under that title.
• [4] Leech, M., Ganis, M., Lee, Y, Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
• [5] Leech, M., "Username/Password Authentication for SOCKS V5", RFC 1929, March 1996.
• [6] Atkinson, R., "IP Encapsulating Payload", RFC 1827, August 1995.
• [7] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
• [8] Stephen Kent, message to the IETF's IPSEC mailing list, Message-Id: <v02130500ae569a3e904e@[128.89.30.29]>, September 6, 1996.
• [9] Tom Markson, private communication, June 12, 1996.
• [10] A. Aziz, T. Markson, H. Prafullchandra. Encoding of an Unsigned Diffie-Hellman Public Value. Available on-line as http://skip.incog.com/spec/EUDH.html.

---

Authors' Addresses 🎀

Gabriel E. Montenegro, the first author 🦋

Gabriel E. Montenegro
Sun Microsystems, Inc.
901 San Antonio Road
Mailstop UMPK 15-214
Mountain View, California 94303

Phone: (415)786-6288
Fax: (415)786-6445
EMail: gabriel.montenegro@Eng.Sun.COM

Vipul Gupta, the second author 🌸

Vipul Gupta
Sun Microsystems, Inc.
901 San Antonio Road
Mailstop UMPK 15-214
Mountain View, California 94303

Phone: (415)786-3614
Fax: (415)786-6445
EMail: vipul.gupta@Eng.Sun.COM

---

Full Copyright Statement 🌈

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.