[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@corp-a.com.

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@corp-a.com 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