doc: Add RFC documents

1 files changed, 1346 insertions, 0 deletions

diff --git a/doc/rfc/rfc2356.txt b/doc/rfc/rfc2356.txt
new file mode 100644
index 0000000..adb285d
--- /dev/null
+++ b/doc/rfc/rfc2356.txt
@@ -0,0 +1,1346 @@
+
+
+
+
+
+
+Network Working Group                                      G. Montenegro
+Request for Comments: 2356                                      V. Gupta
+Category: Informational                           Sun Microsystems, Inc.
+                                                               June 1998
+
+
+              Sun's SKIP Firewall Traversal for Mobile IP
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not 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
+
+   The Mobile IP specification establishes the mechanisms that enable a
+   mobile host to maintain and use the same IP address as it changes its
+   point of attachment to the network. Mobility implies higher security
+   risks than static operation, because the traffic may at times take
+   unforeseen network paths with unknown or unpredictable security
+   characteristics. The Mobile IP specification makes no provisions for
+   securing data traffic.  The mechanisms described in this document
+   allow a mobile node out on a public sector of the internet to
+   negotiate access past a SKIP firewall, and construct a secure channel
+   into its home network.
+
+   In addition to securing traffic, our mechanisms allow a mobile node
+   to roam into regions that (1) impose ingress filtering, and (2) use a
+   different address space.
+
+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
+
+
+
+Montenegro & Gupta           Informational                      [Page 1]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   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 document specifies what support is required at the firewall, the
+   Mobile IP [1] home agent and the Mobile IP mobile node to enable the
+   latter to access a private network from the Internet.  For example, a
+   company employee could attach his/her laptop to some Internet access
+   point by:
+
+      a)   Dialing into a PPP/SLIP account on an Internet service
+           provider's network.
+
+      b)   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 relevant interface
+   (PPP or 10Base-T) is configured with an IP address different from
+   that which it uses "normally" (i.e. at the office). Furthermore, the
+   IP address used is not necessarily a fixed assignment. It may be
+   assigned temporarily and dynamically at the beginning of the session
+   (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case).
+
+   The following discussion assumes a network configuration consisting
+   of a private network separated by a firewall from the general
+   Internet or public network.  The systems involved are:
+
+
+
+
+
+Montenegro & Gupta           Informational                      [Page 2]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+      Private Network
+
+           A protected network 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 are able to 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 removes the system from its home network,
+          and connects it to the Internet at another point.  The
+          mechanisms outlined in this discussion render this mobility
+          transparent:  the mobile node continues accessing its home
+          network and its resources exactly as if it were still within
+          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 is 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 so by a combination of functions such as application
+         gatewaying, packet filtering and cryptographic techniques.
+
+
+
+
+Montenegro & Gupta           Informational                      [Page 3]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   The mechanisms described in this document allow a mobile node out on
+   a public sector of the network to negotiate access past a SKIP
+   firewall, and construct a secure channel into its home network.  This
+   enables it to communicate with correspondent nodes that belong to the
+   private network, and, if bi-directional tunnels are used, with
+   external hosts that are reachable when the mobile node is at home.
+   The mobile node enjoys the same level of connectivity and privacy as
+   it does when it is in its home network.
+
+   This document does not address the scenario in which the mobile node
+   attempts to access its private network, while within another private
+   network.
+
+   Sections 2 and 3 provide an overview of the environment being
+   considered and the restrictions it imposes.  Section 4 examines
+   firewall technologies. Section 5 discusses the best mode of operation
+   of the participating entities from the point of view of Mobile IP.
+   Section 6 discusses possible configuration for the secure channel.
+   Finally, packet formats are the topic of sections 7 and 8.
+
+2. Mobility without a Firewall
+
+   Suppose the mobile node is roaming throughout the general Internet,
+   but its home network is not protected by a firewall. This is
+   typically found in academic environment as opposed to corporate
+    networks.
+
+   This works as prescribed by Mobile IP [1]. The only proviso 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.  This is
+   because, at least in the near term, it is far more likely to be able
+   to secure a temporary care-of-address than it is to find a foreign
+   agent already deployed at the site you are 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 imposes restrictions on packets entering or leaving the
+   private network. Packets are not allowed through unless they conform
+   to a filtering specification, or unless there is a negotiation
+   involving some sort of authentication.
+
+
+
+Montenegro & Gupta           Informational                      [Page 4]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   Another restriction is imposed by the separation between private
+   addresses and general Internet addresses. Strictly speaking, this is
+   not 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 is not that the firewall drops it. Rather, the
+   Internet's routing fabric is unable to process it. This elicits 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 delving into any details, lets examine two technologies which
+   may provide firewall support for mobile nodes:
+
+   -   application relaying or proxying, or
+
+   -   IP Security.
+
+   To understand the implications, let's examine two specific schemes to
+   accomplish the above: SOCKS version 5 and SKIP.
+
+4.1 SOCKS version 5 [4]
+
+   There is an effort within the authenticated firewall traversal WG
+   (aft) of the IETF to provide a common interface for application
+   relays.
+
+   The solution being proposed is a revised specification of the SOCKS
+   protocol. Version 5 has been extended to include UDP services as
+   well.  The SOCKS solution requires that the mobile node -- or another
+   node on its behalf -- establish 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. The steps required by a SOCKS solution are:
+
+   -   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] requires 1 round trip:
+
+
+
+
+Montenegro & Gupta           Informational                      [Page 5]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+           1. client sends a Username/Password request
+           2. FW (server) responds
+
+           The GSS-API negotiation requires 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)
+
+   This is a minimum of 4 (6 with GSS-API) round-trips before the client
+   is able to pass data through the FW using the following header:
+
+      +----+------+------+----------+----------+----------+
+      |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
+      +----+------+------+----------+----------+----------+
+      | 2  |  1   |  1   | Variable |    2     | Variable |
+      +----+------+------+----------+----------+----------+
+
+   Bear in mind that the above must be done each time the mobile
+   registers a new care-of address. In addition to this inefficiency,
+   this scheme requires that we use UDP to encapsulate IP datagrams.
+   There is at least one commercial network that does this, but it is
+   not the best solution.
+
+   Furthermore, SOCKS defines how to establish authenticated
+   connections, but currently it does not provide a clear solution to
+   the problem of encrypting the traffic.
+
+   This header contains the relay information needed by all parties
+   involved to reach those not directly reachable.
+
+4.2 SKIP [3]
+
+   Alternatively, traffic from the mobile node to the firewall could be
+   encrypted and authenticated using a session-less IP security
+   mechanism like SKIP. This obviates the need to set up a session just
+   to exchange UDP traffic with the firewall.
+
+   A solution based on SKIP is very attractive in this scenario, as no
+   round trip times are incurred before the mobile node and the firewall
+   achieve mutual trust: the firewall can start relaying packets for the
+   mobile node as soon as it receives the first one.  This, of course,
+   implies that SKIP is being used with AH [7] so that authentication
+   information is contained in each packet.  Encryption by using ESP [6]
+   is also assumed in this scenario, since the Internet at large is
+   considered a hostile environment.  An ESP transform that provides
+
+
+
+Montenegro & Gupta           Informational                      [Page 6]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   both authentication and encryption could be used, in which case the
+   AH header need not be included.
+
+   The firewall and the mobile node may be previously configured with
+   each other's authenticated Diffie-Hellman public components (also
+   known as public values).  Alternatively, they could exchange them in
+   real-time using any of the mechanisms defined by the SKIP protocol
+   (on-line certificate directory service or 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 to achieve IP layer security.
+   However, they are session-oriented key management solutions, and
+   typically imply negotiations spanning several round-trip times before
+   cryptographically secure communications are possible.  In this
+   respect they raise similar concerns to those outlined previously in
+   the discussion on SOCKS-based solutions.  Others have arrived at
+   similar conclusions regarding the importance of session-less key
+   management for Mobile IP applications [8].
+
+   Another advantage of SKIP is its support for nomadic applications.
+   Typically, two hosts communicating via a secure IP layer channel use
+   the IP source and destination addresses on incoming packets to arrive
+   at the appropriate security association. The SKIP header can easily
+   supersede this default mechanism by including the key ID the
+   recipient must use to obtain 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.
+
+   As an example, by setting NSID to 1 and MKID to its home address, a
+   mobile node tells a receiver "ignore the IP source and use my home
+   address instead to look up my public component". Similarly, 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].
+
+   In addition to the NSID/MKID feature, Mobile IP is best supported by
+   an appropriate policy at the SKIP firewall in the form of a "nomadic"
+   access control list entry. This is an entry which is filtered by key
+   ID, instead of by IP source address, as is the usual case. It
+
+
+
+Montenegro & Gupta           Informational                      [Page 7]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   translates to "allow access from any IP source address for a given
+   NSID/MKID combination".  Furthermore, incoming packets MUST have an
+   AH header, so that after properly authenticating them, the firewall
+   establishes a "current address" or "dynamic binding" for the nomadic
+   host.  The NSID/MKID combination determines which key should be used
+   with the nomadic host [9].
+
+   Notice that this supports Mobile IP, because the mobile node always
+   initiates contact. Hence, the SKIP firewall has a chance to learn the
+   mobile node's "current address" from an incoming packet before it
+   attempts to encrypt an outgoing packet.
+
+   However, this precludes the use of 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 prior care-of address. In order to support simultaneous
+   bindings the firewall must be able to interpret Mobile IP
+   registration messages.
+
+   Section 7.2.2 discusses another advantage 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 in which 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 hinges on 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. The problem is even more apparent when
+   the mobile node attempts a Registration Request.  Here, the foreign
+   agent is not just a relayer, it actually examines the packet sent by
+   the mobile node, and modifies its agent services accordingly. In
+   short, assuming the current specification of Mobile IP and the
+   current lack of trust in the internet at large, only case "b" is
+   possible. Case "a" would require an extension (e.g. a "relay"
+
+
+
+Montenegro & Gupta           Informational                      [Page 8]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   Registration Request), and modifying code at the home agent, the
+   firewall and the foreign agent.
+
+   Assuming that the firewall offers a secure relay service (i.e.
+   decapsulation and forwarding of packets), the mobile node can reach
+   addresses internal to the private network by encapsulating the
+   packets in a SKIP header and directing them to the firewall.
+
+   Therefore, It is simplest to assume that the mobile node operates
+   with a co-located address.
+
+6. Supporting Mobile IP: Secure Channel Configurations
+
+   The mobile node participates in two different types of traffic:
+   Mobile IP registration protocol and data. For the sake of simplicity,
+   the following discussion evaluates different secure channel
+   configurations by examining the initial Registration Request sent by
+   the mobile node to its home agent.
+
+   Assuming the mobile node operates with a co-located address, it can
+   communicate directly with the firewall.  The latter is able to reach
+   the home agent in the private network. Also, the firewall MUST be
+   able to authenticate the mobile node.
+
+   The following channel configurations 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
+
+   The traffic is only encrypted between the mobile node out on the
+   general Internet, and the firewall's external interface. This is
+   minimum required. It is the most desirable configuration as the more
+   expensive encrypted channel is only used where it is necessary: on
+   the public network.
+
+
+
+
+
+
+
+
+
+
+Montenegro & Gupta           Informational                      [Page 9]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+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 perform a simple packet relay or
+   gatewaying function. Even though this could be accomplished by using
+   the proper destination NSID in the packet, in practice it is probably
+   unrealizable. The reason is that this alternative is probably not
+   very popular with computer security personnel, because authentication
+   is not carried out by the firewall but by the home agent, and the
+   latter's security is potentially much weaker than the former's.
+
+6.3 III: End-to-End Encryption, Intermediate Authentication
+
+   A third alternative is to allow the firewall to 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 is used to provide intermediate authentication with end-
+   to-end security. Although possible, this option implies that the
+   participating entities 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
+
+   Traffic is encrypted on the public as well as on the private network.
+   On the public network, encryption is dictated by a security
+   association between the mobile node and the firewall.  On the private
+   network, it is dictated by a security association between the home
+
+
+
+Montenegro & Gupta           Informational                     [Page 10]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   agent and the firewall.
+
+6.5 Choosing a Secure Channel Configuration
+
+   A potential problem in both options 2 and 3 is that their end-to-end
+   channel components assume that the mobile node and the home agent can
+   exchange IP traffic directly with each other. This is generally not
+   the case, as the Internet routing fabric may not have routes to
+   addresses that belong to private networks, and the private routing
+   fabric may ignore how to route to public addresses -- or doing so may
+   be administratively restricted.  Therefore, it is necessary for
+   packets to be addressed directly to the firewall, and indirectly --
+   via some tunneling or relaying capability -- to the real destination
+   on the other side of the firewall.
+
+   Options 1 and 4 are essentially equivalent. The latter may be
+   considered overkill, because it uses encryption even within the
+   private network, and this is generally not necessary. What is
+   necessary even within the private network is for the home agent to
+   add an encapsulation (not necessarily encrypted) so as to direct
+   datagrams to the mobile node via the firewall. The type of
+   encapsulation used determines the difference between options 1 and 4.
+   Whereas option 4 uses SKIP, option 1 uses a cleartext encapsulation
+   mechanism.  This is obtainable by, for example, using IP in IP
+   encapsulation [2].
+
+   Options 1 and 4 are mostly interchangeable. The difference is, of
+   course, that the former does not protect the data from eavesdroppers
+   within the private network itself. This may be unacceptable in
+   certain cases. Traffic from some departments in a company (for
+   example payroll or legal) may need to be encrypted as it traverses
+   other sections of the company.
+
+   In the interest of being conservative, in what follows we assume
+   option 4 (i.e. traffic is encrypted on the general Internet, as well
+   as within the private network.
+
+   Since the firewall is party to the security associations governing
+   encryption on both the public and private networks, it is always able
+   to inspect the traffic being exchanged by the home agent and the
+   mobile node. If this is of any concern, 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 roaming within a private network, a mobile node sends
+   Registration Requests directly to its home agent. On the public
+   Internet, it MUST encapsulate the original Registration Request in a
+
+
+
+Montenegro & Gupta           Informational                     [Page 11]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   SKIP packet destined to the firewall.  The mobile node MUST
+   distinguish between "inside" and "outside" addresses. This could be
+   accomplished by a set of rules defining the address ranges.
+   Nevertheless, actual installations may present serious difficulties
+   in defining exactly what is a private address and what is not.
+
+   Direct human input is a very effective method: it may be obvious to
+   the user that the current point of attachment is outside its private
+   network, and it should be possible to communicate this knowledge to
+   the mobile node software.
+
+   The home agent must also distinguish between "inside" and "outside"
+   addresses, but lacks the potential benefit of direct user input.
+   Accordingly, it should be possible for the mobile node to communicate
+   that knowledge to the home agent. To accomplish this we define a
+   Traversal Extension to the Registration Requests and Replies.  This
+   extension is also useful when traversing multiple firewalls.
+
+   In spite of the above mechanisms, errors in judgement are to be
+   expected.  Accordingly, the firewall SHOULD be configured such that
+   it will still perform its relaying duties even if they are
+   unnecessarily required by a mobile node with an inside care-of
+   address.
+
+   Upon arriving at a foreign net and acquiring a care-of address, the
+   mobile node must first -- before any data transfer is possible --
+   initiate a registration procedure. This consists of an authenticated
+   exchange by which the mobile node informs its home agent of its
+   current whereabouts (i.e. its current care-of address), and receives
+   an acknowledgement. This first step of the protocol is very
+   convenient, because the SKIP firewall can use it to dynamically
+   configure its packet filter.
+
+   The remainder of this section shows the packet formats used.  Section
+   7.1 discusses how a mobile node sends a Registration Request to its
+   home agent via the SKIP firewall. Section 7.2 discusses how the home
+   agent send the corresponding Registration Reply 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 mechanisms
+   defined by Mobile IP, discovers 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.
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 12]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   This is not a simple rule triggered by a given 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 the above conditions are mobility related, it is 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 in order 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, indicating 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 -- an address whose
+   corresponding public component is unknown to the firewall.
+
+   It is also possible to use Unsigned Diffie-Hellman public components
+   [10].  Doing so greatly reduces SKIP's infrastructure requirements,
+   because there is no need for a Certificate Authority. Of course, for
+   this to be possible 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
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 13]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+     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
+   establish a dynamic binding between the care-of address and the
+   mobile node's permanent home address.
+
+   The destination NSID field in the above packet is zero, prompting the
+   firewall to process the SKIP header and recover the internal packet.
+   It then delivers the original packet to another outbound interface,
+   because it is addressed to the home agent (an address within the
+   private network). Assuming secure channel configuration number 4, the
+   firewall encrypts the packet using SKIP before forwarding 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 examines the care-of
+   address reported by the mobile node, and determines whether or not it
+   corresponds to an outside address.  If so, the home agent needs to
+   send all traffic back through the firewall.  The home agent can
+
+
+
+Montenegro & Gupta           Informational                     [Page 14]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   accomplish this by encapsulating 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 via 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
+
+   The SKIP Firewall recovers the original Registration Reply packet and
+   looks at the destination address: the mobile node's care-of address.
+
+   The SKIP Firewall's dynamic packet filtering used the initial
+   Registration Request (Secton 7.1) to establish a dynamic mapping
+   between the care-of address and the mobile node's Master Key-ID.
+   Hence, before forwarding the Registration Reply, it encrypts it using
+   the mobile node's public component.
+
+   This dynamic binding capability and the use of tunneling mode ESP
+   obviate the need to extend the Mobile IP protocol with a "relay
+   Registration Request". However, it requires that the Registration
+   Reply exit the private network through the same firewall that
+   forwarded the corresponding Registration Request.
+
+   Instead of obtaining the mobile node's permanent address from the
+   dynamic binding, a Mobile IP aware firewall could also obtain it from
+   the Registration Reply itself. This renders the firewall stateless,
+   and lets Registration Requests and Replies traverse the periphery of
+
+
+
+Montenegro & Gupta           Informational                     [Page 15]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   the private network through different firewalls.
+
+   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.
+
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 16]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   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                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type
+
+        129
+
+      Length
+
+         10
+
+      Reserved
+
+         0
+
+      MN to HA Traversal Address
+
+         The IP address of the 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.
+
+
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 17]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+         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 proceeds along lines similar to the Registration
+   Request outlined above.  Section 8.1 discusses data traffic sent by a
+   mobile node to a correspondent node. Section 8.2 shows packet formats
+   for the reverse traffic being tunneled by the home agent 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.
+
+   Thus, the mobile node with a co-located address sends encrypted
+   traffic to the firewall, using the following 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
+
+
+
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 18]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+     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 at home, communication between the the mobile node and certain
+   external correspondent nodes may need to go through application-
+   specific firewalls or proxies, 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 such that the Mobile IP encapsulating
+   IP header's source and destination addresses are the home agent and
+   care-of addresses, respectively. This would suffice for delivery
+   within the private network. Since the current care-of address of the
+   mobile node is not within the private network, this packet MUST be
+   sent via the firewall. The home agent can accomplish this by
+   encapsulating the datagram in a SKIP packet destined to the firewall
+   (i.e. we assume secure channel configuration number 4).
+
+
+
+
+
+
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 19]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+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 it 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 currently the
+   mobile node is, in fact, at the care-of address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 20]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+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 by the SKIP firewall for
+   consumption by the mobile node.  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
+
+   The topic of this document is security. Nevertheless, it is
+   imperative to point out the perils involved in allowing a flow of IP
+   packets through a firewall. In essence, the mobile host itself MUST
+   also take on responsibility for securing the private network, because
+   it extends its periphery. This does not mean it stops exchanging
+   unencrypted IP packets with hosts on the public network.  For
+   example, it MAY have to do so in order to satisfy billing
+   requirements imposed by the foreign site, or to renew its DHCP lease.
+
+
+
+Montenegro & Gupta           Informational                     [Page 21]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   In the latter case it might filter not only on IP source address, but
+   also on protocol and port numbers.
+
+   Therefore, it MUST have some firewall capabilities, otherwise, any
+   malicious individual that gains access to it will have gained access
+   to the private network as well.
+
+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.
+
+
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 22]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+   [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
+   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
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 23]
+
+RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro & Gupta           Informational                     [Page 24]
+