[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: phase 2 and ports
I also have this very same problem. I have posted some messages regarding
this issue in the past but it did not trigger a discussion (see
http://www.vpnc.org/ietf-ipsec/mail-archive/msg00555.html ).
I was considering suggesting additions to the ID payload itself to include a
"virtual router" identifier to solve this issue but I agree that a Policy
Payload (or Selector Payload) could also solve it.
The question is how to identify a virtual router in a global way. That can
be easy in a private environment but more complicated in an open one. One
suggestion that I would have is to use a global VPN identifier as defined in
RFC 2685 (http://www.ietf.org/rfc/rfc2685.txt?number=2685).
Claudio Lordello.
Siemens.
> -----Original Message-----
> From: Daniel Fox [SMTP:dfox@ennovatenetworks.com]
> Sent: Tuesday, June 27, 2000 3:49 PM
> To: Jan Vilhuber
> Cc: Scott G. Kelly; Stephen Kent; Dan Harkins; ipsec@lists.tislabs.com;
> dfox@ennovatenetworks.com
> Subject: Re: phase 2 and ports
>
> A new Policy Payload could also solve the problem I currently have, which
> occurs when dealing with more than one IP Address Realm.
>
> 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
> << File: Card for Daniel Fox >>
Follow-Ups: