[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-----