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

[jknowles@SonicWALL.com]

Hi Charlie,

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

OK, Charlie for King!

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

Seems fair to say there is added complexity due to IKE/DHCP
interaction.  Since IKE is "reliable", I'm not sure how much
added complexity there is, other than dealing with timeouts.
I think DHCP and CP are not too far apart in terms of
message structure complexity.  

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

There will be parsing when doing DHCP proxy, as suggested by the
CP authors, right?  We need DHCP support one way or another (some
of us at least).

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

Routing issues have to be dealt with no matter who allocates
the address.  Regarding the common case, certainly DHCP
interaction is "a" common case, though maybe not "the" common
case.  
> 
> 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.

I'm not envisioning advanced capabilities, although having a
standard way to offer them is nice.  By "advantages of DHCP",
I assume you mean "DHCP in IKE".  The main advantage I see
is that there are standard mechanisms for a remote client to
issue DHCP requests and no standard mechanism for CP requests,
(I'm speaking about OS capablities, not IKE client capabilities)
so I don't have to translate the DHCP at all if I'm using a
DHCP server.  Of course, using RADIUS, LDAP, or internal gateway
address space will require translation.  Maybe the entire
argument comes down to your point above about the "common"
case.

Lately, I've been wondering if we can't just add an optional
DHCP CP payload type.  Not sure if that would make everybody
happy or make everybody mad.

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

Regards,

Jim