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

From: Eric Michelsen <[email-masked]>
Date: Wed, 1 Mar 2000 16:22:48 -0800

Any comments?
-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks 

> -----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?
> 
> 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."
> 
> 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?
> 
> The intent of sec 2.1, par 8 is not clear to me: for 
> security, the access device certainly WILL enforce valid 
> agent-information, whether this document requires it or not.  
> But what is the intent here?  Along with this, sec 2.2, par 
> 4, DHCP servers may indeed require the agent-options field to 
> be present.  Anything else may be a potential security weakness.
> 
> Sec 2.1.1, for clarity: why would a relay agent receive a 
> relayed request?  Doesn't the original relay-agent forward 
> the request by unicast directly to the server?
> 
> 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.
> -------------------------------------------
> Eric L. Michelsen, Copper Mountain Networks 
>

---

From: "Michael W. Patrick" <[email-masked]>
Date: Thu, 02 Mar 2000 05:48:29 -0500

Eric,
Sorry about the delay in replying. Responses inline.

-mike

>>>>> "Eric" == Eric Michelsen <[email-masked]> writes:

> Any comments?  ------------------------------------------- Eric
> L. Michelsen, Copper Mountain Networks

>> -----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.

>> 
>> 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. 

Note, btw, that access equipment that are bridges need not be
precluded from acting as relay agents, i.e. adding the agent option
as well as filling in giaddr.

>> 
>> 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.

>> 
>> The intent of sec 2.1, par 8 is not clear to me: for security, the
>> access device certainly WILL enforce valid agent-information,
>> whether this document requires it or not.  But what is the intent
>> here?  Along with this, sec 2.2, par 4, DHCP servers may indeed
>> require the agent-options field to be present.  Anything else may
>> be a potential security weakness.

Unicast packets, including DHCP, are often forwarded by the "fast
path" hardware/software forwarding engine, and for performance reasons
are not required to be modified. 

It is a matter of bilateral agreement between the relay agent and
server as to whether unicast DHCP lease renewals are marked. 

>> 
>> Sec 2.1.1, for clarity: why would a relay agent receive a relayed
>> request?  Doesn't the original relay-agent forward the request by
>> unicast directly to the server?

There are situations in which one relay agent forwards to another.
We added this language to handle such cases.  This might be the
case, for instance, when multiple subnets with separate servers
become served by a single "super DHCP server". Another case where
this happens is when a customer premise downstream of cable/DSL 
modem has a router; this router is the first hop outer and
so has to relay the broadcast DHCP-DISCOVER, but it is downstream
of the "circuit" and doesn't know the circuit (or remote) ID.

>> 
>> 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.

>> ------------------------------------------- Eric L. Michelsen,
>> Copper Mountain Networks
>>