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

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Jul 2005 18:40:02 -0700

hi Jari,

sorry for the late reply.

thanks for reviewing the draft.

> o  Imho, the draft reads too much like a "diff" to RFC 3776. In
>    the light of eventually switching to only this, I think
>    we want a more self-contained document, even if it
>    means more text.

yes. many others have expressed this concern. I plan to make the
document self contained.

> o  Question: do we want to keep the manually keyed case in
>    this document? I mean we will always have RFC 3776 when
>    we want to do that...

well, I wanted to show the manual IPsec entries that take
advantage of the new MH type selector and ICMP type selector.
we didnt have that in RFC 3776.

> o  In some places (such as section 6 and how you explain the
>    use of the AUTH payload) I got the feeling this repeats what
>    IKEv2 spec already says.  Not sure what to do here, just
>    an observation.

personally, it is kind of hard to read the IKEv2 spec. I thought
it would be a good idea to write down what I understood. I have
got comments from others saying that they understood better
how IKEv2 can be used with MIPv6 after reading section 5.2 and 6. :)

> o  I'd prefer seeing recommendations like [8] as orthogonal
>    to what we need for Mobile IPv6 usage of IKEv2. That is,
>    I agree with what [8] is saying, but it seems like a general
>    IKEv2 issue rather than something specific to Mobile IPv6.
>    In some cases you want to point to such work and in some
>    other cases you can leave it out; in this case I think the draft
>    is unfortunately not moving very fast so you might want to
>    drop the discussion about it, as eventual approval of [8]
>    might change the contents.

I really would like to see this implemented by folks. currently I
think using EAP is only realistic way of authenticating mobile
nodes in an Operator deployment. and some deployments like 3GPP2
currently cant support public key or certificate based
authentication for the home agent.

I re-worded the paragraph a bit to say that it is completely
optional. I dont mind moving it to an appendix either so that [8]
does not ever has to become a normative reference. :)

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

what do you think?

> o  Security considerations should perhaps say something about
>    rules regarding the allocation of home addresses, to avoid
>    hijacking them. I think you said something about that already somewhere
>    else, maybe that text could move here.

okay.

> 
> o  It would also be interesting to hear more about how NAT traversal
>    feature of IKEv2 could be used in the connection of this new
>    spec for v4 compatibility, or whether you want to continue to use
>    the K bit or MOBIKE for moving the SAs. But perhaps these are
>    out of scope, I know that at least for the v4-v6 compatibility there
>    are other discussions and drafts.

we plan to address that in the v4 traversal work. we should have
something on this to report at the Paris IETF meeting.

Vijay

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