Subject: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01

From: "Michael Roe" <[email-masked]>
Date: Tue, 2 Mar 2004 18:40:24 -0000

Karen, Steve,

In draft-ietf-rfc2401bis-01, the description of the processing
model is very confusing. The problem is that is keeps switching
between two different representations of the SPD:

 (a) An ordered SPD, which may contain overlapping entries
 (b) An unordered SPD, which must not contain overlapping entries

So we have:

[page 16] "The SPD is an ordered database,..."  - ordered SPD

[page 17] "An SPD is logically divided into three pieces, all of
which should be decorrelated ..."  - unordered SPD

[page 17] "The management interface for the SPD ... MUST support
(total) ordering of these entries, as seen via this interface." 
 - ordered SPD

It seems as though the description of packet processing is based on an
UNordered SPD; implementors may at their discretion implement it either
as an ordered or an unordered datastructure; and as a conformance
requirement, the management user interface MUST present the user with
the appearance of an ordered SPD, using the Annex B algorithm to translate
if necessary.

I appreciate that technical changes are unwelcome at this point, but I thought
I ought to try and explain why the current text is confusing.

Cheers,
Mike

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Mar 2004 00:25:29 -0500

At 20:01 -0800 3/2/04, Charlet, Ricky wrote:
>Howdy,
>
>	Could the flow cashing and decorrelated SPD be implementation
>suggestions?
>
>	I feel implementers should have the freedom to achieve the
>effect of an ordered SPD search in what ever internal mechanism they
>choose. Flow cashing, while a very good idea for processing efficiency,
>is not an interoperability issue. And it may not be the only or even the
>best idea for processing efficiency (though I can't think of others).
>
>	RFC 1812, section 5.2 hinted at a cashing suggestion but only
>required implementers to achieve the effect of a search algorithm while
>specifically allowing impelmentors to innovate (see section 5.2.1). I
>think similar language could be used here.

There is no requirement to decorrelate the SPD or to cache, and the 
text says that. I just found it much easier to describe the flow 
based on the use of caches, which implied decorrleation.

Steve