[strongSwan-dev] DHCP plugin enhancements

[Thor Simon]

So, we were looking at some packet captures of unusual DHCP server behavior, and discovered the patch I just sent below has a residual bug: when it gets very busy, it can retransmit packets too soon, but adjust the elapsed second value in the packet as if it waited the full interval, then time out.

The result is INTERNAL_ADDRESS_FAILURE sent to the client, which unfortunately then stays connected but non-working (in our deployment we have a separate connectivity-check mechanism that fixes this).

In practice, a lot of load and a slow DHCP server are required to trigger this problem, but anyway I'll send another patch that has it fixed.  I am wondering though if when the client receives address-failure, it should perhaps bring the tunnel down or otherwise try to get itself unstuck?

Thor

From: Thor Simon
Sent: Monday, February 5, 2018 11:38 PM
To: 'dev at lists.strongswan.org' <dev at lists.strongswan.org>
Cc: Christos Zoulas <Christos.Zoulas at twosigma.com>; Chris Zimman <Chris.Zimman at twosigma.com>
Subject: DHCP plugin enhancements

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/20180207/666baefe/attachment.html>