INTERNET DRAFT
Category: Kent Leung
Title: draft-subbarao-mobileip-redundancy-00.txt
Expires December 2001 Madhavi Subbarao
Cisco Systems
Home Agent Redundancy in Mobile IP
draft-subbarao-mobileip-redundancy-00.txt
Status of this Memo
This document is an Internet Draft and is in full compliance 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. Internet Drafts 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
In Mobile IP, a Home Agent (HA) creates a mobility binding table
that tracks the association of a Mobile Node's (MN) home address with
its current Care-of Address (CoA). If the HA fails, the mobility
binding table will be lost and all MNs registered with the HA will
lose connectivity. In this draft, we propose a Mobile IP Home Agent
Redundancy framework mechanism that provides the essential robust
redundancy needed at the HA. The mechanism described herein can also
be used to provide the redundancy needed at any "regional/local" HAs.
1. Introduction
In Mobile IP, an HA creates a mobility binding table
that tracks the association of an MN's home address with
its current CoA. The mobility binding table is the core for the HA to
be able to provide the functionality defined in RFC 2002 [1].
If the HA fails, the mobility binding table will be lost and all
mobile nodes registered with the HA will lose connectivity unless a
redundancy mechanism is employed. This becomes of paramount
importance to any service provider, especially those with a large
number of users.
In this draft, we propose a Mobile IP Home Agent Redundancy framework
mechanism that provides the essential redundancy and robustness needed
at the HA. This mechanism can also be used to provide the redundancy
needed at any "regional/local" HAs, e.g., an intermediate mobility
agent in a hierarchy. The main idea is to specify a
'backup' HA and functionality to maintain a synchronized copy of the
mobile binding table at the 'backup' HA. This functionality removes
the single point of failure phenomena present in Mobile IP [1].
2. Home Agent Redundancy Feature Overview
The Mobile IP Home Agent Redundancy framework assumes that a mechanism is
employed to specify an Active/Peer HA and Standby/Peer HA(s). The
method by which this is accomplished is outside the scope of this
document. (Intra-subnet specification may be accomplished by using
an underlying router redundancy protocol such as the Hot Standby
Router Protocol (HSRP) [2] or the Virtual Router Redundancy Protocol
(VRRP) [3]. Similarly, inter-subnet specification may also be
supported using underlying routing protocols, i.e., the Active/Peer HA
and Standby/Peer HAs reside on different subnets and Mobile IP
redundancy information is passed along with routing updates. Future
drafts will provide more details on intra-subnet specification and
inter-subnet specification.) Furthermore, it is assumed in the
intra-subnet case that a virtual HA address is used for communication
between the MN and HAs. Hence, if an HA fails, the failure is transparent
to the MN and results in no routing changes.
The HAs may be configured in an Active HA-Standby HA(s) role, or in a
Peer HA-Peer HA(s) role. In the first case, the Active HA assumes the
lead HA role and synchronizes the Standby HA(s). Note that it is
possible to have more than one Standby HA. In the case that the HAs
are serving as Peer HAs, the HAs share the lead HA role and 'update'
each other accordingly. The Peer HA configuration allows for
load-balancing of the incoming RRQs.
There are two main functions specified for Mobile IP HA Redundancy:
(A) Updating/creating a mobility binding: When a Registration Request
(RRQ) is accepted by the Active/Peer HA, the binding MUST be
updated/created on the Standby/Peer HA(s). Note that this also includes
'updating' a mobility binding by deleting the binding upon a
deregistration. Note that if a mobility binding expires on the
Active/Peer HA, it will also expire on the Standby/Peer HA(s). This
process keeps the mobility binding table synchronized between the
Active/Peer HA and Standby/Peer HA(s).
(B) Downloading the mobility binding table: An HA MUST download the
current mobility binding table from the Active/Peer HA either sometime
before it assumes the Standby/Peer HA role, or immediately upon
assuming the Standby/Peer HA role. (If the download occurs sometime
before the HA enters the Standby/Peer HA state, the implementation
MUST ensure that the HA receives the updates in (A) in the HA's
current state.) This process ensures that the Standby/Peer HA has a
copy of the current mobility binding table before providing backup HA
service.
Five messages are defined in Section 4 for the necessary communication
between the HAs. Each message MUST be protected by the
HA-HA Authentication Extension (HHAE) defined in Section 3.
(i) Binding Information Sync: When an Active/Peer HA accepts an RRQ from an
MN, it MUST send a Binding Information Sync message to the Standby/Peer HA(s).
This message contains the necessary information for the Standby/Peer
HA(s) to update/create the mobility binding.
(ii) Binding Information Sync Acknowledgment: When a Standby/Peer HA
receives a Binding Information Sync, it MUST send a Binding
Information Sync Acknowledgment to the Active/Peer HA, if an
unreliable transport protocol is used for message delivery.
(iii) Binding Table Request: When an HA assumes the Standby/Peer HA
role (or sometime before it assumes the role), it MUST send a Binding
Table Request message to the Active/Peer HA to request a download of
the mobility binding table.
(iv) Binding Table Sync: The Active/Peer HA MUST respond to a Binding
Table Request Message with the appropriate number of Binding
Table Sync messages necessary to download the entire mobility binding
table (or a single Binding Table Sync message indicating an error).
(v) Binding Table Sync Acknowledgment: The Standby/Peer HA MUST
acknowledge each Binding Table Sync message received with a Binding
Table Sync Acknowledgment message, if an unreliable transport
protocol is used for message delivery.
Note that the messages Binding Information Sync Acknowledgment and
Binding Table Sync Acknowledgment MUST be used for acknowledgment
when using an unreliable transport protocol for communication.
However, when a reliable transport protocol is used to deliver the
Mobile IP HA redundancy messages, the acknowledgment messages are not
necessary.
Figure 1 illustrates the message flow for Mobile IP HA Redundancy.
---------- ----------
| Active/ | | Active/ |
| Peer HA | | Peer HA |
---------- ----------
| /|\ /|\ | /|\
1.Binding | 2.Binding 1.Binding | 3.Binding
Information | Information Sync Table | Table Sync
Sync | | Acknowledgment Request | Acknowledgment
| | (if unreliable | | | (if unreliable
| | transport) |2.Binding| transport)
| | | Table |
| | | Sync |
\|/ | | \|/ |
---------- ----------
| Standby/ | | Standby/ |
| Peer HA | | Peer HA |
---------- ----------
(a) Updating Binding Information (b) Downloading Binding Table
Figure 1
3. HA-HA Authentication Extension
An HA-HA Authentication Extension is defined according to the General
Authentication Extension given in [4][6] to provide secure communication
between the HAs. All HAs participating in the Mobile IP HA Redundancy
protocol MUST share a security association.
Exactly one HHAE MUST be present in all HA Redundancy messages defined
in Section 4. This extension is similar to the authentication
extensions defined in [1]. The location of the extension represents
the end of the secure data.
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 | Sub Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 36 (See [6]) (Not skippable)
Sub-Type 4 HA-HA Authentication Extension (TBD)
Length The length of the Authenticator field.
SPI Security Parameters Index. An opaque identifier
as specified in [1].
Authenticator The variable length Authenticator field consists
of a random value of at least 128 bits (as
specified in [1]).
4. HA Redundancy Messages and Extensions
Five Mobile IP HA Redundancy messages are defined to facilitate the
necessary communication between the HAs. Either UDP or TCP may be
used as the transport protocol to deliver the HA Redundancy messages.
For intra-subnet redundancy, UDP using Mobile IP port 434 is preferred
over TCP for its simplicity. (The overhead inherent in TCP (e.g.,
3-way handshake, periodic messaging, back-off retransmission, etc.) is
excessive for the HA Redundancy mechanism.) Each Mobile IP HA
Redundancy message MUST be protected by the HHAE defined in Section 3.
4.1 The Binding Information Sync message MUST be sent by the Active/Peer
HA to the Standby/Peer HA(s) upon receipt of a valid RRQ from an MN.
It is almost identical to the incoming RRQ from the MN, except there
are two additional lifetime fields, and the Type field now specifies
that it is a Mobile IP HA Redundancy 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|r|T|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granted Lifetime | Remaining Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 10 TBD (Binding Information Sync)
Reserved Reserved for future use. MUST be set
to zero on transmission and ignored on
reception.
Granted Lifetime Lifetime granted to the MN by the
Active HA/Peer HA
Remaining Lifetime Lifetime remaining until the MN's
mobility binding expires. Should be
updated right before transmission of
Binding Information Sync message.
The remaining fields are identical to the values set in the
incoming RRQ. The Mobile-Home Agent Authentication Extension (MHAE)
in the RRQ is replaced by the HHAE.
Possible extensions that may be appended to the Binding Information
Sync message include the NAI extension [5], the Security Association
Distribution Extension defined in Section 4.7, and
any Vendor Specific Extensions [7].
4.2 Binding Information Sync Acknowledgment
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 | Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 11 TBD (Binding Information Sync Acknowledgment)
Code Value indicating the result of the Binding Information
Sync. Valid code values are the following:
0 registration/message accepted
128 reason unspecified
129 administratively prohibited
130 insufficient resources
133 registration Identification mismatch
140 TBD HA-HA authentication failed
(HA_FAILED_AUTH - See Section 8)
Reserved Reserved for future use. MUST be set to 0 on
transmission and ignored on reception
Home Address Home IP address of the MN (copied from the
Binding Information Sync message)
Identification A 64-bit number used for matching Binding
Information Sync messages with Binding
Information Sync Acknowledgments, and for
protecting against replay attacks of the
messages.
4.3 Binding Table Request MUST be sent by a Standby/Peer HA to the
Active/Peer HA upon assuming the Standby/Peer HA role or sometime
before assuming the role. This message requests the Active/Peer HA
to download its mobility binding table to the Standby/Peer HA.
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 | NumHA | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address(es)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 12 (Binding Table Request)
NumHA Number of HAs addresses on the
Active HA that the Standby/Peer HA is
requesting to be downloaded.
Reserved Reserved for future use. Must be set to 0 on
transmission and ignored on reception.
Home Agent Address(es) HA Address on Active/Peer HA that the
Standby/Peer HA is requesting to be
downloaded. There MUST be as many HA
addresses included as indicated by the
'NumHA' field. The HA address MAY be
set to 0.0.0.0 to specify that all HA
address bindings should be downloaded.
The 'NumHA' field should be set to '1'
in this case.
Identification An identification field used for
matching Binding Table Requests with
Binding Table Sync messages. Since
there may be many Binding Table Sync
messages associated with a Binding Table
Request message, only the low-order 32
bits are used to match the request and
reply messages.
4.4 Binding Table Sync is sent in response to a Binding Table Request.
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 | Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumBind | MoreBind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type 13 (Binding Table Sync)
Code Value indicating the result of the Binding Table
Request message. Valid code values are the following:
0 registration/message accepted
128 reason unspecified
129 administratively prohibited
130 insufficient resources
133 registration Identification mismatch
140 TBD HA-HA authentication failed
(HA_FAILED_AUTH - See Section 8)
141 TBD Binding Table Not Synced
(NOT_SYNCED - See Section 8)
Reserved Reserved for future use. MUST be set to 0 on
transmission and ignored on reception
NumBind Number of MN Bindings included in this Binding Table
Sync message
MoreBind Number of MN Bindings transmitted thus far,
including this message. Used
in conjunction with Identification field to
match Binding Table Sync and Binding Table
Sync Acknowledgment messages.
Identification Low-order 32 bits are used for matching Binding
Table Requests with Binding Table Sync messages.
All 64 bits are used to match Binding Table
Sync messages with Binding Table Sync
Acknowledgments.
Possible extensions that may be appended to the Binding Table Sync
message include the Mobility Binding Extension defined in Section 4.6
and the Security Association Distribution Extension defined in
Section 4.7. The information for each MN mobility binding is conveyed
via the Mobility Binding extension. If a valid Binding Table Request
is received by the Active/Peer HA, it MUST transmit the necessary
number of Binding Table Sync messages in order to download the entire
mobility binding table to the Standby/Peer HA. The Active/Peer HA may
include the Security Association Distribution Extension to send the SA
of an MN without a current binding (and thus, no Mobility Binding
Extension).
4.5 Binding Table Sync Acknowledgment
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 | Code | MoreBind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 14 (Binding Table Sync Acknowledgment)
Code Value indicating the result of the Binding Table
Sync message. Valid code values are the following:
0 registration/message accepted
128 reason unspecified
129 administratively prohibited
130 insufficient resources
133 registration Identification mismatch
140 TBD HA-HA authentication failed (See Section 8)
MoreBind Number of MN Bindings transmitted thus far,
including this message. Used.
in conjunction with Identification field to
match Binding Table Sync and Binding Table
Sync Acknowledgment message.
(copied from the Binding Table Sync message)
Identification A 64-bit number used for matching Binding
Table Sync messages and Binding Table Sync
Acknowledgments. Low-order 32 bits are used
to match the Binding Table Sync
Acknowledgment message with the original
Binding Table Request.
4.6 Mobility Binding Extension is used to convey the information for
a mobility binding between the Active/Peer HA and Standby/Peer HA(s).
The extension follows the long-extension format given in [4].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|r|T|x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granted Lifetime | Remaining Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions....
+-+-+-+-+-+-+-+-+-+
Type TBD (Mobility Binding Extension)
Sub-Type S, B, D, M, G, T flags as set in the
original RRQ from the MN
Length Length (in bytes) of the data field
within this Extension, including any
appended extensions other than the
HHAE. It does NOT include the Type,
Length and Sub-Type bytes.
Granted Lifetime Lifetime granted to MN
Remaining Lifetime Lifetime remaining until MN binding
expires
Home Address IP home address of MN
Home Agent IP address of MN's HA
Care-of Address IP address for the end of the tunnel
Identification Identification field in the original RRQ
Possible extensions appended to the Mobility Binding Extension include
the NAI extension [5], the Security Association Distribution Extension
defined in Section 4.7, and any Vendor Specific Extensions [7].
4.7 The Security Association Distribution Extension is used between
the Active/Peer HA and Standby/Peer HA(s) to convey information
about a security association. This extension follows the
long-extension format given in [4], and is optimized for the default
case, i.e., replay protection via timestamps, bidirectional SPIs,
'keyed' MD5 with prefix-suffix mode encryption. Hence, in most cases,
the optional fields will not be necessary. However, since it is
prudent to allow for flexibility in design, the optional
fields are provided.
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 | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|M|R|T|H|S| Reserved | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Key.... |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Algorithm (Opt)| Mode (Opt) | Replay (Opt) | Time (Opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address (Opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|M|R|T| Reserved | Key Length2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI2 (Opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Key2.... |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Algorithm2 (Opt)| Mode2 (Opt) | Replay2 (Opt) | Time2 (Opt)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions....
+-+-+-+-+-+-+-+-+-+
Type TBD (Security Association Distribution Extension)
Sub-Type Subtype indicating the type of security
association
1 MN-HA Security Association
Length Length (in bytes) of the data field
within this Extension, including any
appended extensions other than the
HHAE. It does NOT include the Type,
Length and Sub-Type bytes.
Home Address Present (H bit)
If H bit is set to 1, then the Home Address field
contains the IP address associated with the SPI to
index the mobility security association. If the
Security Association Distribution Extension is appended
after the Mobility Binding Extension, the IP address is
is inferred from the Home Address field in the Mobility
Binding Extension.
Directional SPI Present (S bit)
If S bit is set to 1, then the SPI2 field contains
the outbound SPI and SPI1 fields is the inbound SPI,
Otherwise, SPI1 is a bidirectional SPI.
Moreover, if the 'S' bit is set to 1, then the
second set of bit fields 'A M R T' and
'Key Length2' are present.
Algorithm Present (A bits)
If A bit is set to 1, then the Algorithm field
contains the algorithm. Default algorithm is
'keyed MD5'. The first instance of the bit
refers to SPI1 and the second instance (if
present) refers to SPI2.
Mode Present (M bits)
If M bit is set to 1, then the Mode field contains
the mode. Currently, there is no mode defined other
than the default 'prefix-suffix' mode. Future modes
may be supported. The first instance of the bit
refers to SPI1 and the second instance (if
present) refers to SPI2.
Replay Present (R bits)
If R bit is set to 1, then the Replay field contains
the replay protection mechanism being used.
By default, timestamp replay protection is used.
The first instance of the bit refers to SPI1
and the second instance (if present) refers to SPI2.
Time Present (T bits)
If T bit is set to 1, then the Time field contains the
replay protection range. The default replay
range is the HA configured replay range.
The first instance of the bit refers to SPI1
and the second instance (if present) refers to SPI2.
Reserved Reserved for future use. MUST be set to 0 on
transmission and ignored on reception
Key Length(2) Size of the key
SPI1 By default, this means the bidirectional SPI. If
S bit is set, then it is the inbound SPI value.
Key(2) Security key.
Home Address Optional field contains the IP address on the
Mobile Node.
SPI2 Optional field contains the outbound SPI.
Algorithm(2) Optional field with various algorithms
defined. Default is 'keyed MD5' algorithm.
1 HMAC MD5
2 HMAC SHA-1
Mode(2) Optional field with no value defined, default is
prefix-suffix mode.
Replay(2) Optional field contains the replay protection mechanism.
By default, timestamps are used.
1 Nonce
Time(2) Optional field contains the replay range.
The number of seconds can be specified in this field.
By default, HA configuration determines the replay range.
Note that the optional fields MUST be padded to be aligned on 4 octet
boundary.
The Security Association Distribution Extension may follow a Mobility
Binding Extension, or may be sent independent of a Mobility Binding
Extension.
5. Home Agent Considerations
The HAs within the Mobile IP Redundancy group MUST share an HA-HA
security association. (This is easily configurable by a network
administrator.) Furthermore, the HAs MUST be configured similarly and
support the same capabilities, e.g., GRE tunneling, broadcast capability.
All HA Redundancy messages MUST be checked for valid HHAE
authentication (HHAE is subject to the same conditions as the
MHAE defined in [1], and hence will not be repeated in this draft.
Moreover, the behavior in logging security violations is analogous.)
If authentication fails on a Binding Information Sync message, the
Standby/Peer HA MUST discard the message and respond with a Binding
Information Sync Acknowledgment with error code HA_FAILED_AUTH (see
Section 8). If authentication fails on a Binding Table Request
message, the Active/Peer HA MUST discard the message and respond with
a Binding Table Sync message with error code HA_FAILED_AUTH. In either
case, if there is an Identification mismatch as specified in [1],
error code 133 as defined in [1] MUST be returned and the behavior
specified in [1] should be followed. For all other messages, if
authentication fails, the receiving HA MUST silently discard the HA
Redundancy message.
If an HA receives a Mobile IP HA Redundancy message with error
code 133 (Registration Identification mismatch) in response to a
transmitted message, the HA should follow the behavior specified in
[1] and then retransmit the initial message. If a message with error
code HA_FAILED_AUTH is received instead, the HA should verify proper
security configuration, make any necessary adjustments, and attempt to
retransmit the initial message.
The Mobile IP HA Redundancy retransmission and acknowledgment scheme
between the HAs is not necessary when using a reliable transport
protocol for delivery of the HA Redundancy messages.
5.1 Binding Information Sync Message
When an Active/Peer HA accepts an RRQ from an MN, it MUST send the
Binding Information Sync message to the Standby/Peer HA(s).
This message contains the necessary information for the
Standby/Peer HA(s) to update/create the mobility binding.
If an Active/Peer HA sends a Binding Information Sync to a
Standby/Peer HA via an unreliable transport mechanism and does not
receive a Binding Information Sync Acknowledgment within a specified
timeout period, the Active/Peer HA MUST retransmit the Update message
to that Standby/Peer HA. The Active/Peer HA SHOULD retransmit the
Update message until either an Acknowledgment is received or a
preconfigured maximum number of tries have transpired. Note that
before a retransmission, the 'Remaining Lifetime' field should be
updated accordingly.
Upon receipt of an authenticated Binding Information Sync message, the
Standby/Peer HA MUST set up or modify the mobility binding conveyed in
the message. The HA processes the Binding Information Sync
message similar to an incoming RRQ, with the exception that the
'Remaining Lifetime' is already specified and there is no MHAE
authentication.
5.2 Binding Information Sync Acknowledgment Message
When a Standby/Peer HA receives a Binding Information Sync message via
an unreliable transport protocol, it MUST send a Binding Information
Sync Acknowledgment to the Active/Peer HA with the appropriate Code
value.
5.3 Binding Table Request Message
When an HA assumes the Standby/Peer HA role or sometime before it
assumes the role, it MUST send a Binding Table Request message to the
Active/Peer HA to request a download of the mobility binding table.
If a Standby/Peer HA sends a Binding Table Request message and does
not receive a Binding Table Sync message from the Active/Peer HA
within a specified timeout period, the Standby/Peer HA MUST retransmit
the request. The Standby/Peer HA SHOULD continue this process until
either a Binding Table Sync message is received or a preconfigured
maximum number of tries have transpired.
5.4 Binding Table Sync Message
If an Active/Peer HA receives an authenticated Binding Table
Request, it MUST respond with the necessary number of Binding Table
Sync messages in order to transmit its mobility binding table. Note
that the number of mobility bindings that can be sent in one Binding
Table Sync message is variable.
If the Active/Peer HA receives an invalid Binding Table Request
message or it cannot service the Binding Table Request message,
it MUST respond with a Binding Table Sync message with the
appropriate Code value.
5.5 Binding Table Sync Acknowledgment Message
When a Standby/Peer HA receives a Binding Table Sync message via an
unreliable transport mechanism, it MUST send a Binding Table Sync
Acknowledgment message back to the Active/Peer HA with the
appropriate code value.
6. Mobile Node Considerations
There are no modifications in behavior required by the MN.
7. Foreign Agent Considerations
There are no modifications in behavior required by the FA.
8. Error Values
The following table contains the Error Codes to be defined,
the value for the Code, and the Section in which it is first mentioned.
Error Name Value Section Purpose
---------- ------ -------- -------
HA_FAILED_AUTH 140 (TBD) 4 Convey failed authentication
of HHAE
NOT_SYNCED 141 (TBD) 4 HA is still in process of
syncing its mobility binding
table and thus, cannot respond
with a table download to a
Binding Table Request
9. IANA Considerations
The Mobile IP HHAE defined in Section 3 is a Mobile IP General
Authentication Extension subtype as defined in [4][6]. IANA should
assign a Sub-type value consistent with this number space. The Mobile IP
HA Redundancy Messages defined in Section 4 should be assigned a Type
value consistent with the number space defined in RFC 2002 [1]. The
Mobility Binding Extension defined in Section 4.6 and the Security
Association Distribution Extension defined in Section 4.7 are Mobile IP
extensions as defined in RFC 2002 [1], and should be assigned Type
values accordingly. The Error Codes in Section 8 should be assigned
appropriate values as outlined in RFC 2002 [1].
10. Security Considerations
All Mobile IP HA Redundancy messages are protected by the HHAE.
11. Acknowledgment
The authors wish to thank their colleagues Rod Schultz, Stefan Raab,
and Alpesh Patel for their insightful comments on the Mobile IP HA
Redundancy message and extension formats.
12. IPR
Cisco is the owner of US patent No. 6, 195, 705, which relates to this
proposed standard. If this proposed standard is adopted by IETF and
any claims of this or any other Cisco patents are necessary for
practicing this standard, any party will be able to obtain a license
from Cisco to use any such patent claims under openly specified,
reasonable, non-discriminatory terms to implement and fully comply
with the standard.
13. References
[1] C. Perkins, IP Mobility Support for IPv4, revised, Internet
Draft, Internet Engineering Task Force,
draft-ietf-mobileip-rfc2002-bis-04.txt, Work in progress, February 2001.
[2] T. Li, et. al., Cisco Hot Standby Routing Protocol (HSRP), Internet
Engineering Task Force RFC 2281, March 1998.
[3] S. Knight et. al., Virtual Router Redundancy Protocol, Internet
Engineering Task Force RFC 2338, April 1998.
[4] M. Khalil, et. al., Mobile IP Extensions Rationalization (MIER),
Internet Draft, Internet Engineering Task Force,
draft-ietf-mobileip-mier-05.txt, Work in progress, May 2000.
[5] P. Calhoun and C. Perkins, "Mobile IP Network Access
Identifier Extension", Internet Engineering Task Force RFC 2794,
March 2000.
[6] C. Perkins and P. Calhoun, "Mobile IPv4 Challenge/Response
Extensions", Internet Engineering Task Force RFC 3012, Nov. 2000.
[7] G. Dommety and K. Leung, "Mobile IP Vendor/Organization-Specific
Extensions", Internet Engineering Task Force RFC 3025, Feb. 2001.
Author's Addresses
Questions about this draft can be directed to:
Kent Leung
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
email: kleung@cisco.com
phone: +1 408 526 5030
Madhavi Subbarao
Cisco Systems, Inc.
7025 Kit Creek Road
Research Triangle Park, NC 27709
USA
email: msubbara@cisco.com
phone: +1 919 392 8387
Expires December 2001