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

From: "Vijay Devarapallli" <[email-masked]>
Date: Fri, 3 Mar 2006 10:35:35 -0800

hi Jari,

sorry for the delay in responding

On 1/13/06, Jari Arkko <[email-masked]> wrote:

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

I agree that this draft is the wrong one to talk
about this. there was no 4306bis at that time.
maybe we should bring it up for 4306bis, unless
this is considered a big change that cant go into
4306bis. I will remove it for now, but we need
to bring this up with IPsec/IKE folks.

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

the 'K' bit is nice. I saw interoperable implementations
of this at the TAHI 2006 Interop event. IMO, it is every
useful. I am not a big fan of too many small
specifications.

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

IMHO, I dont think anyone would use MOBIKE instead
of the 'K' bit if MIP6 is being used. the signaling part
is already being done by MIP6.

the reference to MOBIKE talks about something
different. it was put in because the following might
be considered incorrect by some folks since MOBIKE
is now a stable specification.

    If the mobile node moves and its care-of address changes, the IKEv2
    SA might not be valid.

we can remove the reference to MOBIKE in section 7.3.

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

I just found how to add this. now it says

MIP6 Working Group
Internet-Draft
Updates: 3776 (if approved)
Expires: August 5, 2006

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

somebody else also pointed this to me. this the current
text

   RFC 3776 describes how IPsec, as described in RFC 2401 [12], is used
   with Mobile IPv6 [2] to protect the signaling messages.  It also
   illustrates examples of Security Policy Database and Security
   Association Database entries that can be used to protect Mobile IPv6
   signaling messages.

   The IPsec architecture has been revised in RFC 4301 [5].  .....

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

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Fri, 3 Mar 2006 10:48:21 -0800

here is the pre05 version of the draft.

http://people.nokia.net/vijayd/mip6/mip6_ikev2.txt

Vijay