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

Re: issues from the bakeoff

To: itojun@itojun.org (Jun-ichiro itojun Hagino)
Subject: Re: issues from the bakeoff
From: Dan McDonald <danmcd@Eng.Sun.Com>
Date: Wed, 16 Jun 1999 09:41:37 -0700 (PDT)
Cc: shacham@cisco.com, dharkins@network-alchemy.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com
In-Reply-To: <23795.929503385@coconut.itojun.org> from "Jun-ichiro itojun Hagino" at Jun 16, 99 12:23:05 pm
Sender: owner-ipsec@lists.tislabs.com

> 	Well-known CPI is not very friendly with PFKEY interface (RFC2367).
> 	RFC2367 expects unique SPI per peer (which can embed CPI in lower
> 	2 bytes), but for well-known CPI we can't.

Why is this an issue?

You can treat the well-known CPI as a pre-added compression association,
which, if you use SADB_GET, would reveal a match.  If you tried to
ADD/UPDATE, you'd just get EEXIST.

> 	What kind of userland API do you expect to see?  I'm now using dummy
> 	SPI (= CPI) to designate the SA database entry for compression,
> 	and add a flag to force the use of well-known CPI on the packet.

The user app would ask for compression (or not complain if it showed up) on a
per-socket basis.

I don't see the problem here.

Dan

Follow-Ups:

Re: issues from the bakeoff

From: itojun@iijlab.net

References:

Re: issues from the bakeoff

From: Jun-ichiro itojun Hagino <itojun@itojun.org>

Prev by Date: Re: Comments about draft-ietf-ipsec-ike-01.txt
Next by Date: Re: issues from the bakeoff
Prev by thread: Re: issues from the bakeoff
Next by thread: Re: issues from the bakeoff
Index(es):
- Main
- Thread