Re: pf_key comments
Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us> Fri, 03 January 1997 18:30 UTC
Received: from cnri by ietf.org id aa13446; 3 Jan 97 13:30 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa15265;
3 Jan 97 13:30 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id
NAA23740 for ipsec-outgoing; Fri, 3 Jan 1997 13:23:37 -0500 (EST)
Message-Id: <199701031826.KAA01494@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 10:26:20 -0800
To: perry@piermont.com
Subject: Re: pf_key comments
cc: Rodney Thayer <rodney@sabletech.com>, ipsec@tis.com
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
References: <199701031703.MAA10942@jekyll.piermont.com>
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 feasable. > 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. -dpg
- Re: pf_key comments Naganand Doraswamy
- Re: pf_key comments Dennis Glatting
- Re: pf_key comments Dennis Glatting