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

Re: 2401bis issues



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