[strongSwan-dev] DHCP plugin enhancements

[Thor Simon]

The attached patch implements some enhancements and bugfixes to the DHCP plugin which may be useful in enterprise environments.  They are mostly concerned with correct operation as a unicast "relay", particularly when operating with redundant (failover) DHCP servers.

FEATURES:

1)      New "relay_addr" parameter to control the source address used when sending DISCOVER messages unicast.  This address generally must be on the network on which the clients are desired to be allocated addresses; before, there was no way to ensure that particular interface of the system would be used.

2)      New "release_on_delete" parameter allowing the administrator to prevent DHCP RELEASE on IKE DELETE, since this will cause some DHCP servers to in turn delete their state for a given client.  If DHCP without hard reservations for clients is being used, but stable client addresses are desired when possible, try release_on_delete=yes.

3)      New "extra_dst" parameter allowing specification of a second (failover) server which should be sent a copy of all DISCOVER messages when operating in unicast relay mode.  Once the first response is received, subsequent messages will be unicast only to the server which responded.  This behavior matches that of most layer 3 switches when operating in "dhcp helper" or "dhcp relay" mode and conforms to  draft-ietf-dhc-failover-12 section 3.

BUGFIXES:

1)      Set "giaddr" (gateway address) in messages when operating as a unicast relay.  Without this, servers on networks which are not directly connected cannot be used.

2)      When running as a unicast relay send from port 67, not port 68, per RFC2131 section 4.1.

3)      Maintain elapsed seconds field in DISCOVER messages, so server can tell we're retrying.  Necessary for failover with ISC DHCPD or Infoblox servers and probably others.

4)      Do not truncate long client identities into the DHCP Client-ID field - this has particularly ugly effects when certificates are in use since many enterprise certificates may be identical through the first 64 bytes in encoded form.  Instead, encode them according to RFC4361, but using the DUID-UUID identifier format from RFC6355.

Diff is against 5.6.0.  We hope this is useful to others.

Thor Simon
Two Sigma Investments, LP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20180206/e4e61ded/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dhcp.diff
Type: application/octet-stream
Size: 12337 bytes
Desc: dhcp.diff
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20180206/e4e61ded/attachment-0001.obj>