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

[Jean-Francois Dive <jef@linuxbe.org>]

Hi all,

I believe 2 issues are discussed here and a new point that may have not
been discussed already (at least that i didn't saw in the mailing list
archive, please point me to the conclustions if i'am wrong).

- The addition of another ID field type in the selector for SG-SG
multi-customer environment: I just want to point the fact that IKEv1 has
that kind of facility as far as i can tell, no one support such usage so
far. As ID payload, for exemple ID type keyid, value "[customer1]blue"
could have achieved such thing, even though no traffic selector could be
passed. I believe that agreement on the format of such ID as much as all
the possible case of utilisation should stay outside of the standard,
but allowing a variable len field instead of a selector payload could be
used by some implementors or be left to other working groups. On the
other hand, as already mentioned, the same functionality could be
achieved using multiple 'sessions (init-auth-child-child-...)', one per
customer which sounds better to me as you add authentication on top of
it.

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


JeF.

On Fri, 2003-10-10 at 12:04, Eric Vyncke wrote:
> Tero,
> 
> 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)
> - ...
> 
> 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...
> 
> Hope it helps
> 
> Just my 0.01 EUR
> 
> -eric
> 
> 
> At 17:27 8/10/2003 +0300, Tero Kivinen wrote:
> >[Please when you send comments to list, use the issue number in the
> >subject, so it is easier for the others to search for other mails with
> >same issue]. 
> >
> >Mark Duffy writes:
> >> >         68 VPNs with overlapping IP address ranges
> >> #68 (as I think you have acknowledged) consists of multiple parts, some of 
> >> which are implementation issues but not all.  Part of #68 involved a 
> >> capability in the protocol:
> >> 
> >>           b. They MUST negotiate a VPN subscriber ID using IKE, as
> >>           noted above, to enable forwarding of inbound IPsec
> >>           traffic after crypto processing.
> >
> >I do not think there is any need to negotiate the VPN subscriber ID
> >between the parties. The VPN subscriber ID is internal to the SGW, and
> >it is not going to trust anything the other end sends.
> >
> >If I have understood correctly about the case it is something like
> >this:
> >
> >
> >
> >        Corp A --------.                          +---- Client C
> >                     +-----+                      |
> >                     | ISP |-----{ Internet } ----|
> >                     | SGW |                      |
> >                     +-----+                      +---- Client D
> >        Corp B --------'
> >
> >
> >Where the ISP SGW is acting as VPN GW for both corporation A and
> >corporation B, and the clients connect to it using IPsec through the
> >internet. Corporations A and B both use 10.0.0.0/8 network, and give
> >out IP address to the clients from the same range. Now when the client
> >C connects to the ISP SGW it authenticates itself as c@corp-a.com. The
> >ISP SGW will now link that authenticated identity to the VPN
> >Subscriber ID of Corp-A, and attach all packets coming from the client
> >C to that VPN ID. When it is sending them out it will send to Corp A
> >interface, because it is also attached to the Corp-A VPN ID.
> >
> >The ISP SGW will not be trusting client C to send him the VPN ID, as
> >if it would trust clinet C, the c@corp-a.com could send VPN ID of
> >corp-b instead and get access to the Corp B network.
> >
> >So only way to get those VPN-IDs is through the configuration based on
> >the authenticated ID of the client, thus there is no need to negotiate
> >them in IKE.
> >
> >This means that client C and D are normal IPsec clients, and they do
> >not have any special processing to be done. If Client C for some
> >reason wants (and is allowed) to be part of both Corp A and B
> >networks, then he can have two authenticated IKE identities
> >c@corp-a.com and c@corp-b.com.
> >
> >All the special processing of VPN IDs etc (or whatever local
> >processing the ISP SGW does) is inside the ISP SGW, thus it is purely
> >local implementation issue. 
> >
> >> When a security Gateway is operating on behalf of multiple contexts (e.g. 
> >> multiple subscribers, or multiple ppvpn-style overlay addressing contexts), 
> >> it is essential that the initiator be able to convey to the responder which 
> >> context is being addressed.
> >
> >Do not use IP addresses as a IKE SA identities then. Use the dns names
> >or email addresses or something else. There is no need to use ip
> >addresses in those cases (or actually using ip addresses would be
> >quite bad, as it is not unique...). 
> >
> >> In the absence of a capability to signal this 
> >> in IKE, the only full-functioned alternative is for the SGs to maintain a 
> >> separate IP address to use for each supported context.  This can waste a 
> >> lot of addresses, and it isn't even as good anyway because it requires 
> >> coordinated configuration on both ends to understand which IP address in 
> >> each SG corresponds to which context.
> >
> >There is no need for that. 
> >
> >> My conclusion:  2401bis should support the concept of multiple contexts 
> >> supported in an IPsec device, and IKE should provide a means to convey the 
> >> desired context in the initial exchange.
> >
> >I do not think this is general case that should be implemented in the
> >all IPsec stacks out there. It will be implemented as purely local
> >matter in some of the IPsec implementations, and there is no need to
> >have any kind of negotiation or changes to the IKE because of that. 
> >-- 
> >kivinen@ssh.fi
> >SSH Communications Security                  http://www.ssh.fi/
> >SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
--