One document matched: draft-montenegro-tunneling-00.txt
Internet Engineering Task Force Gabriel Montenegro
INTERNET DRAFT Sun Microsystems, Inc.
January 5, 1996
Bi-directional Tunneling for Mobile IP
draft-montenegro-tunneling-00.txt
Status of This Memo
This document is a submission to the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
either to the author, or to the mobile-ip@SmallWorks.COM mailing
list.
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
The Mobile IP specification uses tunneling from the home agent to
the mobile node, but not in the reverse direction. Instead, a
mobile node sends its packets through a router in the foreign net,
and relies on routing to be done independently of source address.
When this assumption is not true, or when other considerations
dictate it, it is convenient to establish bi-directional tunnels
between the home agent and the mobile node's care-of address. This
document proposes backwards-compatible extensions to Mobile IP in
order to support bi-directional tunnels.
Montenegro Expires July 5, 1996 [Page 1]
INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996
1. Introduction
The Mobile IP specification specifies tunneling from the home agent
to the mobile node, but not in the reverse direction. This reverse
tunneling is deemed unnecessary because of the following assumption
from section 1.3 of the Mobile IP draft [1]:
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 CERT advisory to this effect [3], routers and
firewalls that break this assumption are increasingly more common.
Use of bi-directional tunnels eliminates the above constraint.
Multicast routing also breaks the above assumption. It requires that
a mobile node send packets that originate at a topologically
significant address. This implies a bi-directional tunnel unless the
mobile node owns another address (or has temporarily acquired one)
for use as a care-of address. However, this option is limited by
foreign agents that set the 'R' ("registration required") bit.
Other benefits are:
a) Bi-directional tunnels applied to mobile routers obviate the
need for recursive tunneling [1].
b) Location Privacy: the outer addresses of the reverse tunnel
(the care-of address and home agent address) shield the
inner mobile node address from examination by intermediate
routers, specially if using an encrypted tunnel.
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
Montenegro Expires July 5, 1996 [Page 2]
INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996
terminates at the home agent.
Pop-up
A mobile node whose care-of address is an address associated
to one of its own interfaces. This address may be a temporary
address acquired dynamically (e.g. by means of DHCP or PPP's
IPCP), or through manual intervention. It may also be a
permanent address assigned to one of the mobile node's
interfaces (e.g. a permanent PPP address). Since pop-ups do
not require a separate foreign agent, they can operate in
foreign nets that lack Mobile IP support.
1.2. Assumptions
The bi-directional tunnels considered here are symmetric, that is,
the reverse tunnel uses 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 cannot know if the
correspondent host can decapsulate packets, bi-directional tunnels
in this context are not discussed here.
1.3. Justification
Given that it is easy to encapsulate packets, why not let the mobile
node do the encapsulation itself? There are several reasons:
a) It is only possible if the mobile node is in pop-up mode,
but one of the primary objectives of the Mobile IP draft is
to not *require* this mode of operation.
NOTE: Strictly speaking, even in the separate foreign agent case,
the mobile node could encapsulate packets and use the
foreign agent's address (or some other topologically valid
address) as the source address of the tunnel. However,
this is an instance of IP spoofing, and as such is likely
to create more problems than it solves (e.g. IP header
identification field conflicts, mobile node authentication
failures in the context of a home agent/foreign agent
security association or raising security alarms).
b) It complicates the mobile node implementation on some
platforms, as it would probably require kernel code, whereas
Montenegro Expires July 5, 1996 [Page 3]
INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996
a pure mobile node implementation does not.
c) The mobile node, perhaps a portable battery-operated device,
is better served if it can offload this extra processing to
the potentially more powerful foreign agent.
2. New Packet Formats
Support for bi-directional tunnels on mobile nodes operating as
pop-ups does not requires changing the Mobile Service Extension in
agent advertisements, only the registration request and reply
packets.
On the other hand, if the mobile node's care-of address belongs to a
separate foreign agent, bi-directional tunneling benefits from
having the proper support in the agent advertisements as well.
2.1. Agent Advertisements: Mobile Service Extension
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 Mobile Service Extension [1] is the
additional 'T' bit:
T Agent offers bi-directional tunneling.
Using this information, an mobile node is able to choose a foreign
agent that supports bi-directional tunnels. Notice that if a mobile
node does not understand this bit, it will simply ignore it.
2.2. Registration Request
Bi-directional tunneling support is added directly into the
registration request by using one of the "rsvd" bits. Notice that
if a foreign or home agent that does not support bi-directional
tunnels receives a request with the 'T' bit set, the registration
request fails. Foreign agents deny the request with status code 70,
Montenegro Expires July 5, 1996 [Page 4]
INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996
and home agents with status code 134.
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|T|rsv| 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 use a bi-directional tunnel.
2.3. New Registration Reply Codes
Foreign and home agent replies must convey if the bi-directional
tunnel request failed. Two new reply codes are defined. Their use
is preferred over code 70 for foreign agents and code 134 for home
agents:
Service denied by the foreign agent:
74 requested bi-directional tunnel unavailable
and
Service denied by the home agent:
137 requested bi-directional tunnel unavailable
3. Changes in Protocol Behavior
Bi-directional tunnels must be handled appropriately by the
different mobility entities. Differences in protocol behavior with
Montenegro Expires July 5, 1996 [Page 5]
INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996
respect to the Mobile IP specification are:
3.1. Mobile Node Considerations
A mobile node sets the 'T' bit in its registration to request a
bi-directional tunnel. Possible outcomes are:
- The foreign agent returns a registration denial. Depending on
the reply code and following the error checking guidelines in
[1], the mobile node MAY try zeroing the 'T' bit and issuing a
new registration.
- The home agent returns a registration denial. Depending on the
reply code and following the error checking guidelines in [1],
the mobile node MAY try zeroing the 'T' bit and issuing a new
registration.
- 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
bi-directional tunnel between its care-of address and its home
agent. If the mobile node is operating as a pop-up, it SHOULD
encapsulate all outgoing data such that the destination address of
the outer header is the home agent. Not doing so does not
necessarily preclude data transmission, but it defeats the purpose
of the bi-directional tunnel.
If the care-of address belongs to a separate foreign agent, the
mobile node SHOULD designate it 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 bi-directional tunnel.
3.2. Foreign Agent Considerations
A foreign agent that receives a registration reply with the 'T' bit
set MAY either:
- Return a registration reply denying the request. Valid return
codes are: requested bi-directional tunnel unavailable (74) or
poorly formed request (70).
- Verify the packet according to [1] and then relay it to the
home agent.
Upon receipt of a Registration Reply that satisfies validity checks,
it MUST update its visitor list, including indication that this
Montenegro Expires July 5, 1996 [Page 6]
INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996
mobile node has been granted a bi-directional tunnel.
While this visitor list entry is in effect, any incoming traffic
from the mobile node must be encapsulated and tunnelled from the
care-of address to the home agent's address.
3.3. Home Agent Considerations
A home agent that receives a registration request with the 'T' bit
set processes the packet as specified in the Mobile IP specification
[1]. As a result, it determines if it can accomodate the forward
tunnel request. As a last check, the home agent verifies that it can
support a reverse tunnel with the same configuration.
If it can, the home agent sends back a registration reply with code
0 or 1. A registration denial should send back code 137 or 134.
After a successful registration, the home agent will receive
encapsulated packets addressed to it. For each such packet it must
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.
The home agent MUST decapsulate, recover the original packet, and
then forward it on behalf of its sender (the mobile node)
to the destination address (the correspondent host).
4. 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.
However, once the tunnel is set up, a malicious user could hijack it
to inject packets into the network. Reverse tunnels might exacerbate
this problem, because upon reaching the end of the tunnel packets
are forwarded beyond the local network.
References
[1] C. Perkins. IP Mobility Support. Internet Draft -- work in
progress, December 1995.
[2] C. Perkins. IP Encapsulation within IP. Internet Draft --
Montenegro Expires July 5, 1996 [Page 7]
INTERNET DRAFT Bi-directional Tunneling for Mobile IP January 1996
work in progress, October 1995.
[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, November 1995.
Author's Address
Gabriel E. Montenegro
Sun Microsystems, Inc.
2550 Garcia Avenue
Mailstop UMPK14-305
Mountain View, California 94043-1100
Tel: (415)786-6288
Fax: (415)786-6445
gabriel.montenegro@Eng.Sun.COM
Montenegro Expires July 5, 1996 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-21 09:50:28 |