The attached patch is against unmodified 5.6.0 and implements the 
improvements/fixes from our first patch, plus also fixes an issue in which 
retransmits could occur too fast, "spamming" the DHCP server but not likely 
eliciting a useful response.  Description of the first patch:

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


From: dev-boun...@lists.strongswan.org 
[mailto:dev-boun...@lists.strongswan.org] On Behalf Of 
thor.si...@unverified.twosigma.com
Sent: Wednesday, February 7, 2018 8:12 AM
To: dev@lists.strongswan.org
Cc: Christos Zoulas <christos.zou...@twosigma.com>; Chris Zimman 
<chris.zim...@twosigma.com>
Subject: Re: [strongSwan-dev] DHCP plugin enhancements

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@lists.strongswan.org' 
<dev@lists.strongswan.org<mailto:dev@lists.strongswan.org>>
Cc: Christos Zoulas 
<christos.zou...@twosigma.com<mailto:christos.zou...@twosigma.com>>; Chris 
Zimman <chris.zim...@twosigma.com<mailto:chris.zim...@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

Attachment: strongswan-dhcp-revised.diff
Description: strongswan-dhcp-revised.diff

Reply via email to