Subject: Re: draft-ietf-ipsec-dhcp-09.txt

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 02 May 2001 18:00:45 -0700

Thomas Narten wrote:
<trimmed...>

> > 6.2.  DHCPOFFER message processing
> >
> > Typically, the security gateway will also store the xid and the chaddr
> > gleaned from the DHCPDISCOVER in a table so as to be able to route the
> > corresponding DHCPOFFER message(s) back to the remote host.
> 
> This would appear to be a fundamental change in relay agent model
> compared to standard DHCP. That is, traditional relay agents are
> stateless. All the info that a relay agent needs in order to relay
> DHCP packets is contained in those packets. No per-client state is
> needed.  The above text suggests that the relay agent caches the
> chaddr field in order to be able to route back DHCP responses. Why is
> this needed? Isn't this info in the packet that needs to be relayed?
> 
> The answer appears to be no, as the chaddr field as defined in this
> document isn't sufficiently useful for this.
> 
> Wouldn't it be better to (say) have the relay agent add a relay agent
> option that includes information about the SA over which the packet
> was received? When the server responds, that relay agent option could
> contain the information needed properly forward the packet. This would
> be consistent with existing DHCP specifications and would eliminate
> the need for the relay agent to maintain per-client state.

The text in the latest rev (11) has been modified to suggest using the
relay option, but I wonder if this doesn't raise backward compatibility
issues. A large number of deployed dhcp servers do not support the relay
agent option, and in these cases, per-client state must be maintained. I
wonder if we shouldn't have some language to this effect. Does anyone
disagree?

Scott

---

From: Thomas Narten <[email-masked]>
Date: Thu, 03 May 2001 06:16:56 -0400

> wonder if we shouldn't have some language to this effect. Does anyone

I would spin the backwards compatability issue differently. In both
cases, it would seem that new code needs to be written, since neither
approach is presumably widely deployed today. Do we recommend that
implementors implement an existing standard that *is* being
implemented in deployed in some environments because it meets a need
(i.e., the reason the relay agent option was defined in the first
place) or do we recommend a different and non-standard way? The choice
seems obvious to me.

Thomas

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 03 May 2001 08:53:51 -0700

Hi Thomas,

> place) or do we recommend a different and non-standard way? The choice

I think I understand your position, and I agree from a philosophical
standpoint. I have always thought the relay agent option was the best
way to implement this. However, from a practical standpoint, we could
not have deployed the units we have out there which use DHCP (in the
thousands, I think) if we had relied upon the relay agent option. I am
not advocating that we suggest an alternative method which may be used
even if the relay option is available; I am suggesting adding text (an
implementation note?) explaining that if the relay agent option is not
supported, that state must be maintained in order for this to work. This
might help to avoid implementer confusion.

I don't feel strongly about this, but thought (based on years of
implementing protocols based upon RFC's) that some clarifying language
might be useful.

Scott

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2001 08:12:11 -0700 (PDT)

Is there some text that someone would like to add to the
draft to address this issue?

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 04 May 2001 18:29:40 -0700

Here's the current text:

----------------------------
Since DHCP Relays are stateless, it is necessary for the security
gateway to insert appropriate information in the DHCP Relay Agent
Information Option [17] prior to forwarding the message to one or more
DHCP servers. This enables the security gateway to route the
corresponding DHCPOFFER message(s) back to the remote host on the
correct IPSec tunnel, without having to keep state gleaned from the
DISCOVER, such as a table of the xid, chaddr and tunnel. This is
accomplished by identification of the virtual port number of the tunnel
via the Agent Circuit ID Sub-option (sub-option code 1) of the DHCP
Relay Agent Information Option, as described in [17].
-----------------------------

How about adding this:

If attempting to interoperate with a legacy DHCP server which does not
support the required options, stateless relay agent behavior will not be
possible. In such cases, implementations may devise a mapping between
the xid, chaddr, and tunnel in order to route the DHCP server response
to the appropriate tunnel endpoint.

--Scott