Subject: SPD Cache in 2401bis

From: "Bora Akyol" <[email-masked]>
Date: Fri, 5 Mar 2004 12:13:20 -0800

Is it possible to remove all the discussion on SPD-cache out of
RFC2401bis and into an informational RFC?

The discussion of the cache within the text even pre-faced
with the caveat given that the cache is optional detracts
from the clarity of the text IMHO. 

This will leave the SPD as ordered and will also take 
all discussion of the decorrelation of the SPD out of 2401bis
as well.

The caching idea has merit by itself and can be either put
in an appendix altogether or removed and put into an informational
RFC.

As far speed of implementation is concerned, there are widely
available TCAMs
that can do millions of look-ups per second in an ordered database
using a 5-tuple or a 6-tuple lookup.
 
Regards,

Bora

---

From: Stephen Kent <[email-masked]>
Date: Fri, 5 Mar 2004 16:13:10 -0500

>RFC2401bis and into an informational RFC?

no.

>from the clarity of the text IMHO.

I've worked on this for a long time and I find that it is much easier 
to discuss steady-state processing using caches.  This is especially 
true for discussing how PFP works, for example.  We had a cache-less 
description in 2401. As primary author of that document I can tell 
you that the one aspect of 2401 that resulted in the most e-mail 
questions was a direct result of not having a cache-based model.

Steve

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 5 Mar 2004 14:08:49 -0800

Thanks,

in this case, can we at least include in sections of the text in
the packet processing path an alternate description
of what an implementation would do if they were not using a cache.

For example, page 28-29, items 2 and 3a/b.

Since the cache is optional, don't you think we should have a
description
of the non-optional ordered SPD case?

Bora

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Friday, March 05, 2004 1:13 PM
> To: Bora Akyol
> Cc: [email-masked]
> Subject: Re: SPD Cache in 2401bis
> 
> 
> >The discussion of the cache within the text even pre-faced with the 
> >caveat given that the cache is optional detracts from the clarity of 
> >the text IMHO.
>

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 6 Mar 2004 22:09:24 +0900 (JST)

> >RFC2401bis and into an informational RFC?

	i think 2401bis is talking about implementation details too much.
	i agree with bora that SPD-cache issues should be a separate document.
	there could be multiple ways we can implement SPD lookup portion
	(and we should be allowed to implement in various ways), for instance.
	SPD lookup portion won't impact interoperability.  wire format part
	will.

	therefore, i believe 2401bis should be spiltted into two document:
	- a document which concentrate onto the on-wire protocol only
	  (mostly references to ESPv3 and AHv2)
	- a document which concentrate onto implementation specifics
	  (how SPD lookup has to be done, how it should be cached, tunnel mode
	  and transport mode)

itojun

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sun, 7 Mar 2004 11:55:54 -0800

Reading through the current draft, I have to agree with Itojun and 
Bora. It's hard to say that the cache is optional when it appears in 
MUST statements, such as in section 5.1. There should either be 
parallel discussions (simpler ones with the cache, more complicated 
ones without the cache), or the main document should describe only 
the mandatory features, and an appendix or different document 
describe the improvements you get with the optional cache.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Mar 2004 09:32:21 -0500

>	  (how SPD lookup has to be done, how it should be cached, tunnel mode

I appreciate the suggestion that 2401/2401bis has more detail than 
some folks would like. However, a protocol spec is not just a matter 
of the bits on the wire format; it also includes a model (e.g., a 
state machine) for how one processes outbound and inbound traffic for 
the protocol. Thus it is essential that 2401bis include such a model. 
On that basis I have to disagree with your suggestion on 
restructuring.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Mar 2004 11:31:40 -0500

>describe the improvements you get with the optional cache.

paul,

Fair criticism.  It would be ideal if we could provide parallel 
descriptions, or relegate one to an appendix, but it is additional, 
non-trivial work.

In 2401 we did not do an adequate job of describing how to handle 
some cases, e.g., named SPD entries and PFP entries. Even for simple 
SPD entries the notion of going back to the SPD to lookup each 
outbound packet is clearly something that scales poorly for bigger 
SPDs and/or high speeds. (Of course all of this is only a concern for 
BITS/BITW/SG implementations. native host implementations have an 
intrinsic form of caching anyway.)

A motivation for introducing caching was to offer a model that scales 
better, as well as describing a simpler model. Decorrelation is 
needed for caching. For named SPD entries, there is a need to create 
a new entry to match outbound traffic, and if we create it in the 
SPD, we have to address the question of exactly where it belongs 
relative to the named entry that gave rise to the transient entry.

The processing model for IPsec is not a proscription for 
implementation. It gives details of one way to implement IPsec. The 
intent is that a compliant implementation should behave in an 
identical manner, as viewed by the IPsec peer and by the user/admin, 
no matter how it is implemented locally.  We need at least one model 
to provide a reference, and it is preferable if the model is as 
simple as possible, to make it easy to describe and to understand.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Mar 2004 21:27:21 +0200

> intrinsic form of caching anyway.)

I think most of the implementations are doing and are going to do the
processing differently what is described in the rfc2401. This happens
regardless how the processing is described there. The method used
tries to be identical from the outside view, but might offer different
extensions and optimizations depending on the scenario the specific
ipsec implementation is aimed for.

Security gateway supporting 10000 vpn-clients will have completely
different optimizations compared to the sgw aimed for connecting 2
branch offices together with one tunnel.

I do not think rfc2401 needs to define the scalable and efficient
procedure, it needs to describe the processing as clearly as possible,
and then we might have another document (or the appendix) describing
all kind of optimizations etc which can be used to make it scalable
and optimal for different uses.

> simple as possible, to make it easy to describe and to understand.

Yes. It needs to be as simple as possible, it does not necessarely
need to be efficient or scalable. If it happens to be both even
better, but no extra complexity should be added to the model to make
it more scalable or efficient.
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Mar 2004 14:30:52 -0500

>ipsec implementation is aimed for.

That is completely consistent with what I said later re the purpose 
of the model.

>branch offices together with one tunnel.

sure.

>it more scalable or efficient.

I think we are in agreement. My feeling is that the cache-based model 
meets that criteria, i.e., it is simpler to explain in detail, and 
happens to scale well.

Steve