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