Internet DRAFT - draft-zhang-mobopts-agent-mip4rr
draft-zhang-mobopts-agent-mip4rr
Network Working Group J. Zhang
Internet-Draft D. Pearce
Expires: February 11, 2006 University of York
August 10, 2005
Agent-Based Return Routability Test for Mobile IPv4 Route Optimization
draft-zhang-mobopts-agent-mip4rr-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document is to propose a more deployable route optimization
scheme for Mobile IPv4, which is transparent to fixed IPv4 end nodes,
and does not need any preconfigured security associations.
Specifically, we propose to adapt the Mobile IPv6 Return Routability
Test for Mobile IPv4 route optimization, on the basis of an agent-
based architecture. In order to achieve this, six new message types
and formats are defined for Mobile IPv4.
Zhang & Pearce Expires February 11, 2006 [Page 1]
Internet-Draft Agent-Based RR for MIPv4 August 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Return Routability Test for Mobile IPv4 . . . . . . . . . . . 7
5. New Message Format . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1 Normative References . . . . . . . . . . . . . . . . . . . 17
8.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Zhang & Pearce Expires February 11, 2006 [Page 2]
Internet-Draft Agent-Based RR for MIPv4 August 2005
1. Introduction
IP Mobility Support for IPv4, or Mobile IPv4 (MIPv4) [RFC3344], is a
routing protocol standardized by the IETF to offer mobility functions
for mobile hosts. It is designed based on the top of the current
IPv4 infrastructure, and no modifications are required in existing
fixed hosts and routers that do not understand the protocol. As a
result, all datagrams destined for a Mobile Node (MN) away from home
are still sent to its home network, and are then redirected by the
Home Agent (HA) using the tunnelling technique to the current
location (care-of address) of the MN. However, datagrams sent by the
MN are forwarded directly to its Correspondent Nodes (CNs) in normal
cases. This leads to the problem called triangle routing. In some
situation, where the ingress filtering policy needs to be tackled in
foreign networks, datagrams sent by the MN MAY be reversed tunnelled
to the HA by the Foreign Agent (FA) or the MN itself, and then routed
normally from the home network to the CNs. In both cases, datagrams
are routed in an inefficient way, because they need to travel a
longer path than in normal routing system. Moreover, the home
network and the HA may incur a big burden for processing datagrams
when there are a large number of MNs with heavy data traffics.
To increase the routing efficiency of MIPv4, several route
optimization schemes have been proposed to help datagrams be routed
directly between MNs and their CNs when they are in foreign networks.
However, all these schemes face a security challenge, since a
Security Association (SA) needs to be set up between the two
communication parties before they can run any route optimization
scheme. Currently, there are still no standardized solutions to
dynamically set up SAs between two random nodes in the IPv4
infrastructure. Manual SA configuration greatly discourages any
MIPv4 route optimization scheme to be standardized and deployed.
Mobility Support in IPv6, or Mobile IPv6 (MIPv6) [RFC3775], is
another mobility support protocol designed by the IETF based on IPv6
networks. One of the major differences between MIPv6 and MIPv4 is
that MIPv6 integrates route optimization support as a fundamental
part of the standard, which is due to the expectation of a better
support for mobility and security functions in every IPv6 node.
Specifically, a method called Return Routability (RR) test is
introduced to run the route optimization process between an MN and
any CN. Using RR, no preconfigured SA and authentication
infrastructure are required between the MN and the CN, and the
possibility of suffering from attacks is limited to a very low level.
In this document, we propose to adapt the MIPv6 RR test for MIPv4
route optimization. Our design goal is two fold: 1) to achieve route
optimization in MIPv4 with the same security level as that in MIPv6;
Zhang & Pearce Expires February 11, 2006 [Page 3]
Internet-Draft Agent-Based RR for MIPv4 August 2005
2) to maintain the original MIPv4 design goal that mobility support
protocol should be transparent to existing fixed nodes and ordinary
routers.
The structure of this paper is as follows. First an introduction on
some related work on route optimization is given in section 3. Then
our designed architecture and MIPv4 Return Routability test procedure
are described in section 4. Afterwards in section 5 the proposed
message formats are presented. Finally, security considerations and
IANA considerations are outlined in section 6 and 7 respectively.
2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Related Work
In this section, a couple of related MIPv4 route optimization schemes
and the MIPv6 RR test are reviewed.
A. MIPv4 Route Optimization Extension
Perkins et al. proposed the route optimization extension [Perki02]
for MIPv4, which provides a means for CNs to maintain a binding cache
for MNs in order to tunnel datagrams directly to them, bypassing
their HA. Basically, an MN's HA and its CNs exchange the Binding
Update (BU) message and the Binding Acknowledgement (BAck) message to
manage the binding cache in the CNs. Obviously, in order to support
this scheme, CNs MUST be modified to understand the protocol.
Moreover, since the BU message needs to be authenticated, a
preconfigured SA is needed between an MN's HA and a CN. These cause
great difficulties for wide deployment.
B. Agent-Based MIPv4 Route Optimization
More recently, Vadali et al. designed an agent-based MIPv4 route
optimization scheme [Vadal01], whose key idea is to introduce
Correspondent Agents (CAs) in networks to maintain binding caches and
tunnel datagrams on behalf of each individual CN. In this way, the
route optimization function is transparent to end nodes, and hence no
modifications are required in CNs. In addition, a CA MAY manage the
binding caches for a number of end nodes in the same subnet. When
multiple CNs in the same subnet are communicating with an MN, only
one BU message is required to update the mobility binding, which
reduces signalling traffics. However, the security challenge still
exists since it is hard to guarantee that an MN's HA shares a SA with
Zhang & Pearce Expires February 11, 2006 [Page 4]
Internet-Draft Agent-Based RR for MIPv4 August 2005
any CA that it will communicate with.
C. Mobile IPv6 Return Routability Test for Route Optimization
In MIPv6 route optimization, a mobility option called Binding
Authorization Data option [RFC3775] is defined to carry
authentication data for protecting Binding Update messages. A
binding management key, Kbm, which can be established through the RR
test procedure, is employed in this option. The RR test involves
four types of messages, which are Home Test Init (HoTI), Care-of Test
Init (CoTI), Home Test (HoT), and Care-of Test (CoT). The RR
procedure can be briefly described as follows:
Each CN holds a secret node key, or Kcn. Each CN also periodically
generates nonces. Each nonce is associated with a nonce index. An
MN initiates a RR test by sending an HoTI (usually reverse tunnelled
using IPsec (IP Security) encapsulating security payload (ESP) to the
HA first) and a CoTI to a CN. Specifically, a 64-bit random number
called the "home init cookie" is included in the HoTI, and another
called the "care-of init cookie" is included in the CoTI by the MN.
These cookies are to be returned by the CN in the HoT and the CoT
respectively later, in order to verify that the HoT and the CoT match
the HoTI and the CoTI respectively.
On receipt of the HoTI, the CN returns an HoT, containing the home
init cookie, home keygen token, and the index of the nonce used to
calculate the home keygen token. The home keygen token is
cryptographically generated from calculating a hash function over the
concatenation of the Kcn, the source address of the HoTI message (the
MN's home address), and a nonce:
home keygen token = hash (Kcn | MN's home address | nonce | 0).
The HoT is usually sent to the MN's HA in plain text first, and then
forwarded to the MN using the IPsec ESP tunnel.
On receipt of the CoTI, the CN returns a CoT, containing the care-of
init cookie, care-of keygen token, and the index of the nonce used to
calculate the care-of keygen token. The home keygen token is
cryptographically generated from calculating a hash function over the
concatenation of the Kcn, the source address of the CoTI message (the
MN's current care-of address), and a nonce:
care-of keygen token = hash (Kcn | MN's care-of address | nonce | 1).
The CoT is sent directly to the MN in plain text.
After receiving both HoT and CoT, the MN is able to create a binding
Zhang & Pearce Expires February 11, 2006 [Page 5]
Internet-Draft Agent-Based RR for MIPv4 August 2005
management key (Kbm) using a hash function over the home keygen token
and the care-of keygen token obtained:
Kbm = hash (home keygen token | care-of keygen token).
Then the MN can send a BU message to the CN protected by the Kbm
contained in the Binding Authorization Data option. Since the BU
also contains both the MN's home address and care-of address, and the
indices of the nonces used to generate the keygen tokens, given the
Kcn, the CN is able to re-generate the keygen tokens, and then
calculate the Kbm in order to authenticate the BU. A BAck message
may be returned by the CN in response.
Figure 1 shows the message flow of the MIPv6 route optimization
procedure.
MN HA CN
| HoTI-Reverse Tunnelled | HoTI(home init cookie) |
|-------------------------->|---------------------------->|
| | |
| CoTI(care-of init cookie) |
|-------------------------------------------------------->|
| HoT-Tunnelled | HoT(home init cookie,home |
|<--------------------------|<----------------------------|
| | keygen token,nonce index) |
|CoT(care-of init cookie,care-of keygen token,nonce index)|
|<--------------------------------------------------------|
| BU(Kbm, HoA, CoA, nonce indices) |
|-------------------------------------------------------->|
| BAck(Kbm, binding status if sent) |
|<--------------------------------------------------------|
| data packets |
|<------------------------------------------------------->|
| |
Figure 1. MIPv6 Route Optimization Procedure
A successful RR test means that the node initiating the test is
reachable at its claimed care-of address and its home address. In
this way, route optimization can be run without the need for
preconfigured SAs. Since the Kbm is available to any nodes who can
get both the HoT and the CoT messages, the RR test can not prevent
attacks from nodes with such capabilities. However, these nodes can
launch similar attacks even without the use of Mobile IPv6.
Zhang & Pearce Expires February 11, 2006 [Page 6]
Internet-Draft Agent-Based RR for MIPv4 August 2005
4. Return Routability Test for Mobile IPv4
Since currently IPv4 networks are dominant and may still be used for
a long time, in order to overcome the obstacles to MIPv4 route
optimization deployment as discussed in section 1, and achieve a
similar promising situation as in MIPv6, adapting the MIPv6 RR test
for use in MIPv4 is proposed in this section. In this scheme, in
order to maintain the original MIPv4 design goal that mobility
support should be transparent to existing fixed IPv4 nodes, the
agent-based architecture introduced in section 3.B is adopted.
Figure 2 shows the basic considered architecture and the RR procedure
in MIPv4. The RR procedure is very similar to that in MIPv6, unless
route optimization is transparent to CNs and performed using
Correspondent Agents. Here only the modifications needed to the
basic MIPv4 protocol are discussed.
MN HA CA CN(s)
| HoTI-Reverse Tunnelled | HoTI(home init cookie) | |
|-------------------------->|---------------------------->| |
| | | |
| CoTI(care-of init cookie) | |
|-------------------------------------------------------->| |
| HoT-Tunnelled | HoT(home init cookie,home | |
|<--------------------------|<----------------------------| |
| | keygen token,nonce index) | |
|CoT(care-of init cookie,care-of keygen token,nonce index)| |
|<--------------------------------------------------------| |
| RRBU(Kbm, HoA, CoA, nonce indices) | |
|-------------------------------------------------------->| |
| RRBA(Kbm, binding status if sent) | |
|<--------------------------------------------------------| |
| data packets | |
|<------------------------------------------------------->+<---->|
| | |
Figure 2. Agent-Based Return Routability Test for
Mobile IPv4 Route Optimization
A. New Messages
Four message types for the RR test need to be defined for MIPv4: the
HoTI, CoTI, HoT and CoT. In MIPv6, these messages are carried in the
Mobility header. In MIPv4, we propose to send these messages by way
of UDP (User Datagram Protocol) packets using the well-known port
number 434, with different type values to distinguish them from other
mobility messages. These message formats MUST be defined with the
Zhang & Pearce Expires February 11, 2006 [Page 7]
Internet-Draft Agent-Based RR for MIPv4 August 2005
capability to contain all required data for performing the RR test
described in section 3.C.
In addition, two other message types for managing binding caches need
to be defined. In order to be distinguishable from the Binding
Update and Binding Acknowledgement messages defined in [Perki02],
they are called RR Binding Update (RRBU) and RR Binding
Acknowledgement (RRBA). These messages are also proposed to be sent
by way of UDP (port 434), with different type values to distinguish
from other mobility messages. Specifically RRBU and RRBA MUST be
defined with the capability to contain the authentication data
(Binding Authorization Data).
Having these six new messages, whether or not MIPv4 RR is supported
does not affect other proposed route optimization protocols such as
the basic MIPv4 route optimization extension [Perki02] described in
section 3.A. This guarantees that other features (if needed)
supported by other proposed route optimization scheme are not
eliminated by MIPv4 RR route optimization. For example, [Perki02]
defines Binding Warning and Binding Request messages in order to
managing binding caches more efficiently.
B. Correspondent Agent Considerations
Correspondent Agents (CAs) are used in this scheme in order to mask
the RR and route optimization procedures from CNs. CAs MAY be co-
located with a gateway router of any IPv4 network that wishes to
support the route optimization function for IPv4 mobility.
CAs are supposed to be able to perform RR tests on behalf of each
individual CN in their managed subnet. Therefore, a CA MUST hold a
secret node key (Kcn), and periodically generate nonces with indices
for each CN. It is responsible for refreshing the Kcn for each CN at
any suitable time. It MUST be able to process the HoTI and CoTI
messages, calculate keygen tokens, and compose the HoT and CoT
messages. It MUST be able to process the RRBU message, verify the
Kbm established during the RR test, and compose the RRBA message with
correct status.
Moreover, a CA is responsible for tunnelling datagrams from a CN that
has a valid binding cache entry with an MN for route optimization.
Note that a binding cache entry can only be created after receiving a
successful RRBU from an MN after an RR test: this is different from
the basic MIPv4 route optimization extension [Perki02], where a
binding cache entry can be created on receiving a successful BU sent
by an MN, its HA or even its FA, and a BU can be triggered by various
methods determining when a binding cache entry should be set up.
Zhang & Pearce Expires February 11, 2006 [Page 8]
Internet-Draft Agent-Based RR for MIPv4 August 2005
C. Home Agent Considerations
The MIPv4 HA MUST be enhanced to be able to correctly forward the
HoTI and HoT messages. As mentioned earlier, the HoTI is reversed
tunnelled from the MN to the HA and then redirected to the CN/CA; the
HoT is sent from the CN/CA to the HA and then tunnelled to the MN.
To protect the HoTI and HoT along the path between the HA and the MN,
IPsec ESP tunnel mode or any other suitable protecting method is
RECOMMENDED.
D. Foreign Agent Considerations
There are no particular requirements on the FA in order to support
the MIPv4 RR route optimization.
E. Mobile Node Considerations
The MN MUST be able to initiate RR tests by sending the HoTI and CoTI
messages containing the newly generated cookies at a suitable time
(normally after a new CoA registration to the HA or whenever the MN
needs a new keygen token). It MUST be able to reverse tunnel the
HoTI and de-tunnel HoT messages, optionally using a suitable
protecting method (such as IPsec ESP tunnel mode) negotiated with its
HA. It MUST be able to process the HoT and CoT messages, generate
Kbm accordingly, compose the RRBU message, and process the RRBA
message.
5. New Message Format
A. MIPv4 HoTI Message Format
The proposed MIPv4 HoTI message format is shown in Figure 3.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. MIPv4 Home Test Init (HoTI) Message Format
IP fields:
Zhang & Pearce Expires February 11, 2006 [Page 9]
Internet-Draft Agent-Based RR for MIPv4 August 2005
o Source Address: The MN's HoA.
o Destination Address: The CN's address.
UDP fields:
o Source Port: Variable.
o Destination Port: 434.
HoTI fields:
o Type: An 8-bit value that can be distinguished from other mobility
messages. To be defined by IANA.
o Reserved: A 24-bit field reserved for future use.
o Home Init Cookie: A 64-bit field containing the home init cookie.
B. MIPv4 CoTI Message Format
The proposed MIPv4 CoTI message format is shown in Figure 4.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. MIPv4 Care-of Test Init (CoTI) Message Format
IP fields:
o Source Address: The MN's CoA.
o Destination Address: The CN's address.
UDP fields:
Zhang & Pearce Expires February 11, 2006 [Page 10]
Internet-Draft Agent-Based RR for MIPv4 August 2005
o Source Port: Variable.
o Destination Port: 434.
CoTI fields:
o Type: An 8-bit value that can be distinguished from other mobility
messages. To be defined by IANA.
o Reserved: A 24-bit field reserved for future use.
o Care-of Init Cookie: A 64-bit field containing the care-of init
cookie.
C. MIPv4 HoT Message Format
The proposed MIPv4 HoT message format is shown in Figure 5.
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 | Reserved | Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. MIPv4 Home Test (HoT) Message Format
IP fields:
o Source Address: The CN's address.
o Destination Address: The MN's HoA.
UDP fields:
o Source Port: Variable.
Zhang & Pearce Expires February 11, 2006 [Page 11]
Internet-Draft Agent-Based RR for MIPv4 August 2005
o Destination Port: 434.
HoT fields:
o Type: An 8-bit value that can be distinguished from other mobility
messages. To be defined by IANA.
o Reserved: An 8-bit field reserved for future use.
o Home Nonce Index: A 16-bit field containing the index of the nonce
used to create the home keygen token.
o Home Init Cookie: A 64-bit field containing the home init cookie.
o Home Keygen Token: A 64-bit field containing the home keygen
token.
D. MIPv4 CoT Message Format
The proposed MIPv4 CoT message format is shown in Figure 6.
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 | Reserved | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. MIPv4 Care-of Test (CoT) Message Format
IP fields:
o Source Address: The CN's address.
o Destination Address: The MN's CoA.
UDP fields:
Zhang & Pearce Expires February 11, 2006 [Page 12]
Internet-Draft Agent-Based RR for MIPv4 August 2005
o Source Port: Variable.
o Destination Port: 434.
CoT fields:
o Type: An 8-bit value that can be distinguished from other mobility
messages. To be defined by IANA.
o Reserved: An 8-bit field reserved for future use.
o Care-of Nonce Index: A 16-bit field containing the index of the
nonce used to create the care-of keygen token.
o Care-of Init Cookie: A 64-bit field containing the care-of init
cookie.
o Care-of Keygen Token: A 64-bit field containing the care-of keygen
token.
E. MIPv4 RRBU Message Format
The proposed MIPv4 RRBU message format is shown in Figure 7.
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 |A|M|G|Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. MIPv4 Return Routability Binding Update (RRBU)
Zhang & Pearce Expires February 11, 2006 [Page 13]
Internet-Draft Agent-Based RR for MIPv4 August 2005
Message Format
IP fields:
o Source Address: The MN's CoA.
o Destination Address: The CN's address.
UDP fields:
o Source Port: Variable.
o Destination Port: 434.
RRBU fields:
o Type: An 8-bit value that can be distinguished from other mobility
messages. To be defined by IANA.
o A: The 'A' bit is set when an RRBA is required in response to the
RRBU.
o M: The 'M' bit is set when datagrams may be tunnelled to the MN
using the minimal encapsulation protocol [RFC2004].
o G: The 'G' bit is set when datagrams may be tunnelled to the MN
using Generic Routing Encapsulation (GRE) [RFC1702].
o Reserved: 5-bit field reserved for future use.
o Lifetime: A 16-bit field containing the number of seconds left
before the binding cache entry MUST be considered expired. A
value of zero means that the binding (if exists) for the MN MUST
be deleted.
o Home Nonce Index: A 16-bit field containing the index of the nonce
used to create the home keygen token.
o Care-of Nonce Index: A 16-bit field containing the index of the
nonce used to create the care-of keygen token.
o MN Home Address: The MN's HoA.
o MN care-of address: The MN's current CoA. When it is set equal to
the MN's HoA, it means that the binding (if any exists) for the MN
MUST be deleted.
Zhang & Pearce Expires February 11, 2006 [Page 14]
Internet-Draft Agent-Based RR for MIPv4 August 2005
o Identification: A 64-bit number used by the receiving node to
sequence RRBUs and by the sending node to match returned RRBAs.
o Authenticator: The 96-bit Binding Authorization Data. The
calculation method of the authenticator is the same as that in
MIPv6, except that the data input to the hash function are the
Kbm, and the RRBU data excluding the authenticator field itself.
E. MIPv4 RRBA Message Format
The proposed MIPv4 RRBA message format is shown in Figure 8.
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 | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. MIPv4 Return Routability Binding Acknowledgement
(RRBA) Message Format
IP fields:
o Source Address: The CN's address.
o Destination Address: The MN's CoA.
UDP fields:
o Source Port: Variable.
Zhang & Pearce Expires February 11, 2006 [Page 15]
Internet-Draft Agent-Based RR for MIPv4 August 2005
o Destination Port: 434.
RRBU fields:
o Type: An 8-bit value that can be distinguished from other mobility
messages. To be defined by IANA.
o Reserved: A 16-bit field reserved for future use.
o Status: An 8-bit field containing the value indicating the status
of the responded RRBU. The value of zero indicates the success of
an RRBU. Otherwise, 8 other values are to be defined to indicate
various failure status: "reason unspecified", "administratively
prohibited", "insufficient resources", "sending node failed
authentication", "poorly formed RRBU", "expired home nonce index",
"expired care-of nonce index", and "expired nonces".
o MN Home Address: The MN's HoA.
o Identification: A 64-bit number copied from the identification
field of the responded RRBU.
o Authenticator: The 96-bit Binding Authorization Data. The
calculation method of the authenticator is the same as that in
MIPv6, except that the data input to the hash function are the
Kbm, and the RRBA data excluding the authenticator field itself.
6. Security Considerations
The proposed MIPv4 RR test cannot prevent attacks from nodes who can
receive both the HoT and CoT messages: this provides the same
security level as the MIPv6 RR test. However, nodes with this
capability can launch similar attacks even without the use of MIPv4
RR test.
Due to the inherent security vulnerabilities of the RR test, a number
of enhancing schemes have been proposed in the IRTF recently. Many
of these enhancement schemes could possibly be adapted for use in the
MIPv4 RR test in a similar way in the future.
7. IANA Considerations
IANA should record the values for the newly defined MIPv4 messages
described in section 5, in order to distinguished them from other
mobility messages.
8. References
Zhang & Pearce Expires February 11, 2006 [Page 16]
Internet-Draft Agent-Based RR for MIPv4 August 2005
8.1 Normative References
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1702,
October 1994.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
8.2 Informative References
[Perki02] Perkins, C. and D. Johnson, "Route Optimization in Mobile
IP", draft-ietf-mobileip-optim-11.txt , April 2002.
[Vadal01] Vadali, R., Li, J., Wu, Y., and G. Cao, "Agent-Based Route
Optimization for Mobile IP", IEEE VTC, October 2001.
Authors' Addresses
Ji Zhang
Communications Research Group, University of York.
Heslington
York YO10 5DD
United Kingdom
Phone: +44 1904 432310
Email: jz105@ohm.york.ac.uk
David Pearce
Communications Research Group, University of York.
Heslington
York YO10 5DD
United Kingdom
Phone: +44 1904 432390
Email: dajp1@ohm.york.ac.uk
Zhang & Pearce Expires February 11, 2006 [Page 17]
Internet-Draft Agent-Based RR for MIPv4 August 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang & Pearce Expires February 11, 2006 [Page 18]
