As per Relevance of the word registration, we have this rfc below:
Network Working Group G.
Request for Comments: 2356 V.
Category: Informational Sun Microsystems, Inc
June 1998
Sun's SKIP Firewall Traversal for Mobile
Status of This
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
The Mobile IP specification establishes the mechanisms that enable
mobile host to maintain and use the same IP address as it changes
point of attachment to the network. Mobility implies higher
risks than static operation, because the traffic may at times
unforeseen network paths with unknown or unpredictable
characteristics. The Mobile IP specification makes no provisions
securing data traffic. The mechanisms described in this
allow a mobile node out on a public sector of the internet
negotiate access past a SKIP firewall, and construct a secure
into its home network
In addition to securing traffic, our mechanisms allow a mobile
to roam into regions that (1) impose ingress filtering, and (2) use
different address space
Table of
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.
This document specifies what support is required at the firewall,
Mobile IP [1] home agent and the Mobile IP mobile node to enable
latter to access a private network from the Internet. For example,
company employee could attach his/her laptop to some Internet
point by
a) Dialing into a PPP/SLIP account on an Internet
provider's network
b) Connecting into a 10Base-T or similar LAN network
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
(PPP or 10Base-T) is configured with an IP address different
that which it uses "normally" (i.e. at the office). Furthermore,
IP address used is not necessarily a fixed assignment. It may
assigned temporarily and dynamically at the beginning of the
(e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case).
The following discussion assumes a network configuration
of a private network separated by a firewall from the
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
A protected network separated from the Internet by
enforcing access restrictions (firewalls). A private
may use a private address space, and its addresses may
even be routable by the general internet
Public
The Internet at large. Hosts are able to communicate with
other throughout the public network without firewall-
restrictions
Mobile Node (MN
Its permanent address falls within the range of the
network. The user removes the system from its home network
and connects it to the Internet at another point.
mechanisms outlined in this discussion render this
transparent: the mobile node continues accessing its
network and its resources exactly as if it were still
it. Notice that when the mobile node leaves its
network, it may migrate both within and outside of
private network's boundaries. As defined by Mobile IP [1],
mobile node uses a care-of address while roaming
Home Agent (HA) for the mobile
Serves as a location registry and router as described in
Mobile IP IETF draft
Foreign Agent (FA
Serves as a registration relayer and care of address for
mobile node as described in the Mobile IP IETF draft
Correspondent Node (CH
A system that is exchanging data packets with the
node
Firewall (FW
The system (or collection of systems) that enforces
control between the private network and the general Internet
It may do so by a combination of functions such as
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
a public sector of the network to negotiate access past a
firewall, and construct a secure channel into its home network.
enables it to communicate with correspondent nodes that belong to
private network, and, if bi-directional tunnels are used,
external hosts that are reachable when the mobile node is at home
The mobile node enjoys the same level of connectivity and privacy
it does when it is in its home network
This document does not address the scenario in which the mobile
attempts to access its private network, while within another
network
Sections 2 and 3 provide an overview of the environment
considered and the restrictions it imposes. Section 4
firewall technologies. Section 5 discusses the best mode of
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
Suppose the mobile node is roaming throughout the general Internet
but its home network is not protected by a firewall. This
typically found in academic environment as opposed to
networks
This works as prescribed by Mobile IP [1]. The only proviso is
the mobile node would most probably operate with a co-located
instead of using a separate foreign agent's care-of address. This
because, at least in the near term, it is far more likely to be
to secure a temporary care-of-address than it is to find a
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
offer DHCP services
- Other locations probably would offer DHCP services
3. Restrictions imposed by a
The firewall imposes restrictions on packets entering or leaving
private network. Packets are not allowed through unless they
to a filtering specification, or unless there is a
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
addresses and general Internet addresses. Strictly speaking, this
not imposed by a firewall, but by the characteristics of the
network. For example, if a packet destined to an internal
originates in the general Internet, it will probably not
delivered. It is not that the firewall drops it. Rather,
Internet's routing fabric is unable to process it. This elicits
ICMP host unreachable packet sent back to the originating node
Because of this, the firewall MUST be explicitly targeted as
destination node by outside packets seeking to enter the
network. The routing fabric in the general Internet will only see
public address of the firewall and route accordingly. Once
packet arrives at the firewall, the real packet destined to a
address is recovered
4. Two Firewall Options: Application relay and IP
Before delving into any details, lets examine two technologies
may provide firewall support for mobile nodes
- application relaying or proxying,
- IP Security
To understand the implications, let's examine two specific schemes
accomplish the above: SOCKS version 5 and SKIP
4.1 SOCKS version 5 [4]
There is an effort within the authenticated firewall traversal
(aft) of the IETF to provide a common interface for
relays
The solution being proposed is a revised specification of the
protocol. Version 5 has been extended to include UDP services
well. The SOCKS solution requires that the mobile node -- or
node on its behalf -- establish a TCP session to exchange UDP
with the FW. It also has to use the SOCKS library to encapsulate
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,
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
2. FW (server)
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
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
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
not the best solution
Furthermore, SOCKS defines how to establish
connections, but currently it does not provide a clear solution
the problem of encrypting the traffic
This header contains the relay information needed by all
involved to reach those not directly reachable
4.2 SKIP [3]
Alternatively, traffic from the mobile node to the firewall could
encrypted and authenticated using a session-less IP
mechanism like SKIP. This obviates the need to set up a session
to exchange UDP traffic with the firewall
A solution based on SKIP is very attractive in this scenario, as
round trip times are incurred before the mobile node and the
achieve mutual trust: the firewall can start relaying packets for
mobile node as soon as it receives the first one. This, of course
implies that SKIP is being used with AH [7] so that
information is contained in each packet. Encryption by using ESP [6]
is also assumed in this scenario, since the Internet at large
considered a hostile environment. An ESP transform that
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
AH header need not be included
The firewall and the mobile node may be previously configured
each other's authenticated Diffie-Hellman public components (
known as public values). Alternatively, they could exchange them
real-time using any of the mechanisms defined by the SKIP
(on-line certificate directory service or certificate
protocol). Home agents and the firewall also MUST have, be able
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,
typically imply negotiations spanning several round-trip times
cryptographically secure communications are possible. In
respect they raise similar concerns to those outlined previously
the discussion on SOCKS-based solutions. Others have arrived
similar conclusions regarding the importance of session-less
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
the IP source and destination addresses on incoming packets to
at the appropriate security association. The SKIP header can
supersede this default mechanism by including the key ID
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
possible name spaces is being used, and
2) a master key identifier (MKID) that uniquely indicates (
the given name space) an id to use in fetching the
certificate
As an example, by setting NSID to 1 and MKID to its home address,
mobile node tells a receiver "ignore the IP source and use my
address instead to look up my public component". Similarly,
NSID to 8 enables using Unsigned Diffie-Hellman (UDH) certificates
In this case, the MKID is set to the MD5 hash of the DH
component [10].
In addition to the NSID/MKID feature, Mobile IP is best supported
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
ID, instead of by IP source address, as is the usual case.
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
NSID/MKID combination". Furthermore, incoming packets MUST have
AH header, so that after properly authenticating them, the
establishes a "current address" or "dynamic binding" for the
host. The NSID/MKID combination determines which key should be
with the nomadic host [9].
Notice that this supports Mobile IP, because the mobile node
initiates contact. Hence, the SKIP firewall has a chance to learn
mobile node's "current address" from an incoming packet before
attempts to encrypt an outgoing packet
However, this precludes the use of simultaneous bindings by a
node. At the firewall, the last Registration Request sent by
mobile node replaces the association between its permanent
and any prior care-of address. In order to support
bindings the firewall must be able to interpret Mobile
registration messages
Section 7.2.2 discusses another advantage of making the
understand Mobile IP packet formats
In what follows we assume a SKIP-based solution
5. Agents and Mobile Node
Depending on which address it uses as its tunnel endpoint, the
IP protocol specifies two ways in which a mobile node can register
mobility binding with its home agent
a) an address advertised for that purpose by the foreign
b) an address belonging to one of the mobile node's
(i.e. operation with a co-located address).
From the firewall's point of view, the main difference between
two cases hinges on which node prepares the outermost
encapsulation. The firewall MUST be able to obtain the Diffie
Hellman public component of the node that creates the outermost
header in an incoming packet. This is only possible to guarantee
case "b", because the mobile node and the firewall both belong to
same administrative domain. The problem is even more apparent
the mobile node attempts a Registration Request. Here, the
agent is not just a relayer, it actually examines the packet sent
the mobile node, and modifies its agent services accordingly.
short, assuming the current specification of Mobile IP and
current lack of trust in the internet at large, only case "b"
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,
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
addresses internal to the private network by encapsulating
packets in a SKIP header and directing them to the firewall
Therefore, It is simplest to assume that the mobile node
with a co-located address
6. Supporting Mobile IP: Secure Channel
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
configurations by examining the initial Registration Request sent
the mobile node to its home agent
Assuming the mobile node operates with a co-located address, it
communicate directly with the firewall. The latter is able to
the home agent in the private network. Also, the firewall MUST
able to authenticate the mobile node
The following channel configurations assume the mobile node
with a co-located address. The region between the HA (home agent)
the FW (firewall) is a private network. The region between the FW
the MN (mobile node) is the outside or public network
6.1 I: Encryption only Outside of Private
HA FW
<=====================> SKIP (AH + ESP
<-----------------------------------> Registration Request
The traffic is only encrypted between the mobile node out on
general Internet, and the firewall's external interface. This
minimum required. It is the most desirable configuration as the
expensive encrypted channel is only used where it is necessary:
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
Another possible configuration extends the encrypted tunnel
the firewall
HA FW
<===================================> SKIP (AH + ESP
<-----------------------------------> Registration Request
This limits the firewall to perform a simple packet relay
gatewaying function. Even though this could be accomplished by
the proper destination NSID in the packet, in practice it is
unrealizable. The reason is that this alternative is probably
very popular with computer security personnel, because
is not carried out by the firewall but by the home agent, and
latter's security is potentially much weaker than the former's
6.3 III: End-to-End Encryption, Intermediate
A third alternative is to allow the firewall to be party to
security association between the home agent and the mobile node
After verifying authentication (AH header), the firewall forwards
encrypted packet (ESP hdr) to the home agent
HA FW
<+++++++++++++++++++++> SKIP
<===================================> SKIP
<-----------------------------------> Registration Request
Here, SKIP is used to provide intermediate authentication with end
to-end security. Although possible, this option implies that
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
system administration personnel, option 3 is unsavory to the
user
6.4 IV: Encryption Inside and
HA FW
<============><=====================> SKIP (AH + ESP
<-----------------------------------> Registration Request
Traffic is encrypted on the public as well as on the private network
On the public network, encryption is dictated by a
association between the mobile node and the firewall. On the
network, it is dictated by a security association between the
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
A potential problem in both options 2 and 3 is that their end-to-
channel components assume that the mobile node and the home agent
exchange IP traffic directly with each other. This is generally
the case, as the Internet routing fabric may not have routes
addresses that belong to private networks, and the private
fabric may ignore how to route to public addresses -- or doing so
be administratively restricted. Therefore, it is necessary
packets to be addressed directly to the firewall, and indirectly --
via some tunneling or relaying capability -- to the real
on the other side of the firewall
Options 1 and 4 are essentially equivalent. The latter may
considered overkill, because it uses encryption even within
private network, and this is generally not necessary. What
necessary even within the private network is for the home agent
add an encapsulation (not necessarily encrypted) so as to
datagrams to the mobile node via the firewall. The type
encapsulation used determines the difference between options 1 and 4.
Whereas option 4 uses SKIP, option 1 uses a cleartext
mechanism. This is obtainable by, for example, using IP in
encapsulation [2].
Options 1 and 4 are mostly interchangeable. The difference is,
course, that the former does not protect the data from
within the private network itself. This may be unacceptable
certain cases. Traffic from some departments in a company (
example payroll or legal) may need to be encrypted as it
other sections of the company
In the interest of being conservative, in what follows we
option 4 (i.e. traffic is encrypted on the general Internet, as
as within the private network
Since the firewall is party to the security associations
encryption on both the public and private networks, it is always
to inspect the traffic being exchanged by the home agent and
mobile node. If this is of any concern, the home agent and
node could set up a bi-directional tunnel and encrypt it
7. Mobile IP Registration Procedure with a SKIP
When roaming within a private network, a mobile node
Registration Requests directly to its home agent. On the
Internet, it MUST encapsulate the original Registration Request in
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
distinguish between "inside" and "outside" addresses. This could
accomplished by a set of rules defining the address ranges
Nevertheless, actual installations may present serious
in defining exactly what is a private address and what is not
Direct human input is a very effective method: it may be obvious
the user that the current point of attachment is outside its
network, and it should be possible to communicate this knowledge
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
that knowledge to the home agent. To accomplish this we define
Traversal Extension to the Registration Requests and Replies.
extension is also useful when traversing multiple firewalls
In spite of the above mechanisms, errors in judgement are to
expected. Accordingly, the firewall SHOULD be configured such
it will still perform its relaying duties even if they
unnecessarily required by a mobile node with an inside care-
address
Upon arriving at a foreign net and acquiring a care-of address,
mobile node must first -- before any data transfer is possible --
initiate a registration procedure. This consists of an
exchange by which the mobile node informs its home agent of
current whereabouts (i.e. its current care-of address), and
an acknowledgement. This first step of the protocol is
convenient, because the SKIP firewall can use it to
configure its packet filter
The remainder of this section shows the packet formats used.
7.1 discusses how a mobile node sends a Registration Request to
home agent via the SKIP firewall. Section 7.2 discusses how the
agent send the corresponding Registration Reply to the mobile node
Section 7.3 defines the Traversal Extension for use with
Requests and Replies
7.1. Registration Request through the
The mobile node arrives at a foreign net, and using
defined by Mobile IP, discovers it has moved away from home.
acquires a local address at the foreign site, and composes
Registration Request meant for its home agent. The mobile node
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
belong to the private network (i.e. the mobile node
currently "outside" its private network),
b) either of
b1) the source address of the packet is the mobile node'
home address (e.g. this packet's endpoints
dictated by a connection initiated while at home),
b2) the source address of the packet is the care-
address and the destination address belongs to
private
Since the above conditions are mobility related, it is best for
Mobile IP function in the node to evaluate them, and then request
appropriate security services from SKIP
7.1.1. On the Outside (Public)
The SKIP module must use the firewall destination address and
firewall's certificate in order to address and encrypt the packet
It encrypts it using SKIP combined with the ESP [6] protocol
possibly the AH [7] protocol
The SKIP header's source NSID equals 1, indicating that the
Key-ID is the mobile node's home address. Notice that the IP packet'
source address corresponds to the care-of address -- an address
corresponding public component is unknown to the firewall
It is also possible to use Unsigned Diffie-Hellman public
[10]. Doing so greatly reduces SKIP's infrastructure requirements
because there is no need for a Certificate Authority. Of course,
this to be possible the principals' names MUST be
communicated
REGISTRATION REQUEST: BETWEEN THE MOBILE NODE AND THE
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+
IP Hdr (SKIP):
Source mobile node's care-of
Destination firewall's public (outside)
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
Destination NSID = 0
Master Key-ID =
Inner IP Hdr
Source mobile node's care-of
Destination home agent's
7.1.2. On the Inside (Private)
The SKIP Firewall's dynamic packet filtering uses this information
establish a dynamic binding between the care-of address and
mobile node's permanent home address
The destination NSID field in the above packet is zero, prompting
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
private network). Assuming secure channel configuration number 4,
firewall encrypts the packet using SKIP before forwarding to the
agent
REGISTRATION REQUEST: BETWEEN THE FIREWALL AND THE HOME
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+
IP Hdr (SKIP):
Source firewall's private (inside)
Destination home agent's
SKIP Hdr
Source NSID = 0
Master Key-ID =
Destination NSID = 0
Master Key-ID =
Inner IP Hdr
Source mobile node's care-of
Destination home agent's
7.2. Registration Reply through the
The home agent processes the Registration Request, and composes
Registration Reply. Before responding, it examines the care-
address reported by the mobile node, and determines whether or not
corresponds to an outside address. If so, the home agent needs
send all traffic back through the firewall. The home agent
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
SKIP packet destined to the firewall (i.e. we assume secure
configuration number 4).
7.2.1. On the Inside (Private)
The packet from the home agent to the mobile node via the
Firewall has the same format as shown above. The relevant fields are
REGISTRATION REPLY: BETWEEN THE HOME AGENT AND THE
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+
IP Hdr (SKIP):
Source home agent's
Destination firewall's private (inside)
SKIP Hdr
Source NSID = 0
Master Key-ID =
Destination NSID = 0
Master Key-ID =
Inner IP Hdr
Source home agent's
Destination mobile node's care-of
7.2.2. On the Outside (Public)
The SKIP Firewall recovers the original Registration Reply packet
looks at the destination address: the mobile node's care-of address
The SKIP Firewall's dynamic packet filtering used the
Registration Request (Secton 7.1) to establish a dynamic
between the care-of address and the mobile node's Master Key-ID
Hence, before forwarding the Registration Reply, it encrypts it
the mobile node's public component
This dynamic binding capability and the use of tunneling mode
obviate the need to extend the Mobile IP protocol with a "
Registration Request". However, it requires that the
Reply exit the private network through the same firewall
forwarded the corresponding Registration Request
Instead of obtaining the mobile node's permanent address from
dynamic binding, a Mobile IP aware firewall could also obtain it
the Registration Reply itself. This renders the firewall stateless
and lets Registration Requests and Replies traverse the periphery
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
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+
IP Hdr (SKIP):
Source firewall's public (outside)
Destination mobile node's care-of
SKIP Hdr
Source NSID = 0
Master Key-ID =
Destination NSID = 1
Master Key-ID = IPv4 addr of the mobile
Inner IP Hdr
Source home agent's
Destination mobile node's care-of
7.3. Traversal
The Traversal Extension MAY be included by mobile nodes
Registration Requests, and by home agents in Registration Replies
As per Section 3.6.1.3 of [1], the Traversal Extension must
before the Mobile-Home Authentication Extension. A
Extension is an explicit notification that there are one or
traversal points (firewalls, fireridges, etc) between the mobile
and its home agent. Negotiating access past these systems may imply
new authentication header, and possibly a new encapsulating
(perhaps as part of tunnel-mode ESP) whose IP destination address
the traversal address
Negotiating access past traversal points does not necessarily
cryptographic techniques. For example, systems at the
between separate IP address spaces must be explicitly
(perhaps using unencrypted IP in IP encapsulation).
A mobile node SHOULD include one Traversal Extension per
point in its Registration Requests. If present, their order
exactly match the order in which packets encounter them as they
from the mobile node towards the home agent
Notice that there may be additional firewalls along the way, but
list of traversal points SHOULD only include those systems with
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
traversal point in its Registration Replies. If present, their
MUST exactly match the order in which packets encounter them as
flow from the home agent to the mobile node
A Traversal Extension does not include any indication about
access is negotiated. Presumably, this information is
through separate means. This document does not attempt to solve
firewall discovery problem, that is, it does not specify how
discover the list of traversal points
As per section 1.9 of [1], the fact that the type value falls
the range 128 to 255 implies that if a home agent or a mobile
encounter a Traversal Extension in a Registration Request or Reply
they may silently ignore it. This is consistent with the fact
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
129
10
0
MN to HA Traversal
The IP address of the an intermediate system or
encountered by datagrams sent by the mobile node towards
home agent. Typically, this is the external address of
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.
Registration Replies, it is typically all 0's, otherwise,
mobile node SHOULD interpret it as a hint
HA to MN Traversal
The IP address of an intermediate system or
encountered by datagrams sent by the home agent towards
mobile node. Typically, this is the internal address of
firewall or firewall complex
This field MUST be initialized in Registration Replies.
Registration Requests, it is typically all 0's, otherwise,
home agent SHOULD interpret it as a hint
8. Data
Data transfer proceeds along lines similar to the
Request outlined above. Section 8.1 discusses data traffic sent by
mobile node to a correspondent node. Section 8.2 shows packet
for the reverse traffic being tunneled by the home agent to
mobile node
8.1. Data Packet From the Mobile Node to a Correspondent
The mobile node composes a packet destined to a correspondent
located within the private network
The Mobile IP function in the mobile node examines the Inner
header, and determines that it satisfies conditions "a" and "b1"
Section 7.1. The mobile node requests the proper encryption
encapsulation services from SKIP
Thus, the mobile node with a co-located address sends
traffic to the firewall, using the following format
DATA PACKET: FROM THE MOBILE NODE VIA THE
+---------------+----------+----+-----+--------------+------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP |
+---------------+----------+----+-----+--------------+------+
IP Hdr (SKIP):
Source mobile node's care-of
Destination public (outside) address on the
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
Destination NSID = 0
Master Key-ID =
Inner IP Hdr
Source mobile node's home
Destination correspondent node's
The SKIP Firewall intercepts this packet, decrypts the Inner IP
and upper-layer payload (ULP) and checks the destination address
Since the packet is destined to a correspondent node in the
network, the "Inner" IP datagram is delivered internally. Once
SKIP firewall injects this packet into the private network, it
routed independently of its source address
As this last assumption is not always true, the mobile node
construct a bi-directional tunnel with its home agent. Doing so
guarantees that the "Inner IP Hdr" is
Inner IP Hdr
Source care-of
Destination home agent
When at home, communication between the the mobile node and
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
these hosts, MUST use a bi-directional tunnel
8.2. Data Packet From a Correspondent Node to the Mobile
The home agent intercepts a packet from a correspondent node to
mobile node. It encapsulates it such that the Mobile IP
IP header's source and destination addresses are the home agent
care-of addresses, respectively. This would suffice for
within the private network. Since the current care-of address of
mobile node is not within the private network, this packet MUST
sent via the firewall. The home agent can accomplish this
encapsulating the datagram in a SKIP packet destined to the
(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)
From the home agent to the private (inside) address of the
the packet format is
DATA PACKET: BETWEEN THE HOME AGENT AND THE
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP |
| (SKIP) | Hdr | | | IP Hdr | IP Hdr | |
+--------+------+----+-----+--------+--------+-----+
IP Hdr (SKIP):
Source home agent's
Destination private (inside) address on the
SKIP Hdr
Source NSID = 0
Master Key-ID =
Destination NSID = 0
Master Key-ID =
Mobile-IP IP Hdr
Source home agent's
Destination care-of
Inner IP Hdr
Source correspondent node's
Destination mobile node's
ULP: upper-layer
The packet format above does not require the firewall to have
dynamic binding. The association between the mobile node's
address and it care-of address can be deduced from the contents
the "Mobile-IP IP Hdr" and the "Inner IP Hdr".
Nevertheless, a nomadic binding is an assurance that currently
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)
The SKIP firewall intercepts the packet, and recovers the Mobile
encapsulated datagram. Before sending it out, the dynamic
filter configured by the original Registration Request
encryption of this packet, this time by the SKIP firewall
consumption by the mobile node. The resultant packet is
DATA PACKET: BETWEEN THE FIREWALL AND THE MOBILE
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP |
| (SKIP) | Hdr | | | IP Hdr | IP Hdr | |
+--------+------+----+-----+--------+--------+-----+
IP Hdr (SKIP):
Source firewall's public (outside)
Destination mobile node's care-of
SKIP Hdr
Source NSID = 0
Master Key-ID =
Destination NSID = 1
Master Key-ID = IPv4 address of the mobile
Mobile-IP IP Hdr
Source home agent's
Destination care-of
Inner IP Hdr
Source correspondent node's
Destination mobile node's
ULP: upper-layer
At the mobile node, SKIP processes the packets sent by the firewall
Eventually, the inner IP header and the upper-layer packet (ULP)
retrieved and passed on
9. Security
The topic of this document is security. Nevertheless, it
imperative to point out the perils involved in allowing a flow of
packets through a firewall. In essence, the mobile host itself
also take on responsibility for securing the private network,
it extends its periphery. This does not mean it stops
unencrypted IP packets with hosts on the public network.
example, it MAY have to do so in order to satisfy
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,
also on protocol and port numbers
Therefore, it MUST have some firewall capabilities, otherwise,
malicious individual that gains access to it will have gained
to the private network as well
Ideas in this document have benefited from discussions with at
the following people: Bill Danielson, Martin Patterson, Tom Markson
Rich Skrenta, Atsushi Shimbo, Behfar Razavi, Avinash Agrawal,
Shimomura and Don Hoffman. Jim Solomon has also provided many
comments on this document
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003,
1996.
[3] A. Aziz and M. Patterson, Design and Implementation of SKIP
available on-line at http://skip.incog.com/inet-95.ps.
previous version of the paper was presented at INET '95
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.,
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,
1995.
[7] Atkinson, R., "IP Authentication Header", RFC 1826,
1995.
[8] Stephen Kent, message to the IETF's IPSEC mailing list
Message-Id: ,
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
Unsigned Diffie-Hellman Public Value. Available on-line
http://skip.incog.com/spec/EUDH.html
Authors'
Gabriel E.
Sun Microsystems, Inc
901 San Antonio
Mailstop UMPK 15-214
Mountain View, California 94303
Phone: (415)786-6288
Fax: (415)786-6445
EMail: gabriel.montenegro@Eng.Sun.
Vipul
Sun Microsystems, Inc
901 San Antonio
Mailstop UMPK 15-214
Mountain View, California 94303
Phone: (415)786-3614
Fax: (415)786-6445
EMail: vipul.gupta@Eng.Sun.
Montenegro & Gupta Informational [Page 23]
RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP June 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A
Montenegro & Gupta Informational [Page 24]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
