[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution)
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/