[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)



Hi Tero,

Thank you for your careful response, but still I disagree. I think we may have different understandings of the scenarios to be addressed and the implications of those scenarios. I have added some further comments below which I hope better explain the need as I see it.

--Thanks, Mark


At 05:27 PM 10/8/2003 +0300, Tero Kivinen wrote: ...
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.

It will trust what the peer sends because it authenticates the peer identity, and its configuration tells it which context(s) a given peer may access. Semantically this is no different than placing separate SGWs there for each context -- each of them only allowing connections from certain peers.



If I have understood correctly about the case it is something like
this:

That is one case. Two other cases are actually more important:
1. The case where Clients C and D are replaced by fixed SGW's or perhaps even another shared "ISP SGW". I.e. site-site rather than remote access.
2. The PPVPN overlay case where the IPsec SAs secure "virtual links" between independed IP routing/forwarding contexts.





        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

I believe your statement above embeds the assumption that Clients C and D connect to the same logical SGW. I.e. the ISP SGW presents the same identity, offers the same phase 1 policies, etc. to both of them. I should like the ISP SGW to have the capability to present different identities and policies on behalf of Corp A and Corp B.


Your statement above also embeds an assumption that the context to be assigned by the ISP SGW (responder) can be inferred from the identity asserted by the clients. I think this is a highly undesirable condition to impose, especially for the PPVPN overlay case where the set of ISP SGWs (called PE routers in PPVPN-speak) will be supporting many contexts. They will not want to have separate identities and credentials for each context!

 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.

No, because when client C sends the VPN ID of corp-b, it has to authenticate itself to the corp-b context. The corp-b context does not have any configured policy that will let client C connect.


...

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

I agree it should not affect implementations that don't need this capability. However, implementations that need it need the IKE support. I would envision that implementations that don't implement this will, as initiators, send their proposals without any context identifier. And as responders they will discard proposals containing a context identifer. And implementations that do implement this, when acting in the responder role, will either discard proposals that arrive with no context identifier, or process them under some default context.


Cheers,
Mark