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

["DENG, HUI -HCHBJ" <hdeng at hitachi.cn>]

Hi, Francis,

Thanks for your review, 
Please check some reply below inline headed with [Hui]

Regards,

-Hui

-----Original Message-----
From: Francis Dupont [mailto:Francis.Dupont at fdupont.fr] 
Sent: 2007年3月6日 20:43
To: Basavaraj Patil
Cc: mip6 at ietf.org; ietf-ipsec-failover.vpnc.org at tao.fdupont.fr
Subject: Re: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt 

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:
[Hui] I agree that IKE could do this too if this mechanism is only dedicated to home agent switch with one more assumption: authentication option is not used here. I guess that it could have multiple usages in the future.

   * 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.
[Hui] Do you mean IPsec other than IKE here? Why these messages need to be propagated to IKE? There is a need about API between MIP6 and IKE, but this is a generic requirement, not only happen in home agent switch case. 

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

 - 1.Introduction (comment): note the security function can be considered
  as an integral part of the Home Agent service.

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

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

 - 5.1 Receiving Home Agent Switch Messages:
   perform home agent discovery -> perform home agent address discovery?

 - 9. Security Considerations: again...

 - 9. Security Considerations: use the home agent -> use a home agent?

Regards

Francis.Dupont at fdupont.fr

_______________________________________________
Mip6 mailing list
Mip6 at ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

Disclaimer:
The contents of this e-mail, and its attachments, if any, are confidential and may be protected
by law against any unauthorized use.  If you have received this e-mail by mistake or have
reason to believe that you are not the intended recipient, please notify the sender by reply
e-mail as soon as possible and delete it from your computer system immediately thereafter.
If you are not the intended recipient, you must not copy this e-mail or attachment or disclose
the contents to any other person.  While we have made every effort to keep our network virus free,
we take no responsibility for any computer virus which might be transferred by way of this e-mail.

_______________________________________________
Mip6 mailing list
Mip6 at ietf.org
https://www1.ietf.org/mailman/listinfo/mip6