Subject: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 01 Apr 2005 11:55:56 -0800

hi Gerardo,

thanks for the review.

Gerardo Giaretta wrote:
> Hi Vijay,
> 
> I have some comments on draft-ietf-mip6-ikev2-ipsec-01.
> 
> Overall, the draft looks good. In my opinion, the unique general issue
> is that it is tied very much to rfc 3776 and as a result it is not
> self-contained. I mean that it is not possible to read the draft without
> having also rfc3776 in front of you. This is ok to me, but I wonder if
> it is acceptable in general.

I guess it can be difficult. I was worried about this too, but didnt
want repeat all the requirements. will ask the working group about this.

> Some more detailed comments:
> 
> - section 3.2: I don't understand very well how this list should be
> read. The draft states: "The mobile node and the Home Agent MUST support
> the requirements listed in Section 4 of RFC 3776 with the following
> exceptions" (btw, s/support/fulfill). I'd expect a clear reference to
> requirements in rfc3776, but I found sometimes difficult to match the
> requirements and to understand what really changes. Isn't much clearer
> to state all the requirements (old and new ones)? More details below.
> 
> - section 3.2, bullet 1: in order to be more adherent to rfc 3776, I'd
> say "It is not required to configure security policies security policy
> database entries specifically for the tunnel interface in order to
> protect return routability signaling messages".

okay.

> - section 3.2, bullet 2: how is this requirement different from the one
> specified in rfc 3776 (4th bullet page at page 12)? Could you clarify
> please?

the text on dynamic keying part has changed. for IKEv1 we talk about
Phase 1. for IKEv2, we talk about IKE_AUTH exchange. but we cant just
state that. need to explain why the HA needs to check if the identity
presented in IKE_AUTH exchange is allowed to create security
associations for a particular home address.

suggestions to improve this are welcome.

> 
> - section 3.2, bullet 3: maybe I am missing something here, but how this
> is different from IKEv1 and rfc 3776?

not different. I see the problem very well now. some requirements I
am repeating from 3776. will fix this, based on what the working
group decides.

> - section 5.1.1, last paragraph at page 11: "In the examples shown
> above, the home address of the mobile node might not be available all
> the time." Are you referring to the case where the HoA is dynamically
> allocated? If yes, I'd mention it at least as an example. 

yes.

> Moreover, the draft continues: "When the mobile node acquires a new home
> address, it must add the address to the corresponding SPD entries." What
> about the HA? Does the HA need to add the address to the corresponding
> SPD entries or can it keep generic entries? I think it should add the
> HoA in SPD entries.

no. if the MN initiates IKE exchange, the HA can just populate the
SPD from the IKE exchange. it doesnt need to create a SPD entry for
a specific HoA.

> - section 7: this section refers to dynamic HoA assignment. I wonder if
> this procedure should be explained in this document or in the
> bootstrapping document. Maybe the latter, if needed, can simply point to
> this one. 

I prefer the bootstrapping document just pointing to this section
for HoA configuration.

Vijay

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 01 Apr 2005 14:57:11 -0800

hi Gerardo,

> SPD from the IKE exchange. it doesnt need to create a SPD entry for

here is some new text.

    In the examples shown above, the home address of the mobile node
    might not be available all the time.  For instance, the mobile node
    might have not configured a home address yet.  When the mobile node
    acquires a new home address, it must either add the address to the
    corresponding SPD entries or create the SPD entries for the home
    address.

    The SPD entries on the home agent are created when the mobile node
    initiates IKE exchange.  The home agent can also have generic SPD
    entries to prevent mobility header traffic that requires IPsec
    protection from bypassing the IPsec filters.

does this look good?

Vijay

---

From: Pekka Savola <[email-masked]>
Date: Sat, 2 Apr 2005 11:07:48 +0300 (EEST)

> want repeat all the requirements. will ask the working group about this.

A higher-level comment, not having read the draft properly,

I don't see this as a problem as long as the list of exceptions is 
clear enough (I don't have an opinion about this because I didn't look 
closely enough).

In particular, as long as we put RFC3776 in as a normative reference, 
it's OK to just reference a section of it.  This won't become a 
problem before we want to recycle this spec to Draft Standard, but not 
move forward with RFC3776 -- and we could make the document 
self-contained then.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 4 Apr 2005 14:22:57 +0200

Hi vijay,

 one comment inline,

>    protection from bypassing the IPsec filters.

 I'm not sure to well understand this part. 
 Do you mean that the home agent creates the SPD entries for the mobile
 node after receiving the first IKE packet ?

-- 
julien.bournelle at int-evry.fr

---

From: Francis Dupont <[email-masked]>
Date: Tue, 05 Apr 2005 11:31:52 +0200

In your previous mail you wrote:

   
=> as the 2401bis is deeply different, for instance it has a syntax
for SPD entries, IMHO the document should be rewritten from scratch
(and if possible by an IPsec person, ideally someone who participated
to 2401bis/IKEv2 development).

   
=> there is a wrong lower case should in place of the MUST for using
the care-of address as the source address of packets.

Regards

[email-masked]

PS: I still believe the document goes to the wrong direction, for instance
requiring support for MH type selectors when it is expected than the
common policy will be to protect all the packets on the MN-HA tunnel
(better for privacy, simpler, and easy to implement by BITW).
Another issue is the total lack of implicit or explicit references to
the pki4ipsec work...

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 05 Apr 2005 16:30:00 -0700

> the care-of address as the source address of packets.

the MN cant use anything other than CoA as source address of IKE
exchange. so why is there a need for a MUST? thats the only way
to do it.

> (better for privacy, simpler, and easy to implement by BITW).

the MN can always negotiate SAs so that all traffic is sent through
the MN-HA tunnel. but I find it wierd not to take advantage of
the additional selectors provided by 2401bis. it is better for privacy
I agree. see section 2.1 of
http://www.ietf.org/internet-drafts/draft-koodli-mip6-location-privacy-solutions-00.txt
but that shouldnt be the default mode, IMHO.

> Another issue is the total lack of implicit or explicit references to

what should we be in specific referring to? to
draft-ietf-pki4ipsec-ikecert-profile or to some section in it?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 05 Apr 2005 16:39:13 -0700

>  node after receiving the first IKE packet ?

yes. in the case of a dynamically assigned/auto-configured home
address an SPD entry for a specific home address is created only
when the HA gets to know about the home address of the MN. the
HA itself could be allocating the home address during the IKE
exchange.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Apr 2005 12:26:37 +0200

=> so we agree the draft should be fixed.

   the MN can always negotiate SAs so that all traffic is sent through
   the MN-HA tunnel. but I find it wierd not to take advantage of
   the additional selectors provided by 2401bis.

=> I am not against to take advantage, only to make this mandatory.

   it is better for privacy
   
=> I agree, the default mode should be the same than in 3776, i.e.,
MH protocol as the selector. But the two others (all traffic and only
the critical MH types) have to be allowed.

   
=> IMHO the most of the text is relevant, for instance 3.1.1
   o  the administrator intends the implementation to verify that the
      peer source address matches the IP address in the ID received, and
      that in the iPAddress field in the peer certificate's
      SubjectAltName extension.
...
   In addition, implementations MUST be capable of verifying that the
   address contained in the ID is the same as the peer source address,
   contained in the outer most IP header.  If ID is one of the IP
   address types, then implementations MUST perform this verification by
   default.  If this default is enabled, then a mismatch MUST be treated
   as an error and security association setup MUST be aborted.  This
   event SHOULD be auditable.  Implementations MAY provide a
   configuration option to (i.e.  local policy configuration can enable)
   skip that verification step, but that option MUST be off by default.
   We include the "option-to-skip-validation" in order to permit better
   interoperability, as today implementations vary greatly in how they
   behave on the topic of verification of source IP.

So in your draft section 5.2 the first option should not be recommended
(i.e., it should be used only when the two (and far better) others are
not available).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Apr 2005 12:35:37 +0200

=> IMHO the verb "create" is too strong because an SPD entry can exist
without addresses (addresses are only a form of selectors), quoting
2401bis draft:

      - Name:  This is not a selector like the others above.  It is not
        acquired from a packet. A name may be used as a symbolic
        identifier for an IPsec Local or Remote address. Named SPD
        entries are used in two ways:

         1. A named SPD entry is used by a responder (not an initiator)
            in support of access control when an IP address would not be
            appropriate for the Remote IP address selector, e.g., for
            "road warriors."  The name used to match this field is
            communicated during the IKE negotiation in the ID payload.
            In this context, the initiator's Source IP address (inner IP
            header in tunnel mode) is bound to the Remote IP address in
            the SAD entry created by the IKE negotiation. This address
            overrides the Remote IP address value in the SPD, when the
            SPD entry is selected in this fashion.  All IPsec
            implementations MUST support this use of names.

I believe we are in this case (and note its support is mandatory) even
in the real world one can't see the difference with your proposal.

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 06 Apr 2005 14:15:48 -0700

> => so we agree the draft should be fixed.

hmm... if there is only one way to do it, do we need a 'MUST' to
talk about it. if there are multiple ways of doing it and we
want interoperability, then we should be using a MUST. anyway,
this is what we have currently.

    o  The mobile node should use its Care-of Address as source address
       in protocol exchanges, when using dynamic keying.  However, the
       security associations MUST be created for the home address of the
       mobile node.

you want it changed to the following?

    o  The mobile node MUST use its Care-of Address as source address
       in protocol exchanges, when using dynamic keying.  However, the
       security associations MUST be created for the home address of the
       mobile node.

okay.

> => I agree, 

okay. atleast we agree that the tunnel mode shouldnt be the default.
you want it explicitly mentioned in the draft?

> the default mode should be the same than in 3776, i.e.,

anybody else has an opinion on this?

>    behave on the topic of verification of source IP.

I agree. infact the entire section 3.1 is relevant because many
times the identification presented in the IDi payload might be NAI
or FQDN.

I propose adding the following to section 5.2

    When PKI based authentication is used between the mobile and the Home
    Agent, the identity presented by the mobile node in the IDi payload
    must correspond to the identity in the certificate obtained by the
    Home Agent.  The Home Agent uses the identity presented in the IDi
    payload to lookup the policy and the certificate that corresponds to
    the mobile node.  If the mobile node presents its home address in the
    IDi payload, then the Home Agent MUST verify that the home address
    matches the address in the iPAddress field in the SubjectAltName
    extension [9].

    [9]   Korver, B., "The Internet IP Security PKI Profile of
          IKEv1/ISAKMP, IKEv2, and PKIX",
          Internet-Draft draft-ietf-pki4ipsec-ikecert-profile-03, October
          2004.

if you are not happy with this, please propose some text.

> (i.e., it should be used only when the two (and far better) others are

Francis, I dont think we can mandate that somebody use PKI instead
of shared secrets through IETF specs. deployment considerations
determine this. not us. I do agree that if PKI is available it
should be used. maybe we can emphasize that PKI be used if available.
would that be enough?

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Apr 2005 16:13:21 +0200

=> OK for me.

=> I don't believe the word default is necessary: IMHO we should just
present things in the right order and explain there are two alternatives
to the selector = MH protocol.

   > the critical MH types) have to be allowed.
   
=> in fact any selector set which provides the right protection should be
allowed... The two alternatives need to be detailed because they have
some advantages so should become common. Of course both sides should
agree before.

=> I agree we may not put a "MUST" but this is a good place to play
with SHOULD and MAY with a good explaination.

=> we agree about the target.

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Apr 2005 14:57:34 -0700

thanks Francis.

here is the new text.

    The Home Agent should have named SPD entries per mobile node, based
    on the identity of the mobile node.  The identity of the mobile node
    is stored in the "Name" selector in the SPD [5].  The Home Address
    presented by the mobile node during the IKE negotiation is stored as
    the Remote IP address in the resultant IPsec security associations.
    The home agent MAY also have generic SPD entries to prevent mobility
    header traffic that requires IPsec protection from bypassing the
    IPsec filters.

is this okay with everyone?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Apr 2005 15:17:57 -0700

>           security associations MUST be created for the home address of the

okay, changed it.

> some advantages so should become common. Of course both sides should

so you want the default mode be the same as in RFC 3776, but present
the "tunnel everything" mode and the "MH type as a selector" as two
options?

I disagree with this. IMHO, the "MH type as a selector" should be
supported atleast by the Home Agent, so that some mobiles can take
advantage of this. the "tunnel everything mode" can be specified
as part of privacy solution documents.

> => we agree about the target.

okay, I added the following to sectino 5.2

    If public key
    based mechanism is available, it should be the preferred mechanism
    for mutual authentication.

Vijay