Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution)

[Eric Vyncke <evyncke@cisco.com>]

Tero

See in-line

At 18:01 14/10/2003 +0300, Tero Kivinen wrote:
>Jean-Francois Dive writes:
>> - The other point which i think is very important is what Eric mention
>> as an Id in the fist exchange. This is a big reason why people do use
>> aggressive mode with IKEv1. Without any other way of an exchange than by
>> IP address, protection suite for 'phase1' are biased and hard to
>> implement, this is the whole problem of responder profile/template
>> matching when a new exchange is received. I do understand that customer
>> wants identity protection, but we could again add a marker and leave
>> authentication where it is.
>
>The question there is, "do you really have different phase 1
>protections?". I think most of the cases the phase 1 protection is
>irrelevant, as long as it is strong enough. Also there is no reason to
>accept too weak phase 1 protection for anybody. Also the amount of
>data encrypted etc is so small that it does not matter if what the
>algorithm is.

It is not only about negotiation of phase 1 protection, it can also be:
- for a shared SG: a hard limit on the number of IKE SA per customer
- selection of the right CA to send CERT_REQ (again in the case of a 
  shared SG with dozens or more customers each with its own CA)

>With current IKEv2 document you can select the phase 2 algorithms
>based on the identity of the initiator and also based on information
>to whom the initiator wants to talk (i.e initiator can send responder
>ID to whom he wants to talk before the responder selects the
>algorithms.
>
>I think this is enough. I do not see any good reason for the policy
>that for the user X use 3DES and 3DES only for phase 1 protection and
>for user Y use AES to encrypt phase 1 traffic.

Agreed on this one, but, again there could be some corner cases; and
having worked with a lot of customers, I can guarantee you that
there are always weird ones requesting weird stuff.

>I would think the policy would define that use the strongest one
>proposed by the other end.
>
>Note, that the main reason for the aggressive mode in the IKEv1 was
>the use of preshared keys tied to the identity of the other end, not
>the selection of phase 1 algorithms based on the identity. The main
>mode didn't allow selecting of the pre-shared key based on the
>identity, thus vendors were forced to use aggressived mode which
>sent identity in clear thus allowed seeing the identity before
>selecting the pre-shared keys.

This was indeed the main reason why IKEv1 is like it is. But, other
people re-used this 'feature' to do other services with it (like
the ones described above).

And, it would be really useful to keep the same services with
IKEv2.

>The IKEv2 does not tie pre-shared keys to the phase 1 encryption keys,
>thus the implementation can decrypt the IKE_AUTH message and see the
>identity before verifying and generating the AUTH payloads using the
>pre-shared key. 

And, this is really a Good Thing (tm).

Just my 0,01 EUR

-eric