RE: Configuration portion of OPEN ISSUES...

[Gregory Lebovitz <Gregory@netscreen.com>]

within...

> -----Original Message-----
> From: Stephane Beaulieu [mailto:stephane@cisco.com]
> Sent: Wednesday, February 26, 2003 8:53 AM
> To: Theodore Ts'o; Gregory Lebovitz
> Cc: ipsec@lists.tislabs.com; byfraser@cisco.com
> Subject: RE: Configuration portion of OPEN ISSUES...
> 
--SNIP--
> 
> Some of us had agreed that a good path forward would be to keep the
> configuration payload for initial very basic configuration 
> (IP, WINS, DNS,
> DHCP-SERVER-IP).  This would satisfy a VERY LARGE number of existing
> deployments (100% that I've seen so far, though I'm not naive 
> enough to
> think that it won't change ;).  It would also allow you to 
> use a RADIUS or
> LDAP server in the back-end (rather than DHCP). 

We have probably understated how important it is to the installed base to be
able to use RADIUS and LDAP for client configuration backend server. Most of
my organziation's large enterprise and xSP customers use RADIUS today, not
DHCP for client configuration. That is why so many of us implementors are in
consensus about the solution I and Stephane are describing: it would offer
the network operators the most flexibility to leverage their current
configuration infrastructure, be it DHCP, RADIUS or LDAP. 

> *IF* other 
> DHCP specific
> information is required, a remote Client MAY send a DHCP 
> packet (via a valid
> IPsec SA) directly to the DHCP server to get the rest of the 
> configuration.
> 
> I *thought* this was the agreement, but somewhere along the way, this
> changed to
> 
> > > 	* Keep configuration payload and allow optional
> > > 		RFC 3456-style configuration
> 
> Nobody wants to do this because this basically says you need 
> to support both
> CP and RFC3456.
> 
> Where it should have said
> 
> *Keep configuration payload and allow optional unicast DHCP 
> configuration
> after phase 1 is complete.

Or maybe:
 * Keep configuration payload, and show (possibly in Appendix or another
document) how it works with various backend config servers, i.e. DHCP,
RADIUS, LDAP.

BTW, Darren Dukes and I are working right now on some text for this. Stay
tuned.
 
> I *think* everyone can live with this.  Some have expressed a 
> desire for
> other solutions (DHCP in IKE for example), but I have not 
> heard anyone say
> that the above solution is not acceptable.

This is the consensus I thought we had reached.

Gregory.