Re: Proposed Configuration payload for IKEv2

[Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>]

-----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
    Charlie> messages.

  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

  DHCP Inform.
  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
to me.

]       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

iQCVAwUBPiHiE4qHRg3pndX9AQHDlQQAtf9R0C8bnBRN0TW/BAjD8kjSQAAZRUtd
kioPH/9bGkgAOpsXZ1Dl+vPfEds/EXKWFiE49VGtEfcBdkE6mnNgc0Lvbg1pAY3A
u+1fVA1/9n/3gfsfMrJx2osHdk58MZVVb2pnRWE5PnXdnMXbr64Xh1ThW+hcxizB
yK8um6ppLJ4=
=U0ZZ
-----END PGP SIGNATURE-----