Say for instance, customer A has his own private IP network distinctly separate from customer B's network. Customer A and B each have a "virtual router" on the VPN switch. In this case, one needs to differentiate, in IKE, which IP network an SA pertains to.
Look at this example:
10.1/16 ---------+
+------- 10.2/16
network A |
| network B
+-------+
+-------+
|VPN |--Global IP Network--|VPN |
|Switch |
|Switch |
+-------+
+-------+
|
|
10.1/16 ----------+
+------- 10.2/16
network B
network A
In IKE, in order to set up an SA for packets going from 10.1/16
to 10.2/16 in network A, you need to specify for the SA:
network A
source 10.1/16
destination 10.1/16
Currently, there is no way to specify this kind of topology in IKE.
Now this brings up the issue that more and more complex policies may be envisioned. The Policy Payload could be extensibly defined to allow for this.
Another global solution that I have in mind is to have all policies configured out-of-band, and simply have IKE include a Policy Identifier.
Jan Vilhuber wrote:
On Tue, 27 Jun 2000, Scott G. Kelly wrote:
> Stephen Kent wrote:
> >
> > Jan is right. We used to have port ranges and similar features for
> > SPD configuration in the I-D precursor to RFC 2401, but they were
> > deleted because IKE didn't support them and nobody wanted to change
> > the IKE spec.
> >
> > Note, that we have a WG on IP security policy and it is exploring
> > ways to offer real negotiation for IPsec peers, prior to IKE
> > exchanges. That way one need not add complexity to IKE but one can
> > offer more sophisticated negotiation capabilities.
> >
> > Steve
>
> I agree that actual policy exchange might be better handled within ipsp,
> but I would really like to see ike support something more comprehensive
> than the current mechanism. If we wished to minimize complexity, this
> could consist in simply permitting multiple ID payloads,Skip also suggested this to me. I rejected this, because I don't like the
implicit semantics of the two ID payloads to begin with. Having multiples of
two ID payloads just adds to the non-obvious nature of how ID payloads are
used in phase 2.I'd much rather come up with a new payload. In my mind I dubbed it the
selector payload, but someone else mentioned Policy Payload, which I can also
live with.jan
> and/or adding
> some new ID payloads to facilitate ranges. I think this is a serious
> shortcoming in terms of real-world requirements.
>
> On a related note, I think we may be getting bogged down with this
> notion that we can't change ike in any way. While I think it would be
> ill-advised to change ike in a fundamental way (i.e. changing one of the
> existing exchanges in a way that creates interoperability and
> compatibility issues), I think we should be open to extending ike when a
> solid case for it exists.
>
> Scott
>--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
begin:vcard n:Fox;Daniel tel;work:978-206-0405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Principal Software Engineer fn:Daniel Fox end:vcard