RE: Proposed Configuration payload for IKEv2

[Charlie_Kaufman@xxxxxxxxxxxxxxxx]

>Wouldn't it be simpler to use DHCP all the way i.e. the construct
>DHCPClient-Relay-Server ?

I initially had the same thought, but was talked out of it. Let me repeat
the logic that convinced me, and see if it does anything for you.

The bottom line is that while I believe this would be possible, I don't
believe it simpler. The problem is that DHCP runs over IP only though heavy
kludgery. Since you don't initially know your IP address, you must send
initial DHCP messages from IP address zero and get responses either via
your hardware address or by multicast. If we wanted to tunnel these
messages over IPsec protected ESP, we would have to first set up an ESP SA
tunnelling packets from address zero to a broadcast address, and then after
the IP address becomes known set up a new ESP SA with the new address. I
would expect some substantial confusion with the packet forwarding tables
on the server, and a lot of special casing.

Alternatively, we could run DHCP over the IKE SA instead of over a special
ESP SA set up for that purpose, but this requires even more special casing
for what the endnode fills in for hardware address, etc.

I would think a not unlikely scenario would be where a user has a permanent
internal IP address and the IPsec gateway wants to assign that internal IP
address based on the user's identity (independent of what address the user
is tunnelling from). This would require more special case kludgery if we
wanted the negotiation to look like DHCP but use other fields from the IKE
messages.

DHCP is capable of carrying lots of kinds of information. Except for
dynamic IP address, all of it is obtainable after you have your IP address
- and in fact it works more smoothly and efficiently once that happens. So
my second thought was that IKE be capable of negotiating an internal IP
address after which DHCP tunnelled over ESP could be used for obtaining any
other information desired. This would work, and it's my understanding that
an endnode could use this mechanism to get DHCP-based information not
available through IKE. Throwing a few more commonly used parameters into
IKE - like the IP address of a DNS server - is clearly unnecessary but will
simplify the common case of implementations that only want that additional
information. I could be convinced either way on that one.

I had another objection to the design I added to ikev2-04. If we're going
to negotiate IP address leases over IKE, it would seem like the lease
should last for the duration of the ESP SA rather than expecting the client
to periodically renew it. This would require some additional state on the
server (renewal timers), and would require that the server close the ESP SA
if it were ever unable to renew the lease, but it would simplify the
client, simplify the minimal IKE implementation,
and reduce the number of error states we could get into. I believe this
would be an improvement, but gave in to people who understand this stuff
better than I do. But if others with more confidence would like to argue
about it...

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).