[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)
[I will combine my reply to one email about all the issues].
Paul Knight writes:
> I think you are right that the VPN subscriber ID is not required in the case
> you describe (individual host or client connecting via a gateway), but the
> more difficult case is where there are multiple "ISP SGW" devices, which are
> used to interconnect multiple corporate sites in a VPN. In the VPN-related
> working groups, the terminology would be "PE" - provider edge devices.
Ok, there are some other usage cases too, but the approach I presented
would work for them too, with the overhead of extra IKE SA and extra
credential.
Note, that if the ISP SGW boxes are doing IPsec on the interface
hardware which can fail independantly, then the current IKEv2 draft
requires you to have separate IKE SAs per each hardware, as it is not
accectable for IPsec SA to fail (on the interface hardware) when the
IKE SA stays up.
Also having multiple credentials is good thing, as it offers
protection that if one of the ISP SGW box is compromized, only those
networks which go through that box are compromized, not all VPN
networks anywhere in the ISP SGW (yes, you can have access filters to
limit the damage, but its complexity is the more than having separate
credentials, thus if ISP didn't do multiple credentials because it is
too hard, they would not include the filters either).
For the IKEv2 point of view the VPN ID is not traffic selector, nor is
it pure authentication ID. If you do not want to have multiple IKE SAs
between ISP SGWs then it cannot be authentication ID. It is not
traffic selector as it does not fit current traffic selector approach.
The IKEv2 will have list of traffic selectors items, where you can
select any subset. Each traffic selector item includes ip address
range, protocol, and port range. The VPN ID does not fit to this
approach very well. It should propably be included in all of the
traffic selector items, meaning that it requires quite major change in
the IKEv2 traffic selectors (i.e traffic selector item would have VPN
ID, address range, protocol, and port range). With that approach you
would be able to combine multiple VPN IDs to one IPsec SA (provided
there is no overlapping IP addresses). I.e this IPsec SA traffic
selectors would be:
VPN ID corp-a, 10.0.0.1-10.0.0.255, any proto, any port
VPN ID corp-b, 192.168.2.0-192.168.2.255, any proto, any port.
If we add it as separate type of traffic selector to the list, then
what happens if the responder choose not to include it. I.e the IPsec
SA traffic selectors would be:
10.0.0.1-10.0.0.255, any proto, any port
VPN ID corp-a
and the responder could narrow the selection:
10.0.0.1-10.0.0.255, any proto, any port
Better approach would be to include it (if it is really needed) as
notification that is attached to the create child sa exchange. This
would have the meaning that it communicates the VPN ID to the
responder associated to one IPsec SA created with that exchange. Good
thing about this is that this kind of change can be included as
separate document without breaking any existing implementations (they
will simply ignore the notification if they do not understand it), and
it is much smaller change to be implemented in implementations.
> There are ways to multiplex the VPN traffic over a single SA pair, but these
> all seem to require either extra encapsulation or the addition of some "tag"
> to every packet. It appears to me that a solution allowing a single
I think that using the SPI as a tag is the best approach. It is small
(32 bits), we already have rules how to allocate and what to do with
them etc. I.e use separate IPsec SA for each VPN tunnel. Also IPsec SA
overhead in the SGW is not that much either (8 bytes for sequence
number * 2, 8 bytes for replay window, 16 bytes * 4 for keys (ESP +
auth), both directions etc, i.e about 100 bytes + the information
about the VPN ID (interface id or similar)).
Now the only question is how to tie one SPI to one VPN ID...
> They have at least two basic ways to do this:
> (1) Set up a single IPsec connection between PE1 and PE2 for both VPNs.
> (2) Set up one IPsec connection *per VPN* between PE1 and PE2. Two ways to
> do this:
> (2a) use one IP address per VPN on the Internet-facing interface(s) of
> each PE, and negotiate an IPsec connection for each IP address pair, and use
> an internal mechanism to associate the IP addresses and IPsec connections to
> the VPNs.
> (2b) use a single IP address on the Internet-facing interface of each PE,
> use a context identifier (VPN-ID) to negotiate multiple IPsec connections
> (one per VPN), and use an internal mechanism to associate the IPsec
> connections to the VPNs.
So, I would propose 2b, but with different way to send the VPN ID
between hosts. My first choice would not send it at all, instead use
different credentials per VPN, and tie VPN ID to the credentials. This
have also better security than using one global authentication
credential.
My second choice would include the VPN-ID-NOTIFICATION in the
CREATE_CHILD_SA exchange in IKEv2, and also document that notification
in separate document.
> requirement would be to add a Context-Identifier Payload to IKEv2. It
> should support multiple types of context identifiers, since there are
> several potential identifiers already known: 1 - VPN-ID - 7 bytes (RFC 2685)
> 2 - Route Distinguisher - 8 bytes (RFC 2547) 3 - MPLS Label
That notification could easily include any type of identifiers needed.
The first choice does not care about the types, as the identifiers are
there purely local matter.
Mark Duffy writes:
> 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 each system is going to have list of all possible remote GWs which
can connect to it, there is already separate configuration for each
remote end per each VPN. Using separate credentials would then be just
one more configuration information added to this same configuration.
Actually it might also make the configurations smaller, as some of the
configuration can be simply said: if you can authenticate yourself
with certificate from this ISP-Corp-A-internal-CA (internal CA from
the ISP created only for Corp-A), then you are part of Corp-A VPN.
Each box still needs to have only one private key, they only need
multiple certificates for the same private key from different CAs.
There are also other ways to do the same thing (use the dns name
inside the certificate to find out the VPN ID or if using pre shared
keys, use the common key for Corp-A VPN etc).
> 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.
It can already do that, because the client C can use the you Jane me
Tarzan approach. Note, having different proposals for different
connections is only possible if we are using per VPN IKE SA along with
per VPN credentials. If we only have one IKE SA then we cannot have
different IKE SA parameters per each VPN. If we have only one identity
and credentials then there is no way to identify during the initial
exchange to which VPN you want to connect (or we have to move the
VPN-ID-NOTIFICATION to IKE_SA_INIT exchange).
So if there is requirement that we need to have different IKE SA
parameters in different VPNs then we do not have any other choice than
having different IKE SAs per VPNs.
> 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!
Why not? With certificates the identity costs them about 1-2 kB or so,
with pre shared keys it costs 50 bytes (name) + 4+16 bytes (ip + key)
per each other end node. If you have 100 VPNs its still quite a small
amount of memory.
> >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.
I.e you need to have mapping from the authenticated ID to the VPN ID,
so why cannot use that information to derive VPN ID in the first place.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/