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

[Tero Kivinen <kivinen@ssh.fi>]

Eric Vyncke writes:
> Regarding your point that SG should not trust the VPN-ID as
> received: this is for sure ;-)  
> 
> But, the VPN-ID can be used during the IKE_SA_INIT exchange in order
> for the SG to: 
> - check whether to continue the IKE exchange (i.e. custA has a
>   contract for max 10 'tunnels') 
> - see what kind of security parameters to use (i.e. custA can
>   enforce AES-256 for IKE or use only certs from this CA) 
> - ...

Now I am confused. Earlier I thought that VPN-ID was meant to be like
a traffic selector, i.e that you could create one IKE SA and then for
each IPsec SA you select which VPN-ID is used. You seem to be
proposing that VPN-ID is more like the IKE authentication ID, i.e the
identity of the other end.

For that kind of use you need to have separate IKE SA for each VPN,
and then the proper way to do that is use separate credentials and
authentication ID per VPN.

Adding VPN-ID as authentication ID propably would not be enough, as
you propably also need to identify the remote end box also, not only
the VPN where it belongs, thus you need VPN-ID and box id. Easiest
thing for that is to use something like dns-name or email address and
format that name so that it have VPN identifier part and box
identifier part inside, and map those strings to the actual local
VPN-ID through the configuration. 

> Then, during IKE_AUTH exchange, the SG will check whether the ID (as
> proven by the authentication) does indeed match the VPN-ID. 
> 
> On a side note: the VPN-ID as exchanged during IKE_SA_INIT could
> potentially be different to the one used by the PPVPN on 'the other
> side' of the SG. 
> 
> On another side note, the use of VPN-ID will be dictated most
> probably by an ISP/MSSP while the actual IKE ID will be selected by
> the customer. I'm afraid that forcing both parties to agree to a
> common naming for the ID (assuming that VPN-ID is rejected) will be
> a real pain in the real world... 

I think both VPN ID and IKE ID will be selected by the ISP, as both of
the boxes are controlled by ISP (unless there is yet another different
scenario), thus format of the IKE ID will be completely local matter
to the ISP.

Anyways, I think this is something that is not for general IPsec use,
but more specific case, thus I do not think we should include the
current issue #68 in the RFC2401bis now. I think we can write new
document to describe how to do that kind of things.

Can we agree on that now?
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/