Subject: Re: [MEXT] Fwd: I-D Action:draft-ietf-mip6-hareliability-06.txt

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 22 Oct 2010 13:40:31 -0700

Hi Raj,

Thanks for review. Some comments inline.

On 2010/08/06, at 13:48, <[email-masked]> <[email-masked]> wrote:

> 
> Hello,
> 
> Below is my review of the MIP6 HA reliability protocol I-D. I am
> skeptical about the usefulness of this protocol (please see comments
> in the review below). Publishing it as an experimental RFC may allow
> implementations and results from those can determine the viability in
> real-world deployments.

There are several implementations and experimentations for HA redundancy.
IMO, if it is useless, we shouldn't publish it as any RFC.
<SNIP>
> Comment: In section 2, the I-D says:
>     "For protecting the Home Agent Switch, the mobile
>   node should have IPsec Security Associations (SA) with the standby
>   home agent before any failover.  The mobile node may pre-establish
>   multiple IPsec SAs with all the home agents."
> 
> This is a pretty steep requirement. Not only does the MN have to
> establish an IPsec SA with the active HA, it now needs to have an SA
> with the standby HA(s) as well. This approach does not seem like a
> feasible one for real-world deployments.
> 
>     I-D states: "IPsec/IKE states synchronization is out of scope in this
>   document."
> 
> Given the lack of synchronization of the IPsec SA and IKEv2 state, how
> useful is the protocol if the MN has to re-establish an SA and then
> send the BU. 

IPsec/IKE sync is not the scope of MEXT. This was clear point. 
Unfortunately, there are no protocol-based state sync for IPsec/IKE at this moment.
Rather, each vender develop own solution. 

> VHARP seems to be a better way to provide the reliability. However the
> I-D states that VHARP is optional.

VHARP is an optional, because it requires IPsec/IKE functions (out of this document).

> - d/However, some Virtual Private Network (VPN) products have
>   proprietary IPsec/IKEv2 state synchronization among multiple boxes.
> 
> The above statement is irrelevant in the context of this I-D.
> 
> - s/This specification provides for a manual home agent management./
>  This specification enables manual intervention for home agent
>  management.
> 
> Comment:
> 
> In the case of HARP, the standby HA which takes over will send a
> message to all MNs and the MNs have to perform registration. If the HA
> is serving a very large number of MNs, this would be a difficult
> operation (flooding, delays, retransmissions).

This is warned in the document (section 4.5). 

  If there are a large number of mobile nodes served by the failed home
   agent, the overhead sending Home Agent Switch messages is high.  This
   overhead cannot be avoided if the active home agent suddenly stop
   serving mobile node because of unexpected reasons (crash, network
   trouble, etc).  However, if this switch over is operated under the
   administrative operation (maintenance, etc), the previous active home
   agent may continue serving the mobile nodes until the switch over is
   completed.  Until the mobile node sends a binding update to the new
   active home agent, it still sends the packet to the previous home
   agent.

> - In sec 4.4 s/It can carry several state information about /It can carry
>  multiple aspects of the state information associated with
> 
> Comment:
> 
> The I-D states: "When a home agent need to send the state of multiple
>   mobile nodes in a single state synchronization message (SS-REQ or
>   SS-REP), a Binding Cache Information option is used as a separator.
>   For each mobile  node, a Binding Cache Information option is placed
>   first, followed by any other options related to the mobile node if
>   necessary. "
> 
> If an HA serves a million or more MNs (as an example), the approach of
> sending state information presented in the I-D is suboptimal. There
> needs to be a better way to transfer bulk state. Has this been
> considered?

This is discussed. However, the optimization is required not for all the cases.
The optimization brings complexity. so there is pros & cons. 
We need to exchange binding states anyway for a million or more MNs .
Using other transport protocol (other than MH) may be beneficial in such case. 

> <SNIP>

> - In sec 4.5: 
>  "MUST use IPsec ESP to the Home Agent Switch message"
>  Why? The only thing is that the message needs to be securely
>  delivered. IPsec is one way of enabling security. But mandating that
>  this message MUST be secured by IPsec ESP is not required.

HAswitch message MUST be protected by ESP. This is clearly defined in RFC5142.

> 
> - Not clear what this sentence means: "MUST set only that standby home
>      agent address in the Home Agent Switch message". Rephrase.
> 
> Comment:
> In Sec 4.5 the I-D states:
> "When the failed home agent recovers from failure and would return to
>   the active home agent, it MUST re-establish IPsec SA with all the
>   mobile nodes.  All the mobile nodes lost IPsec SA with the home agent
>   when the failure is occurred.  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 Rekey message to all the mobile nodes
>   served by other home agents in the same redundant home agent set, and
>   includes the recovered home agent address in the Home Agent Addresses
>   field.
> "
> 
> I dont see how this is practical in the scenario where an HA serves
> millions of MNs. 
> 
> And it goes on to say:
> "Alternatively, the mobile node MAY  start a new IKE session with the
> recovered home agent."
> 
> Reducing the overhead of signaling has been a concern with
> MIP6. Imagine initiating IKEv2 signaling for a very large number of
> MNs and the associated overhead on various types of access networks.

As far as MIP6 stick to IPsec, this extra-signalings cannot be omitted..

> 
> - In sec 5: s/Non of operations /None of the operations described
> 
> Comment:
> In Sec 5.1 the I-D states:
> "A mobile node authenticates itself to two or more home agents and
>   creates IPsec SAs with them during bootstrapping.  When the active
>   home agent fails, another home agent can use the pre-existing SA to
>   notify the mobile node about the failure by sending a Home Agent
>   Switch mesage"
> 
> Reliability at the cost of establishing multiple IPsec SAs with
> multiple HAs for each MN is just not acceptable in many deployment
> environments. 

The second SA is necessary for sending HA switch messages. 

> Comment:
> 
> In Sec 7 the I-D states:
> "  All the messages newly defined in this document SHOULD be
>   authenticated by IPsec AH and MAY be encrypted by IPsec ESP. "
> 
> Mandating IPsec for securing the signaling between HAs is
> unnecessary. The choice of how the messages are secured should be left
> to deployments. The only requirement is that the reliability signaling
> messages be secured.

right. This is also stated in the document.

7.  Security Considerations

   All the messages newly defined in this document SHOULD be secured by
   IPsec ESP.  When a HA-HELLO message is multicast, the multicast
   extensions to IPsec [RFC-5374] is used.  In some operational
   scenarios, home agents are located in deeply core network and
   securely managed.  If there is a secure transport network between
   home agents, some of security mechanism can be turned off depending
   on administrative policy.

thanks,
ryuji

> 
> 
> 
> On 7/14/10 7:56 PM, "ext Ryuji Wakikawa" <[email-masked]> wrote:
> 
>> Hi all,
>> 
>> We submitted the newer version of HA reliability document with a lot of
>> editorial updates and small technical update such as IKE resumption
>> interaction support.
>> Please provide your comments, this document stays as WG doc for 4 years
>> without progress ...
>> 
>> thanks in advance,
>> 
>> ryuji
>> 
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: [email-masked]
>>> Date: 2010/07/12 01:30:03GMT-07:00
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: [MEXT] I-D Action:draft-ietf-mip6-hareliability-06.txt
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Mobility EXTensions for IPv6 Working Group
>>> of the IETF.
>>> 
>>> 
>>>      Title           : Home Agent Reliability Protocol (HARP)
>>>      Author(s)       : R. Wakikawa
>>>      Filename        : draft-ietf-mip6-hareliability-06.txt
>>>      Pages           : 43
>>>      Date            : 2010-07-12
>>> 
>>> The home agent can be a single point of failure when Mobile IPv6 and
>>> its compatible protocols are operated in a system.  It is critical to
>>> provide home agent reliability in the event of a home agent crashing
>>> or becoming unavailable.  This would allow another home agent to take
>>> over and continue providing service to the mobile nodes.  This
>>> document describes the problem scope briefly and provides mechanisms
>>> of home agent failure detection, home agent state transfer, and home
>>> agent switching for home agent redundancy and reliability.
>>> 
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-06.txt
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>