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

[Tero Kivinen <kivinen@ssh.fi>]

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.

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.

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.

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. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/