[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
VPN identification for phase 2 exchange
Greetings,
I am working on an IPSec implementation which is to be used in an
environment that is not (at least clearly) addressed by the existing RFC's.
Below I describe a) the problem itself with some background info, b) the
constraints of my application, and finally c) a quick description of
previous threads on issues similar to this one that I found in this mailing
list.
What I would like to hear from other implementors is:
1) How are other implementations out there dealing with this issue?
(interoperable and/or proprietary approaches).
2) If it turns out that only proprietary solutions are being employed, is
there enough interest from other implementors to define a common aproach for
interoperability (I think there is an RFC which now defines a VPN
identification scheme)? If work in progress already exists, pointers to it
would be appreciated.
I would also offer myself to write a summary of the discussions/suggestions
and, if there is enough interest, even start a draft on this subject.
A) The problem
Background:
My SG will be used in an environment where IP interfaces belong to a virtual
router. In such an environment a VPN is simply a set of IP interfaces which
are assigned to the same virtual router accross the ISP network. In
addition, it must be possible (although not required) for all tunneled
traffic to travel on common IP interfaces (these are the uplinks for the ISP
network itself). The address domain for different VPN's can (and certainly
will) overlap as indicated in the picture. The traffic for each VPN must be
carried in distinct IPSec SA's between SG-A and SG-B although only one IKE
SA will exist between them.
10.1.* 10.2.*
-------+ +------+ +------+ +-------
siteX | VR-1 | | | | VR-1 | siteY
+--------+ | | +--------+
| | VR-0 | |
| SG-A +---------------------+ SG-B |
VR-2 | | (tunneled traffic) | | VR-2
+--------+ | | +--------+
siteW | | | | | | siteZ
-------+ +------+ +------+ +-------
10.1.* 10.2.*
Issue:
Traffic from 10.1.* from siteX arrives at SG-A and triggers a phase 2
exchange (assuming one did not exist already). SG-B receives the phase 2
negotiation message with the phase 2 identity. Now SG-B has no means to tell
if the intended IPSec SA is for the VR-1 or the VR-2 flows given that the
VPN Identification is not included in the phase 2 exchange and the phase 2
identities are identical.
B) Constraints
It has been suggested in previous threads to use different SG identities for
each VPN (VR) that a SG has to establish tunnels for. Unfortunately that is
not a scalable solution (for the environment that my SG will be used on), so
I would like to avoid that.
C) Previous threads on this subject
On a similar thread (November 99 - "Phase 2 ID's for different VPN's with
different Address Space") it has been suggested to "use SIT_SECRECY with a
defined secrecy category as the ID of the VPN". I can not understand how
exactly this works as it is not completely covered in the RFC's (in fact, it
is only briefly mentioned). I assume this would provide a proprietary
solution to the problem. Am I right? More information on this approach would
be helpful.
Another thread (July 99 - "paralell vpns") does not seem to have the same
definition of VPN as I have (i.e. overlapped address space does not seem to
be an issue in that case) and, in addition, creating multiple IKE SA's do
not seem to be an issue as well, which is not my case.
Any suggestions and/or information would be greatly appreciated.
Claudio Lordello.