Re: Another field for traffic selector?

[Mark Duffy <mduffy@quarrytech.com>]

Hi Shane,

I think your point here raises an interesting question.

When one uses a unique public IP address per customer/context (as you 
describe below) one ends up with separate IKE SAs, and probably separate 
identities, used for each customer/context.

OTOH, putting the VPN ID in the Traffic Selector Payload as proposed in 
this thread binds each child SA to a VPN; the IKE SA is shared across 
multiple VPNs.

Another possibility that presents itself is putting the VPN ID attribute in 
some payload that binds it to the IKE SA.  (HDR payload?  An optional 
VPN-ID payload?)  This would make it more similar to the way you describe 
below, only not require all the separate IP addresses.

Which is better?  Sharing an IKE SA across VPN contexts probably scales 
better and is probably sufficient when say a service provider is operating 
the SGs at both ends.  However, for the case of multi-user/customer IPSec 
GW's, especially where the remote peer might be a single-user GW or a 
multi-user one operated by a different service provider, it might be the 
case that each user/customer would want to use their own identity.

--Mark


At 03:23 PM 3/12/2003 -0700, Shane Amante wrote:
[snip]
>One example of where signalling VPN-ID's is most useful
>is multi-user/customer IPSec GW's, where:
>a) there is only a single, unique public IP address on the public side
>of the chassis; and,
>b) there are multiple customers on the private side of the chassis,
>each of which has the same, overlapping RFC1918 address space, e.g.:
>         C1-private: 192.168.1.0/24
>         C2-private: 192.168.1.0/25
>         C3-private: 192.168.0.0/23
>         ...
>NOTE: All three of the above customers/contexts ARE NOT related to
>one another, e.g.: do not share security policies, etc.
>
>As it stands now, the only way to overcome the above limitation (aside
>from proprietary signalling) is to create a unique, public IP address
>per customer/context, which: a) hurts SP's that strive to conserve
>their public IP addresses; and, b) is no different than deploying a
>whole IPSec GW per customer.
>
>-shane