Re: pf_key comments

Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us> Fri, 03 January 1997 19:52 UTC

Received: from cnri by ietf.org id aa14702; 3 Jan 97 14:52 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa17341; 3 Jan 97 14:52 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24348 for ipsec-outgoing; Fri, 3 Jan 1997 14:41:38 -0500 (EST)
Message-Id: <199701031944.LAA01547@imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Date: Fri, 3 Jan 97 11:44:18 -0800
To: dennis.glatting@plaintalk.bellevue.wa.us
Subject: Re: pf_key comments
cc: perry@piermont.com, Rodney Thayer <rodney@sabletech.com>, ipsec@tis.com
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
References: <199701031703.MAA10942@jekyll.piermont.com> <199701031826.KAA01494@imo.plaintalk.bellevue.wa.us>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

> > > I am looking into implementing PF_KEY and I have some comments on this too:
> > >
> > > 1. I like the idea of sending the IV down from an application.  I think
> > > that an application is a reasonable place to do the random number
> > > generation because
> >
> > Its completely unreasonable to send the IV from the
> > application. Since IVs have to be sent on every packet, that
> > would mean you would need to do a PF_KEY operation on every
> > packet. This is not going to be feasible.
> >
>
> There is no need to do an operation for every packet. The kernel
> could ask for a block of random data and use it as it wishes.
>

However, if we assume a 100mbs ethernet link ~85% efficient and
1024 byte packets (and enough CPU juice to handle that data :),
that's ~10k packets per second. Using 8 bytes of random IV for
each packet the kernel will require ~80k of random IV per
second.

It seems unreasonable for the kernel to acquire that amount of
data from a user level process each second; however, I wonder
whether pseudo random data generators can produce that amount
of data at that rate too. If not, then pseudo random IV is useful
for slow packet rates in which case it may be reasonable for the
kernel to request random data from a user level process.


-dpg