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

[Ryuji Wakikawa <[e-mail]>]

Hi Arnaud,


I submitted the new version (-05).
Most of your comments were solved in this version.

Please review it and confirms the update (see the inline messages, I  
list up the changes).


On 2009/05/04, at 6:10, Arnaud Ebalard wrote:

> 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?


see section
        9.5.3.  Synchronizing State: K-bit treatment . . . . . . . . .  
37


>
<SNIP>
>>       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.

see the following sections.

        5.1.4.  Home Agent Rekey Message . . . . . . . . . . . . . . .  
17
       9.3.  Sending Home Agent Rekey  
Messages  . . . . . . . . . . . . 36
        9.5.5.  Receiving Home Agent Rekey message . . . . . . . . . .  
38

>
>> 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.

I added new sections
        9.5.3.  Synchronizing State: K-bit treatment . . . . . . . . .  
37
        9.5.5.  Receiving Home Agent Rekey message . . . . . . . . . .  
38


>
>> 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.

This text still stay in the Security Consideration section.
I prefer keeping this in the security consideration, because it is  
just informational text.

thanks
ryuji


>
> Cheers,
>
> a+
>