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

[Tero Kivinen <kivinen@ssh.fi>]

derek@ihtfp.com (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. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/