[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On the Use of SCTP with IPsec



First Angelos D. Keromytis wrote:

>2) Good question; I would imagine that this draft would serve as a basis
>for existing documents (to address the issues raised); in particular, I
>think the following existing RFCs would be amended/modified/reissued (note
>that some of them are in the process of doing so): IPsec Architecture,
>IPsec DOI, IKE. It is possible to turn this draft into a document describing
>what's needed to support SCTP, as an addendum to all the other RFCs, but
>I don't think that's as helpful to implementors.

Then Stephen Kent wrote:

> ...
> different selector fields.  I'd recommend that IKE be enhanced to
> support those three means of specification of values for all 5
> selectors.
> 
> While recursive identities are sexy, I too worry that we could easily
> make the selector processing too complex, with adverse implications
> for high speed IPsec implementations.

Finally, Ari wrote that:

>I haven't read that draft you refer to, but I'd vote against
>'recursive identity types'. An ordinary identity type is
>already pretty complex to encode/decode, with all checks.

So, what we have is the following:

1. There are multiple people who feel IKE identities should be
   able to match to the ones in RFC 2401 (including me).
   Currently, however, there is no such support.

2. The SCTP-people really want the possibility to have multiple
   separate IP addresses in identities. Currently, this isn't
   possible. Note that even if a VPN gateway vendor doesn't
   need or want this extension, the need for the SCTP people
   is still very real; they feel strongly about this (even
   if it just an optimization in the end).

3. The two requirements are disjoint, we can't use
   ranges to do what the SCTP people want, and vice.
   versa.

4. Nobody wants to implement the complexity for the
   other guy's situation.

So, what can we do? Well, for instance: we keep the current
IKE behaviour as a MUST and then we add two MAY extensions,
one for the full selector set and another one for the
recursive identities.

(One big question mark though I have in the current IETF ipsec
work is whether everything waits for the publication of a new
mega ipsec RFC or if small optional extensions can be published
individually...)

Jari


References: