Re: 2401bis issues

[Tero Kivinen <kivinen@ssh.fi>]

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.

----------------------------------------------------------------------
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?

What is the rationale behind this change?

> >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...

> >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).

> 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. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/