[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Configuration payload for IKEv2
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman@xxxxxxxxxxxxxxxx> writes:
Charlie> Alternatively, we could run DHCP over the IKE SA instead of over a special
Charlie> ESP SA set up for that purpose, but this requires even more special casing
Charlie> for what the endnode fills in for hardware address, etc.
No, the endnode fills in the normal thing - its hardware address. It is
still unique, and still relevant to the DHCP server.
Charlie> I would think a not unlikely scenario would be where a user has a permanent
Charlie> internal IP address and the IPsec gateway wants to assign that internal IP
Charlie> address based on the user's identity (independent of what address the user
Charlie> is tunnelling from). This would require more special case kludgery if we
Charlie> wanted the negotiation to look like DHCP but use other fields from the IKE
I disagree. it is not kludgery - it is very intelligent reuse of protocols.
Let's be clear - only in rare cases client (i.e. inside MS-Windows) will
you get to reuse the DHCP client code. For pretty much everyone else
(including *nix systems) you have to at a minimum recompile dhclient code
into your IKE daemon.
The win is on the gateway side - there is only the one DHCP server, and it
can be pretty much any piece of code.
Charlie> - and in fact it works more smoothly and efficiently once that happens. So
Charlie> my second thought was that IKE be capable of negotiating an internal IP
Charlie> address after which DHCP tunnelled over ESP could be used for obtaining any
Charlie> other information desired. This would work, and it's my understanding that
Many of suggested that most of the PPP IP options should have been done
with the DHCP Inform over PPP IPCP.
Charlie> I had another objection to the design I added to ikev2-04. If we're going
Charlie> to negotiate IP address leases over IKE, it would seem like the lease
Charlie> should last for the duration of the ESP SA rather than expecting the client
Charlie> to periodically renew it. This would require some additional state on the
Charlie> server (renewal timers), and would require that the server close the ESP SA
Charlie> if it were ever unable to renew the lease, but it would simplify the
Charlie> client, simplify the minimal IKE implementation,
This sounds complicated to me. And adding state on the gateway is not a
good idea (please state "dhcp server" or "ipsec gateway").
If the address assignment on the gateway side is not done by the DHCP
server, then it has got to be coordinated - i.e. the gateway will have to
speak DHCP (client) to the real dhcp server. This just seems more complicated
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx 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
-----END PGP SIGNATURE-----