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

From: [email-masked]
Date: Mon, 14 Apr 2003 15:00:26 -0700

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

---

From: "Jing Xiang" <[email-masked]>
Date: Tue, 15 Apr 2003 11:54:28 -0400

I would prefer that we stay with CP for its simplicity & performance.

I don't have any technical arguments against DHCP. It's just I failed to see
any added benefits for its complexity if all we are using is just an ip
address 
configuration in most cases. 

/Jing

Jing Xiang (jxiang@nortelnetworks)
Nortel Networks 
Contivity Engineering
(978)288-8985 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Monday, April 14, 2003 9:02 PM
To: [email-masked]
Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload

Some comments on others' postings:

"Theodore Ts'o" <[email-masked]> wrote:
> 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).

I'm concerned that in the past such a statement has caused the
people who agree with the current state to ignore the debate but
energize those who disagree. People who care should speak up!

"Scott G. Kelly" <[email-masked]> wrote:
> I think Darren's summary is pretty accurate. It's kind of a toss up.
> However, one difference that I note is that with the dhcp approach, all
> client config is (potentially) done prior to the instantiation of the
> child sa. I'm not sure if this is a benefit or not, but it might be.

This will be a blessing in some circumstances and a curse in others.
While doing client config early makes for a simpler boot rom, it
means that a site must be willing to give out client config information
to anonymous requestors (or else place additional requirements on
ordering of authentication messages and state machines within IKE
processing. In most scenarios, I wouldn't expect it to matter.

Michael Thomas <[email-masked]> wrote:
> I'm not entirely sure how impolitic this is wrt my
> employer's hive mind, but the thing that really
> tips my feeling about this is that DHCP-in-IKE
> keeps the IPsec wg out of the business of dealing
> with... configuration. That seems like a huge boon
> in my mind from a wheel-reinvention standpoint.
>
> So, mark my preference as DHCP-in-IKE.

There are two ways CP might evolve in the future. CP has
a syntax clearly designed for extensibility, and hence is
an "infection site" for architects who want to add
configuration options in the future in one more
different way. I find that
prospect scary. But it doesn't have to happen. If our
successors show restraint, they will not enhance CP to
include information that could better be sent over DHCP.
DHCP can be effectively tunnelled over ESP, and could (and
should) be used for such extensions. The configuration step
of allocating an IP address is special because it results
in information necessary for configuring the ESP SA. It
therefore can't be done over the ESP SA without significant
kludgery (though someone did make it work with IKEv1).

          --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: Tero Kivinen <[email-masked]>
Date: Wed, 16 Apr 2003 05:30:18 +0800

[email-masked] (Derek Atkins) writes:
> 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.

It is harder to generate CP to DHCP converter, because some of the
necessary information is not available in the CP. On the other hand if
we do add all the information that DHCP have to the CP, then we have
just duplicated the DHCP...

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

The easy way to do is to create virtual interface and allow normal
operating system to run dhcp over it. When those dhcp packets arrive
to the ipsec processing engine it will cause trig to the usermode and
usually it will also send the packet along to the usermode. Then the
usermode IKE can take this dhcp packet and stuff it inside the IKE and
send it forward. When the reply DHCP packet comes then the usermode
IKE forwards those packets back to the tunnel and to the real dhcp
client, which will then reply to them and again the engine will pass
those to the usermode IKE to be sent inside the IKE.

This kind of stealing all dhcp packets from the tunnel is needed
anyway, thus using that to get the initial bootstrap dhcp packets is
also very easy way to do.

The actual implementation in the IPsec engine is very small (when dhcp
packets are seen, send them to IKE, when IKE asks the engine to send
packet to local tunnel send them to there).

The implementation in the IKE is even simplier, simply take the dhcp
packets coming from the engine and stuff them in the next IKE packet
you are going to send, and if the other end send dhcp packet inside
the IKE, then send them to local stack. Zero dhcp packet processing is
needed there... :-)

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

Some people say that definately, some say that never... :-) I don't
know. 

> On another note, can you even start the configuration process before
> EAP finishes?

With dhcp backend yes, and it can even finish before that.

With radius backend, it depends. Some radius servers might give out
the configuration information before the EAP finishes, some might.
With internal backend yes or no depending on the policy.

In case of real dhcp backend the gateway might want to release the
lease if the client has already finished the dhcp, but then the EAP
fails, or it might be so that dhcp server is using short enough leases
that it does not matter if they are given out for some time even
without real authentication. 

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

In some radius servers that will happen. On the other hand you can
configure the radius server to allow responding to the configuration
requests before authentication if needed. 

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

As far as I understand radius then it can respond to configuration
attributes at any packets, thus it can give the configuration
attributes out when the first radius packet is done (i.e when the EAP
starts). After that the sgw will know all configuration thus it can
create the needed dhcp packets simultaneously to the EAP process.

I do not know if any actual radius servers/clients can be configured
to do so, but I would assume that they allow that kind of operation
too.

Ps. I will be on the vacation for about two weeks starting tomorrow,
so I might not be able to reply to questions before that. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Wed, 16 Apr 2003 13:28:04 -0400

>requests before authentication if needed.

There's some danger involved in having the IKE daemon blindly forward DHCP 
packets from the peer onto the protected network, particularly if the DHCP 
happens *before* the user is authenticated. If there is a known exploit on 
the DHCP server then the DHCP packet could install a trojan. Also, the DHCP 
forwarding policy creates an extra channel for a pre-existing trojan on the 
protected network to communicate with arbitrary peers (not that there's 
likely to be any shortage of those).

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.

_________________________________________________________________

---

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 18 Apr 2003 18:16:51 -0700

I vote for CP.
And Darren and I can submit the draft we presented in SF to make life easy
for everyone to implement w/ DHCP, RADIUS, LDAP, etc.

> From: Theodore Ts'o [mailto:[email-masked]]
> Sent: Friday, April 11, 2003 12:29 PM
> To: Darren Dukes
> Cc: [email-masked]
> Subject: Re: CALL FOR DISCUSSION: DHCP over IKE vs 
> Configuration Payload
> 
> 
> 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
> 						- Ted

---

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 18 Apr 2003 18:22:31 -0700

I see this as both a pro and con. 

PRO - it gets it done earlier, in terms of the exchange process, whereas the
doc we wrote has the more extensive DHCP config occuring after CHILD-SA;
only the basics are done in IKE.

CON - it makes IKE heavier, more bytes (the more config options returned,
the more bytes) and thus IKE will take longer time-wise to complete.

Gregory.

> From: Scott G. Kelly [mailto:[email-masked]]
> Sent: Monday, April 14, 2003 9:37 AM
> Scott

---

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 18 Apr 2003 18:29:17 -0700

> Sent: Sunday, April 13, 2003 7:19 PM
> To: Theodore Ts'o
> Cc: [email-masked]; [email-masked]
--SNIP--
> reasons of simplicity. (If I were king, I'd pick a protocol that was

for example? But then again, its too late for that ;-)
 
> Tero's proposal describes how to deal with all these cases, but it's

agreed. Though CP isn't too much less awkward, we are all just more used to
it since we all implemented it already (or dang close to it) for IKEv1
ModeCFG.
 
> complex translating them to DHCP than translating them to CP. 

also agreed. But that's because CP was sort of designed for more with RADIUS
in mind than DHCP. Is that right, Darren?

> address routed to it (most likely by responding to ARPs).

Usually the whole pool and the routes to it are already entered in the
internal network's routing infrastructure. This is not an issue in all the
networks I've seen.

Gregory.

---

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 18 Apr 2003 18:33:01 -0700

> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Monday, April 14, 2003 1:03 PM
> To: Michael Thomas
> Cc: [email-masked]; Theodore Ts'o;
> [email-masked]; [email-masked]
> > 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...
> 
> 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

so the problem here is that we are assuming that the world uses only DHCP to
configure, when, from all my customer contact, it seems to me that people
use DHCP on local networks, but for remote access, especially the very large
ones, they tend to use RADIUS for configuration and authentication. This is
ESPECIALLY true of all my large enterprise customers.

---

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 18 Apr 2003 18:42:17 -0700

> From: Darren Dukes [mailto:[email-masked]]
> Sent: Tuesday, April 15, 2003 11:38 AM
> To: Derek Atkins; Michael Richardson
--SNIP--
> > EAP finishes?  I'm not convinced you can run it 
> concurrently with EAP,
> > have to be serialized, making the exchange even longer!  I say this
> > Am I missing something?
> 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.
> 

In the case of a RADIUS back-end, the EAP is absolutely required, because it
is the only way to get the credentials by which to lookup/validate the user,
by which to know which configuration parameters to offer them. 

This is all detailed out in the draft darren and I wrote. (We never got to
submitting it... sorry). It's at VPNC:
 
 <http://www.vpnc.org/temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt>

---

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 18 Apr 2003 18:46:21 -0700

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Tuesday, April 15, 2003 2:30 PM

--SNIP--
> so I might not be able to reply to questions before that. 

He's not here to defend himself. CP wins!!!!
 <smirk> Just Kidding ;-)

---

From: [email-masked]
Date: Mon, 21 Apr 2003 10:53:35 -0700

Hi Gregory,

Well, I probably wasn't clear, but I wasn't referring
to sending the server addr.  I'd like to see a CP
payload type that encapsulates the DHCP.  Tunnelling
DHCP in CP in IKE.  Getting kinda waist-deep here, but
it gives me what I'd like, which is a way to get a
DHCP packet generated by the OS over to the DHCP server.

Just to clarify Ted's list, without this mechanism, I'd
vote for DHCP-over-IKE, as CP alone does not provide
what I want.

Regards,

Jim

-----Original Message-----
From: Gregory Lebovitz [mailto:[email-masked]]
Sent: Friday, April 18, 2003 6:36 PM
To: Jim Knowles; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, April 14, 2003 3:00 PM
> To: [email-masked]; [email-masked]
--SNIP--

> happy or make everybody mad.

That is what Darren Dukes and I proposed in the doc we wrote and presented
in SF. Send a DHCP server addr in CP along w/ IP and DNS/WINS (if needed)
and do the rest of the DHCP extensions via INFORM in protected by CHILD-SA.