[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: phase 2 and ports
Using the RFC 2685 may be workable, I'll look at it more closely.
Actually, I broached this subject months ago, with some suggesting that we use
the Secrecy Level.
But if we are opening up a Selector Payload, then perhaps we can put it there.
Claudio Lordello wrote:
> 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 >>
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
References: