by redmail.netbsd.org with SMTP; 13 Mar 2000 02:36:52 -0000
	by mail-blue.research.att.com (Postfix) with ESMTP
	id DBE6C4CE1A; Sun, 12 Mar 2000 21:36:50 -0500 (EST)
	by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id VAA13861;
	Sun, 12 Mar 2000 21:37:42 -0500 (EST)
	id 0096D41F16; Sun, 12 Mar 2000 21:36:49 -0500 (EST)
	by SIGABA.research.att.com (Postfix) with ESMTP
	id E3B12400B5; Sun, 12 Mar 2000 21:36:44 -0500 (EST)
From: "Steven M. Bellovin" <smb@research.att.com>
To: thorpej@shagadelic.org
Cc: tech-security@netbsd.org
Subject: Re: IPsec configuration issues 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 12 Mar 2000 21:36:44 -0500
Message-Id: <20000313023649.0096D41F16@SIGABA.research.att.com>

In message <20000312180336.A1139@dhcp0.wlan.shagadelic.org>, Jason R Thorpe wri
tes:
> ...this might really belong on tech-net, but...
> 
> I've been having some trouble figuring out how to get setkey(8)/racoon(8)
> to do precisely want I want.
> 
> To summarize, I have a server which serves data to some mobile stations
> which have dynamically assigned addresses, often not on networks which
> are under the administrative control of the server's admin (me :-)
> 
> Some of the services that the server provides have some security problems
> of their own (e.g. POP3), and IPsec is the most obvious way to address them
> for a variety of reasons.
> 
> Now, the server's addresses (it has 2) are static.  However, I need a
> way to say "any" for the other end.  In English, I'd like to say this:
> 
> 	For all packets destined to <ip_address_of_server>[tcp port 110],
> 	they must be encrypted with <algorithm>.
> 
> There will be one key for each client, and it will be a fairly static thing
> (much like an ssh_host_key).  However, the IP address of the client will
> NOT be static.
> 
> There's not an obvious way to do this from what's documented in the
> setkey(8) and racoon(8) manual pages.
> 
> Any experts on these programs have some suggestions?

I'm certainly not an expert on those programs.  However -- there's a known 
deficiency in IPsec key management (IKE) in shared secret mode:  it can't be 
used when the clients have dynamic IP addresses, since the the identity of the 
client isn't communicated until after the secret has to be used.  If racoon is 
implementing this mode of IKE, it *can't* do what you want -- this is a bug in 
the protocol spec, rather than in the code.

		--Steve Bellovin