[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