[dhcwg] Text for draft-ietf-dhc-server-override

Stig's recent message reminded me this has been sitting in my edit buffer
a bit too long.  I think it's passed the point where more time in my
edit buffer will make it any better.

I promised Kim Kinnear some text, at least as a starting point, to help
describe better the situations this option might reasonably be used since
we seem to be fairly fuzzy on that point.

To those ends I suggest:

1.  Introduction

-  There are many situations where the DHCP relay is involved and can
-  insert a relay agent option with appropriate suboptions easily into
-  DHCP DISCOVER messages.  Once the lease has been granted, however,
+  When a DHCP Client is in the INIT, INIT-REBOOT, BINDING or REBIND
+  states (or at any time a client's DHCP packet is broadcast), it is
+  able to contact a local DHCP Relay which can insert a relay agent
+  option with appropriate suboptions easily into DHCP DISCOVER or
+  REQUEST messages.  Once the lease has been granted, however,
   future DHCP RENEWAL messages are sent directly to the DHCP Server as
   specified in the Server Identifier option.  This means that the relay
   may not see the DHCP RENEWAL messages (depending upon network
   topology) and thus can not provide the same relay agent option
   information in the RENEWAL messages.

+  The relay agent circuit-id option combined with others is often used to
+  identify a specific port in a Service Provider's network, and may be
+  tied to billing or even what pool of addresses the client is allowed to
+  allocate from.  An up-to-date value, in those cases where it may change
+  such that the client can maintain IP connectivity (such as is the case
+  with multiple switch ports on the same IP subnet), is useful to those
+  ends.
+
+  But there are several situations where the relay may wish or need to
+  remain a constant part of the communication between server and client,
+  which does not include the need to supply up-to-date relay agent
+  information options:
+
+  If the client and server were not connected in terms of IP routing,
+  such as may be the case if the client were attached only to a VPN,
+  and the server had no direct attachment (or is attached to a different
+  VPN).  In such a case, the DHCP client's RENEWAL can not be received
+  by the server, which causes the client ultimately to enter REBINDING
+  state in order to extend its lease.  This is undesirable as it presents
+  a momentary loss of network connectivity to the client.  The situation
+  already requires that a DHCP Relay Agent exist which straddles both the
+  VPN and publically routed networks, so that the initial message exchanges
+  can be relayed between server and client.  But such an agent would need
+  to remain a part of the conversation between Client and Server for clients
+  to successfully RENEW their leases, so that this cross-network relay
+  service can continue to function.
+
+  If the relay was administratively configured to maintain a running
+  state based upon observations in the DHCP protocol.  For example, there
+  exist a number of implementations already of IP Firewall services which
+  seek to provide additional limitations to clients on public networks
+  that refuse to negotiate with a DHCP server ("stealing a lease").  Such
+  implementations use the DHCP ACK messages transmitted by the DHCP
+  server to build a dynamic firewall ruleset which allows IP access to
+  only those leases that have negotiated an active lease with their
+  network's DHCP server.  In so doing, clients 'stealing' leases are
+  ultimately relegated to losing global IP connectivity (if they ever had
+  it to start with).  In order to maintain an up-to-date list of permitted
+  client addresses, the Relay Agent needs to remain a part of the
+  conversation between Client and Server during RENEW state.
+
+  If the Relay Agent and Server participated in DHCP Relay Agent
+  Authentication, or IPSec, or similar means to authenticate one another
+  to justify the hole presented in Firewall configuration to communicate,
+  but such means of authentication were not available to DHCP Clients
+  resting behind a firewall.  Under such a circumstance, an IP Source
+  Address that happens to match the desired DHCP Server is not sufficient
+  to guarantee DHCP security in a firewalled network.  Such a Relay Agent
+  would serve to secure its clients from DHCP vectors of attack by serving
+  only relayed responses to them, guaranteeing all responses come from the
+  trusted DHCP Server.  This produces the identical failure mode for DHCP
+  Clients in RENEW state as was previously described for VPNs, and the
+  identical solution set is needed.
+
   This new DHCP relay agent suboption, Server Identifier override,
   allows the relay to tell the DHCP server what value to place into the
   Server Identifier option.  Using this, the relay agent can force
   RENEWAL messages to come to it instead of the server.  The relay may
   then insert the relay agent option with appropriate suboptions and
   relay the DHCPREQUEST to the actual server.  In this fashion the DHCP
   server will be provided with the same relay agent information upon
   renewals (such as Circuit-ID, Remote-ID, Device Class, etc.) as was
-  provided in the initial DISCOVER message.  In effect, this makes a
-  RENEWAL into a REBINDING.
+  provided in the initial DISCOVER message.
+
+  This has the effect of making all DHCP REQUEST messages from clients in
+  the RENEW state appear to the DHCP Server as though the client were
+  instead in the REBIND state, and therefore may be subject to network
+  attachment correction (the transmission of a DHCP NAK message to inform
+  a client it is no longer attached to the network it is presently addressed
+  on).  This is unusual for a client in RENEW state, but not incompatible,
+  and may be correct behaviour under certain specific circumstances, as
+  documented in the APPLICABILITY section.

...jumping ahead...

+4. APPLICABILITY
+
+  DHCP Server Implementations today may not perform Network Attachment
+  detection upon receiving DHCP REQUEST messages, unless it was known
+  to be received on a local interface by broadcast means, or unless it
+  was received via a DHCP Relay Agent (the giaddr field is nonzero),
+  which until the Server-Override suboption assures it was received on
+  a remote interface by broadcast means.
+
+  Consequently, this option is only applicable to environments where the
+  DHCP Relay and Server will collude to conclude correctly about the
+  actual network to which the Client is attached when it is in RENEW state.
+  This is a combination of the specific means the Relay will mark the DHCP
+  packet to identify its source of origin, and the compatible use by the
+  DHCP Server to determine the point of attachment of the client.
+  
+  This is the case under the following Applicable Environments, but MAY
+  NOT be the case otherwise, where this option SHOULD NOT be used.
+
+4.1. SIMPLE USE CASE
+
+  The DHCP Relay MUST select a Server-Override IPv4 Address which is an
+  interface address local to the subnet that the DHCP Client will be
+  addressed upon.  This carries some additional limitations:
+
+   o There is only one IPv4 subnet on the broadcast domain.
+   o There are multiple IPv4 subnets on the broadcast domain, but the DHCP
+     Relay Agent somehow knows in advance which one the client will be
+     addressed upon.
+   o The DHCP Client's implementation MUST prefer to use locally connected
+     routes to acheive the Server-Identifier, rather than to select
+     another Internet-connected interface for any reason (such as relative
+     speed, reliability, or power consumption).
+
+  By providing an address that is link-local to the DHCP Client at all
+  times, it can be assured that the client will utilize that local
+  network attachment rather than favoring any additional network
+  interfaces default routers.  This stipulates client behaviour that is
+  not specified in any DHCP protocol RFC, but is not known to be
+  implemented otherwise.
+
+  Should the DHCP Client roam to another network, and through some
+  contrivance still be able to exit its local subnet (such as might
+  be the case if both networks DHCP Relays utilized VRRP, tagged VLANs,
+  or any mechanism that produces non-unique MAC addresses), the client's
+  IP Unicast is likely to reach the DHCP Relay.  DHCP Relay behaviour in
+  this circumstance is undefined - it may either elect to indicate the
+  client is attached upon the interface the packet was actually received
+  upon, or it may elect to indicate the interface of the address the
+  client unicast its REQUEST to (the Berkeley Socket or similar from
+  which the packet was read).  It is expected that the DHCP Server will,
+  upon performing Network Address detection, emit either a DHCP NAK or
+  ACK respectively, but only in the NAK case is it possible this message
+  might reach the DHCP Client in question (assuming it is actually
+  connected to that location).
+
+  For this reason, DHCP Relay Agents SHOULD make all indications for
+  Client attachment based upon the actual physical interface the packet
+  was received upon.
+
+4.2. PRESENCE OF ADDITIONAL INFORMATION
+
+  Future DHC WG work includes defining additional Relay Agent flags
+  fields to allow a DHCP Relay to indicate wether the received packet
+  was an IP Unicast to one of the DHCP Relay's IP addresses or "not"
+  (implying the DHCP Relay received the packet via some form ofbroadcast).
+
+  In such a case, where the DHCP Relay makes use of this option, all
+  environments become applicable under the following conditions.
+
+   o The DHCP Server MUST NOT perform Network Attachment detection when
+     the DHCP Relay indicates the client packet was Unicast, and so no
+     DHCP NAK must be transmitted for this reason.
+   o The DHCP Relay MUST unicast the Server's DHCP response to the IP
+     address indicated in the 'ciaddr' field.  It MUST NOT use the normal
+     means to determine which interface to transmit the packet.  Instead,
+     normal IP Routing to the 'ciaddr' contents MUST be used.  This MAY
+     NOT be the interface to which the client is actually attached, and MAY
+     NOT be the interface from whence the DHCP Client packet that
+     precipitated a response came from.

I thought there was a third case, but I seem to have simplified it
into the simple case as I was editing.  I have this nagging feeling
I'm forgetting an environment discussed at IETF 65.

While thinking about this, I came up with some network diagrm
distillations of 'does not work' environments which I'm trying to make
"not applicable", thanks in whole to the discussion on this mailing list
and at IETF 65.  Of those, I find this one the most salient:

		+-------------+
		| DHCP Client |
		+-------------+
	10.0.0.x eth0 | | wi0  10.0.1.y
		      | |
	10.0.0.1 eth0 | | eth1 10.0.1.1
		+-------------+ eth2			+-------------+
		| DHCP Relay  |----------[Internet]-----| DHCP Server |
		+-------------+				+-------------+
		lo0:1 10.255.255.1

In the above, if the 10.255.255.1 address is used in the server-override,
all DHCP REQUEST messages sent in unicast (RENEW) will be sent via one of
the default routers selected by the DHCP Client.  Implementations vary,
but the most sensible would be to use the wired ethernet (because it has
the lower number).

If the server performs network attachment detection in this case,
as it will if giaddr is set, it will NAK one of the two incorrectly,
and that NAK packet will be able to reach the client.

After all our time running around this bush, I think the above diagram is
the most lean distillation of 'the problem' I've seen yet.  It may be
easier to just throw this network diagram in, or one like it, and explain
how it causes false network attachment detection.  "Don't do that then"
etc.

I think I've used enough 'ink' at this point however, so if someone else
wants to take a stab...

It's also amusing (and I include this for those ends explicitly) to
consider the logical extension of the use of this option by IP Firewall
environments:

	+-------------+		+-------------+		+-------------+
	| DHCP Client |		| DHCP Client |		| DHCP Client |
	+-------------+		+-------------+		+-------------+
	10.0.0.x |		10.0.1.x |		10.0.2.x |
		 |			 |			 |
	10.0.0.1 | /24		10.0.1.1 | /24		10.0.2.1 | /24
	+-------------+		+-------------+		+-------------+
	| DHCP Relay  |		| DHCP Relay  |		| DHCP Relay  |
	+-------------+		+-------------+		+-------------+
	      |			      |			      |
	      \------------[Routed Private Network]-----------/
				      |
			 10.255.254.1 | /24
				+-------------+
				| IP Firewall |	lo0:1 - 10.255.255.1
				+-------------+
				      |
				[More Routing]
				      |
				+-------------+
				| DHCP Server |
				+-------------+

At broadcast, each individual DHCP relay on these networks picks up the
client.  They're in the game until the clients are addressed.  Let us
imagine they set giaddr to their inside-interface address (the listed
10.0.x.1's), do not supply subnet-select, and provide relay agent options
that include a server-override set to 10.255.255.1.

They may or may not transmit the client packets to this second relay on
the firewall, but in either case the server responses go direct to the
first relay, so the IP firewall at best is only half inside the loop at
that stage, then fully in the loop once the clients are unicasting renews
to the firewall directly.

So, in this environment, you'd have to know the likely initial lease
time to apply to the lifetime of any dynamic firewall rules (which
you would then apply to the requested address of any DHCPREQUEST got
via relays, speculating they will succeed), and this can be more easily
enforced if you also control the DHCP Server.  This is only useful if
you're trying to keep ip routing off of clients that don't want to
emit DHCP packets at all (the DHCP server may still not allow them),
uninvited guests.

So alternatively you could engineer a backchannel and get the lease time
out of acks sent to the first line relays.

Or even more alternatively, you could purposefully give out a very short
lease time to initial bindings so there's an immediate renewal via the
firewall, then give out longer lease times now that the relay can see
them.

Or even further off the alternatives beaten path where the weeds grow
thick, they could not set giaddr, provide a relay agent information
option that includes a server-override set to 10.255.255.1 and a
subnet-selection option, and forward the packet to the IP firewall
(which will not touch the relay agent options, but will put an address
of its own on giaddr).  You would expect the IP Firewall would have to
have a way to reach the first line relay.  Let us imagine the first
line relay is known to encode this in the agent options.

Whatever the case, the clients are cetainly never attached to
10.255.254.0/24, so performing network attachment detection is rather
pointless, and broken in this environment.

Given those worst possible cases, I tried to provide reasonable
guidance in that applicability section to steer people away from use
here unless agent options start telling us their unicast or broadcast
status.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins