[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: phase 2 and ports
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
Follow-Ups:
References: