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

RE: Modefg considered harmful



I think any mature implementations that will be trying to use DHCP for
complete configuration of the ipsec client (beyond network addresses, as is
possible with modecfg today) will need to implement their own DHCP client
and server in order to include their user-specific ipsec-VPN configuration.
So what we'll end up with is as follows.

OS-DHCP-client(optional) <-> ipsec-DHCP-client <TUNNEL> SGW-DHCP-server

Reusing the OS DHCP client (if possible at all) will not give enough
flexibility.

Darren

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson
> Sent: Friday, January 31, 2003 12:40 PM
> To: ipsec@lists.tislabs.com
> Cc: Scott G. Kelly
> Subject: Re: Modefg considered harmful
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> >>>>> "Scott" == Scott G Kelly <scott@bstormnetworks.com> writes:
>     Scott> This is probably a point of confusion for some, and is
> what originally
>     Scott> resulted in a change that some folks have referred to
> as "kludgy", that
>     Scott> being the on-the-fly modification of the selectors you
> can do to after
>     Scott> dhcp to avoid the second sa negotiation.
>
>     Scott> We should back up a bit, as there is something really
> fundamental that
>     Scott> should be called out. Not all ipsec users have the
> same security
>     Scott> requirements, so ideally, the mechanisms we design
> should be adaptable
>     Scott> to varying levels of security, depending upon one's needs.
>
>   No, I want to back up further.
>
>   The only reason to carry the DHCP over the IPsec SA is because you've
> figured out a way to *reuse* an existing DHCP client
> implementation.  I want
> to hear from multiple people who implemented this that they were actually
> able to preserve the DHCP client code.
>
>   I can see that this may work for bump-in-the-stack people... but if you
> have a bump, you have complete control on where the packet goes.
>
>   I do not see how carrying this info over an IPsec SA is at all
> workable for
> implementations that have IPsec in the stack. In the case of the KAME
> implementation, for instance, there isn't even a virtual
> interface on which
> you could run the dhclient on.
>
>   The kludge, to me, is using an IPsec SA at all for this.
>   I think that the DHCP payload should be encapsulated in IKE.
>
> ]       ON HUMILITY: to err is human. To moo, bovine.           |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON
> |net architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/
> |device driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking,
> security guy"); [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
>
> iQCVAwUBPjq1AIqHRg3pndX9AQEd1gP/ZwbzDqY5G6ueKr71ei29o6bIP+ACO6LA
> LxgAG8+mXObjhy/njQDXNPxcbeK2gEXVCzguyv0TUZ1cG80+5e4f/vkVAD4twpjz
> LFOyzDDzJNJIqY+vQkduuu/fS5lPKsQB2q/4pjaeYw554f/voun3ZkV/E/IgC5oH
> whe/X3bjbo0=
> =5KUI
> -----END PGP SIGNATURE-----