[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Configuration portion of OPEN ISSUES...
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Bill" == Bill Sommerfeld <sommerfeld@east.sun.com> writes:
>> *Keep configuration payload and allow optional unicast DHCP
>> configuration after phase 1 is complete.
>>
>> 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.
Bill> You should have heard people (including myself) say that any
Bill> configuration scheme within IKE should reuse as much of DHCP syntax
Bill> and option codes as possible rather than defining a wholly new
Bill> parameter space.
I want to emphasis that just because one says "DHCP-over-IKE", that
does not mean that such a system has to talk to a DHCP server. Decoding
DHCP messages is no more difficult than radius, PPP or IKEv2. (Maybe
a lot easier than IKEv1)
You can implement the relevant pieces in the gateway. DHCP vs modecfg
can be just about syntax.
I will fill the state machine changes, and suggest text for dhcp-over-ike,
but I won't bother if there is no interest.
] 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
iQCVAwUBPl1J+YqHRg3pndX9AQHMRgP9EEaKTJVVrKoz+P87fsj52uFIq0uKTdSW
8lvf89beo60rPR4sxIQwXptmYEMbCQqqgvNJR4eHf1fhZ64PhAY4/cWK1VgMjnZn
fqxoSdEobN2fTiDQILqhUBGnQFhu7cpoxoNxhbpPzcFoxjRZ01P4p67NHCoi9JtX
tQQiE/IrQkI=
=m1sI
-----END PGP SIGNATURE-----