Subject: RE: WG Last Call for "DHCP Relay Agent Information Option" I-D

From: Eric Michelsen <[email-masked]>
Date: Fri, 3 Mar 2000 09:52:26 -0800

Comments embedded.
-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks 

> -----Original Message-----
> From: Michael W. Patrick [mailto:[email-masked]]
> Sent: Thursday, March 02, 2000 2:48
> To: [email-masked]
> Cc: DHCPv4 discussion list; [email-masked]
> Subject: Re: WG Last Call for "DHCP Relay Agent Information 
> Option" I-D 
...
> >> -----Original Message----- From: Eric Michelsen Sent: Wednesday,
> >> February 23, 2000 9:14 To: [email-masked]' Subject:
> >> agent-options-08
> >> 
> >> 
> >> Why the prohibition against modifying BOOTP requests (sec 2.1, par
> >> 2)?  The clients may be old, and may issue BOOTP instead of DHCP.
> >> Since the Agent-information is for the benefit of the access device
> >> and the DHCP server, why disrupt existing deployments of BOOTP
> >> clients, when the agent and server don't care?
> 
> The relay agent would have to do a lot more than just add the
> agent options; it would have to *change* the BOOTP to a DHCP by
> adding the magic number. It wouldn't know, of course, critical
> other DHCP-only info like client ID.  Changing BOOTP to DHCP is
> a big can of worms we can discuss separately but not something to
> add in at the last minute here.

I don't see any reason why the agent would have to change BOOTP to DHCP.
The "agent-information" option is like almost every other option: it applies
equally to DHCP and BOOTP.  Relay-agents today handle both DHCP and BOOTP
requests all the time.  This requires no special effort or work on their
part.  The relay-agent function is identical for both protocols.

> 
> >> 
> >> As an access equipment vendor, I have several scenarios where the
> >> access equipment has the knowledge of Circuit ID, etc., but is not
> >> acting at a protocol layer that allows it to actually *be* a DHCP
> >> relay agent.  These applications require that upstream Relay Agents
> >> accept requests where the "agent-information" is present, but
> >> giaddr = 0.  Because servers and agents "know" if they require
> >> circuit IDs or not, I don't see any security benefit to requiring
> >> *relay agents* to discard such requests (sec 2.1, par 3).  A better
> >> statement would be that "devices inserting 'agent-information' must
> >> remove any pre-existing 'agent-information', to prevent spoofing."
> 
> We've discussed anti-spoofing in the WG, including, for instance,
> "layering" multiple relay agent options. We've decided to keep the
> principle that "he that relays adds giaddr". That is, either both
> are added or neither. 

This is a restatement of the draft, but it is not enforceable, and not
necessary.  The forwarding agents in my example have no IP addresses (a
configuration nightmare in the DSL scenario).  As a malicious client, I can
put in my own giaddr, spoof any other fields I want, and send a request up
to the server.  The network must protect itself against such attacks.  As
such, forwarding agents won't care whether giaddr is filled in or not.  They
will either discard invalid packets, or replace the bogus information.
Either way, the upstream relay agents know from network topology that the
request is valid and spoof-proof.  They can confidently perform their normal
relay-agent function.

I have been participating in the DSL Forum's auto-configuration working
group, and this is a very real requirement.

...

> >> 
> >> The intent of sec 2.1, par 6 is not clear to me: why would the
> >> sname or file fields have agent-information options in them, and
> >> why shouldn't the access device remove them?
> 
> Using "option overload" significantly complicated the logic,
> (and so programming and testing) for adding options. It was felt to
> be an unnecessary complication, and so it is precluded.

Is this a special case for the agent-information option?  I don't see how
"agent-information" is different from any other DHCP/BOOTP option in that
respect.  I don't see how any logic is complicated for this option
differently than for any other option.  Can you elaborate?

...
> >> 
> >> Sec 3.2, I think the "remote-ID" should be clarified, for the case
> >> of PVC-like connections to the premise (e.g., DSL), the remote-ID
> >> may be an identifier of the physical line (essentially, all the
> >> circuit-ID suggestions, plus the additional suggestions given).
> >> From the descriptions, it seems like servers interpret remote-ID as
> >> the definitive client identification, and circuit-ID may be
> >> interesting, but not necessarily definitive.
> 
> I'm hesitant to add the language "definitive client identification".
> I can imagine a DSL scenario, say, where the "definitive client
> identification" is pre-assigned ATM VC IDs in the DSLAM. In this case,
> the circuit ID is the option to be used by the server, because the
> remote ATM "caller ID" wouldn't be known from SVC signalling.
> I already give "ATM virtual circuit number" as one of the choices
> of the circuit ID.

There is an ambiguity that leads to interoperability problems:  I'm a DHCP
server, I receive a request with both the remote-ID and circuit-ID options.
Which one do I use to securely identify the source of the request?  

In contrast, client-ID is defined as *the* unique identifier for a Server to
index its database.  The agent-options option needs a similar definitive
statement of the Server's interpretation of the sub-options.

---

From: Eric Michelsen <[email-masked]>
Date: Mon, 20 Mar 2000 06:18:06 -0800

I spoke with with Michael Patrick on the phone Friday (3/17).  We agreed on
the following minor changes to move this draft to "Proposed Standard"
without delay.  These changes allow the draft to be used in
non-routed-front-end applications, such as DSL:

1. 2nd paragraph in section 2.1, remove the reference to BOOTP which
contradicts RFCs 1534, 2131, and 2132.  The BOOTP exclusion also prevents
working with thousands of installed BOOTP clients.  Since this draft is
transparent to BOOTP vs DHCP, it applies equally to both of them.  This
change to the draft introduces no interoperability issues, and at most
requires removal of special forwarding-agent code that filtered out the
BOOTP case, which is now handled the same as all other options.

2. 3rd paragraph in section 2.1: Change "Relay agents receiving a DHCP
packet with giaddr set to zero ..." to something like "Relay agents
receiving a DHCP packet from an untrusted source with giaddr set to zero
(indicating that they are the first-hop router) but with a Relay Agent
Information option already present in the packet SHALL discard the packet
and increment an error count."

Let's move to Proposed Standard with these small (but important) changes.
Other clarifications can be made in moving from Proposed Standard to Draft
Standard.

I appreciate Mr. Patrick's attention to these issues, and apologize again
for my late entry into the discussion.
-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks