Re: [Mip6] Summary of Justification for Alternative Authentication Option

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

   Summary
   =======
   
   The WG has been engaged in a discussion over the last week on the
   topic of standardizing an authentication date suboption based

=> I believe "standardizing" means to make it a Proposed Standard,
doesn't it?

   mechanism for the purpose of registering an MN with its HA via the
   BU/BAck messages.
   To summarize the discussion in brief:
   1. The I-D draft-patil-mip6-whyauthdataoption-00.txt was used as the
       baseline for the discussion
   2. Opinion was expressed that the I-D was more inclined in justifying
       why the use of  IKE was a problem for setting up the MN-HA IPsec SA
       and not really providing sufficient justifications for an
       alternative scheme to the use of IPsec for securing the signaling
       messages between the MN and HA
   3. There were a few people who expressed strong views of keeping IPsec
       as the only means for MIP6 security between MN and HA (Francis and 
   Hesham (?))
   4. There were others who claimed the need for an alternate option to
       MIP6 including one operator who plans to deploy the protocol in
       their network (Raj, James Kempf, Alpesh, Gopal, Kuntal, Vijay,
       Michael Roe)

=> you should be more accurate: just alternate option or standardized
alternate option?

   5. There was also a note from an implementers perspective on the
       challenges of integrating MIP6 with IPsec (Michael Roe)
   6. There was discussion about the problem of replay attacks and the
       need for key refreshment
   7. IKEv2 is expected to provide a solution to the problem of setting
       up dynamic SAs in networks that rely on AAA infrastructures. While
       IKEv2 itself has been approved, the details of how IKEv2 is used
       with MIP6 are still being worked out in an I-D that is not ready
       yet.

=> IMHO the main problem with an IKEv2 based solution is that there is
no public implementation... Another point is that IKEv2 does not support
home agent allocation.

   8. There was an opinion that the bootstrap work being done in the WG
       would address the needs of the environment claimed in I-D
       draft-patil-mip6-whyauthdataoption-00.txt
   
=> some AAA/EAP based solutions are already ready (i.e., implemented)
and of course they support home agent allocation.

There are some other points:
 - we were supposed to ask an advice from security area directors
 - the requirement level of auth data option is still not clear enough
 - if the auth data option is only for the 3GPP2 environment there is
   no reason to standardize it at the IETF: the 3GPP2 can require what
   it wants in its own environment. If it likes to get an IETF document,
   an informational RFC should be enough and even faster (less possible
   concerns from the IESG).
Some of these points were already mentioned on the list...

Regards

[e-mail]

_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6