Mobile IP Working Group Jari T. Malinen
INTERNET DRAFT Franck Le
2 March 2001 Charles E. Perkins
Category: Standards Track Nokia Research Center
Mobile IPv6 Regional Registrations
draft-malinen-mobileip-regreg6-01.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 MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
This document describes Mobile IPv6 regional registration as an
optional extension to Mobile IPv6. Regional registration introduces
visited-domain mobility agent functionality for proxying a public
care-of-address which remains the same while the mobile node
moves in the visited domain. This reduces the binding update
signaling latency for the mobile node and signaling load outside the
visited domain. The protocol defines regional mobility capability
negotiation, regional binding update signaling, and regional-aware
data routing through a hierarchy of visited-domain mobility agents.
The protocol allows for an arbitrary point in the visited-domain
hierarchy to distribute the connection-state maintenance between
several mobility agents. IPSec AH is used for securing the protocol
as in basic Mobile IPv6.
Malinen, Le, Perkins Expires 2 November 2001 [Page 1]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
Contents
Status of This Memo 1
Abstract 1
1. Introduction 3
2. Terms 4
3. Protocol Operation Overview 5
3.1. Movement to a new Link . . . . . . . . . . . . . . . . . 7
3.2. Visited-domain capability discovery . . . . . . . . . . . 8
3.3. Regional Registrations signaling . . . . . . . . . . . . 8
3.4. Regional-Aware Data Routing . . . . . . . . . . . . . . . 10
4. Protocol Extensions 11
4.1. Router Advertisement modifications . . . . . . . . . . . 12
4.2. Regional CoA Extension . . . . . . . . . . . . . . . . . 12
4.3. Regional Binding Update . . . . . . . . . . . . . . . . . 14
4.4. Previous Access Router Sub-Option . . . . . . . . . . . . 14
5. New requirements for IPv6 Nodes 15
5.1. Visited Domain Router Requirements . . . . . . . . . . . 16
5.2. Mobile Node Requirements . . . . . . . . . . . . . . . . 16
6. IANA Considerations 16
7. Security Considerations 16
A. Changes to the previous version 18
B. Regional Registrations Security 19
B.1. Trust delegation . . . . . . . . . . . . . . . . . . . . 20
B.2. Key distribution principles . . . . . . . . . . . . . . . 20
B.3. The full per -mobile trust delegation model . . . . . . 21
B.3.1. Regional Registrations Key Distribution . . . . . 21
B.3.2. Anti replay attacks . . . . . . . . . . . . . . . 21
B.3.3. Key Material Destination Option . . . . . . . . . 22
B.4. "trust delegated to edge routers" security model . . . . 23
B.4.1. Security Association Acquisition from AAA . . . . 23
B.4.2. Movement to a new Link . . . . . . . . . . . . . 25
B.4.3. Anti replay attacks . . . . . . . . . . . . . . . 25
B.5. Forwarding Modes and comparison of these different modes from
a security point of view . . . . . . . . . . . . . . . 26
Addresses 28
Malinen, Le, Perkins Expires 2 November 2001 [Page 2]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
1. Introduction
Mobile IPv6 regional registration reduces the binding update
signaling latency and the signaling load for a mobile node moving
within the same visited domain. The latency is reduced by localizing
binding updates to the visited domain and the signaling load is
reduced by using a regional-aware router for a proxy care-of-address,
as seen by hosts outside the visited domain. The protocol re-uses
the general idea of regional registrations for Mobile IPv4 [3], but
is a different IPv6-specific protocol.
The regional care-of address can be in an arbitrary node in the
visited domain, not just in an edge router or the gateway mobility
agent highest in the hierarchy. The selection of a particular
regional care-of address is done by the mobile node from a list of
addresses advertised by the access router.
The regional binding update is transported over an arbitrary-depth
tree hierarchy of regional-aware routers up to the closest possible
router in the hierarchy. This router is the crossover between the
old path from the gateway router to the previous access router and
from the gateway router to the new access router. The protocol
supports network-controlled selection of the crossover router
which hides the inner structure of the hierarchy and enables
constant-length signaling independent of the depth of the hierarchy.
The regional registration protocol does not require modifications
to any network elements other than the mobile node and the
regional-aware routers. These modifications are optional additions
to basic Mobile IPv6. Non-regional-aware routers, hosts, home
agents, and mobile nodes can interoperate with regional-aware
entities without change.
The added routing state maintenance in the visited domain is minimal.
It does not involve the routing tables at all; all per-mobile state
is kept in the regional binding cache. This data structure is
internal to the regional mobility agent and can re-use the existing
binding cache.
Security is provided with the same signaling protection extensions as
in the basic Mobile IP. However, for an efficient MN-visited domain
signaling security, dynamic security association acquisition and
usage is discussed Appendix B.
A special anycast address represents the visited domain and the
visited-domain part of the obtained key material is propagated within
the anycast group.
Malinen, Le, Perkins Expires 2 November 2001 [Page 3]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
This protocol defines the regional registration signaling for IPv6
and it can be used in combination with other components of the
general smooth hand-over framework [6] for gaining cost-efficient
signaling. In such a combination, the mobile node sends the message
over the wireless interface encapsulated with the state transfer SHIN
option up to the access router. The encapsulating header may carry
e.g. buffering [7] or header compression [5] state transfer signaling
needed for smooth and efficient handovers.
2. Terms
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 RFC 2119 [2].
In addition, this document uses the following terms:
Access Router
The closest router to the mobile node in the visited
domain that the mobile node uses to access the network.
Crossover Router
When a mobile node is performing a regional registration,
the Crossover Router is the router where the old path
leading to a mobile node and the new path cross, i.e.
the regional router in the hierarchy where a connection
state change is needed to maintain an up-to-date
communication path to the mobile node.
Gateway Mobility Agent
The software module implementing regional registrations
in the gateway router.
Gateway Router
A router controlling the regional care-of-address of a
mobile node which may be located anywhere in the physical
hierarchy.
Highest Router
Router used in a visited domain as the root of a physical
hierarchy; The visible hierarchy for a mobile node is
thus rooted at the gateway router possibly below the
highest router.
Home Binding
The binding cache entry in a home agent used for storing
home registration state.
Malinen, Le, Perkins Expires 2 November 2001 [Page 4]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
Home Registration
Sending a binding update to the home agent to create a
home binding.
Regional-aware Router
Router that supports regional registrations.
Regional Binding Cache
A conceptual data structure in regional-aware routers;
it is keyed on the home address of a mobile node and
contains the care-of-address, lifetime, flags, security
association, and network interface as data elements. All
regional routing state is contained in this entry.
Regional Care-of-address
A care-of-address, as seen from outside the visited
domain, used to locate a mobile node. Remains the same
while the mobile node does regional binding updates
within a visited domain.
Regional Mobility Agent
The software module implementing regional registrations
in a regional-aware router.
Visited Domain
A domain that is visited by the mobile node; a set of
subnets usually administered by one entity. In this
document, all routers in a visited domain are assumed to
have a security association with one another.
This terminology is intended to conform to those that have been
used in Mobile IP and other Internet protocols. Basic Mobile IPv6
terminology is used as defined in [4].
3. Protocol Operation Overview
A foreign domain advertises its capability for regional registrations
with a newly defined router advertisement flag. When entering a
visited domain for the first time, the mobile node registers with its
home domain. During or after this registration, the mobile node can
perform a regional registration.
A regional registration establishes a regional care-of-address
that is seen from outside the visited domain as the mobile node's
primary care-of-address. This address is controlled by one of the
visited-domain routers and the mobile node obtains the address from a
list of Regional CoA extensions (Section 4.2), attached to the router
advertisement.
Malinen, Le, Perkins Expires 2 November 2001 [Page 5]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
________
+------------+ / \ +--------------------+
| Home Agent |------( Internet )----| Corresponding node |
+------------+ \________/ +--------------------+
|
| regional \
| care-of-address +
+------------------------+ |
| Gateway Mobility Agent | |
| (GMA) | |
+------------------------+ |
/ \ |
1./ \ |
/ \ |
+------------------+ +--------+ |
| Crossover Router | | Router | |
+------------------+ +--------+ \
/ \ \ Visited
1./ \ 2. / Domain
/ \ /
+----------+ +--------+ |
| Previous | | New | |
| Access | | Access | |
| Router | | Router | |
+----------+ +--------+ |
^ ^ |
|1. |2. |
| | |
+-+ +-+ (on-link) primary |
| | ---> | | care-of-address |
+-+ +-+ +
Mobile Mobile /
Node Node
Figure 1: Hierarchy of regional-aware routers
After obtaining a regional care-of-address, the mobile node stores
the current visited domain identity, and sends binding updates to
its home agent and corresponding nodes. The mobile node uses the
regional care-of-address as the alternate care-of-address when
sending basic Mobile IPv6 binding updates to nodes outside the
visited domain.
Malinen, Le, Perkins Expires 2 November 2001 [Page 6]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
While staying within the visited domain, the mobile node MAY send
regional binding updates for the duration of its home binding. The
mobile node may also send ordinary binding updates to the home agent
or to corresponding nodes at any time.
Figure 1 illustrates a typical regional registration scenario. The
mobile node sends a regional binding update to the crossover router
which updates its connection state from the old path to the new path.
The gateway router is the crossover router during the first regional
registration (signal 1). After this (signal 2), the crossover may
exist lower in the hierarchy.
The regional binding update is a modified Binding Update destination
option. It updates the regional binding cache entries of a mobile
node in regional-aware router hierarchy. The binding update also
enables the visited domain to decide the crossover router. The
mobile node attaches additional information to this binding update
such that a regional-aware router can decide from it whether it is a
crossover router.
The regional binding cache is used for regional data routing,
forwarding of encapsulated or source-routed Mobile IPv6 data packets
to the mobile node. The binding cache entries are deleted by timeout
or by de-registration. The semantics of this is identical to that in
basic Mobile IPv6.
3.1. Movement to a new Link
When entering a new foreign link, with the same or another visited
domain, the mobile node performs movement detection and uses router
discovery to discover new routers as defined in Mobile IPv6. The
mobile node may also receive a handover indication from the link
layer and consequently send a router solicitation. Similarly,
the mobile node may receive an unsolicited router advertisement
containing the indication that handover is imminent.
The mobile node also performs visited domain detection as an
additional part of the movement detection of basic Mobile IPv6.
The mobile node uses as visited domain identity a ``visited
domain routers'' anycast address. This is derived from the
selected regional care-of-address in the router advertisement
option (Section 4.1) and used for detecting movement to a new visited
domain. This identity MUST be unique.
The anycast address is formed from the prefix in the regional
care-of-address extension and a host number 0 (TBD). The prefix
can e.g. be shorter than the actual prefix of the regional
care-of-address in the gateway router. Such a shorter prefix can
Malinen, Le, Perkins Expires 2 November 2001 [Page 7]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
thus contain many regional care-of-addresses in the same visited
domain.
When the mobile node changes its regional care-of-address, or
when the selected regional care-of-address is not in the router
advertisement of the new access router, the mobile node SHOULD behave
as if it arrived to a new visited domain. This avoids the situation
where the crossover router would be beyond the GMA in the hierarchy.
The mobile node then selects its primary care-of-address, which
is on the same link as is the access router, as defined in Mobile
IPv6. The address is co-located to the mobile node together with its
routing identity, its home address, and used as the target for local
communication between the visited domain and the mobile node. The
mobile node MAY also use this address as the care-of-address in its
binding updates for corresponding nodes within the visited domain.
3.2. Visited-domain capability discovery
The router advertisement from a regional-aware router contains flags
to indicate the supported capabilities. The supported capability
flag for regional registrations is the `I' bit in the Reserved1 field
of the Mobile IPv6 Modified Router Advertisement Message's Modified
Prefix Information Option [4].
If the `I' bit is set, the mobile node SHOULD make use of regional
registration. In this case, the mobile node selects its regional
care-of-address from the one or more regional care-of-address
extensions in the router advertisement.
3.3. Regional Registrations signaling
When entering the visited domain, the mobile node performs a home
registration in combination with the first regional binding update.
The regional binding update MAY be an outer encapsulator around the
home registration binding update.
The regional binding update is a modified Mobile IPv6 binding update
destination option. It propagates upwards hop-by-hop through a
hierarchy of regional-aware routers to a router controlling the
selected regional care-of-address. There may be regional-unaware
routers between adjacent regional-aware routers in a hierarchy.
The regional care-of-address can be an address of the visited domain
router or an address from a pool of regional care-of-addresses
controlled by a router. Association between such a care-of-address
Malinen, Le, Perkins Expires 2 November 2001 [Page 8]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
and a router within the visited domain, selected as target of the
first regional binding update, is implementation-specific.
The destination address in the IP header of the regional binding
update at the sending mobile node is the ``visited domain routers''
anycast address. It MAY also be the IP address of the access router.
A packet sent to this address is first received by the regional-aware
access router. There MUST be a home address destination option in
the IPv6 packet carrying the regional binding update as with basic
Mobile IPv6.
The regional binding update is then propagated to the next-higher
regional-aware router by encapsulation. The encapsulating header
around the regional binding update or around the returned binding
acknowledgement MAY carry key material within the anycast group as
described in Appendix B.
When the regional binding update is re-sent from the receiving router
up to the next higher router, each regional-aware router establishes
or updates its regional binding cache entry for the mobile node.
The key to the entry is the home address, and the care-of-address
is the source address of the regional binding update received from
the next lower regional-aware router. In the access router, the
care-of-address is the sending link address of the mobile node.
Implementation of the regional binding cache can reuse the basic
Mobile IPv6 binding cache entry with a new `I' flag set.
Since the network controls the crossover router selection, the
responding visited domain target router is not known to the mobile
node. It sends the packet to the anycast address or the unicast
address of the router. The packet is received by the router
from which the mobile node received the router advertisement.
The regional care-of-address MUST be inserted as a alternate
care-of-address sub-option of the regional binding update. The `A'
bit MUST be set and the `H' bit MUST NOT be set.
The mobile node appends the previous access router sub-option (Section 4.4)
to the regional binding update. This sub-option identifies the
previous access router so that each router can locally decide whether
it is the crossover router. When the signal is propagated upwards,
the first router that has the previous access router among its
descendants is the crossover router. When this sub-option is absent,
the regional binding update propagates up to the gateway mobility
agent. To know its descendants, a regional-aware router maintains a
list of all of its descendants. How this list is configured is out
of the scope of this protocol; it can be statically configured from a
parameter file, for example. Alternatively, a mobile router can set
the 'R' bit in the regional binding update to join the hierarchy as
a leaf router. Then, a descendant list entry is established with a
Malinen, Le, Perkins Expires 2 November 2001 [Page 9]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
lifetime, and the mobile router marks the upper regional router as a
father router.
After a successful regional binding update, a basic Mobile IPv6
binding acknowledgement is returned to the mobile node back through
the hierarchy. In case of signaling where anycast address is
used all the way through the hierarchy, a binding acknowledgement
SHOULD be sent to the MN and to the anycast address. A successful
regional registration is denoted by a new success status value
1. This denotes regional-aware success; status value 0 denotes
regional-unaware success. In the latter case, the receiving node
accepted the binding update as any corresponding node would. The
mobile node can thus send regional binding updates to any node and
recognize regional-awareness of the other end from this status
value. This gives the protocol robustness against mis-configured
regional-aware routers.
The mobile node SHOULD NOT send binding updates with the regional
care-of-address to regular nodes until it has received the
regional-aware success status value 1. If the regional-aware
router fails to accept the regional registration, it returns a
Reason Unspecified status value 128 in the binding acknowledgement.
However, if the mobile node does not receive status value 1 from
the gateway mobility agent, the mobile node MUST re-send a binding
updates with the primary care-of-address.
A regional-aware mobile node MAY support mobile multi-homing,
i.e. the mobile node MAY register more than one home address
simultaneously with one or more home agents. Operation of these
addresses occur independently, i.e. as if there were multiple mobile
nodes within the same physical host. The mobile node MUST NOT
register more than one care-of-address for each home address.
If regional-aware propagation uses unicast addresses, the regional
binding update is re-generated in each intermediate router. If the
first target is anycast address, the propagation MAY change into
unicast-based inside visited domain or it MAY remain anycast-based.
A discussion on differencies with these modes is in Appendix B
3.4. Regional-Aware Data Routing
Since the regional care-of-address is in the visited domain, packets
targeted to it go through the regional-aware routing hierarchy from
the GMA towards the mobile node. The other direction is not affected
by regional registrations.
When a corresponding node sends data packets to a mobile node to
which it does not yet have an entry in its binding cache, these
Malinen, Le, Perkins Expires 2 November 2001 [Page 10]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
packets are intercepted by the home agent and encapsulated to
the registered care-of-address mobile node, as specified in the
basic Mobile IPv6. However, this care-of-address is the regional
care-of-address.
For tunneled packets, the regional care-of-address of the mobile node
is selected as the target for the outer encapsulation header. The
router which controls that regional care-of-address decapsulates the
tunneled packets. The destination of the encapsulated packet is the
home address of the mobile node.
If there is an entry in the regional binding cache for this home
address, the router SHOULD re-encapsulate these packets to the
corresponding lower care-of-address. This is in the next lower
regional-aware router or in the mobile node if the forwarder is the
access router. Thus, the data packets SHOULD get re-capsulated at
each regional-aware router on their way down the hierarchy.
If the lower regional-aware router is at link-distance from the
forwarding regional-aware router, or a routing protocol maintains
host-based routes between regional-aware routers, the router
MAY forward these packets simply by using host-based routes.
The forwarding MAY also use other methods such that the packet
propagation occurs as with the above methods. A method of forwarding
is local to a router in a way that multiple methods of forwarding can
be used in a visited domain without a negotiation mechanism.
4. Protocol Extensions
The following protocol extensions are defined:
- A modification to the Modified Router Advertisement Message
to indicate whether the visited domain supports regional
registrations (the `I' bit) (Section 4.1).
- A regional care-of-address extension to the router
advertisement (Section 4.2).
- A modification to the Binding Update destination option to
indicate whether the option is a Regional Binding Update (the `I'
bit) (Section 4.3).
- An previous access router sub-option for the binding
update (Section 4.4).
Malinen, Le, Perkins Expires 2 November 2001 [Page 11]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
4.1. Router Advertisement modifications
The router advertisement, as defined in the basic Mobile IPv6,
contains additionally the `I' bit and the visited domain identity in
the Modified Prefix Information Option of the Router Advertisement
Message. The format of the new Modified Prefix Information Option is
the following:
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 | Prefix Length |L|A|R|I|Rsrvd1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Modified Prefix Information Option
I Indicates regional registrations support.
The Rsvrd1 field is here a 4-bit field instead of the 5 bits
Reserved1 prior to adding the `I' bit. Other fields are as described
in the Mobile IPv6 and the Neighbor Discovery [8] documents.
4.2. Regional CoA Extension
The router advertisement may contain one or more visited-domain
care-of-addresses from which the mobile node chooses a regional
care-of-address. Each such address is advertised in a Regional CoA
Extension of the modified Router Advertisement.
The format of the regional CoA extension is the following :
Malinen, Le, Perkins Expires 2 November 2001 [Page 12]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
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 | Prefix Length | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Regional Care-of-Addresses |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Regional CoA extension
Type 6, TBD (skippable)
Length 8-bit unsigned integer. The length of the option
(including the type and length fields) in units of 8
octets. This field MUST be 3.
Lifetime The time the advertised CoA is valid in the visited
domain.
Prefix Length
An 8 bit unsigned integer. This denotes prefix length
of the ``visited domain routers'' anycast address where
the prefix is taken from the regional care-of-address
and the host number is 0 (TBD). One of these options
MUST identify the visited domain. Prefix length fields
in the other regional CoA options in the same router
advertisement MUST be zero.
Index Index describing which of the global prefixes can be
used with this address. 1 denotes the first prefix in
the advertisement. Special value 0 denotes that this
address applies to all prefixes. The options SHOULD be
ordered so that regional CoA extensions associated with
a given prefix are immediately after that prefix.
Regional Care-of-Address
The advertised address, which MUST be a global IPv6
address from the visited domain.
Malinen, Le, Perkins Expires 2 November 2001 [Page 13]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
4.3. Regional Binding Update
The Regional Binding Update is a Mobile IP Binding Update with the
following modifications. In the Reserved field after the flags
field, there will be the following additional bit.
Description of extensions to the BU option:
I Indicates regional registrations support. This implies
that the receiving router will use the BU information to
establish or maintain a regional binding cache entry. The
bit is the first bit from the Reserved field of the Mobile
IPv6 Binding Update destination option.
Previous Access Router Sub-Option
A sub-option for determining the crossover router.
4.4. Previous Access Router Sub-Option
The previous access router sub-option is used by the network
to determine the crossover router. A crossover router address
is obtained from the IP header source address of the router
advertisement. The mobile node remembers this for the previous
router and uses it to create an previous access router sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | PathId | PathCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Previous access router |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Previous Access Router Sub-option
Malinen, Le, Perkins Expires 2 November 2001 [Page 14]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
Type 5, TBD (skippable)
Length 8-bit unsigned integer. The length of the sub-option
(including the type and length fields) in units of 8
octets.
PathId 8-bit unsigned integer. This optional field identifies
a route for one mobile node with multiple routes within
a visited domain from the edge router to GMA.ix from
the
PathCount 8-bit unsigned integer. Identifies the number of path
branches on the path of a regional binding update.
This optional field is also used for multiple routes
support. A crossover functionality can e.g. propagate
regional binding updates to the GMA if the PathCount is
greater than one.
Previous access router
The IP address of the previous access router as seen by
the mobile node.
There is no requirement for alignment of the Previous Access Router
sub-option.
The previous access router sub-option is valid in the Binding Update
destination option. The previous access router contains the IPv6
address of the access router as seen by the mobile node. It is used
to identify the crossover router in the visited domain regional
router graph. This is done by comparing the previous access router
to the known descendants when the regional binding update gets
forwarded upward in the tree of regional-aware routers. When the
router finds the previous access router in its list of descendants,
it is the crossover router.
5. New requirements for IPv6 Nodes
The presented option requires modifications to the visited-domain
routers and to the mobile node. The option does pose no new
requirements to the home agent, to correspondent nodes, or to other
network elements than to the regional-aware routers in the visited
domain.
Malinen, Le, Perkins Expires 2 November 2001 [Page 15]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
5.1. Visited Domain Router Requirements
The support of the protocol is optional to basic Mobile IPv6;
elements can function in both regional-aware and regional-unaware
visited domains. Introducing regional-aware routers to a visited
domain does not mandate the use of regional registrations.
The regional-aware access router MUST be capable of advertising
regional registration support. The router MUST be capable of
maintaining regional binding cache entries based on regional
binding updates. These routers MUST route the data packets to the
regional-registered mobile nodes so that a mobile node can recognize
the use of route optimization from the presence of a routing header,
as described in Section 3.4.
5.2. Mobile Node Requirements
A regional non-aware mobile node can operate in a regional-aware
network. The regional-aware mobile node SHOULD select a regional
care-of-address and send a regional binding update accordingly.
6. IANA Considerations
The presented protocol does require the addition of one skippable
option type to the router advertisement [8] and one skippable
sub-option type to the Binding Update destination option.
Also, the protocol requires two modifications from the Modified
Router Advertisement Message`s Prefix Information Option, one bit in
its Reserved1 field, from the format specified in the basic Mobile
IPv6 [4]. The protocol also needs one new bit from the Reserved
field of the Mobile IPv6 Binding Update option.
The Binding Acknowledgement would need one new regional-aware success
code, with a proposed value of 1 to be added to the list of known
status field values.
A host number for the ``visited domain routers'' anycast address
would be needed. The value 0 is suggested.
7. Security Considerations
The regional-aware mobile node SHOULD use a mobile-visited-domain key
for authentication. The IPSec authentication header (AH) is used for
security as in basic Mobile IPv6. In regional signaling, the mobile
node and visited domain share a security association, in form of a
Malinen, Le, Perkins Expires 2 November 2001 [Page 16]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
mobile-visited-domain key for IPSec. The mobile-visited-domain key
is obtained when entering the visited domain and transported to the
visited domain routers and to the mobile node.
The protocol in this document assumes that the routers have a way to
authenticate messages based on anycast security associations. The
usage of AAAL as a source of unique SPIs among all visited domain
routers, as explained in Appendix A, is utilized to enable the use
of anycast address -based security association identification. As
long as the visited domain anycast address -based SPD entries are
not created by means other than specified, this allows for the
use of anycast security association in this particular case. A
challenge-response -based replay service for aycast in this case is
also introduced.
Malinen, Le, Perkins Expires 2 November 2001 [Page 17]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
References
[1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA for
IPv6 Network Access (work in progress). Internet Draft, Internet
Engineering Task Force, March 2000.
[2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[3] Eva Gustafsson, A. Jonsson, and C. Perkins. Mobile IP Regional
Registration. draft-ietf-mobileip-regtun-03.txt, July 2000.
(work in progress).
[4] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress). Internet Draft, Internet Engineering Task Force,
November 2000.
[5] R. Koodli, M. Tiwari, and C. Perkins. Header Compression
State Relocation in IP Mobile Networks (work in
progress). Internet Draft, Internet Engineering Task
Force. draft-koodli-rhoc-hcompr6-00.txt, July 2000.
[6] Rajeev Koodli and Charles E. Perkins. A Framework for
Smooth Handovers with Mobile IPv6 (work in progress).
Internet Draft, Internet Engineering Task Force.
draft-koodli-mobileip-smoothv6-02.txt, November 2000.
[7] G. Krishnamurthi, R. Chalmers, and C. Perkins. Buffer
Management for Smooth Hand-Overs in Mobile IPv6 (work in
progress). Internet Draft, Internet Engineering Task Force.
draft-krishnamurthi-mobileip-ipv6buf-00.txt, July 2000.
[8] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
[9] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys for
Mobile IP (work in progress).
draft-ietf-mobileip-aaa-key-03.txt, September 2000.
A. Changes to the previous version
This version introduces an anycast address to represent the
visited domain as a distributed network endpoint in addition to
supporting the unicast-based approach of the previous version. A
one message-exchange multi-level signaling is efficient e.g. when
the mobile node needs to communicate both with the access router
Malinen, Le, Perkins Expires 2 November 2001 [Page 18]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
and the gateway mobility agent (GMA). The other changes address
problems mentioned in earlier working group minutes, in security and
in providing uniqueness of the visited domain identity.
- This version distributes the network endpoint of communication
identifying it with an anycast address. A common security
association per mobile node can be used in the visited domain
when key material received from AAAv6 is propagated to members of
the anycast group, as described in Appendix B. This change also
preserves the cost-efficiency of having a single message exchange
with the deep hierarchy while now providing a fully specified
security option.
- The regional forwarding now is based on encapsulation or
host-based routes. Other methods specified elsewhere may also be
used. The earlier regional forwarding of route-optimized packets
is now separated into another draft.
- The router advertisement now also uniquely identifies the
visited domain with the special ``visited domain routers''
anycast address. This address is formed using prefix of the
regional care-of-address and a host number 0 (TBD). Thus, no
visited domain identifier is used in this version from the
prefix information option. The same anycast address is used
by the mobile node to send the regional binding update to the
distributed endpoint, the destination IP address of the regional
binding update.
- The unicast address of the advertising router can also be used
as a destination of a regional binding update. Internally this
means a different propagation of the regional binding update
but does not require any extra negotiation between the mobile
node and the access router. The mobile node can now send the
regional binding update to either to the unicast or to the
anycast address.
- A security appendix now describes a temporary security
association acquisition and propagation mechanisms with
alternative regional binding update propagation schemes. These
give the visited domain builder several configuration options
while remaining transparent to the mobile node.
B. Regional Registrations Security
Mobile IPv6 Regional Registrations signaling is secured using
Authentication Header using binding updates as with Mobile IPv6 home
registration binding updates. However, since the communicating
parties in sending regional binding updates are the mobile node
Malinen, Le, Perkins Expires 2 November 2001 [Page 19]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
and regional routers, a static security association can not be
assumed between mobile node and each visited domain in a scalable
solution. Regional registrations security considers scalable
acquisition of the needed security association(s) and their use with
Authenitcation Header -based security. This document specifies
mechanisms and extensions to the Mobile IP Binding Update, and
binding acknowledgements messages that can be used to distribute such
security information to the mobile node and visited domain.
B.1. Trust delegation
A mobile-visited domain security association can be obtained in a
multiple ways, depending on availability of mechansims and policy
requirements of the visited domain. The visited domain can also
provide open access.
A regional-aware visited domain can view trust delegation in
two distinct ways. A full per-mobile trust delegation from an
authorization center provides trust from a key distribution center
in form of per-mobile session key material to every regional-aware
router which participates to regional signaling. This can be
used when propagating a regional binding update unmodified to the
crossover router.
A model with trust propagated to the edge routers of a visited domain
can be used with a policy where the more static intra-visited-domain
security associations are used for protecting the propagated regional
binding update. In this case the regional signals are re-transmitted
from intermediate regionals routers using new authentication header.
A benefit is that the visited domain does not need to have per-mobile
security associations in all routers making the visited domain more
scalable for a very large number of mobile nodes.
B.2. Key distribution principles
Security credentials for mobile-visited domain security associations
can be obtained in a multiple ways. One way is to assume an
AAA-based key distribution and use mechanisms like AAA registration
keys for Mobile IP [9]. The latter provides two key distribution
schemes for getting temporary session keys for the mobile node and a
router.
If trust is delegated to the edge routers, and no per-mobile key
distribution inside the visited domain is desired, a regional
binding update is propagated by recreating it with authentication
headers used between adjacent regional routers. The regional binding
acknowledgement is then propagated in a similar way back to the edge
Malinen, Le, Perkins Expires 2 November 2001 [Page 20]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
router which finally re-sends the binding acknowledgement to the
mobile node using the mobile-visited-domain security association.
An intra-visited-domain key distribution mechanism may be applied
with regional signaling, if full per-mobile trust delegation is
desired. A regional binding update is propagated with its original
authentication header to the crossover router, encapulated with an
outer IP header and a key distribution option.
The two modes have the same signaling behavior seen from the mobile
node. Thus the visited domain administrator can locally configure
either of the modes without it being visible to mobile nodes.
B.3. The full per -mobile trust delegation model
B.3.1. Regional Registrations Key Distribution
A regional-aware gateway router with the selected regional
care-of-address MAY communicate with the AAAv6 local authority
during the first regional binding update into a visited domain,
depending on the local requirements for authorizing network access.
The visited domain MAY provide temporary access rights for regional
registrations while the AAA infrastructure is generating a reply to
the authorization request. When the AAA has granted access, the
access to the visited domain is decisively granted.
AAAv6 is expected to provide temporary key material for the mobile
node and the visited domain to be used in subsequent regional
authentications. As mentioned previously, many solutions currently
exist like AAA registration keys for Mobile IP IP [9]. This material
is provided for the mobile node in combination with a Binding
Acknowledgement, and also for the visited domain. The latter is then
propagated together with regional registration signaling in a key
material destination option. This option is inserted to the outer
encapsulation header when propagating subsequent regional binding
updates or binding acknowledgements inside the visited domain. It
can be protected with IPsec using intra-visited-domain security
associations.
Or as an alternative, the intermediate routers retrieve the user
specific session key from the AAA-L which also stores it.
B.3.2. Anti replay attacks
Anti replay attacks can not be provided by the Sequence number
specified in the Authentication Header protocol since this requires
Malinen, Le, Perkins Expires 2 November 2001 [Page 21]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
all the intermediate routers to have synchronized counters which is
difficult.
Instead, nonces SHOULD be used to provide anti replay attacks: The
mobile node takes the Local Challenge citedraft-ietf-perkins-aaav6,
sent in Router advertisements messages, as an input to the
authentication data computation of the regional binding update
message. The Local challenge is then included in the Regional
Binding Update and the access router first ensures the freshness of
the message by verifying that the Local Challenge carried in the
Binding Update message is a recent one. This Local Challenge is also
encapsulated with the Regional Binding Update message until the cross
over router which ensures freshness of the message by verifying that
the authentication data takes into account the recent Local Challenge
carried in the message.
The mobile node SHOULD also generate a Host Challenge that is also
included in the Binding Update message as a destination option and
encapsulated until the cross over router which tales that Host
Challenge as an imput when computing the authentication data of the
Binding Acknowledgement message. The Host Challenge is then sent
back in the Binding Acknowledgement message and the mobile node
can thus verify the freshness of the reply from the access router
by making sure the authentication data computationtook this Host
Challenge into consideration.
B.3.3. Key Material Destination Option
This is a possible extension to carry the user specific key between
the intermediate routers. The message carrying this extension should
be encrypted and intergrity protected by using intra domain security
(e.g. IPsec)
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 | Alg | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Key Material Destination Option
Malinen, Le, Perkins Expires 2 November 2001 [Page 22]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
Type TBD (skippable), one for key request, one for key reply
Length 8-bit unsigned integer. The length of the option
(including the type and length fields) in units of 8
octets.
Alg 8-bit algorithm indication as specified for the
Authentication Header.
Key Length
8-bit unsigned integer. The length of the key in
units of 4 octets.
SPI 32-bit Security Parameter Index value.
Key Encrypted key material of at most 1024 octets.
As an alternative, the intermediate routers can retrieve the user
specific session key fro the AAA-L: this requires only security
associations between intermediate routers and AAA-L whereas the
propagation of the user keys requires security associations between
all the intermediate routers.
B.4. "trust delegated to edge routers" security model
This section describes another alternative of a security model where
Regional Registration could deployed securely. This solution is
more scalable requiring only user specific security association
between the MN and the Access routers and then relying on intra
domain security to authenticate the regional binding update within
the visited domain.
B.4.1. Security Association Acquisition from AAA
When entering a visited domain, the mobile node performs a home
registration in combination with the first regional binding update:
The mobile node computes some authentication data (e.g. from a
Local challenge sent to the Hosts in Router advertisments messages,
from a Home Challenge generated by the Home domain for anti replay
attacks [1], and using the Long term key shared between the mobile
node and its Home domain), and adds a Regional Registration key
request in the regional binding update.
The destination address in the IP header of the regional binding
update at the sending mobile node is the source address of the router
Malinen, Le, Perkins Expires 2 November 2001 [Page 23]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
advertisement containing the selected regional care-of-address or the
anycast address identifying the visited domain.
The receiving Access Router, due to the presence of the
authentication extension, forwards the message to the AAA-L, which
invokes the AAA-H for entity authentication: the serving system
wants to make sure the user is a valid one before giving him access
to its network resources. If the Home agent is in the home network,
this AAA invocation to the Home domain may include the Home Binding
Update [1] to the Home Agent. If Home agent is dynamically assigned
in the home network, AAA-H assigns the Home agent and sends a Binding
update to the assigned Home agent. These are possible optimizations
to save round trips between the visited and home domain reducing time
delay and load over the network. In such cases, the home binding
update may indicate the regional care of address as the alternate
care-of-address and if regional registration fails (e.g. RcoA is not
valid), the mobile node will update the Home agent.
Once authentication succeeded, thanks to the keying material, AAA-L
can compute a regional registration key K wich is specific to the
mobile node. AAA-L sends it to the Access Router with the keying
material destined to the mobile node for it to be able to derive K.
The access router then sends the Binding Acknowledgement with some
extension carrying the keying material to the mobile node which will
derive K and create a regional binding update authenticated using K.
As another optimization, since in wireless networks, radio resources
are limited, the Access router, on receipt of the network access
authorization from AAA-L, knows the mobile node is valid and can
perform regional registration thus saving one additional round trip
over the air interface.
The access router sends a new binding update to the next-hop cross
over router to create the binding between the mobile node home
address and the access router care of address. This binding update
is authenticated using a intra domain security association: Access
Router and Cross over router share a key which can be set up in
different ways and is operator dependant. This key is not user
specific.
The Cross over router propagates the binding update until the GMA
using as previously intra domain security. Thus, only Access routers
needs to maintain user specific security asociations which is more
scalable than having user specific security associations up to the
GMA requiring the GMA to maintain the security associations for all
the users it is serving.
Malinen, Le, Perkins Expires 2 November 2001 [Page 24]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
B.4.2. Movement to a new Link
When entering a new foreign link within the same domain, the mobile
node sends a regional binding update authenticated using K. The
receiving access router can either retrieves the key from the
previous access router indicated by the mobile node or from the
AAA-L. The latter option only requires security association between
access router and AAA-L whereas the first option also needs security
association between Access routers.
The access router then verifies the authenticity of the binding
update message and if succeeded, it sends binding update messages up
to the crossover router using intra domain security. Alternatively,
if so wished by trust delegation policy, the binding update can be
propagated to the crossover router with the original authentication
header, and with an outer encapsulation containing a key material
destination option (Section B.3.3) with the distributed key encrypted
using intra domain security. Each router decapsulating this option
inserts it to its security policy database prior to using it for
authenticating the regional binding update.
B.4.3. Anti replay attacks
Between the mobile node and the access router, since the access
router creates the binding acknowledgement message to the mobile
node, replay protection can be provided by various methods:
Timestamps: The MN and the access router verify the freshness of the
messages by making sure that the timestamp used is the current one.
Sequence number: Authentication header has a Sequence number to
provide anti replay service. This counter is one possibility and in
such cases, when mobile node moves to a new link, the new serving
access router when retrieving the user specific key K, also needs to
retrieve the value of this sequence number from the previous access
router.
Nonces: The mobile node can take the Local challenge [1] sent in
Router Advertisements messages as an input to the AH authentication
data of regional binding update messages. The access router
ensures freshness of binding update message from the mobile node
by verifying that the local challenge included in the Request is a
recent one. The mobile also generates a Host Challenge that will
be included in the authentication data of the Binding update and
binding acknowledgement messages. This way, the host can verify the
freshness of the reply from the access router.
Malinen, Le, Perkins Expires 2 November 2001 [Page 25]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
B.5. Forwarding Modes and comparison of these different modes from a
security point of view
First, as described in the security models in the previous section,
the Access Router can either re-create new binding update message
or encapsulate the mobile node's binding update message to perform
regional registration within the visted domain.
The trust model is different but in both cases, the MN needs to
rely on the intra domain security of the visted domain: Either
to re-create binding update message in the "trust delegated to
edge routers model" or to distribute the keys to the different
intermediate routers in the "full per-mobile trust delagation model".
These two models also differ on a scalability point of view: the
"trust delegated to edge routers model" only requires user specific
security associations between mobile nodes and access routers whereas
the "full per-mobile trust delegation model" requires user specific
security associations between all the intermediate routers from the
Access router serving the MN up to the GMA. This may requires many
security associations to be maintained in particularly for the GMA
and thus may have some scalability issues.
In addition, a visited domain can be administratively configured
to different forwarding schemes. The visited domain can forward
the regional binding update and acknowledgement by receiving and
re-sending them between intermediate regional routers. This can
take place when the mobile node initially sends the regional binding
update either to the advertising router's unicast or to the anycast
address. Also, the regional binding update, sent to the anycast
address can be forwarded unmodified to the crossover router.
In the case of RBU re-sending, the key distribution principle of
delegation to the edge routers is used. This enables two different
modes of key propagation where a session key is acquired either from
the previous access router or from the AAAL. Session keys are not
propagated deeper into the visited domain so the state space for
a large number of mobile nodes is smaller than in the full trust
delegation mode. Also, network topology is not revealed in this
case since the binding acknowledgements seem to come from the edge
routers.
In the full trust delegation mode we use the anycast-based unmodified
RBU forwarding. This provides direct mobile node authentication in
the crossover with a fast forwarding of the unmodified RBU. It also
results in propagating the key material, either in-line with the key
material destination option, or by asking the key from the AAAL in
each router. This can be considered inefficient in a large visited
Malinen, Le, Perkins Expires 2 November 2001 [Page 26]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
domain. Since the mobile node in this case directly gets replies
from crossover routers, the visited domain topology is revealed.
Malinen, Le, Perkins Expires 2 November 2001 [Page 27]
Internet Draft Mobile IPv6 Regional Registrations 2 March 2001
Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola
6000 Connection Drive 1501 West Shure Drive
M/S M8-540
Irving, Texas 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com
Questions about this memo can also be directed to the authors:
Jari T. Malinen Charles E. Perkins
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Phone: +1-650 625-2355 Phone: +1-650 625-2986
E-mail: jmalinen@iprg.nokia.com E-mail: charliep@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Malinen, Le, Perkins Expires 2 November 2001 [Page 28]