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

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 09 Apr 2003 17:19:17 -0400

Last week on Thursday, Tero Kevinen has submitted three drafts (*) that
define DHCP over IKE.  Comments to these documents are solicted, and
thoughts about whether this approach is superior or inferior to the
currently specified Configuration payload in ikev2-06 are hereby
solicited.

(*) Tero, go ahead and submit them as IPSEC wg I-D's --- Barbara and I
will approve them as working group documents.

---

From: "Darren Dukes" <[email-masked]>
Date: Thu, 10 Apr 2003 23:04:09 -0400

I mostly see the DHCP-over-IKE as a bits on the wire change from CP.  The
biggest differences between the two are:
1 - With DHCP backend DHCP-over-IKE does not necessarily require SGW to
store DHCP state while CP requires a DHCP client on the SGW per IKE-SA.
2 - DHCP-over-IKE extends the IKE_AUTH exchange, similar to what EAP does.
3 - With DHCP backend DHCP-over-IKE offers end to end DHCP which may be
useful for future DHCP options but I see no clear advantage today with
current DHCP.
4 - With non-DHCP backends there is little to no difference between the two
options.

DHCP-in-IKE will satisfy what I think IKEv2 needs for address assignment, I
don't know if the differences are significant enough to change things for
rev07.  I would like to know what others think.

I've included a pro/con list for the two I used to come up with the stuff
above, if you have more then add to this list.

Pro DHCP-over-IKE
~~~~~~~~~~~~~~~~~
+ Uses standard DHCP messages, and state machine on client
+ SGW may be able to be relatively stateless with DHCP backend (if DHCP
server supports the DHCP relay options)
+ Allows end to end DHCP client address assignment with DHCP server (may be
useful in the future but no current need)
+ Makes possible standard DHCP address re-assignment to local and remote
clients (only useful/likely in very small networks)
+ Integration with RADIUS and DHCP (LDAP, etc. should not be a big deal)

Con DHCP-over-IKE
~~~~~~~~~~~~~~~~~
- Minimum addition of 280 bytes to IKE messages, more options will make this
bigger.
- Extends IKE_AUTH exchange (but EAP does this too).
- When DHCPDISCOVER will be to an unauthenticated peer (true for CP as well
but DHCPDISCOVER may have many options that may be dangerous to give to an
attacker impersonating the SGW, recommend sending _minimal_ DHCPDISCOVER).

Pro CP
~~~~~~
+ Small payload size
+ Similar to IKEv1 modecfg
+ Integration with RADIUS and DHCP (LDAP, etc. should not be a big deal)

Con CP
~~~~~~
- No end to end DHCP negotiation, SGW must be DHCP client
- No DHCP standard way to assign the same address to clients when physically
on the LAN and when connecting via ipsec (Likely only useful in very small
LANs)
- Does not use DHCP state machine end to end may have future impact
- When a DHCP backend is used the SGW will need to actively communicate with
a DHCP server and keep DHCP client state

Darren

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Theodore Ts'o
> Sent: Wednesday, April 09, 2003 5:19 PM
> To: [email-masked]
> Subject: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload
>
>
>

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 11 Apr 2003 15:29:19 -0400

Darren, thanks for your good summary of the pros versus cons of DHCP
over IKE vs. Configuration Payload.  Only one thing was missing: your
weighing on which proposal you think is superior.  :-)

To the rest of the list, the amount of comments on this item has been
extremely underwhelming.  Barbara and I would like to call on
supporters of the two proposals to send their comments to the list
ASAP.  We note that in San Francisco the wg had decided that in the
absence of strong support, the default would be to stay with the
existing text in the ikev2 document (Configuration Payload).

						- Ted

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 11 Apr 2003 17:15:15 -0400

As should surprise nobody, I strongly support the use of DHCP over IKE
instead of the config payload approach for a number of reasons.

Among other things it coexists better with existing non-IPsec network
infrastructure and provides a better future expansion/extension path,
and avoids a bunch of redundant standardization work.

					- Bill

---

From: Derek Atkins <[email-masked]>
Date: 11 Apr 2003 16:51:35 -0400

Personally, I dont have a strong opionion on DHCP-over-IKE vs.
Configuration Payload.  Both provide the necesaary security hooks I
think need to be there, so it's mostly a syntactic, performance, and
extensibility issue, rather than a major semantic issue.

The question is whether the syntax, performance, and extensibility
issues point at one towards the other.  I think Config Payload wins on
performance, and DHCP-over-IKE wins on extensibility.  DHCP certainly
wins in terms of using end-to-end DHCP authentication, but that
implies the use of a DHCP infrastructure.  If the Security Gateway
backend is using something other than DHCP then it's probably more
work to use DHCP... I think it's probably a toss-up over syntax ;)

Ted, I'm sorry this doesn't help add weight to one side or the other.
I'm just as happy with flip-a-coin...

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: "Darren Dukes" <[email-masked]>
Date: Fri, 11 Apr 2003 17:37:35 -0400

To me it's a bits on the wire change.  I don't particlarly like the 280+
bytes extra or the extra round trips but I don't think they are evil.  DHCP
end to end may be good in some cased but don't see it as a necessity (others
opinions differ here).  I'm leaning toward CP just because it's in the
current rev.

Darren

> Sent: Friday, April 11, 2003 3:29 PM
> To: Darren Dukes
> Cc: [email-masked]
> Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload
>
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Apr 2003 17:52:04 -0400

>>>>> "Derek" == Derek Atkins <[email-masked]> writes:
    Derek> issues point at one towards the other.  I think Config Payload
    Derek> wins on performance, and DHCP-over-IKE wins on extensibility.
    Derek> DHCP certainly wins in terms of using end-to-end DHCP
    Derek> authentication, but that implies the use of a DHCP infrastructure.

  The use of DHCP syntax on the wire does not imply that a DHCP
infrastructure must exist.

  If you want to build a self-contained gateway box that manages its own
address pool (on the box irself), then you can do that.
  If you want to translate to other infrasture (radius), Tero has documented
how to do that. 

  Tero also argues that if you are using Radius with EAP, that your round
trip count is already larger than 4, so DHCP does not add to it.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Ravi <[email-masked]>
Date: Sat, 12 Apr 2003 15:58:26 +0530

Hi Bill,
I prefer configuration payload for serving the IP address,
Domain name servers and other information. 
It gives flexibility in the deployment and the configuration 
can be configured locally OR configuration can be retrieved
from the DHCP Server OR other mechanism. So, by de-coupling
the serving IP address from specific protocol like DHCP 
will give lot of flexibility.

-Ravi

-- 

The views presented in this mail are completely mine. The company is not 
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>

---

From: [email-masked]
Date: Sun, 13 Apr 2003 22:19:08 -0400

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Apr 2003 12:13:00 -0700 (PDT)

> Tero's proposal describes how to deal with all these cases, but it's

Charlie,

Neither of these seems like a big deal to me. In
fact, knowing the destination of the relay
*constrains* the problem space, not the other way
around. Also: many protocols which have both a
reliable and unreliable transport face these same
questions (DNS, SIP...), so the how-to doesn't
seem too hard to overcome.

 > would want to set up the IPsec connection, get an IP address, and then run

Well, there's that too, but I get the impression
that config-over-IKE is pretty well ingrained so
trying to excise that mindset at this point is
pretty hopeless. Thus to my mind, lesser of evils
is to beg, borrow and steal and punt as much work
as possible to other wg's that actually care about
this sort of thing...

	  Mike

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 14 Apr 2003 16:02:59 -0400

> as possible to other wg's that actually care about

Indeed.  My sense is that configuration is not an area of expertise
for the members of this WG, and incorporating DHCP as-is is a better
solution than trying to reinvent a wheel here.

					- Bill

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Apr 2003 23:34:40 +0300

> Last week on Thursday, Tero Kevinen has submitted three drafts (*) that
			       ^
> currently specified Configuration payload in ikev2-06 are hereby

As you can guess, I prefer the DHCP over IKE :-)

> will approve them as working group documents.

I sent them out few minutes ago.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Apr 2003 20:53:55 -0400

Charlie> DHCP. Do we envision using the advanced capabilities of DHCP to do
    Charlie> things like booting over the IPsec connection? If so,
    Charlie> encapsulating 

  Very few devices (by installed base) use DHCP to boot.
  Yet, when the DHCP server went down at IETF on Sunday, it was a crisis.
  
  The whole point of DHCP is that what Michael Thomas says:

    Michael> pretty hopeless. Thus to my mind, lesser of evils
    Michael> is to beg, borrow and steal and punt as much work
    Michael> as possible to other wg's that actually care about
    Michael> this sort of thing...

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Apr 2003 10:23:35 +0200

In your previous mail you wrote:

=> I agree: for instance the CP stuff is not the proper solution
for IPv6 and nobody'd like to spend some years to fix it (remember
DHCPv6 :-).

Regards

[email-masked]

---

From: Derek Atkins <[email-masked]>
Date: 15 Apr 2003 12:36:11 -0400

> infrastructure must exist.

The converse is just as true.. Not using DHCP syntax on the wire dos
not imply that a DHCP cannot exist....  It's all just a translation
issue at the security gateway -- a gateway which must be involved in
the configuration path anyways in order to read the address and set
traffic selectors.

>   If you want to translate to other infrasture (radius), Tero has documented

Sure, but it works in reverse, too -- the IKE Daemon on the security
gateway needs to be able to translate from whatever Foo-over-IKE we
choose to whatever actual configuration protocols are in use.  So
what?  It's no easier to implement a DHCP to RADIUS converter as it is
to implement a CP to RADIUS converter.

Similarly, are there actual DHCP libraries available?  The ISC DHCP
software certainly doesn't install "libdhcp" anywhere on my system.
Are there other DHCP client libraries that are available, so IKE
implementors don't need to implement DHCP as well as IKE?

> trip count is already larger than 4, so DHCP does not add to it.

Yea, sure, but is that necessarily that "common case" when using IKE
Configuration?  In other words, do we expect that IKE Configuration
will be used simultaneously with EAP the vast majority of the time?
Or do we think that it will be used just as often with other forms of
authentication, like RSA certs?

On another note, can you even start the configuration process before
EAP finishes?  I'm not convinced you can run it concurrently with EAP,
which implies that the extra messages from EAP and then DHCP would
have to be serialized, making the exchange even longer!  I say this
because I don't see how a server can respond with a DHCPOFFER until
the client has authenticated (e.g. EAP finished).

Am I missing something?

-derek

---

From: "Darren Dukes" <[email-masked]>
Date: Tue, 15 Apr 2003 14:37:51 -0400

> the client has authenticated (e.g. EAP finished).

Nope, you are correct.  DHCP should be done after EAP, the same as CP is
done after/with the last EAP message.  I think implementations could get
clever and block DHCPREQUESTs until after the client authenticates, but it
seems simpler to require the client side to start the DHCP-over-IKE exchange
after EAP completes and the client is authenticated.

Darren