[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On the Use of SCTP with IPsec
Steve Kent wrote:
>I've made similar suggestions earlier, i.e., we have an inconsistent
>set of options for expressing selector values. Originally 2401
>allowed individual values, ranges, and enumerated lists for all
>selectors. It was late in the process when we discovered that IKE
>didn't allow all of these, and was uneven in what it supported for
>different selector fields. I'd recommend that IKE be enhanced to
>support those three means of specification of values for all 5
>selectors.
I agree with this, but I'll point out that it's outside the scope of
the SCTP/IPsec draft.
>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.
Perhaps there's a misunderstanding here ? Verification/processing of the
recursive identities would happen only in IKE; it is just *one* way
to express the various selectors that are relevant to an SA endpoint
*inside the IKE negotiation*. You would not need to modify your IPsec
stack to somehow grok them: IKE would simply setup n*m SPD entries,
based on the n subidentities the Initiator proposes and the m subidentities
the Responder does.
(Parenthentical comment: in practice, you'd probably want to change your
SPD handling to allow for multiple source/destination selectors associated
with each SPD rule, simply to avoid this n*m state explosion. This is an
implementation detail, and is in fact addressed in the draft.)
The alternative to recursive identities is to allow multiple ID payloads
in Quick Mode. Either of these approaches (recursive or multiple IDs)
requires changes to implementations; the former however does not require
changes to the *protocol* itself.
-Angelos
p
Follow-Ups: