Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-mip6-hareliability-04

[[e-mail] (Arnaud Ebalard)]

Hi,

Some comments on an inline version of draft-ietf-mip6-hareliability-04
are provided below.

>From a general standpoint, I think the document is useful and provides
a sensible solution to the problem while taking into account the various 
difficulties and possible cases. 

That been said, at some point during the reading, I started considering
that the most interesting review would be (as usual) from someone that
would have tried implementing *and testing* the protocol. Ryuji, are you
aware of some tentative implementation or is it only a pure spec at the
moment?  

Just a thought before starting: I understand the technical difficulties
to implement the HA Virtual Switch functionality compared to the HA Hard
Switch one but I think it is worth the effort both from a user (no
additional traffic, no need for additional computations, code and
logic), traffic and a management perspective.

>    Home Agent Hard Switch
>
>       In the Home Agent Hard Switch, IPsec/IKE states synchronization is
>       not required.  The home agents are addressed by different IP
>       addresses.  When an active home agent fails, a mobile node will
>       receive a notification (Home Agent Switch message [RFC-5142]) from
>       a standby home agent, and send a Binding Update to the standby
>       home agent.  In order for the mobile node to receive the Home
>       Agent Switch message securely from the standby home agent, the
>       mobile node needs to establish an IPsec SA with both the active
>       and the standby home agents beforehand.

I understand the need for the SA to be available beforehand. Some
questions though:

- I guess that the pair of SA is similar to the ones negotiated between
  the HA and the MN, i.e. that they reference the HoA, not the CoA,
  don't they?
- When the MN moves and the CoA changes, the IKE_SA on both sides
  (MN and standby HA) need to be updated. On the MN side, this is
  feasible because the MIPv6 module is aware of the handover and of the
  new CoA but because no exchange occur *directly* between the MN and
  the standby HA, this is trickier on the standby HA side. Is it
  expected that the handover information received from the state
  synchronization with the active HA be used for that purpose? If this
  is the case, it should be stated/described. If not, how is it done?
  Full rekeying initiated by the MN?

>    State Synchronization
>
>       The information for mobile nodes must be able to be synchronized
>       between an active home agent and standby home agents.  This
>       includes the Binding Cache, AAA information, other Mobile IPv6 and
>       NEMO related information.  Note that the Home Agent Reliability
>       protocol exchanges only running states of mobile nodes.
>       Therefore, we do not have any specific operation for synchronizing
>       the configuration information.  For instance, when Mobile IPv6 is
>       operated with Authentication protocol, the synchronizing the
>       configurations of the Authentication protocol is out of scope in

        "the synchronizing the configurations": first 'the' should be
        removed  

>       this document.  Operators MAY correctly configure in multiple home
>       agents.

        Maybe it's just my english, but I do not understand last
        sentence.

> 4.1.  Home Agent Virtual Switch
>
>    A mobile node remains unaware about the change in the active home
>    agent since the home agents have replicated all session state
>    including IPsec/IKE/ESP states.  IPsec/IKE/ESP state transfer is out
>    of scope of this document.

     What about changing 'IPsec/IKE/ESP' to 'IPsec/IKE'

> 4.2.  Home Agent Hard Switch
>
>    The overview of the Home Agent Hard Switch is shown in Figure 2.
>    This mode is not transparent to the mobile node when the active home
>    agent failure occurs.
>
>
>      MN      HA1(active)    HA2(Standby)
>       |           |           |
>       |<--------->|           | 1. IKE exchange (with HoA assignment)
>       |---------->|           | 2. Binding Update
>       |<----------|           | 3. Binding Acknowledgment
>       |<--------------------->| 4. IKE exchange (without HoA assignment)
>       |           |           |
>       |           |<--------->. 5. State exchanges (binding cache)
>       |           |           |
>       |           X           |  HA1 FAILURE
>       |           X           |
>       |           X<----------| 6. Failure Detection
>       |<----------------------| 7. Sending Home Agent
>       |           X           |          Switch message
>       |<--------------------->| 8. Binding Registration
>       |           X           |
>       |           X           |    RECOVERY COMPLETE
>
>
>                Figure 2: Overview of Home Agent Hard Switch
>
>    The mobile node establishes IPsec/IKE state with all the home agents
>    in the redundant home agent set beforehand (1 and 4), however it
>    registers its binding only with the active home agent (2 and 3).
>    When an active home agent fails, a standby home agent uses a pre-
>    existing IPsec SA to notify the mobile node about the failure by
>    securely sending a Home Agent Switch message.  In order to discover
>    home agent addresses, two different mechanisms are defined, as
>    described in Section 9.4.1.  The active home agent synchronizes the
>    required states of the mobile nodes, such as Binding Cache and AAA
>    information, with other standby home agents periodically (5).  The
>    mobile node MUST NOT request a home address(es) assignment through
>    the IKE exchange to the standby home agent when it establishes an SA
>    with it (4).
>
>    When the standby home agent detects the failure of the active home
>    agent (6), it sends a Home Agent Switch message to all the mobile
>    nodes that were registered with the failed home agent (7).  The Home
>    Agent Switch message must be encrypted by a pre-established IPsec SA.
>    After the switch message, the mobile node MUST send a binding update
>    to the new active home agent in order to update the Mobile IPv6
>    tunnel end points (8).

     s/end points/endpoints/

>          2: Reply-Ack
>
>          The message is called State Synchronization Reply-Ack (SS-ACK)
>          and is used to acknowledge to the SS-REP.  This message is

                       s/acknowledge to/acknowledge/

>       *  IP Address Option (Sub-type: Home Address) defined in [RFC-
>          5268].  If a home agent wants the Binding Cache information for
>          a particular mobile node, it includes the mobile node's home
>          address in an IPv6 Address Option.  If a home agent want to

                                                               wants to

>          solicit all the active mobile nodes' states, it can include the
>          unspecified address (0::0) in an IPv6 address option.

                                s/0::0/::/

> 5.1.4.  Home Agent Switch Message
>
>    This message is defined in Section 9.4.3.  The Home Agent
>    Reliability protocol extends this message for the Home Agent Hard 
>    Switch. 

     Waht about changing those two sentences for the following:

     "This message is defined in [RFC5142]. The Home Agent Reliability
     protocol extends this message for the Home Agent Hadr switch, as
     described below. Its precise use in the context of HA reliability
     mechanism is defined in section 9.4.3."

>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                       |# of Addresses |I|  Reserved   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       .                      Home Agent Addresses                     .
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                        Mobility options                       .
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                     Figure 7: Home Agent Switch Message
>
>    IPsec Re-key (I)
>
>       The IPsec re-key (I) bit is set to indicate that the mobile node
>       SHOULD start an IPsec re-key with the home agent specified in the
>       Home Agent Addresses field.  This flag is used when a failed home
>       agent recovers and needs to re-establish IPsec SA/IKE state with a
>       mobile node.  When this flag is set, the mobile node does not
>       switch the home agent, but only re-key the SA.

If I understand things correctly, when a Home Agent Switch message is
sent to a MN by a standby HA, it means that the MN should send a binding
update to the standby HA (referenced in the Home Agent Addresses field
of the message), *except* when the I flag is set in the message which in
that case means that the MN should perform an IKE negotiation with the
HA in the Home Agent Addresses field *but* not send a binding update to
that HA.

If that is correct, this breaks the semantic of the message. In that
case, having a simple flag changing the whole purpose of the message
looks like a bad idea.

I reread RFC5142 (more precisely the end of section 5.1 and the content
of section 6.1 describing how the MN should process the message). 2
cases are described (from a MN perspective):

- Home Agent Switch message is sent by a HA which is our current HA,
  containing one or more addresses which should be considered in
  order. In all cases, the MN is expected to send a de-registration
  binding and send a BU to the first HA of the list.
- Home Agent Switch message is sent by a HA which is not our current HA:
  the message SHOULD contain one address, which is the address of the
  sender of the message, which implies the MN should switch to the
  sender of the message, i.e. send a BU.

Current proposal in section 5.1.4 of the draft would basically add the
additional third case:

- Home Agent Switch message is sent by a HA (standby or not based on
  what is in 9.4.3, but chances are high is is the active HA) *with* I
  flag set *and* an address different from the one of the sender. In
  that case, the MN does not switch, it just setup an IPsec SA with the
  addresses in the message.

In the context of Hard Switch mechanism, I understand the need to have
the MN set up SA with the reborn HA (in order for that standby HA to be
able to send switch messages later in the process). But IMO that "Please 
rekey" feature needs a different (MH) container.

>    Reserved
>
>       The reserve field is reduced from 8 to 7 bits

       s/reserve/reserved/

> 5.2.2.  Binding Cache Information Option
>
>    The binding cache information option has an alignment requirement of
>    8n+2.  The Binding Cache Information option is only valid in a State
>    Synchronization message.  Its format is as follows:
>
>         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 = TBD  | Length = 40   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Flags                |       Sequence Number         |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Lifetime             |          Reserved             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                        Home Address                           |
>        +                                                               +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +                        Care-of Address                        +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        .                                                               .
>        .                                                               .
>        .                Mobile Network Prefix Option                   .
>        .                                                               .
>        .                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                 Figure 8: Binding Cache Information Option
>
>    The fields of Home Address, Care-of Address, Flags, Sequence Number,
>    and Lifetime are copied from the registered binding of a particular
>    mobile node or mobile router.  The 8-bit Reserved field MUST be set

                                       16-bit

> 5.2.3.  AAA Information Option
>
>    This option is used to carry the AAA state of the mobile node's
>    Mobile IPv6 sessions.  The AAA state information can be carried in
>    RADIUS or Diameter AVP formats including the user and session info.
>    This information option is only valid in a State Synchronization
>
>         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 = TBD  |   Length      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        .                                                               .
>        .                                                               .
>        .                        AAA AVPs                               .
>        .                                                               .
>        .                                                               .
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                Figure 9: Vendor Specific Inforamtion Option

                                           Information

> 7.  Home Agent Common Operation
>
> 7.1.  Home Agent List Management
>
>    In Mobile IPv6 [RFC-3775], each home agent periodically sends router
>    advertisements with the Home Address Information option [RFC-3775]
>    when there are multiple home agents present on a link.  This
>    information is managed in a home agent list.  For the Home Agent
>    Reliability Protocol, HA-HELLO messages are used to manage the home
>    agent list.  There are several reasons to use HA-HELLO message
>    instead of Router Advertisement such as:
>
>    1.  In the Home Agent Virtual Switch mode, if the standby home agents
>        send unsolicited Router Advertisements to the home link, the
>        mobile nodes attached to the home link are aware of the presence
>        of standby home agents.  However, the standby home agents must be
>        hidden until the active home agent fails.  HA-Hello messages are
>        exchanged only between home agents.
>
>    2.  As shown in Section 6.1, standby home agents are not always
>        configured at the same link.  In this case, Router Advertisements
>        cannot be sent to the recovery link unless the home link and the
>        recovery link are connected (ex.  L2TP).  HA-HELLO can be sent
>        beyond the link.
>
>    3.  The Home Agent Reliability protocol defines to manage

                                         s/defines/is defined to/

>        additional information such as Group ID and Active/Standby
>        Status of the home agents in the home agent list.

>    In Mobile IPv6, Router Advertisement are to carry the home agent
>    information to both mobile nodes on the home link and the home
>    agents.  On the other hand, in the Home Agent Reliability protocol,
>    HA-Hello is to exchange the information among the home agents and the
>    Router Advertisement is used to notify the information to the mobile
>    nodes.

     nodes on the home link.

> 7.3.2.  Sending Hello Message
>
>    Each home agent periodically sends HA-HELLO for the home agent's
>    failure detection.  The interval time is configured at each home
>    agent.  Each home agent MUST also send a HA-HELLO in following case:
>
>    1.  when a home agent receives a HA-HELLO with the R-flag set
>
>    2.  When a home agent detects its local information such as home
>        agent preference, home agent lifetime, and registration status
>        change.
>
>    3.  When a new home agent boots up, it SHOULD solicit Hello messages
>        by multicasting a Hello message with the R-flag set in parallel
>        with sending its own Hello message.
>
>    When a home agent sends HA-HELLO, the following rule MUST be applied.

>    o  Whenever a home agent generates HA-HELLO, it MUST increment in

                                              s/increment in/increment/

>    o  If the source IPv6 address of HA-HELLO is not belong to one of

                                    s/is not belong/does not belong/

>    o  If the Group ID field of the received HA-HELLO and the receiver's
>       Group ID is different, HA-HELLO MUST be discarded.  HA-HELLO MUST
>       NOT be sent to home agents whose Group ID is different from the

            s/sent/unicasted/

>    o  If the Sequence Number value in the HA-HELLO is equal to or less
>       than the last received Sequence Number value stored in the home
>       agent list entry, the HA-HELLO MUST be discarded.

        Except when the number wraps, I imagine.

> 7.4.1.  Requesting State of a Particular Mobile Node(s)
>
>    When a home agent needs the state information for a particular mobile
>    node or a subset of mobile nodes, it sends a SS-REQ message
>    constructed as follows:
>
>    o  It MUST set the Type field to 0 (Request).
>
>    o  It MUST set a random value in the Identifier field that does not
>       coincide with any other currently pending Requests.
>
>    o  It MUST include an IP address mobility option(s) which subtype is
>       set to the home address if the target is mobile node(s).
>
>    o  It MUST include a Mobile Network Prefix mobility option(s) for
>       mobile router(s).
>
>    o  It MUST set the unspecified address (0::0) in the Home Address

                                            s/0::0:/::/

> 7.4.2.  Synchronizing State
>
>    State synchronization messages SHOULD be sent when:
>
>    1.  The active home agent receives SS-REQ.
>
>    2.  The active home agent creates a binding cache entry for a
>        particular mobile node.
>
>    3.  The active home agent deletes a binding cache entry for a
>        particular mobile node.
>
>    The active home agent MAY additionally send state synchronization
>    message in following cases:
>
>    1.  The active home agent update the state information for all
>        sessions that changed since the last update in a periodic
>        interval
>
>    2.  Only for the Home Agent Virtual Switch mode, the active home
>        agent updates a binding cache entry for a particular mobile node
>        whenever the binding cache entry is updated.  In the Home Agent
>        Hard Switch mode, standby home agents only need the mapping
>        information of a home address of the mobile node/router and the
>        home agent address of the active home agent to which the mobile
>        node/router is currently registering.  This mapping is used to
>        send a Home Agent Switch message.
>
>    If an active home agent sends a State Synchronization message
>    whenever the local state information changes, such as a binding cache
>    change, the number of the State Synchronization messages sent can be
>    quite large.
>
>    All the state information of the requested mobile nodes is stored in
>    the SS-REP.  Following rules must be applied when the active home
>    constructs SS-REP.

                                                       the active home
     agent constructs SS-REP. 

>    o  If the unspecified address is found in the Home Address mobility
>       option carried with the SS-REQ, the active home agent MUST return
>       the state of all the active mobile nodes and mobile routers by the
>       SS-REP. The IP fragmentation can be occurred depending on the
>       total size of all the states.

     What about changing last sentence by:

     "The message may be fragemented depending on the total size
     needed to carry all states"


> 7.5.2.  Active Home Agent becomes in-active

                                    inactive

> 7.6.  Interworking with VRRP

     not that familiar with VRRP, I skipped the section.

> 8.1.  Consideration of Routing and Neighbor Discovery Protocol
>
>    This section gives a brief explanation of how a home agent interacts
>    with routing and Neighbor Discovery Protocol (NDP) when the Home
>    Agent Virtual Switch mode is used.
>
>    When a standby home agent becomes active in the Home Agent Virtual
>    Switch mode, it MUST start to advertise the home agent address and
>    the home prefix of the home addresses serviced by the redundant home
>    agent set into the routing infrastructure.  This operation is
>    normally done using a route selector such as BGP or an OSPF modifier.
>    For example, we can use the AS_Path prepend operation for BGP, and
>    the Metric field in OSPF for the route selection.  When each home
>    agent participates in OSPF routing, each home agent should be
>    configured with the appropriate metric matched to the home agent
>    preference value.  When the active home agent fails, OSPF detects the
>    failure and can dynamically switch the route to the standby home
>    Agent based on the OSPF cost value.  If this cost conflicts with

                                                 s/cost/creates/

> 9.1.  Home Agent Recovery
>
>    After detecting the active home agent has failed, the standby home
>    agent whose preference value is the highest MUST take over the failed
>    home agent.  The standby home agent MUST send a Home Agent Switch
>    message to all the mobile nodes that were registered at the failed
>    home agent as described in Section 9.2, using the pre-established
>    IPsec SA.  The standby Home Agent MUST set its own address in the
>    Home Agent Address field in the Home Agent Switch message so that it
>    will receive the binding update from the mobile node as an
>    acknowledgment of the sent Home Agent Switch message.  The home

     acknowledgement

> 9.2.  Sending Home Agent Switch Messages
>
>    The standby home agent which is going to be active MUST send a Home
>    Agent Switch message as defined in [RFC-5142] to all the mobile nodes
>    that were being served by the failed home agent.  The Home Agent
>    Switch message must be securely sent to the mobile node by using
>    IPsec ESP.  The standby home agent MUST include only its own home
>    agent address in the Home Agent Switch message.

     When it gets active. At the moment, when I flag is set, it contains
     the address of another HA.

>    When a failed home agent recovers, it MUST re-establish an IPsec SA
>    with each mobile node served by its redundant home agent set.
>    Otherwise, it cannot be either a standby or active home agent for the
>    mobile nodes.  Therefore, as soon as the active home agent detects
>    the recovery of the failed home agent, it sends a Home Agent Switch
>    message with the I-flag set to all the mobile nodes serving by other

                                                      s/serving/served/

> 9.4.2.  IKE/IPsec pre-establishment to Home Agents
>
>    After a mobile node obtains multiple home agent addresses, it needs
>    to trigger multiple IKE exchanges with the multiple home agents
>    selected from the home agent list.  Since both IKEv1 and IKEv2 can be
>    used to bootstrap Mobile IPv6, this solution does not introduce any
>    new operations to co-operate with IKEv1 or IKEv2.  It should initiate
>    IKE for home agents as soon as home registration is complete.
>
>    The mobile node MUST follow the standard IKEv2 exchange in the
>    bootstrapping solution of the split scenario [RFC-5026].  Home
>    Address configuration maybe also be included, if necessary, for the
>    first IKE exchange.  After its Home Address is assigned or approved
>    by the first home agent, mobile node SHOULD register itself with the
>    second home agent with IKE using the same Home Address.  Therefore,
>    no home address configuration should be used in the second IKEv2
>    procedure.  Note that the mobile node only sends a Binding Update
>    message to the first home agent.

I have the feeling that this subsection should be extended in order to
describe what happens when a handover occurs, from an IKE standpoint
(IKE_SA management/update on both sides) between the reborn HA and the
MN.

> 9.4.3.  Receiving Home Agent Switch message
>
>    A mobile node must follow the operation specified in [RFC-5142] when
>    it receives a Home Agent Switch message.
>
>    If the I-flag is set in the received Home Agent Switch message, the
>    mobile node MUST re-key the SA with the home agent addresses stored
>    in the Home Agent Addresses field.  The mobile node MUST NOT change
>    its active home agent when the I-flag is set.  If the home agent
>    address is not known from the bootstrapping described in
>    Section 9.4.1, the mobile node MUST NOT start an IKE session with the
>    unknown home agent.  Instead, it SHOULD re-start home agent discovery
>    again to update its home agent address information.
>
>    When the mobile node receives a Home Agent Switch message without
>    I-flag set, and if the message contains the IPv6 address of a standby
>    home agent, it MUST select the standby home agent in the switch
>    message as the active home agent and send a new Binding Update
>
>    message to it.  Note that the standby home agent address in the Home
>    Agent Switch MUST be equal to the sender of the Home Agent Switch
>    message.  The standby Home agent expects the Binding Update as an
>    acknowledgment of the Home Agent Switch message.  The mobile node
>    already has a pre-established SA with the standby home agents and
>    should use that SA to send the Binding Update.  If the address stored
>    in the Home agent address field is different from the sender, the
>    mobile node MUST send a binding update to the sender.

I already provided some comments about the content of that section at
the beginning of the review.

> 10.  Security Considerations
>
>    Since Mobile IPv6 operation requires ESP in transport mode between
>    the mobile node and the home agent, we will discuss the ESP field
>    synchronization issues between the mobile node and the redundant set
>    of home agents.  This synchronization is required only for Home Agent
>    Virtual Switch mode.  Most of fields should be synchronized based on
>    [RFC-4301].  The ESP header has the following fields:
>
>    SPI
>
>       This field identifies the SAD at the receiver.
>
>       The mobile node negotiates only one IPsec SA.  Hence, the SPI
>       value will remain unchanged upon home agent failover.
>
>    Sequence Number
>
>       This field is used for "anti-replay" feature of ESP.  The
>       transmitter must include this monotonically increasing number.
>       The receiver may process the sequence number based on local
>       policy.
>
>       The mobile node and the redundant home agent set will have the
>       same set of sequence numbers for transmit and receive.  Hence,
>       synchronization of the sequence number field is mandatory in this
>       mode of operation.
>
>       The SA1, SA2, SA3, SA4 could be synchronized between the home
>       agents as these messages are not sent continuously.  Moreover for
>       the Binding Update case, if the mobile node is in the middle of
>       sending a Binding Update to an active home agent for a binding
>       refresh, and the active home agent is not available at that
>       moment, the mobile node will not get any response from the active
>       home agent.  After a standby home agent becomes active, the mobile
>       node will retry and it will receive the Binding Update from the
>       mobile node with a sequence number that is +n from its last known
>       sequence number for SA1.  For the Binding Acknowledgment case
>       (SA2), the standby home agent SHOULD add a random number to the
>       last known sequence number over and above the replay window to
>       ensure that the packet passes the replay check at the mobile node.
>       The same applies to HoTi and HoT messages with SA3 and SA4.  Note
>       that this windowing of the sequence numbers for Mobile IPv6
>       signaling is only needed to cover the corner cases when Binding
>       Update or HoTi is in-flight and the active home agent fails.
>
>       The technique explained above should work for user data packets if
>       ESP is used to encrypt user data traffic as well.  The actual
>       switchover time and the routing infrastructure convergence time is
>       the only latency that the user may perceive.
>
>    Initialization Vector
>
>       Since the Initialization Vector will be delivered in each exchange
>       between a mobile node and home agent, this field is not
>       necessarily synchronized between home agents.
>
>    Others
>
>       Other fields should be synchronized based on RFC4301 [RFC-4301]
>
>    In the Home Agent Hard Switch mode, the standby home agent needs to
>    send a Home Agent Switch message using IPsec encryption.  Since the
>    mobile node has pre-established an IPsec SA with both the active and
>    standby home agents, the standby home agent can send the message to
>    the mobile node with the pre-established IPsec SA.

I wonder if previous text really belongs to the "Security
Considerations" section. IMHO, it should be in a dedicated section. 

Cheers,

a+