Re: 2401bis issues

[Stephen Kent <kent@bbn.com>]

At 12:29 +0300 10/15/03, Tero Kivinen wrote:
>Stephen Kent writes:
>>  I agree that this is not an interoperability issue, but 2401
>>  established a per-interface SPD requirement and I think we now have
>>  heard from various folks that this is unduly restrictive.
>
>The processing model in RFC2401 is just one example way how to do it,
>and as RFC2401 says, you can implement IPsec processing in a way you
>like, as long as it looks from the outside that it is similar than
>what is described in the RFC2401. If we cannot see the difference of
>those two ways, I do not think we need to change it. Implementators
>who want to implement it that way can already do it, I do not think
>RFC2401 restricts anybody in that way.

correct.

>
>----------------------------------------------------------------------
>4.4 Security Association Databases
>
>    Many of the details associated with processing IP traffic in an IPsec
>    implementation are largely a local matter, not subject to
>    standardization.  However, some external aspects of the processing
>    must be standardized, to ensure interoperability and to provide a
>    minimum management capability that is essential for productive use of
>    IPsec.  This section describes a general model for processing IP
>    traffic relative to security associations, in support of these
>    interoperability and functionality goals.  The model described below
>    is nominal; compliant implementations need not match details of this
>    model as presented, but the external behavior of such implementations
>    must be mappable to the externally observable characteristics of this
>    model.
>----------------------------------------------------------------------
>
>>  So as part of the revised processing model we need to remove the
>>  old, 2401 restriction and explain what the new model does and why.
>
>Does the new processing model require interface selectors or not? Does
>it help describing the processing model if we have interface selectors
>instead of per interface SPD?

when I published my first draft of the new model, it had a way to tag 
a packet with a VID, for forwarding purposes, and because we still 
had a per interface SPD, the VID selected the SPD too. The VID is not 
a selector, per se.  However, as I have listened to comments from 
various folks I am less convinced that we should have per-interface 
SPDs as a basic part of the model. Instead it seems more important to 
have a function to select an appropriate SPD, if more than one is 
needed, and to leave the forwarding decision as a separate matter.

>
>What is the rationale behind this change?

the rationale is that if we do not need to impose the constraint of a 
per-interface SPD, then it should go away, and a more flexible way of 
specifying the SPD should be accommodated, explicitly.

>
>>  >Issues 44 ("forwarding table lookup to select virtual interface ID") and
>>  >        45 ("use of cache with de-correlated SPD")
>>  >are still open, waiting for 2401bis draft.
>>  this will also be covered i the revised model.
>
>I would really like to have that revised model as soon as possible...

me too :-)

>
>>  >Rejected Issue 69 ("Multiple protocols per SPD entry")
>>  >Rationale: This is covered by
>>  >            issue 47 ("all selectors can be a list of ranges, per 
>>IKEv2 spec").
>>
>>  Tero has pointed out in some private e-mail that this
>>  characterization in quotes is not quite right, i.e., IKEv2 does not
>>  work this way!
>
>That was what we were refereing to, i.e while we fix the issue 47, it
>will make clear that we do not need protocol ranges in the SPD, but we
>do need each SPD entry to have list of selector items (source and
>destination ip-address ranges, protocol id, source and destination
>port ranges).

agreed, and thanks for the clarification!

>
>>  So, we are revising the characterization accordingly.
>>  The bottom line is that one can accommodate multiple protocols in a
>>  single SPD entry, because the entry really consists of a list of
>  > selector sets, each set contains S/D IP address range, ONE protocol
>>  (or ANY), and S/D port range.  The "list of ranges" effect is
>>  achieved in that fashion.
>
>Yep, and as this will be taken care of inside the Issue 47, then we
>can reject the issue 69 proposing about the same thing, but
>differently.

OK.

Steve