NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs
Expires: April 7, 2005 J. Hirano
Panasonic
October 7, 2004
Extending Return Routability Procedure for Network Prefix (RRNP)
draft-ng-nemo-rrnp-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 April 7, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo highlights the inadequacy of existing return routability
procedure when one takes network prefix into consideration under the
context of route optimization with Network Mobility (NEMO). An
extended return routability procedure, called Return Routability with
Network Prefix (RRNP), is thus proposed to address this problem.
With RRNP, a correspondent node can verify the collocation of care-of
Ng & Hirano Expires April 7, 2005 [Page 1]
Internet-Draft RRNP October 2004
address, home address, and network prefix(es) specified in a binding
update message.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Inadequacy of Existing RR Procedure . . . . . . . . . . . . . 4
2.1 Possible Route Optimization Mechanism in NEMO . . . . . . 4
2.2 Security Threats with Unverified Network Prefixes . . . . 5
3. Overview of RRNP . . . . . . . . . . . . . . . . . . . . . . . 7
4. Modifications to Existing Protocols . . . . . . . . . . . . . 8
4.1 New Network Prefix Test Message . . . . . . . . . . . . . 8
4.2 New Number of Prefixes Option . . . . . . . . . . . . . . 9
4.3 Modifications to Home Test Init Message . . . . . . . . . 10
4.4 Modifications to Home Test Message . . . . . . . . . . . . 10
5. Detailed Description of RRNP . . . . . . . . . . . . . . . . . 11
5.1 Initiating the RRNP: Sending HoTI and CoTI . . . . . . . . 11
5.2 Responding to the CoTI with CoT . . . . . . . . . . . . . 12
5.3 Responding to the HoTI with HoT and NPT . . . . . . . . . 13
5.4 Intercepting the NPT messages . . . . . . . . . . . . . . 15
5.5 Sending the Binding Update . . . . . . . . . . . . . . . . 16
5.6 Error Handling . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
A. Applicability of RRNP . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
Ng & Hirano Expires April 7, 2005 [Page 2]
Internet-Draft RRNP October 2004
1. Introduction
Currently, mobile node uses a procedure known as the Return
Routability (RR) procedure [1] to allow a correspondent node to be
assured of the collocation of the mobile node's home address and
care-of address. When one consider network mobility [2], it is
foreseeable that for route optimization to work [3], it might be
necessary for a mobile router to inform the correspondent node which
network prefixes the mobile network is using, so that the
correspondent node can forward packets destined to mobile network
nodes in the mobile network directly to the mobile router's care-of
address.
In such situation, the original return routability procedure is
inadequate since it does not provide a means for the correspondent
node to ascertain that the network prefixes specified by the mobile
router are in fact handled by the mobile router. In order to solve
this problem, this memo describes an improved procedure known as the
Return Routability with Network Prefix (RRNP) procedure where the
mobile router will first list the network prefixes it owns in the
Home Test Init (HoTI) message. The correspondent node tests the
collocation of these network prefixes by generating some
cryptographic tokens and sending each of these tokens to an address
randomly selected from each network prefix. The mobile router must
capture these packets, extract the cryptographic tokens, and use
these tokens to generate a hash value in the binding update message
it later sends to the correspondent node. In this way, the
correspondent node can verify that the mobile router indeed owns the
network prefixes it claims to own.
It is assumed that readers are familiar with the original return
routability procedure specified in [1], and the terminology related
to network mobility (NEMO) defined in [4].
We begin by first describing the problem of the existing return
routability procedure when Mobile Network Prefix option is inserted
into Binding Update messages in Section 2. Section 3 then presents
an overview of the extended return routability procedure to solve
this problem. The new mobility message and option formats are then
introduced in Section 4 before we explain the improved procedure with
greater detail in Section 5. Finally, Section 6 discusses some
security considerations in the design of the RRNP.
Ng & Hirano Expires April 7, 2005 [Page 3]
Internet-Draft RRNP October 2004
2. Inadequacy of Existing RR Procedure
2.1 Possible Route Optimization Mechanism in NEMO
There is currently no accepted route optimization solution for
Network Mobility. However, it is foreseeable that a possible
approach to route optimization involves sending binding updates with
Network Prefix Options as defined in [2] to correspondent nodes. As
an illustration of how this will work, consider the deployment
scenario depicted in Figure 1 below.
+----------------+ +------+
| | +---+ MNN1 |
+-----+ | | +-----+ | +------+
| CN1 +-----+ INTERNET +----+ MR1 +--+
+-----+ | | +-----+ | +------+
| | +---+ MNN2 |
+-------+--------+ +------+
|
+--+--+
| HA1 |
+-----+
Figure 1: Deployment Scenario
Here, the mobile network with mobile network prefix MNP consists of a
mobile router MR1 with two mobile network nodes, MNN1 and MNN2,
behind MR1. The home address of MR1 is MR1.HoA, and current care-of
address of MR1 is MR1.CoA. HA1 is the home agent of MR1 and CN1 is
the correspondent node communicating with, say MNN1. If route
optimization is not used, a packet sent from CN1 to MNN1 will follow
the path:
CN1 ---> HA1 ===> MR1 ---> MNN1
Now, suppose MR1 sends CN1 a Binding Update message with the Mobile
Network Prefix option, such that within CN1, it will insert a route
into its own routing table that all packets sent to the prefix MNP
will be tunneled to the address MR1.CoA, then route optimization will
have been achieved. The path of the packet will now be:
CN1 ===> MR1 ---> MNN1
Ng & Hirano Expires April 7, 2005 [Page 4]
Internet-Draft RRNP October 2004
2.2 Security Threats with Unverified Network Prefixes
Although the inclusion of Mobile Network Prefix option allows route
optimization to be setup between a mobile network and a correspondent
node, existing return routability procedure as defined in [1] does
not provide a means for correspondent node to verify that the Mobile
Network Prefix option specified in the binding update is valid and
legitimate. This exposes the correspondent node to additional
security threats.
One immediate threat is that the Mobile Network Prefix option may be
changed, or inserted, by an attacker. This cause the correspondent
node to send data packets meant for other network to the mobile
router. This can be used to launch a flooding attack on the mobile
router, overwhelming the mobile router with data packets not meant
for its network. However, this attack is inherently diverted by the
existing return routability procedure, since the integrity of the
Binding Update message is protected by the binding management key,
Kbm. So any change in the Mobile Network Prefix option will cause
the Binding Authorization Data option to carry a wrong Authenticator
value. This could be easily checked by the correspondent node.
Another threat is when a "mobile router" is itself malicious. It can
specify prefixes that it does not actually own in the Mobile Network
Prefix option. This way, the correspondent node is tricked into
forwarding packets (which it intends to send to some other network)
to the malicious "mobile router". Thus, this allows the "mobile
router" to spoofed into packets sent by the correspondent node to
some destination, which is otherwise not possible. This threat is
illustrated in Figure 2 below.
Ng & Hirano Expires April 7, 2005 [Page 5]
Internet-Draft RRNP October 2004
(1) Initially, CN1 sends
packets directly to
+-----+ victim's network. +------------+
| CN1 | ---------------------> | victim's |
+-----+ | network |
(2) Attacker ^ || (3) CN1 now starts +------------+
sends BU to CN1 | || to tunnel all data
with MNP option | || packets for
claiming to | || victim's network
handle victim's | || to attacker.
network prefix. | \/
+----------+
| Attacker |
+----------+
Figure 2: Attacker claiming to handle victim's network prefix
Existing return routability procedure cannot prevent such attacks.
This is because return routability procedure can only verify that the
home address and care-of address are collocated. Thus an attacker
may very well own both the home address and care-of address specified
in the Binding Update, causing the return routability procedure to
pass successfully. The correspondent node has no way of checking if
the network prefix claimed to be owned by a sender of the Binding
Update message is indeed owned by the sender.
Thus, an improved return routability procedure has to be designed to
allow the correspondent node to check the validity of the Mobile
Network Prefix option, before route optimization between CN and MR
can be established without exposing the nodes involved to additional
security threats.
Ng & Hirano Expires April 7, 2005 [Page 6]
Internet-Draft RRNP October 2004
3. Overview of RRNP
The improved return routability procedure, known as the RRNP, is
meant to extend the existing return routability procedure to bindings
of network prefixes. In the RRNP, the mobile router will first list
the network prefixes it owns in the Home Test Init (HoTI) message.
When the correspondent node sees these prefixes, it sends, in
addition to the normal HoT message, a new message referred to as
Network Prefix Test (NPT) message for each network prefix included in
the HoTI message. The NPT message contains a token that is
cryptographically generated based on the network prefix, and is
addressed to an address that is randomly generated from the network
prefix. The mobile router must intercept all the NPT messages, and
store these tokens. In the Binding Update message the mobile router
send to the correspondent node, the Authenticator value of the
Binding Authorization Data option is generated using the tokens
contained in the Home Test (HoT), Care-of Test (CoT) and NPT messages
sent from the correspondent node. In this way, the correspondent
node can verify that the care-of address and home address of the
mobile router are collocated, and that the mobile router indeed owns
the network prefixes it claimed to own.
Figure 3 below illustrates the message sequence diagram of the RRNP.
Mobile Home Correspondent
Router Agent Node
--+-- --+-- ------+-----
| CoTI |
|------------------------------------------------------->|
| Encapsulated HoTI | |
|===========================>| HoTI |
| |-------------------------->|
| CoT (Care-of Keygen) |
|<-------------------------------------------------------|
| | HoT (Home Keygen) |
| Encapsulated HoT |<--------------------------|
|<===========================| |
| | NPT (Prefix Keygen) |
| Encapsulated NPT |<--------------------------|
|<===========================| |
| BU (Hash(Home Keygen,Care-of Keygen,Prefix Keygen)) |
|------------------------------------------------------->|
Figure 3: Message sequence diagram of a RRNP procedure
Ng & Hirano Expires April 7, 2005 [Page 7]
Internet-Draft RRNP October 2004
4. Modifications to Existing Protocols
4.1 New Network Prefix Test Message
The Network Prefix Test (NPT) message is sent by a correspondent node
to a random address selected from a prefix. This message is meant to
be intercepted by a mobile router owning the prefix. Figure 4 below
shows the format of Network Prefix Test message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Network Prefix Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Network Prefix Test Message
MH Type
To be assigned. Identifies the mobility message as a Network
Prefix Test message.
Home Nonce Index
The index of the nonce used to generate the Network Prefix Keygen
Token. Note that this should be the same as the once used to
generate the Home Keygen Token.
Home Init Cookie
This value is copied from the Home Test Init message.
Ng & Hirano Expires April 7, 2005 [Page 8]
Internet-Draft RRNP October 2004
Network Prefix Keygen Token
This is the keygen token generated based on the network prefix
specified in a Mobile Network Prefix option.
Mobility Options
The Network Prefix Test message should contain one (and only one)
Mobile Network Prefix option as defined in [2]. This value is
copied from the Home Test Init message.
4.2 New Number of Prefixes Option
The Number of Network Prefixes option is included in a Home Test
(HoT) message sent by a correspondent node to indicate to the mobile
router how many network prefixes is accepted. This option is
included to allow the mobile router to know how many Network Prefix
Test message it needs to intercept. In addition, it also serves to
indicate to the mobile router that the correspondent node understands
the Mobile Network Prefix options included in the Home Test Init
message. Figure 5 below shows the format of option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Prefix |
+-+-+-+-+-+-+-+-+
Figure 5: Number of Prefixes Option
Option Type
To be assigned. Identifies the mobility option as a Number of
Prefixes option.
Option Length
The length in octets of this option, excluding the first 2 octets.
Always equal to 1.
Num Prefix
The number of prefixes the correspondent node is willing to
accept.
Ng & Hirano Expires April 7, 2005 [Page 9]
Internet-Draft RRNP October 2004
4.3 Modifications to Home Test Init Message
There is no change to the format of the Home Test Init (HoTI) message
as per defined by Mobile IPv6 [1], except that the Home Test Init
message is now extended to be able to include the Mobile Network
Prefix option as defined by NEMO Basic Support [2].
4.4 Modifications to Home Test Message
There is no change to the format of the Home Test (HoT) message as
per defined by Mobile IPv6 [1], except that the Home Test message is
now extended to be able to include the Number of Prefixes option as
defined in Section 4.2.
Ng & Hirano Expires April 7, 2005 [Page 10]
Internet-Draft RRNP October 2004
5. Detailed Description of RRNP
5.1 Initiating the RRNP: Sending HoTI and CoTI
Once the mobile router determines that it wishes to perform route
optimization with a correspondent node, it initiates the return
routability procedure by sending the Home Test Init and Care-of Test
messages to the correspondent node.
Sending of the Care-of Test Init message is exactly the same as the
original return routability procedure. The packet contents is shown
below:
IPv6 Header {
Source = care-of address of mobile router
Destination = correspondent node
}
Mobility Header {
MH Type = Care-of Test Init
Care-of Init Cookie = random value
}
Sending of the Home Test Init message is also largely similar to that
in the original return routability procedure, except that the mobile
router inserts one (or more, depending on the number of prefixes the
mobile router owns and wishes to perform route optimization with the
correspondent node) Mobile Network Prefix option in the Home Test
Init message. It may not be to the benefit of the mobile router to
inform the correspondent node of all the NEMO prefixes it owns since
this may result in a longer message and a longer time period of
intercepting NPT messages (see Section 5.4).
The packet contents of the HoTI message is shown below:
IPv6 Header {
Source = home address of mobile router
Destination = correspondent node
}
Mobility Header {
MH Type = Home Test Init
Home Init Cookie = random value
Mobile Network Prefix Option {
Prefix Length = length of prefix
Mobile Network Prefix = prefix of the mobile network
}
}
Ng & Hirano Expires April 7, 2005 [Page 11]
Internet-Draft RRNP October 2004
Since the Home Test Init message is sent using the home address as
the source, this packet is encapsulated into a tunnel back to the
home agent of the mobile router.
5.2 Responding to the CoTI with CoT
When the correspondent node receives the Care-of Test Init message,
and decides to accept route optimization with the mobile router, it
responds with a Care-of Test message. Preparation of the Care-of
Test message is exactly the same as that specified in Mobile IPv6
[1]. First, the correspondent node selects a nonce to generate a
keygen token. The nonce selected should be identifiable by a 16-bits
nonce index. The Care-of Keygen Token, CoK, is then generated by
CoK := First(64,
HMAC_SHA1(Kcn, (care-of address | nonce | 0x01))) (Eq 1)
where
First(L,m) is to truncate the message m leaving the leftmost L
bits,
HMAC_SHA1(K,m) is the hash result of taking the HMAC-SHA1 hash
function [5][6] on the message m using the cryptographic key K,
Kcn is a secret key of the correspondent node, and
'|' denotes concatenation of bit stream.
The Care-of Keygen Token and the nonce index are then included in a
Care-of Test message to be returned to the mobile router, including
the Care-of Init Cookie copied from the Care-of Test Init message.
The packet contents is shown below:
IPv6 Header {
Source = correspondent node
Destination = care-of-address of mobile router
}
Mobility Header {
MH Type = Care-of Test
Care-of Nonce Index
Care-of Init Cookie = copied from CoTI
Care-of Keygen Token = generated as per (Eq 1)
}
Ng & Hirano Expires April 7, 2005 [Page 12]
Internet-Draft RRNP October 2004
5.3 Responding to the HoTI with HoT and NPT
When the correspondent node receives the Home Test Init message, and
decides to accept route optimization with the mobile router, it
responds with a Home Test message. In addition, for every network
prefix specified in a Mobile Network Prefix option in the Home Test
message it is prepared to accept, the correspondent node will reply
with a Network Prefix Test message. Note that it is up to the
discretion of the correspondent node whether to respond to the
HoTI/CoTI message, and the number of network prefixes to accept (see
Section 6).
In preparation of the Home Test message, the correspondent node first
selects a nonce to generate the keygen token. The nonce selected
should be identifiable by a 16-bits nonce index. The Home Keygen
Token, HoK, is then generated by
HoK := First(64,
HMAC_SHA1(Kcn, (home address | nonce | 0x00))) (Eq 2)
The Home Keygen Token and the nonce index are then included in a Home
Test message to be returned to the mobile router, including the Home
Init Cookie copied from the Home Test Init message. In addition, a
Number of Network Prefix option is also included to indicate to the
mobile router how many network prefixes specified in the Home Test
Init message the correspondent node is prepared to accept. For every
network prefix the correspondent node is willing to accept, the
correspondent node will sent a separate Network Prefix Test message.
The packet contents is shown below:
IPv6 Header {
Source = correspondent node
Destination = home address of mobile router
}
Mobility Header {
MH Type = Home Test
Home Nonce Index
Home Init Cookie = copied from HoTI
Home Keygen Token = generated as per (Eq 2)
Number of Network Prefix Option {
Number of Prefix = maximum number of prefixes accepted
}
}
For the Network Prefix Test message, a Network Prefix Keygen Token is
also generated. The nonce selected is the same as the one used to
generate the Home Keygen Token. The Network Prefix Keygen Token,
Ng & Hirano Expires April 7, 2005 [Page 13]
Internet-Draft RRNP October 2004
NPK, is given by
NPK := First(64,
HMAC_SHA1(Kcn, (network prefix | nonce | 0x02))) (Eq 3)
The Network Prefix Keygen Token and the nonce index are then included
in a Network Prefix Test message to be returned to the mobile router,
including the Home Init Cookie copied from the Home Test Init
message. In addition, a Mobile Network Prefix option is also
included to indicate to the mobile router which mobile network prefix
this Network Prefix Test message is for. The packet contents is
shown below:
IPv6 Header {
Source = correspondent node
Destination = random address selected from network prefix
}
Mobility Header {
MH Type = Network Prefix Test
Home Nonce Index
Home Init Cookie = copied from HoTI
Network Prefix Keygen Token = generated as per (Eq 3)
Mobile Network Prefix Option {
Copied from the HoTI message
}
}
The Network Prefix Test message is sent to an address randomly
selected from the mobile network prefix that this Network Prefix Test
message is for. Because the correspondent node sent more than one
packet for each Home Test Init message with Mobile Network Prefix
option received, the correspondent should add a random delay before
sending each Network Prefix Test message sent to avoid amplification
effect. The delay, however, must be within a known limit. For the
purpose of this document, we specify the random delay selected must
be within the range of (0, MAX_NPT_DELAY). A suitable value of
MAX_NPT_DELAY can be 0.5 seconds.
In addition, the correspondent node should also take note of the
mobile router sending the HoTI message. Should multiple HoTI
messages are received from the same mobile router within a short time
span, the correspondent node should reject subsequent HoTI messages
as it is possible that the mobile router is trying to stage a
denial-of-service attack against the network prefix specified.
Ng & Hirano Expires April 7, 2005 [Page 14]
Internet-Draft RRNP October 2004
5.4 Intercepting the NPT messages
After sending the Home Test Init and Care-of Test Init messages, the
mobile router must start intercepting the Home Test, Care-of Test,
and Network Prefix Test messages. The Home Test and Care-of Test
messages should not pose any problem, as they are addressed to the
home address and care-of address of the mobile router respectively.
To intercept the Network Prefix Test messages, the mobile router must
inspect every packet addressed to the mobile network to see if they
are indeed a Network Prefix Test message.
It is recommended that the mobile router starts a timer after sending
the Home Test Init message. During this time period, the mobile
router will inspect every packet that satisfies all of the following
criteria to check if it is a Network Prefix Test message:
o the packet arrives in a tunnel from the home agent
o the packet bears the correspondent node's address as the source
address
o the packet bears a destination address that is formed from a
network prefix that is sent to the correspondent node in a Mobile
Network Prefix option in the Home Test Init message
The timer value should be chosen such that it is sufficiently long
for all Network Prefix Test message to be received by the mobile
router. A reasonable value is given by
timer = T_rtt + n * MAX_NPT_DELAY (Eq 4)
where
T_rtt is the round-trip time taken for a packet to be sent from
the mobile router to the correspondent node and back again, via
the home agent, and
n is a number of Mobile Network Prefix options included in the
HoTI message.
This a best estimate assuming there is no congestion in the network.
A more conservative value can be given by
timer = 2 * T_rtt + n * MAX_NPT_DELAY (Eq 5)
In addition, once the mobile router has received the Home Test
message, it will know from the Number of Prefixes option how many
network prefixes the correspondent node is willing to accept. The
Ng & Hirano Expires April 7, 2005 [Page 15]
Internet-Draft RRNP October 2004
mobile router can then adjust the timer value accordingly.
Once the mobile router has received the Home Test message, Care-of
Test message, and all the Network Prefix Test messages (as specified
by the Number of Prefixes option) or when the timer expires, it can
proceed to complete the return routability procedure by sending the
Binding Update message. This is described in the next sub-section
(Section 5.5).
There are several sanity checks the mobile router can perform when
receiving the Home Test, Care-of Test, and Network Prefix Test
messages. Firstly, the mobile router can verify that the Home Init
Cookie and Care-of Init Cookie are the same as those it has sent in
the Home Test Init and Care-of Test Init messages. Secondly, it can
check that the Network Prefix Test message specifies the same Home
Init Cookie. Thirdly, it can verify that the Network Prefix Test
message specifies the same Home Nonce Index as that specified in the
Home Test message.
5.5 Sending the Binding Update
To complete the return routability procedure, the mobile router will
have to send the Binding Update message to the correspondent node.
In the Binding Update message, the mobile router should include the
nonce indices in the Nonce Indices option. In addition, a Mobile
Network Prefix option should also be included for every network
prefix that the mobile router has received a Network Prefix Test
message. Furthermore, the mobile router should include a
cryptographic checksum in the Authenticator field of a Binding
Authorization Data option. To generate the checksum, the mobile
router must first obtain the binding management key, Kbm, given by
Kbm := SHA1 (HoK | CoK | NPK_1 | ... | NPK_n) (Eq 6)
where
SHA1(m) is the result of applying the Secure Hash Algorithm [5] on
the message m,
HoK is the Home Keygen Token from the HoT message,
CoK is the Care-of Keygen Token from the CoT message, and
NPK_i is the Network Prefix Keygen Token from the i-th NPT
message.
This gives the Kbm as a 20 octets (160 bits) long value. It is used
by both the mobile router and the correspondent node to generate the
Ng & Hirano Expires April 7, 2005 [Page 16]
Internet-Draft RRNP October 2004
Authenticator value. For the Binding Update message, the
Authenticator value is given by
Authenticator := First(96,
HMAC_SHA1(Kbm, (CoA | correspondent | BU)) (Eq 6)
where
CoA is the care-of address of the mobile router,
correspondent is the address of the correspondent node, and
BU is the entire Binding Update message except the Authenticator
field itself.
When generating the Authenticator value, the Checksum field of the
Mobility Header is first initialized as zero. Before sending the
Binding Update message, the Binding Authorization Data option is
appended as the last option, and the Checksum is finally calculated,
including the Authenticator field in the calculation. If there are
multiple Mobile Network Prefix options, the mobile router must be
careful to ensure that the order of the Mobile Network Prefix options
is the same as the order the corresponding Network Prefix Keygen
Token is concatenated in (Eq 6) to generate the Kbm. The packet
contents of the Binding Update message is shown below:
IPv6 Header {
Source = care-of address of mobile router
Destination = correspondent node
}
Mobility Header {
MH Type = Binding Update
Flags = H,K must be cleared, R should be set
Nonce Indices Option {
Home Nonce Index
Care-of Nonce Index
}
Mobile Network Prefix Option {
Prefix Length = length of prefix
Mobile Network Prefix = prefix of the mobile network
}
Binding Authorization Data Option {
Authenticator = calculated as per (Eq 7)
}
}
It must again be noted that the correspondent node need not maintain
Ng & Hirano Expires April 7, 2005 [Page 17]
Internet-Draft RRNP October 2004
any state information before the receipt of the Binding Update
message. Using information contained in the Binding Update message,
it is sufficient for the correspondent node to generate the Home
Keygen Token, Care-of Keygen Token, and Network Prefix Keygen
Token(s) to derive the binding management key independently and
verify the Authenticator value.
5.6 Error Handling
This section outlines some of the possible error conditions that
might occur during a RRNP procedure.
o Failure to receive HoT/CoT message
When a mobile router fails to receive a HoT or CoT message after
sending the HoTI and CoTI message, the mobile router must not
proceed with sending of binding update. If a pre-determined time
period, possibly determined by (Eq 5), has elapsed, the mobile
router may assume that some packets are lost, and re-initiate the
RRNP procedure. The mobile router may give up after consecutive
failed attempts.
o Failure to receive NPT message
If the mobile router failed to receive any NPT message, even
though the HoT message indicates that the correspondnet node has
accepted one or more Mobile Network Prefix options, the mobile
router may choose to proceed with sending normal Binding Update
message (without any Mobile Network Prefix options) or to
re-initiate the RRNP procedure. It makes sense to proceed with
sending normal Binding Update message only if the mobile router
itself is communicating with the correspondent node. If the
mobile router choose to re-initiate the RRNP procedure, it may
give up after consecutive failed attempts.
o Correspondent node does not support RR procedure
If the correspondent node does not support the original return
routability procedure, it will respond to the HoTI and CoTI
messages with an ICMP parameter problem code 1. The mobile router
should take such messages as indication of the correspondent node
not supporting the RR procedure.
o Correspondent node does not support RRNP procedure
If the correspondent node supports the original return routability
procedure, but not the RRNP extension, it will silently ignore the
Mobile Network Prefix option in HoTI message. This will result in
Ng & Hirano Expires April 7, 2005 [Page 18]
Internet-Draft RRNP October 2004
the correspondent node returning a HoT message without any Number
of Prefixes option. The mobile router should take the absence of
Number of Network Prefixes option as an indication of the
correspondent node not supporting the RRNP procedure, and either
proceed with the normal RR procedure, or give up the RRNP
procedure. It makes sense to proceed with the normal RR procedure
only if the mobile router itself is communicating with the
correspondent node.
Ng & Hirano Expires April 7, 2005 [Page 19]
Internet-Draft RRNP October 2004
6. Security Considerations
The RRNP procedure described is designed to minimize the possible
security threats mobile routers and correspondent nodes are exposed
to when attempting to achieve route optimization. The RRNP procedure
described here is an extension of the original RR procedure described
in Mobile IPv6. This extension has been carefully designed to retain
all the beneficial features of the original RR procedure [7].
Firstly, keys and nonce used are never transmitted in clear. For an
attacker to independently derive the binding management key, the
attacker must be able to intercept all the Home Test, Care-of Test
and Network Prefix Test messages sent by the correspondent node. It
is especially difficult for the attacker to intercept the Network
Prefix Test message since the destination is a randomly selected
address.
Secondly, the correspondent node is not required to maintain any
state information before accepting the binding update. This reduces
the possibility of the correspondent node being exposed to
denial-of-service attack.
Thirdly, replay attacks are diverted since the Binding
Update/Acknowledgment message is protected by the Authenticator data,
so a replay attack staged by simply changing the sequence number of
previously snooped Binding Update/Acknowledgment message and
re-calculating the mobility header checksum will not work since the
cryptographic hash value in the Authenticator data will not tally.
The only relaxation in terms of security this RRNP procedure has is
that the correspondent node will need to send more than one packets
for every HoTI message received. It is thus possible for an attacker
to make use of this amplification effect to launch a distributed
denial-of-service attack against a victim, by having the
correspondent node send large number of HoT and NPT messages to the
victim. As mentioned in the earlier text, the correspondent node can
somewhat ameliorate this by adding random delays before sending the
NPT messages. In addition, the correspondent node can also refuse to
process subsequent HoTI messages when it has received a large number
of HoTI messages in a short span of time. Finally, the option of
whether to respond to route optimization should be made configurable
in implementations of correspondent node, and the default
configuration should be set to not perform route optimization.
Ng & Hirano Expires April 7, 2005 [Page 20]
Internet-Draft RRNP October 2004
7 References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Devarapalli, V., "Network Mobility (NEMO) Basic Support
Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
June 2004.
[3] Thubert, P., Molteni, M. and C. Ng, "Taxonomy of Route
Optimization models in the Nemo Context",
draft-thubert-nemo-ro-taxonomy-02 (work in progress), February
2004.
[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-01 (work in progress), February
2004.
[5] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[6] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[7] Nikander, P., "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-01 (work in
progress), July 2004.
[8] Wakikawa, R., "Optimized Route Cache Protocol (ORC)",
draft-wakikawa-nemo-orc-00 (work in progress), July 2004.
Authors' Addresses
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
EMail: cwng@psl.com.sg
Ng & Hirano Expires April 7, 2005 [Page 21]
Internet-Draft RRNP October 2004
Jun Hirano
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3 Hikarino-oka
Yokosuka, Kanagawa 239-0847
JP
Phone: +81 46 840 5123
EMail: hirano.jun@jp.panasonic.com
Ng & Hirano Expires April 7, 2005 [Page 22]
Internet-Draft RRNP October 2004
Appendix A. Applicability of RRNP
Although this memo assumes route optimization to be achieved by
binding network prefixes to care-of address at the correspondent
node, the same principle behind RRNP can be used as long as a node
needs to verify if prefixes are indeed owned by some other node that
claims to own them.
For instance, in [8], correspondent router is performing route
optimization in proxy of correspondent node. The correspondent
router can then use RRNP to verify that mobile router owns the mobile
network prefix it claims to own. In addition, if the correspondent
router sends to the mobile router one or more network prefixes that
the correspondent router claims to be able to perform route
optimization on behalf of, the mobile router can use the same
principle behind RRNP to test the validity of such a claim.
In the latter case, there is no need to send the CoTI message if the
correspondent router is a fix node. The correspondent router can
simple send the HoTI message to the mobile router with network prefix
information. To test the validity, the mobile router responds with
HoT and NPT messages. The mobile router only accepts the
correspondent router as a valid proxy for the correspondent nodes the
correspondent router claims to manage when the RRNP procedure is
succesfully completed.
Ng & Hirano Expires April 7, 2005 [Page 23]
Internet-Draft RRNP October 2004
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 (2004). 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.
Ng & Hirano Expires April 7, 2005 [Page 24]