Re: [dhcwg] Questions about layer two relay agents in dhcpv4...

[Josh Littlefield <[e-mail]>]

 I do think this is a problem. TR-101, in which I participated in
defining the L2RA requirements for EtherDSL, specifically requires the
L2RA to remove option-82 from all packets:

R-99 The Access Node MUST, when performing the function of a Layer 2
DHCP Relay Agent,
remove option-82 information from all DHCP reply messages received from
the Broadband
Network Gateway before forwarding to the client.

This goes with the earlier requirement to add option-82 to all packets:

R-98 The Access Node MUST, when performing the function of a Layer 2
DHCP Relay Agent, add
option-82 with the ‘circuit-id’ and/or ‘remote-id’ sub-options to all
DHCP messages sent by the
client before forwarding to the Broadband Network Gateway.

The option-82 info is needed in unicast packets in order to ensure
circuit information is available to the DHCP server (or a DHCP proxy in
the BNG) during any lease renewal, so the proper policy can be employed.

RFC 3046 is pretty clear that option-82 "MUST be removed by either the
relay agent or the trusted downstream network element which added it
when forwarding a server-to-client response back to the client." In this
case, the "trusted downstream network element" is the L2RA.

On 8/14/2010 2:28 PM, Ted Lemon wrote:
> I'm in the process of writing the section in the relay agent encapsulation draft that describes how relay agents forward messages toward clients.   In doing so, I encountered a fairly serious problem with the current l2ra specification.   It looks like the authors of the l2ra specifications, and possibly also implementors of existing l2ra devices, have had some experience with this, so rather than just writing new text, I wanted to pose some questions.
>
> First, the l2ra draft says that an l2ra may intercept a message and append a relay agent information option (RAIO) to it.   If that happens, then on the way back, if the message is unicast, the l2ra may or may not intercept the message and strip the RAIO.   If it does not, the client will receive the RAIO.
>
> This is an obvious no-no.   But I'm convinced this text is there for a reason.   I presume that the reason is that the authors envisioned a scenario where the message from the client to the server would pass through the l2ra, but on the way back it would take a different path, and hence could not be intercepted.
>
> There's no way to support this scenario with relay agent encapsulation, because the client will be unable to process a RELAYREPLY message.   And I think it's wrong to support this scenario even with regular l2ra, because while the client probably can process the packet, RFC3046 allows the DHCP server to make the message bigger than the default maximum message size, as long as the message, stripped of the RAIO, would be smaller.   So in that case the message the client received would be out of spec--too big.   Also, potentially there might be a problem with information leakage, where the client would gain access to RAIO information it shouldn't have access to.
>
> So my question is this: is it true that the text in the l2ra draft that allows the l2ra to not strip the RAIO is motivated by the possibility that the reply from the server might take a different path back to the client?
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Josh Littlefield                                  Cisco Systems, Inc.
[e-mail]                             1414 Massachusetts Avenue
Phone: [phone]                     Boxborough, MA  01719-2205