[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@xxxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxx and c@xxxxxxxxxxx
>
>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@xxxxxx
>SSH Communications Security                  http://www.ssh.fi/
>SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/