Subject: [Mip6] review of draft-ietf-mip6-ikev2-ipsec

From: Jari Arkko <[email-masked]>
Date: Fri, 13 Jan 2006 12:22:24 +0200

Per request, I'm reviewing this a second time now that its
going to the AD and the IESG.

Overall:

I liked this document, particularly the home address
allocation that becomes much, much easier with this.
And the ability to employ in practise any type of
existing AAA via EAP.

The spec does still have some issues. My main concern is that
it tries to do perhaps a bit too much, there are parts
we should and others that we could delete -- likely
resulting in more readable and easily implementable
spec.

Technical:

>   The IKEv2 specification [4] requires that public key based mechanism
>   be used to authenticate the home agent to the mobile node, when EAP
>   is used.  This should be used by default by the mobile node and the
>   home agent.  If the EAP method that is used, supports mutual
>   authentication and key generation, then the mobile node MAY use EAP
>   itself to authenticate the home agent.  The mobile node can request
>   this by including the EAP_ONLY_AUTHENTICATION notification payload
>   [8] in message 3.  If the home agent supports the
>   EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP,
>   it omits the public key based AUTH and CERT payloads in message 4.
>   If the home agent does not support this mechanism, it rejects it by
>   including an AUTH payload in message 4.  More details can be found in
>   [8].
>
(snip)

>   The use of EAP for authenticating the mobile node to the home agent
>   is described in Section 8.  This document recommends that if the EAP
>   method used, supports mutual authentication, then EAP itself be used
>   for authenticating the home agent to the mobile node also.  This runs
>   contrary to the recommendation in [4].  The home agent can ignore the
>   recommendation in this document and implement EAP authentication as
>   described in the IKEv2 specification.  Security considerations
>   related to the use of EAP with IKEv2 are described in [4] and [8].
>  
>
I think that EAP-only auth mode in IKEv2 makes a lot of
sense. But I'm very concerned that a document from MIP6
WG overrides a MUST in another WG's main document.
Here's what RFC 4306 says:

   In addition to authentication using public key signatures and shared
   secrets, IKE supports authentication using methods defined in RFC
   3748 [EAP].  Typically, these methods are asymmetric (designed for a
   user authenticating to a server), and they may not be mutual.  For
   this reason, these protocols are typically used to authenticate the
   initiator to the responder and MUST be used in conjunction with a
   public key signature based authentication of the responder to the
   initiator.

My suggestion would be to take the specific extension of
IKEv2 out of the draft and pursue that separately. Obviously,
this extension is also very useful in non-MIPv6 scenarios, so
this is also logical from the point of view of keeping our specs
modular.

In any case, I think the above text would make [8] normative
dependency, which I don't think you want...

>   o  If the mobile node has used IKEv2 to establish security
>      associations with its home agent, it should follow the procedures
>      discussed in Section 11.7.1 and 11.7.3 of the base specification
>      [2] to determine whether the IKE endpoints can be moved or if the
>      IKE SA has to be re-established.
>
>   o  If the home agent has used IKEv2 to establish security
>      associations with the mobile node, it should follow the procedures
>      discussed in Section 10.3.1 and 10.3.2 of the base specification
>      [2] to determine whether the IKE endpoints can be moved or if the
>      IKE SA has to be re-established.
>  
>
Hmm... I wonder if we really want to carry the K bit scheme
forward. I saw that as an intermediate solution. There's
no requirement for you to handle everything in this spec,
you can also streamline & simplify. Also, I would prefer the
above text to allow IKEv2-specific address changes. In
particular, there seems to be no reason to disallow
automatic NAT-T address changes or even MOBIKE. None
of that has any effect on Mobile IPv6, as long as the
client still sends a correct Mobile IPv6 Binding Update
inside. And MOBIKE is already referenced from elsewhere
of the spec, so this is also a consistency issue.

Same issue in Section 7.3.

>MIP6 Working Group                                        V. Devarapalli
>Internet-Draft                                                     Nokia
>Expires: April 26, 2006                                        F. Dupont
>                                                                  Point6
>                                                        October 23, 2005
>
>
>  
>
The header says nothing about the relationship to RFC 3776.
Updates? Obsoletes? Personally, I think "updates" would make
more sense, but this is related to the issue of whether you
want to carry the manual SA stuff from 3776 here.  Its quite
a lot to carry, and everyone who uses manual SAs can still
use 3776, so no one would actually lose anything. But YMMV,
maybe you wanted to show how you get rid of per-interface
policies with the new architecture.

Editorial:

>   The IPsec architecture has been revised [5].  Among the many changes,
>
Maybe "RFC 3776 was, however, defined for the first revision
of the IPsec architecture. The second revision [5] has introduced..."
And change "revised IPsec architecture" later in the document
to "the second revision of the IPsec architecture". (Or is the
2nd? Was the something before 2401? Anyway, my point is that
when someone reads this 10 years from now, it may no longer
be obvious what "revised ipsec architecture" means.)

>If the
>   home address of the mobile node changes, the SPD and SAD entries need
>   to re-created or updated for the new home address.
>
s/need to/need to be/

>   The author would like to thank Mika Joutsenvirta, Pasi Eronen,
>   Francis Dupont, Jari Arkko, Gerardo Giaretta and Shinta Sugimoto for
>   reviewing the draft.
>  
>
Francis is thanking himself :-)

--Jari

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

---

From: Francis Dupont <[email-masked]>
Date: Sat, 14 Jan 2006 19:29:36 +0100

In your previous mail you wrote:

=> it seems most concerns are for Vijay (:-).

   Technical:

=> I leave this point to Vijay as I already raised this point.

=> same (:-)!

   >      IKE SA has to be re-established.

=> note the situation is different between IKEv1 which "established" SAs
and IKEv2 which "manages" SAs, i.e., in IKEv2 when the IKE SA goes down
all the IPsec SAs are closed too. So the K bit stuff is more important
(and BTW easier) to implement with IKEv2 than in IKEv1 where one can
consider it as an optimization.

   automatic NAT-T address changes or even MOBIKE.

=> there is a simple reason: to have two mechanisms doing the same
thing is bad, and to have two conflicting mechanisms is very bad.

   None of that has any effect on Mobile IPv6, as long as the
   client still sends a correct Mobile IPv6 Binding Update
   inside. And MOBIKE is already referenced from elsewhere
   of the spec, so this is also a consistency issue.

=> section 7.3 is supposed to solve the consistency issue.
I suppose you can propose a better wording?

=> this is the rule for an I-D. I agree for an update mention in the RFC.

   

   2nd? Was the something before 2401?

=> 1825 (August 1995, both IPsec and IPv6 are a bit more than 10 year old).

   Anyway, my point is that
   
=> 4301 says "updated" which should be better.

=> oops, we missed this one (:-).

Thanks

[email-masked]