[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Phase 2 ID's for different VPN's with different Address Space
On Mon, 01 Nov 1999 11:14:24 EST you wrote
>
> I have an interesting problem, and I am hoping that someone on the list
> can help with the solution.
>
> I am implementing a sgw that has many physical interfaces (T1, T3, etc.)
> to different private networks. Each private network has its own address
> space. A very simple architecture looks like this:
>
> VPN 1, site A VPN 1, site B
> -------+ +------+ +------+ +-------
> | | | | | |
> +--------+ | | +--------+
> | GW A +----------+ GW B |
> +--------+ | | +--------+
> | | | | | |
> -------+ +------+ +------+ +-------
> VPN 2, site A VPN 2, site B
>
> My thinking is, I do a phase 1 IKE between GW A and GW B.
>
> To set up the ESP tunnel for VPN 1, I do a phase 2 IKE between GW A and
> GW B, using PFS. I do another similar phase 2 exchange for VPN 2 to set
> up the ESP tunnel for this VPN.
>
> Question: how do I identify that my clients are a particular VPN?
>
> I can't use ID_IPV4_ADDR_SUBNET, since each VPN has its own address
> space.
That should be fine. They're gonna be separate negotiations. Assuming that
site A is initiating to site B, the first packet from VPN{1,2} will hit
GWA who will queue it up and do a phase 1 IKE exchange with GWB. The ID
used there depends on how you're authenticating. Then the phase 2 exchange
happens. The IDs are constructed from the selector that the packet hit.
So if your selector is from one subnet to another then they're both
ID_IPV4_ADDR_SUBNET. If it's a subnet to a paricular host then the 1st
is an ID_IPV4_ADDR_SUBNET and the 2nd one is a ID_IPV4_ADDR. When another
packet for the other VPN hits the GWA it will do another phase 2 exchange
and this one will be identified by the specifics of the particular selector
that matched that packet which will necessarily be different than the
specifics of the selector that matched the first packet.
> I could use ID_FQDN, but then I couldn't specify the IP addresses (plus
> it's ugly). What I'd really like is to specify a 32-bit VPN identifier,
> along with the IP subnet and transport port. Can I do this without
> defining new ID types?
An ID_FQDN can't be used because it doesn't convey any addressing information,
as you noted. ID_FQDN is intended for phase 1 exchanges.
What is this VPN identifier? Where is that defined? IKE doesn't define
VPNs so you can't specify that somebody is "in a VPN" using IKE.
> I could use ID_KEYID, but it really doesn't identify a key, and, of
> course, it wouldn't be interoperable. However, I will use this if this
> seems to be the preferred method.
ID_KEYID does identify a key but it too is for phase 1 exchanges.
Whatever the parameters of an RFC2401 selector there are corresponding
RFC2407/RFC2408 identities to use with RFC2409. In fact, it was limitations
of the ID payload that caused the port range to be removed as an RFC2401
selector parameter. Hopefully the next rev of the documents will allow
that to be added back.
Dan.
Follow-Ups:
References: