Re: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt

[Francis Dupont <Francis.Dupont@xxxxxxxxxx>]

 In your previous mail you wrote:

   Hi Francis,
   
   Just re-reading emails before the WG meeting tomorrow and decided I 
   should comment on this.
   
   First, thanks for the comments, I do have a few questions.
   
   Francis Dupont wrote:
   > Comments about draft-ietf-mip6-ha-switch-03.txt:
   > 
   >  - I really like the draft as I believe the service it provides is needed
   >   and is a major missing piece for MIPv6 in the real world but I have
   >   a critical concern with it: it collides with the IPsec failover
   >   activity, i.e., we could get two competiting mechanisms for the same
   >   thing. So this issue must be solved before going further:
   >    * obviously the basic mechanisms are the same: the server sends to the
   >     client a "look-somewhere-else" message with a list of potential "better"
   >     servers.
   >    * when the message is delivered to the MIPv6 stack the information
   >     must be propagated IKE, when it is deliveded to IKE (for instance by
   >     a new notification) it must be propagated to the MIPv6 stack: in all
   >     cases there must be an API between both.
   >    * when the two mechanisms overlap they don't handle exactly the same
   >     cases so we'll need a way to extend the coverage of the chosen one.
   >    * IKE has a little advantage for the security because it has a secured
   >     built-in reliable request/reply facility. At the opposite a new
   >     MH message needs an extra SPD entry, retransmission policy, etc.
   
=> as I've fixed the IPsec failover list address I've kept this long part.

   Sorry, I don't have any knowledge of the IPsec failover activity you 
   mentioned and how it would compete with HA-switch.  Can you point me at 
   a draft?  I don't follow any IETF IPsec-related WGs at the moment.
   
=> IMHO the easiest and fastest way is to go and/or read the agenda of
the "ifare" BOF (tomorrow morning).

   It is true that there might have to be some API between the network 
   stack and IKE, but it won't be necessary in all cases (and like Hui 
   mentioned, isn't a MIPv6-specific requirement).  In the HA-reliability 
   case, the MN will have an SA with every HA already, so won't need to 
   tell IKE to do anything during a switch.

=> can I translate this into it doesn't matter to keep unused IPsec SAs
until they timeout?

   In the non-HA-reliability case  there will be more work for the MN to do.
   
   I'm also not sure that trying to switch to using a different 
   infrastructure (IKE) will fit in the timeframe in which a switch 
   mechanism is required.
   
=> collaboration can help, no collaboration is likely a source of slow down.

   >  - 1.Introduction (comment): note the security function can be considered
   >   as an integral part of the Home Agent service.
   
   Did you want me to add some text?
   
=> IMHO only on good opportunity or if someone (else) asks for this.

   >  - 4.1 Sending Home Agent Switch Messages "o A home  agent to mobile
   >    node authentication option": this idle introduces a bidding down
   >    security issue. I propose to say the authentication MUST use the
   >    same mechanism than BU/BA (this is what we want and this should keep
   >    everybody happy :-).
   
   This issue will be on the slide at the WG meeting for discussion, I 
   suppose it would make it both easier to specify and implement, and would 
   support any future BU/BA security mechanism.
   
=> what do you think about my proposal?

   >  - 5.1 Receiving Home Agent Switch Messages "o The packet MUST be
   >    authenticated, either...": same issue (and same proposed solution).
   > 
   >  - 5.1 Receiving Home Agent Switch Messages: the presentation can suggest
   >    the connection to a new HA has to be done after leaving the current one
   >    (obviously this is not the intended behavior).
   
   There are two cases here:
   
   1. Switch is from current HA - in this case you would break-before-make 
   and teardown the old binding before replacing with one at the new HA. 
   If we don't do this then ND-proxy could fail with the new HA, along with 
   the BU.
   
=> IMHO this is not so clear:
 - the current HA can be clever enough to avoid the ND-proxy issue because
  it knows exactly what should happen.
 - when you move to another home link there is not possible ND-proxy issue.
So the problem is not a wording problem as I believed, perhaps we need
an explicit "break-before-make is authorized" notification.

   2. Switch is from new HA - you would just send a BU to the new HA, 
   assuming your current HA is dead.  This method is assumed in the 
   HA-reliability case.
   
Thanks

Francis.Dupont@xxxxxxxxxx