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