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

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 02 Aug 2010 15:52:55 +0200

Dear Ryuji,

Thanks for tyour reply. Some comments below.

On Mon, 2010-07-26 at 11:43 +0200, Ryuji Wakikawa wrote:
> Hi Carlos,
> 
> Thanks for your review. I finally receive comments in the MEXT list;-)
> 
> On 2010/07/24, at 22:40, Carlos Jesús Bernardos Cano wrote:
> 
> > Hi Ryuji, all,
> > 
> > I've read the draft. Overall it seems OK to me. I have some comments and
> > questions (in no particular order):
> > 
> > Technical:
> > - Page 4: "if a home agent loses the binding cache state, due to failure
> > or some other reason, it results in a loss of service for the mobile
> > nodes", the draft covers more cases, right? I mean, (V)HARP can be used
> > to provide reliability against a HA that loses the binding cache (e.g.,
> > because it hangs/halts/breaks down), but also for example against a home
> > agent that stops being reachable because connectivity problems (that can
> > be just local to the HA or to the home link where the HA is attached
> > to). I think this should be better captured in the Introduction.
> 
> I describe the most typical scenario of this protocol.  I will clarify it with your suggestion.
> 
> 
> > - Page 5: Home Agent Preference: for the case of VHARP, I guess all the
> > HA of the set share the same value for DHAAD, but can use a different
> > one for VHARP purposes, right? I think this is not very clear.
> 
> It's up to the operation. 
> Admin can configure the different set of preferences for HARP operation or use the same preference value of DHAAD. 
> 
> > - Page 6: Availability of a redundant home agent set. From current text
> > I understand that standby home agents cannot be added for an MN after it
> > bootstraps, but I don't think that is right. Am I not properly
> > understanding that piece of text?
> 
> From the MN point of view, we just use the MIP6 bootstrapping mechanism (split and integrated one) for HA addresses discovery.
> MN should re-discover the HA addresses by looking up DNS again, etc...
> From the HA point of view, the new HA start sending a HELLO to the HAs in the same HA set.

Then I think it is not very clear in the text. From your response, I
understand that for VHARP, HAs can be added anytime, as for HARP, the MN
would need to re-discover the HAs in order to add some after
bootstrapping, right?

> 
> 
> > - Page 7: The text below the "Considerations of IPsec/IKE transfer" item
> > seems to me contradictory with the text above that and also on page 9.
> > Is IPsec/IKE state synchronization in scope or not of the document?
> 
> It is out of scope in this document.

Then I'd suggest to fix the text to make it clear.

> 
> 
> > - Page 7: Secured Message Exchanges: why MAY there? I'd say MUST be
> > authenticated (and MAY be encrypted).
> 
> We had comments that HAs are often placed in the secured link (deep in the operators network).
> In these network, the security is just redundant since the link is securely operated.
> That's why we relax the security level.

Then I'd explain this in the text.

> 
> 
> > - Page 8: IMHO, it is not clear in the draft how standby home agents
> > coordinate to ensure that only the one with the highest preference value
> > takes over.
> 
> The pref value is exchanged by HELLO, therefore, the HA whose pref is highest should start taking over.

How are possible conflicts solved? what happens if two HAs
simultaneously try to take over?

> 
> > - Page 12: for the scenario depicted in Figure 5, how would the HAs in
> > region-2 know that the HAs in region-1 have failed and it is not just
> > that the connectivity between region-1 and region-2 is broken? It might
> > be possible that region-1 is just not reachable from region-2 but still
> > from the rest of the Internet.
> 
> We assume the internal connectivity (between Reg1 and Reg2) is stable.

Isn't that a strong requirement? Anyway, I think this should be
explicitly mentioned in the text.

>  
> 
> > Editorial:
> > - IMO, References to RFC3775 should be updated to point to RFC3775bis.
> 
> -bis is still in draft. I though I should wait for it being RFC.

I'm not sure it makes sense to submit a draft that references an RFC
that is becoming obsolete anytime soon.

Thanks,

Carlos

> 
> > - Page 4: /s/Home Agent Reliability protocol (HARP)/ Home Agent
> > Reliability Protocol (HARP)/
> > - Page 4: /s/refers to both a mobile node/refers both to a mobile host/
> > - Page 4: The definitions of HARP and VHARP do not seem really
> > definitions to me. I think they should be rewritten slightly.
> > - Page 4: /s/A home agent which will serve the mobile nodes/A home agent
> > which can serve the mobile node/
> > - Page 6: /s/Reliable Home agent service/Reliable home agent service/
> > - Page 8: I'd rewrite the paragraph starting "If the active home agent
> > fails"... as it does not seem completely clear to me. For example, it
> > talks about exchanging information with the active home agent in case
> > the active home agent fails... how can a standby home agent exchange
> > info with a node that has failed?
> > - Page 8: Figure 1, IMO, the rows used to indicate HA1-addr and HA2-addr
> > may be misleading, as they might seem messages.
> > - Page 14: /s/SHOULD NOT be set to source and/SHOULD NOT be set to
> > source or/
> > - Page 15 and more: /s/multicasted/multicast/
> > - Page 15: The line "Performed the following functions when a HARP
> > message is received" needs proper context.
> > - Page 17 and more: /s/unicasted/unicast/
> > - Page 17: /s/following verification/following verifications/
> > - Page 18: /s/The standby home Agent/A standby home agent/
> > - Page 19: /s/When a home agent need to send/When a home agent needs to
> > send/
> > - Page 20: "If a state synchronization message is unicasted" --> in the
> > previous paragraph it is stated that "A state synchronization message is
> > only unicasted", so the "If" seems a bit weird here.
> > - Page 23: It says "If a virtual MAC address [...] is used", but in page
> > 25 it says that "it SHOULD use a virtual MAC address".
> > - Page 26: /s/non of operations/none of operations/
> > - Page 27: /s/a mobile node need to manage/a mobile needs to manage/
> > - Page 28: /s/it MUST proceed/it MUST process/
> 
> I will fix these editorial errors. 
> 
> Thanks again!
> 
> regards,
> ryuji
> 
> 
> > 
> > Regards,
> > 
> > Carlos
> > 
> > On Wed, 2010-07-14 at 17:56 -0700, Ryuji Wakikawa 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.
> >>> _______________________________________________
> >>> MEXT mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/mext
> >> 
> >> _______________________________________________
> >> MEXT mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mext
> > 
> > -- 
> > Carlos Jesús Bernardos Cano     http://www.netcoms.net
> > GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> 

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: <[email-masked]>
Date: Fri, 6 Aug 2010 22:48:10 +0200

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.

-Basavaraj

Comments:

In abstract:
- s/compatible protocols/associated supporting protocols

In Intro:
- s/compatible protocols/derivatives

- s/switch a home agent in case of the active home agent
  failure./switch service from an active to a standby home agent in
  the case of an active HA failing.

The definition for HARP is not clear. Proposed change:
s/     Providing reliability by using multiple home agents with
      individual home agent addresses.  It requires binding re-
      registration to the new home agent./
      A protocol between Mobile IPv6 Home agents which provides
      reliability by moving state and service from an active home
      agent to a standby in the case of the active home agent
      failing. 

s/ A group of an active and standby home agent(s)/ A grouping which
   includes an active and standby home agent(s).

s/HARP assumes multiple home agents placement on a same home link or
   different links and groups them into a redundant home agent
   set./HARP works when one or more home agents are provisioned on a
   home link or different links and these are grouped into a redundant
   home agent set.

s/because Mobile IP adapts IPsec as its security mechanism for
      signaling./because mobile IPv6 relies on IPsec for securing
      the signaling and optionally user plane traffic.

s/all these information per mobile node is vanished/all state
      information associated with an MN is lost.

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. 

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

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

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

- s/In VHARP, home agent fail-over is completed without mobile nodes'
   binding re-registration. / In the case of VHARP, home agent
   fail-over is accomplished without the mobile nodes having to perform
   re-registration.

- Sec 4.4.1 
  Question: This information is stored somewhere in a standby home
  agent.
  Where? Just delete the sentence.

- s/A state synchronization message is only unicasted./A state
  synchronization message is unicast.

- s/message is unicasted , it SHOULD be authenticated by IPsec AH and
  MAY be encrypted by IPsec ESP./message is unicast, it SHOULD be
  secured (using IPsec or other means).

- s/Which security mechanism is used depend on the operational
  policy./The choice of security mechanism used depends on the
  operational model of the network.

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

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

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

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.

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.