Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload

[Charlie_Kaufman@notesdev.ibm.com]

Having read Tero's DHCP over IKE proposal, I continue to believe that while
either DHCP or CP could be made to work that CP is the better choice for
reasons of simplicity. (If I were king, I'd pick a protocol that was
simpler than either).

While it's attractive to reference DHCP rather than define a subset of it
in order to shorten the spec, Tero's drafts make it clear that using DHCP
won't shorten the spec because of the integration issues that would need to
be added. DHCP was designed to run over an unreliable datagram protocol
with broadcast capabilities for server discovery. IKE is a reliable
request/response protocol to a single peer. So running DHCP over IKE
requires that we specify how DHCP timeouts get handled and how to deal with
the case where the responder has a packet but it's not his turn to talk.
Tero's proposal describes how to deal with all these cases, but it's
awkward.

The strongest case for DHCP is when optimizing for the configuration where
the IKE responder doesn't itself allocate IP addresses to the IKE initiator
but rather acts as a DHCP relay to some DHCP server it accesses over a
network. Then there would be pretty much a one-to-one mapping between the
messages on the wire and the DHCP payloads in the IKE messages. But the IKE
endpoint would still be doing more processing than a DHCP relay since it
would have to parse the DHCP messages as it passed them through to learn
what address was assigned in order to put that address in the traffic
selectors.

When the IKE responder is allocating addresses out of its own pool or
getting them using RADIUS, it appears to me that processing would be more
complex translating them to DHCP than translating them to CP. My intuition
is that having the IKE responder lease addresses from its own pool will be
the common case, since if the address is acquired from elsewhere the IKE
responder will have to take some action to get traffic to the allocated
address routed to it (most likely by responding to ARPs).

So I continue to "not get it" in trying to understand the advantages of
DHCP. Do we envision using the advanced capabilities of DHCP to do things
like booting over the IPsec connection? If so, encapsulating all the
messages in IKE seems even more cumbersome. I would think the boot rom
would want to set up the IPsec connection, get an IP address, and then run
DHCP over ESP.

          --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).