Internet Engineering Task Force G. Montenegro, Editor
INTERNET DRAFT Sun Microsystems, Inc.
August 10, 1997
Reverse Tunneling for Mobile IP
draft-ietf-mobileip-tunnel-reverse-03.txt
Status of This Memo
This document is a submission by the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the Working Group mailing list at "mobile-ip@SmallWorks.COM".
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as ``work in
progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Mobile IP uses tunneling from the home agent to the mobile node's
care-of address, but rarely in the reverse direction. Usually, a
mobile node sends its packets through a router on the foreign
network, and assumes that routing is independent of source address.
When this assumption is not true, it is convenient to establish a
topologically correct reverse tunnel from the care-of address to the
home agent.
This document proposes backwards-compatible extensions to Mobile IP
in order to support topologically correct reverse tunnels. This
document does not attempt to solve the problems posed by firewalls
located between the home agent and the mobile node's care-of
address.
Montenegro Expires February 10, 1998 [Page 1]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
Table of Contents
1. Introduction ................................................... 3
1.1. Terminology .................................................. 4
1.2. Assumptions .................................................. 4
1.3. Justification ................................................ 4
2. Overview ....................................................... 5
3. New Packet Formats ............................................. 5
3.1. Mobility Agent Advertisement Extension ....................... 5
3.2. Registration Request ......................................... 6
3.3. Encapsulating Delivery Style Extension ....................... 7
3.4. Cookie Extensions ............................................ 8
3.4.1 Mobile-Foreign Cookie Extension ............................. 8
3.4.2 Foreign-Home Cookie Extension ............................... 10
3.5. New Registration Reply Codes ................................. 11
4. Changes in Protocol Behavior ................................... 12
4.1. Mobile Node Considerations ................................... 12
4.1.1. Sending Registration Requests to the Foreign Agent ......... 12
4.1.2. Receiving Registration Replies from the Foreign Agent ...... 13
4.2. Foreign Agent Considerations ................................. 14
4.2.1. Receiving Registration Requests from the Mobile Node ....... 14
4.2.2. Relaying Registration Requests to the Home Agent ........... 15
4.3. Home Agent Considerations .................................... 16
4.3.1. Receiving Registration Requests from the Foreign Agent ..... 16
4.3.2. Sending Registration Replies to the Foreign Agent .......... 17
5. Mobile Node to Foreign Agent Delivery Styles ................... 18
5.1. Direct Delivery Style ........................................ 18
5.1.1. Packet Processing .......................................... 18
5.1.2. Packet Header Format and Fields ............................ 18
5.2. Encapsulating Delivery Style ................................. 19
5.2.1 Packet Processing ........................................... 20
5.2.2. Packet Header Format and Fields ............................ 20
5.3. Support for Broadcast and Multicast Datagrams ................ 21
5.4. Selective Reverse Tunneling .................................. 22
6. Security Considerations ........................................ 22
6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ....... 22
6.2. Ingress Filtering ............................................ 23
7. Acknowledgements ............................................... 24
References ........................................................ 24
Editor and Chair Addresses ........................................ 24
Montenegro Expires February 10, 1998 [Page 2]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
1. Introduction
Section 1.3 of the Mobile IP specification [1] lists the following
assumption:
It is assumed that IP unicast datagrams are routed based on the
destination address in the datagram header (i.e., not by source
address).
Because of security concerns (e.g. IP spoofing attacks), and in
accordance with the IAB [8] and CERT [3] advisories to this effect,
routers that break this assumption are increasingly more common.
In the presence of such routers, the source and destination IP
address in a packet must be topologically correct. The forward
tunnel complies with this, as its endpoints (home agent address and
care-of address) are properly assigned addresses for their
respective locations. On the other hand, the source IP address of a
packet transmitted by the mobile node does not correspond to the
network prefix from where it emanates.
This document discusses topologically correct reverse tunnels.
Mobile IP does dictate the use of reverse tunnels in the context of
multicast datagram routing and mobile routers. However, the source
IP address is set to the mobile node's home address, so these
tunnels are not topologically correct.
Notice that there are several uses for reverse tunnels regardless of
their topological correctness:
- Mobile routers: reverse tunnels obviate the need for recursive
tunneling [1].
- Multicast: reverse tunnels enable a mobile node away from home
to (1) join multicast groups in its home network, and (2)
transmit multicast packets such that they emanate from its home
network [1].
- The TTL of packets sent by the mobile node (particularly when
sends packets to other hosts in its home network) may be so low
that they might expire before reaching their destination. A
reverse tunnel solves the problem as it represents a TTL
decrement of one [5].
Montenegro Expires February 10, 1998 [Page 3]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
1.1. Terminology
The discussion below uses terms defined in the Mobile IP
specification. Additionally, it uses the following terms:
Forward Tunnel
A tunnel that shuttles packets towards the mobile node. It
starts at the home agent, and ends at the mobile node's
care-of address.
Reverse Tunnel
A tunnel that starts at the mobile node's care-of address and
terminates at the home agent.
1.2. Assumptions
Mobility is constrained to a common IP address space (e.g. the
routing fabric between, say, the mobile node and the home agent is
not partitioned into a "private" and a "public" network).
This document does not attempt to solve the firewall traversal
problem. Rather, it assumes one of the following is true:
- There are no intervening firewalls along the path of the
tunneled packets.
- Any intervening firewalls share the security association
necessary to process any authentication [6] or encryption [7]
headers which may have been added to the tunneled packets.
The reverse tunnels considered here are symmetric, that is, they use
the same configuration (encapsulation method, IP address endpoints)
as the forward tunnel. IP in IP encapsulation [2] is assumed unless
stated otherwise.
Route optimization [4] introduces forward tunnels initiated at a
correspondent host. Since a mobile node may not know if the
correspondent host can decapsulate packets, reverse tunnels in that
context are not discussed here.
1.3. Justification
Why not let the mobile node itself initiate the tunnel to the home
Montenegro Expires February 10, 1998 [Page 4]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
agent? This is indeed what it should do if it is already operating
with a topologically correct co-located care-of address.
However, one of the primary objectives of the Mobile IP
specification is not to require this mode of operation.
The mechanisms outlined in this document are primarily intended for
use by mobile nodes that rely on the foreign agent for forward
tunnel support. It is desirable to continue supporting these mobile
nodes, even in the presence of filtering routers.
2. Overview
A mobile node arrives at a foreign network, listens for agent
advertisements and selects a foreign agent that supports reverse
tunnels. It requests this service when it registers through the
selected foreign agent. At this time, and depending on how the
mobile node wishes to deliver packets to the foreign agent, it also
requests either the Direct or the Encapsulating Delivery Style
(section 5).
In the Direct Delivery Style, the mobile node designates the foreign
agent as its default router and proceeds to send packets directly to
the foreign agent, i.e., without encapsulation. The foreign agent
intercepts them, and tunnels them to the home agent.
In the Encapsulating Delivery Style, the mobile node encapsulates
all its outgoing packets to the foreign agent. The foreign agent
decapsulates and re-tunnels them to the home agent, using the
foreign agent's care-of address as the entry-point of this new
tunnel.
3. New Packet Formats
3.1. Mobility Agent Advertisement Extension
Montenegro Expires February 10, 1998 [Page 5]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|V|T| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
The only change to the Mobility Agent Advertisement Extension [1] is
the additional 'T' bit:
T Agent offers reverse tunneling service.
A foreign agent that sets the 'T' bit MUST support the two delivery
styles currently supported: Direct and Encapsulating Delivery Style
(section 5).
Using this information, a mobile node is able to choose a foreign
agent that supports reverse tunnels. Notice that if a mobile node
does not understand this bit, it simply ignores it as per [1].
3.2. Registration Request
Reverse tunneling support is added directly into the Registration
Request by using one of the "rsvd" bits. If a foreign or home agent
that does not support reverse tunnels receives a request with the
'T' bit set, the Registration Request fails. This results in a
registration denial (failure codes are specified in section 3.5).
Most home agents would not object to providing reverse tunnel
support, because they "SHOULD be able to decapsulate and further
deliver packets addressed to themselves, sent by a mobile node"
[1]. In the case of topologically correct reverse tunnels, the
packets are not sent by the mobile node as distinguished by its home
address. Rather, the outermost (encapsulating) IP source address on
such datagrams is the care-of address of the mobile node.
Nevertheless, home agents probably already support the required
decapsulation and further forwarding.
Montenegro Expires February 10, 1998 [Page 6]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
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 |S|B|D|M|G|V|T|-| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
The only change to the Registration Request packet is the additional
'T' bit:
T If the 'T' bit is set, the mobile node asks its home
agent to accept a reverse tunnel from the care-of
address. Mobile nodes using a foreign agent care-of
address ask the foreign agent to reverse-tunnel its
packets.
3.3. Encapsulating Delivery Style Extension
The Encapsulating Delivery Style Extension MAY be included by the
mobile node in registration requests to further specify reverse
tunneling behavior. It is expected to be used only by the foreign
agent. Accordingly, the foreign agent MUST consume this extension
(i.e. it must not relay it to the home agent or include it in
replies to the mobile node). As per Section 3.6.1.3 of [1], the
mobile node MUST include the Encapsulating Delivery Style Extension
after the Mobile-Home Authentication Extension, and before the
Mobile-Foreign Authentication Extension, if present.
Encapsulating Extension MUST NOT be included if the 'T' bit is not
set in the Registration Request.
If this extension is absent, Direct Delivery is assumed.
Encapsulation is done according to what was negotiated for the
forward tunnel (i.e., IP in IP is assumed unless specified
otherwise). For more details on the delivery styles, please refer to
section 5.
Montenegro Expires February 10, 1998 [Page 7]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
128
Length
0
3.4. Cookie Extensions
In the absence of mobility security associations, Cookie Extensions
are used by mobile nodes, foreign agents and home agents to provide
some level of protection against reverse tunnel hijacking and denial
of service attacks (see Section 6). Cookies are not needed if the
mobile node operates in co-located mode since the two entities
involved (mobile node and home agent) MUST have a mobility security
association in place [1].
The Mobile-Foreign Cookie Extension is used only between the mobile
node and the foreign agent. Similarly, use of the Foreign-Home
Cookie Extension is limited to registration traffic between the
foreign agent and the home agent.
If a Registration Request with the 'T' bit on includes a Cookie
Extension, the corresponding successful (code 0) Registration Reply
MUST include one as well.
3.4.1 Mobile-Foreign Cookie Extension
Mobile nodes and foreign agents MAY include a Mobile-Foreign Cookie
Extension in Registration Requests and Replies, subject to the
conditions detailed in Sections 4.1 and 4.2.
The foreign agent MUST consume this extension (i.e. it MUST NOT
relay it to the home agent).
If the Mobile-Foreign Cookie Extension is present, as per Sections
3.6.1.3 and 3.7.3.2 of [1], the mobile node and the foreign agent
Montenegro Expires February 10, 1998 [Page 8]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
MUST include it after the Mobile-Home Authentication Extension.
For further details about the processing of this extension, at the
mobile node and the foreign agent, refer to Sections 4.1 and 4.2,
respectively.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
130
Length
10
Reserved
0
Current Cookie
In Registration Requests, it is a value generated randomly by
the mobile node.
In Registration Replies, the foreign agent sets it to the value
sent by the mobile node as the "Current Cookie" in the
corresponding Registration Request.
Previous Cookie
Set to 0 by the foreign agent in Registration Replies.
Set to 0 by the mobile node in initial Registration Requests.
In re-registrations, the mobile node sets this field to the
"Current Cookie" field of the Mobile-Foreign Cookie Extension
in the last successful (code 0) Registration Reply.
Montenegro Expires February 10, 1998 [Page 9]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
3.4.2 Foreign-Home Cookie Extension
Foreign agents and home agents MAY include a Foreign-Home Cookie
Extension in Registration Requests and Replies, subject to the
conditions detailed in Sections 4.2 and 4.3.
If the Foreign-Home Cookie Extension is present, as per Sections
3.7.3.2 and 3.8.3.3 of [1], the foreign agent and the home agent
MUST include it after the Mobile-Home Authentication Extension.
For further details about the processing of this extension, at the
foreign agent and the home agent, refer to Sections 4.2 and 4.3,
respectively.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
131
Length
10
Reserved
0
Current Cookie
In Registration Requests, it is a value generated randomly by
the foreign agent.
In Registration Replies, the home agent sets it to the value
sent by the foreign agent as the "Current Cookie" field of the
Foreign-Home Cookie Extension in the corresponding Registration
Request.
Previous Cookie
Montenegro Expires February 10, 1998 [Page 10]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
Set to 0 by the home agent in Registration Replies.
Set to 0 by the foreign node in initial Registration Requests.
In re-registrations, the foreign agent sets this field to the
"Current Cookie" field of the Foreign-Home Cookie Extension in
the last Registration Reply.
3.5. New Registration Reply Codes
Foreign and home agent registration replies MUST convey if the
reverse tunnel request failed. These new reply codes are defined:
Service denied by the foreign agent:
74 requested reverse tunnel unavailable
75 reverse tunnel is mandatory and 'T' bit not set
76 bad cookie
77 bad cookie from home agent
78 mobile node too distant
and
Service denied by the home agent:
137 requested reverse tunnel unavailable
138 reverse tunnel is mandatory and 'T' bit not set
139 requested encapsulation unavailable
140 bad cookie
In response to a Registration Request with the 'T' bit set, mobile
nodes may receive (and MUST accept) code 70 (poorly formed request)
from foreign agents and code 134 (poorly formed request) from home
agents. However, foreign and home agents that support reverse
tunneling MUST use codes 74 and 137, respectively.
Absence of the 'T' bit in a Registration Request MAY elicit denials
with codes 75 and 138 at the foreign agent and the home agent,
respectively.
Forward and reverse tunnels are symmetric, i.e. both are able to use
the same tunneling options negotiated at registration. This implies
that the home agent MUST deny registrations if an unsupported form
of tunneling is requested (code 139). Notice that Mobile IP [1]
already defines the analogous failure code 72 for use by the foreign
agent.
Montenegro Expires February 10, 1998 [Page 11]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
In response to a Registration Request with the 'T' bit set, mobile
nodes may receive (and MUST accept) codes 76 (bad cookie), 77 (bad
cookie from home agent) and 78 (mobile node too distant). from
foreign agents. Similarly, foreign agents MUST accept code 140 (bad
cookie) from home agents, and then relay it to mobile nodes. These
codes are sent as response to the absence of an expected Cookie
Extension, or if the values in the fields are unexpected.
4. Changes in Protocol Behavior
Reverse tunnels must be handled appropriately by the different
mobility entities. Differences in protocol behavior with respect to
the Mobile IP specification are specified in the subsequent
sections.
4.1. Mobile Node Considerations
This section describes how the mobile node handles registrations
that request a reverse tunnel.
4.1.1. Sending Registration Requests to the Foreign Agent
In addition to the considerations in [1], a mobile node sets the 'T'
bit in its Registration Request to petition a reverse tunnel.
If registering via a separate foreign agent, it MUST use either one
of the following:
a. If the mobile node has a security association with the
foreign agent, it MUST use it as specified in [1].
b. Otherwise, it MUST append a Mobile-Foreign Cookie Extension
to the Registration Request after the Mobile-Home
Authentication Extension. The "Current Cookie" field MUST
be generated randomly by the mobile node using guidelines
similar to those used in generating nonces.
If using a Mobile-Foreign Cookie Extension, the mobile node MUST set
the TTL field of the IP header to 255. This is meant to limit a
denial of service attack introduced by the use of Cookie Extensions
(Section 6).
The mobile node MAY optionally include an Encapsulating Delivery
Montenegro Expires February 10, 1998 [Page 12]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
Style Extension.
4.1.2. Receiving Registration Replies from the Foreign Agent
If the mobile node included a Mobile-Foreign Cookie Extension in its
Registration Request, the Registration Reply MUST also include one.
If it doesn't, the mobile node MUST ignore the reply. If such an
extension is present, the mobile node MUST verify that the value of
the "Current Cookie" field in the reply is equal to that in the
request. If it isn't, the mobile node MUST ignore this reply. The
mobile node SHOULD treat flag either of these two conditions as
security exceptions.
Possible valid responses are:
- A registration denial issued by either the home agent or the
foreign agent:
a. The mobile node follows the error checking guidelines in
[1], and depending on the reply code, MAY try modifying the
registration request (for example by eliminating the
request for alternate forms of encapsulation), and issuing
a new registration.
b. Depending on the reply code, the mobile node MAY try
zeroing the 'T' bit, eliminating the Encapsulating Delivery
Style Extension (if one was present), and issuing a new
registration.
c. The foreign agent returns code 76 ("bad cookie"). If
reissuing the Registration Request, the mobile node MUST
set the "Previous Cookie" to the appropriate value. If the
mobile node ignores this value, it can (a) wait for the
current binding at the foreign agent to expire, (b) attempt
registering using another foreign agent.
d. The foreign agent returns codes 77 (bad cookie from home
agent) or 78 (mobile node too distant). The mobile node MAY
try issuing a new registration via another foreign agent or
registering with another home agent. It SHOULD also flag
this event as a security exception.
e. The foreign agent relays code 140 ("bad cookie") from the
home agent. The mobile node MAY try issuing a new
registration via another foreign agent. It SHOULD also flag
this event as a security exception.
Montenegro Expires February 10, 1998 [Page 13]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
- The home agent returns a Registration Reply indicating that the
service will be provided.
In this last case, the mobile node has succeeded in establishing a
reverse tunnel between its care-of address and its home agent. If
the mobile node is operating with a co-located care-of address, it
MAY encapsulate outgoing data such that the destination address of
the outer header is the home agent. This ability to selectively
reverse-tunnel packets is discussed further in section 5.4.
If the care-of address belongs to a separate foreign agent, the
mobile node MUST employ whatever delivery style was requested
(Direct or Encapsulating) and proceed as specified in section 5.
A successful registration reply is an assurance that both the
foreign agent and the home agent support whatever alternate forms of
encapsulation (other than IP in IP) were requested. Accordingly, the
mobile node MAY use them at its discretion.
If a valid Mobile-Foreign Cookie Extension is present in the
Registration Reply, the mobile node MUST record the value reported
by the foreign agent in the "Current Cookie" field. This value MUST
be used to set the "Previous Cookie" field of the Mobile-Foreign
Cookie Extension in a subsequent re-registration. Failure to do so
will result in a registration denial. Of course, after the
registration expires at the foreign agent the mobile node may
register with a "Previous Cookie" set to 0.
In order to re-register after rebooting, a mobile node MAY choose to
record a Registration Reply's "Current Cookie" field in non-volatile
storage. Alternatively, it MAY request a sufficiently short lifetime
in its registration (e.g. comparable to the time the mobile node
takes to reboot).
4.2. Foreign Agent Considerations
This section describes how the foreign agent handles registrations
that request a reverse tunnel.
4.2.1. Receiving Registration Requests from the Mobile Node
A foreign agent that receives a Registration Request with the 'T'
bit set processes the packet as specified in the Mobile IP
specification [1], and determines whether it can accomodate the
Montenegro Expires February 10, 1998 [Page 14]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
forward tunnel request. If it cannot, it returns an appropriate
code. In particular, if the foreign agent is unable to support the
requested form of encapsulation it MUST return code 72.
The foreign agent MAY reject Registration Requests without the 'T'
bit set by denying them with code 75 (reverse tunnel is mandatory
and 'T' bit not set).
A foreign agent expects a Registration Request with 'T' bit on to be
secured by either of these:
a. Mobile-Foreign Authentication Extension (preferred), or
b. Mobile-Foreign Cookie Extension.
If neither of the above is present, the foreign agent MUST reject
the registration with code 76 (bad cookie).
If the Registration Request includes a Mobile-Foreign Extension, the
foreign agent MUST verify that the TTL field of the IP header is set
to 255. Otherwise, it MUST reject the registration with code 78
(mobile node too distant). The foreign agent MUST record the value
of the "Current Cookie" field. This value MUST match the "Previous
Cookie" field in subsequent re-registrations issued by the same
mobile node. A mismatch MUST result in the foreign agent's denying
the registration with code 76 (bad cookie).
As a last check, the foreign agent verifies that it can support a
reverse tunnel with the same configuration. If it cannot, it MUST
return a Registration Reply denying the request with code 74
(requested reverse tunnel unavailable).
4.2.2. Relaying Registration Requests to the Home Agent
Otherwise, the foreign agent MUST relay the Registration Request to
the home agent. The foreign agent MUST use either of these:
a. Foreign-Home Authentication Extension (preferred), or
b. Foreign-Home Cookie Extension.
If the foreign agent receives a denial with code 140 (bad cookie)
from the home agent, it MUST relay it to the mobile node.
If the foreign agent included a Foreign-Home Cookie Extension when
it relayed the Registration Request, the Registration Reply MUST
Montenegro Expires February 10, 1998 [Page 15]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
also include one. If it doesn't, the foreign agent MUST send a
denial to the mobile node with code 77 (bad cookie from home
agent). If such an extension is present, the foreign agent MUST
verify that the value of the "Current Cookie" field in the reply is
equal to that in the request. If it isn't, the foreign agent MUST
send a denial to the mobile node with code 77 (bad cookie from home
agent). The foreign agent SHOULD flag either of these two
conditions as security exceptions.
If the reply includes a Foreign-Home Authentication Extension, the
foreign agent MUST record the value of the "Current Cookie" field.
This value must be used to set the "Previous Cookie" field when
relaying a subsequent re-registration from the same mobile node.
Upon receipt of a Registration Reply that satisfies validity checks,
the foreign agent MUST update its visitor list, including indication
that this mobile node has been granted a reverse tunnel and the
delivery style expected (section 5).
The foreign agent MUST then relay the Registration Reply to the
mobile node, including either a Mobile-Foreign Authentication
Extension or Mobile-Foreign Cookie Extension, whichever was present
in the corresponding Registration Request. In the latter case, the
value of the "Current Cookie" MUST be equal to that in the same
field of the corresponding request.
While this visitor list entry is in effect, the foreign agent MUST
process incoming traffic according to the delivery style,
encapsulate it and tunnel it from the care-of address to the home
agent's address.
4.3. Home Agent Considerations
This section describes how the home agent handles registrations that
request a reverse tunnel.
4.3.1. Receiving Registration Requests from the Foreign Agent
A home agent that receives a Registration Request with the 'T' bit
set processes the packet as specified in the Mobile IP specification
[1] and determines whether it can accomodate the forward tunnel
request. If it cannot, it returns an appropriate code. In
particular, if the home agent is unable to support the requested
form of encapsulation it MUST return code 139.
Montenegro Expires February 10, 1998 [Page 16]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
The home agent MAY reject registration requests without the 'T' bit
set by denying them with code 138 (reverse tunnel is mandatory and
'T' bit not set).
A home agent expects a Registration Request with 'T' bit on to be
secured by either of these:
a. Foreign-Home Authentication Extension (preferred), or
b. Foreign-Home Cookie Extension.
If neither of the above is present, the home agent MUST reject the
registration with code 140 (bad cookie).
If the Registration Request includes a Foreign-Home Extension, the
home agent MUST record the value of the "Current Cookie" field. This
value MUST match the "Previous Cookie" field in subsequent
re-registrations relayed by the foreign agent on behalf of the same
mobile node. A mismatch MUST result in the home agent's denying the
registration with code 140 (bad cookie).
As a last check, the home agent determines whether it can support a
reverse tunnel with the same configuration as the forward tunnel. If
it cannot, it MUST send back a registration denial with code 137.
Upon receipt of a Registration Reply that satisfies validity checks,
the home agent MUST update its mobility bindings list to indicate
that this mobile node has been granted a reverse tunnel and the type
of encapsulation expected.
4.3.2. Sending Registration Replies to the Foreign Agent
In response to a valid Registration Request, a home agent MUST issue
a Registration Reply to the mobile node, including either a
Foreign-Home Authentication Extension or a Foreign-Home Cookie
Extension, whichever was present in the corresponding Registration
Request. In the latter case, the value of the "Current Cookie" MUST
be equal to that in the same field of the corresponding request.
After a successful registration, the home agent may receive
encapsulated packets addressed to it. For each such packet it MAY
search for a mobility binding whose care-of address is the source of
the outer header, and whose mobile node address is the source of the
inner header. If no such binding is found, or if the packet uses an
encapsulation mechanism that was not negotiated at registration the
home agent MUST silently discard the packet and SHOULD log the event
Montenegro Expires February 10, 1998 [Page 17]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
as a security exception.
While the registration is in effect, a home agent MUST process each
valid reverse tunneled packet (as determined by checks like the
above) by decapsulating it, recovering the original packet, and then
forwarding it on behalf of its sender (the mobile node) to the
destination address (the correspondent host).
5. Mobile Node to Foreign Agent Delivery Styles
This section specifies how the mobile node sends its data traffic
via the foreign agent. In all cases, the mobile node learns the
foreign agent's link-layer address from the link-layer header in the
agent advertisement.
5.1. Direct Delivery Style
This delivery mechanism is very simple to implement at the mobile
node, and uses small (non-encapsulated) packets on the link between
the mobile node and the foreign agent (potentially a very slow
link). However, it only supports reverse-tunneling of unicast
packets, and does not allow selective reverse tunneling (section
5.4).
5.1.1. Packet Processing
The mobile node MUST designate the foreign agent as its default
router. Not doing so will not guarantee encapsulation of all the
mobile node's outgoing traffic, and defeats the purpose of the
reverse tunnel. The foreign agent MUST:
- detect packets sent by the mobile node, and
- modify its forwarding function to encapsulate them before
forwarding.
5.1.2. Packet Header Format and Fields
This section shows the format of the packet headers used by the
Direct Delivery style. The formats shown assume IP in IP
encapsulation [2].
Montenegro Expires February 10, 1998 [Page 18]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
Packet format received by the foreign agent (Direct Delivery
Style):
IP fields:
Source Address = mobile node's home address
Destination Address = correspondent host's address
Upper Layer Protocol
Packet format forwarded by the foreign agent (Direct Delivery
Style):
IP fields (encapsulating header):
Source Address = foreign agent's care-of address
Destination Address = home agent's address
Protocol field: 4 (IP in IP)
IP fields (original header):
Source Address = mobile node's home address
Destination Address = correspondent host's address
Upper Layer Protocol
These fields of the encapsulating header MUST be chosen as follows:
IP Source Address
Copied from the Care-of Address field within the Registration
Request.
IP Destination Address
Copied from the Home Agent field within the Registration
Request.
IP Protocol Field
Default is 4 (IP in IP [2]), but other methods of
encapsulation MAY be used as negotiated at registration time.
5.2. Encapsulating Delivery Style
This mechanism requires that the mobile node implement
encapsulation, and explicitly directs packets at the foreign agent
by designating it as the destination address in a new outermost
header. Mobile nodes that wish to send either broadcast or
multicast packets MUST use the Encapsulating Delivery Style.
Montenegro Expires February 10, 1998 [Page 19]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
5.2.1 Packet Processing
The foreign agent does not modify its forwarding function.
Rather, it receives an encapsulated packet and after verifying that
it was sent by the mobile node, it:
- decapsulates to recover the inner packet,
- re-encapsulates, and sends it to the home agent.
If a foreign agent receives an un-encapsulated packet from a mobile
node which had explicitly requested the Encapsulated Delivery Style,
then the foreign agent MUST NOT reverse tunnel such a packet and
rather MUST forward it using standard, IP routing mechanisms.
5.2.2. Packet Header Format and Fields
This section shows the format of the packet headers used by the
Encapsulating Delivery style. The formats shown assume IP in IP
encapsulation [2].
Packet format received by the foreign agent (Encapsulating Delivery
Style):
IP fields (encapsulating header):
Source Address = mobile node's home address
Destination Address = foreign agent's address
Protocol field: 4 (IP in IP)
IP fields (original header):
Source Address = mobile node's home address
Destination Address = correspondent host's address
Upper Layer Protocol
The fields of the encapsulating IP header MUST be chosen as
follows:
IP Source Address
The mobile node's home address.
IP Destination Address
The address of the agent as learned from the IP source address
of the agent's most recent registration reply.
Montenegro Expires February 10, 1998 [Page 20]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
IP Protocol Field
Default is 4 (IP in IP [2]), but other methods of
encapsulation MAY be used as negotiated at registration time.
Packet format forwarded by the foreign agent (Encapsulating Delivery
Style):
IP fields (encapsulating header):
Source Address = foreign agent's care-of address
Destination Address = home agent's address
Protocol field: 4 (IP in IP)
IP fields (original header):
Source Address = mobile node's home address
Destination Address = correspondent host's address
Upper Layer Protocol
These fields of the encapsulating IP header MUST be chosen as
follows:
IP Source Address
Copied from the Care-of Address field within the Registration
Request.
IP Destination Address
Copied from the Home Agent field within the Registration
Request.
IP Protocol Field
Default is 4 (IP in IP [2]), but other methods of
encapsulation MAY be used as negotiated at registration time.
5.3. Support for Broadcast and Multicast Datagrams
If a mobile node is operating with a co-located care-of address,
broadcast and multicast datagrams are handled according to Sections
4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using a
foreign agent care-of address MAY have their broadcast and multicast
datagrams reverse-tunneled by the foreign agent. However, any
mobile nodes doing so MUST use the encapsulating delivery style.
This delivers the datagram only to the foreign agent. The latter
decapsulates it and then processes it as any other packet from the
Montenegro Expires February 10, 1998 [Page 21]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
mobile node, namely, by reverse tunneling it to the home agent.
5.4. Selective Reverse Tunneling
Packets destined to local resources (e.g. a nearby printer) might be
unaffected by ingress filtering. A mobile node with a co-located
care-of address MAY optimize delivery of these packets by not
reverse tunneling them. On the other hand, a mobile node using a
foreign agent care-of address MAY use this selective reverse
tunneling capability by requesting the Encapsulating Delivery Style,
and following these guidelines:
Packets NOT meant to be reversed tunneled:
Sent using the Direct Delivery style. The foreign agent
MUST process these packets as regular traffic: they MAY be
forwarded but MUST NOT be reverse tunneled to the home agent.
Packets meant to be reverse tunneled:
Sent using the Encapsulating Delivery style. The foreign agent
MUST process these packets as specified in section 5.2: they
MUST be reverse tunneled to the home agent.
6. Security Considerations
The extensions outlined in this document are subject to the security
considerations outlined in the Mobile IP specification [1].
Essentialy, creation of both forward and reverse tunnels involves an
authentication procedure, which reduces the risk for attack.
6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks
Once the tunnel is set up, a malicious node could hijack it to
inject packets into the network. Reverse tunnels might exacerbate
this problem, because upon reaching the tunnel exit point packets
are forwarded beyond the local network. This concern is also present
in the Mobile IP specification, as it already dictates the use of
reverse tunnels for certain applications.
Unauthenticated exchanges involving the foreign agent allow a
malicious node to pose as a valid mobile node and re-direct an
existing reverse tunnel to another home agent, perhaps another
Montenegro Expires February 10, 1998 [Page 22]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
malicious node. The best way to protect against these attacks is by
employing the Mobile-Foreign and Foreign-Home Authentication
Extensions defined in [1]. If the necessary mobility security
associations are not available, Cookie Extensions (Section 3.4) MUST
be used to protect against off-the-path attacks.
The Mobile-Foreign Cookie Extension enables a foreign agent to
distinguish between a mobile node for which it has a current visitor
list entry and an off-the-path attacker. The Foreign-Home Cookie
Extension enables a foreign agent to distinguish between the home
agent for a mobile node currently in a visitor list entry and an
off-the-path attacker.
However, cookies are unauthenticated state, and as such, may be used
to launch denial-of-service attacks. For example, a malicious node
may register via a foreign agent using another malicious node as its
home agent. The existence of this visitor list entry at the foreign
agent effectively blocks the real mobile node from registering. As
a consequence, the mobile node SHOULD cache the cookies in permanent
storage, otherwise it will be unable to register in the event of a
reboot as long as it has a valid visitor list entry at the foreign
agent. Alternatively, the mobile node MAY request appropriately
short lifetimes in its Registration Requests.
This document also introduces other mechanisms to reduce the range
and effectiveness of the attacks. Requiring a TTL value of 255 in
the IP headers of Registration Requests received at the foreign
agent prevents malicious nodes more than one hop away from posing as
valid mobile nodes. Additional codes for use in registration denials
make those attacks that do occur easier to track.
6.2. Ingress Filtering
There has been some concern regarding the long-term effectiveness of
reverse-tunneling in the presence of ingress filtering. The
conjecture is that network administrators will target
reverse-tunneled packets (IP in IP encapsulated packets) for
filtering. The ingress filtering recommendation spells out why this
is not the case [8]:
Tracking the source of an attack is simplified when the source is
more likely to be "valid."
Montenegro Expires February 10, 1998 [Page 23]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
7. Acknowledgements
The encapsulating style of delivery was proposed by Charlie
Perkins. Jim Solomon has been instrumental in shaping this document
into its present form.
References
[1] C. Perkins. IP Mobility Support. RFC 2002, October 1996.
[2] C. Perkins. IP Encapsulation within IP. RFC 2003, October
1996.
[3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
and Hijacked Terminal Connections", CA-95:01, January 1995.
Available via anonymous ftp from info.cert.org in
/pub/cert_advisories.
[4] D. Johnson and C. Perkins. Route Optimization in Mobile IP --
work in progress, draft-ietf-mobileip-optim-06.txt, July 1997.
[5] Manuel Rodriguez, private communication, August 1995.
[6] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[7] R. Atkinson. IP Encapsulating Security Payload. RFC 1827,
August 1995.
[8] P. Ferguson and D. Senie. Network Ingress Filtering: Defending
Against IP Source Address Spoofing -- work in progress,
draft-ferguson-ingress-filtering-02.txt, July 1997.
Editor and Chair Addresses
Montenegro Expires February 10, 1998 [Page 24]
INTERNET DRAFT Reverse Tunneling for Mobile IP August 1997
Questions about this document may be directed at:
Gabriel E. Montenegro
Sun Microsystems, Inc.
an Antonio Road
Mailstop UMPK 15-214
Mountain View, California 94303
Voice: +1-415-786-6288
Fax: +1-415-786-6445
E-Mail: gabriel.montenegro@eng.sun.com
The working group can be contacted via the current chairs:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd. - Rm 2240
Schaumburg, IL 60196
Voice: +1-847-576-2753
Fax: +1-847-576-3240
E-Mail: solomon@comm.mot.com
Erik Nordmark
Sun Microsystems, Inc.
901 San Antonio Road
Mailstop UMPK17-202
Mountain View, California 94303
Voice: +1-415-786-5166
E-Mail: erik.nordmark@eng.sun.com
Montenegro Expires February 10, 1998 [Page 25]
