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

[Tero Kivinen <kivinen@ssh.fi>]

Eric Vyncke writes:
> 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

This should be done only after the authentication, as only after then
you really know who the other end is. 

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

Send multiple certificate requests, i.e for each CA there are, or
simply leave out the certificate requests, and assume that you either
have the certificate, or that the client is configured to send you the
certificate anyways. 

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

I think the best way to solve that kind of 'features' is to use
something like proprietary notification or something similar if you
cannot do it by the normal rules. I most of those cases there are ways
to get over with the problems by just doing little extra work.

I.e when you initially respond to the IKE SA you guess some policy and
use it. When you see the identity you verify your guess. If the guess
was incorrect you abort the negotiation, and request other end to
restart it, and mark it in your internal table that this IP address
should use this guess next time for next n minutes. Then when the
initiator restarts you select this different policy guess, and use
that instead. So all of these are doable, they might just need some
extra work. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/