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

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Aug 2010 14:28:21 -0400

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?

---

From: Pavan Kurapati <[email-masked]>
Date: Sun, 15 Aug 2010 11:28:30 +0530

Hi Ted,
 While I agree to the concern that you mentioned below (of MTU and security
aspect if RAIO is not stripped) the reason behind the text was not because
it would take a different path. If we assume that layer 2 relay agents
intercept only broadcasted messages and add RAIO, DHCPDISCOVER and
DHCPREQUEST will be intercepted (since they are broadcast) and RAIO  will be
added by the L2RA. However if the DHCP server is unicasting the DHCPOFFER
and DHCPACK respectively to the clients, it will not be intercepted by the
l2ra hence the RAIO may leak to the client.

Having said that, in actual deployments, L2RAs usually intercept the
messages whether it is unicast or broadcast hence this situation generally
would not arise. We had put that text in place after receiving some reviews
that there are L2 relays existing which do not intercept the unicast
messages.

Thanks,
Pavan

On Sat, Aug 14, 2010 at 11:58 PM, Ted Lemon <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Josh Littlefield <[email-masked]>
Date: Mon, 16 Aug 2010 10:55:33 -0400

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.

-- 
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
Phone: +1 978-936-0001                     Boxborough, MA  01719-2205

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Aug 2010 13:56:34 -0400

On Aug 16, 2010, at 10:55 AM, Josh Littlefield wrote:
>  [...]

Yes.

This is complicated by the fact that the l2ra draft is informational, not standards-track.   So essentially it just reports what people are doing with regards to l2ra, rather than specifying how to do l2ra.  I'm finding myself adding text to the relay agent encapsulation draft specifying how to do l2ra because of this.

Personally, I'd like to see the l2ra draft aimed at standards track, and specifying the correct way to do l2ra, rather than, as it does now, simply documenting various implementation strategies, some of which are clearly (to me!) broken.

I'm curious to know what the authors of the current draft think about this.   I'm pretty sure we've talked about this before, so I apologize for re-visiting well-trod ground, but I'm seeing the problem with new eyes now... :'}

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 17 Aug 2010 09:09:10 +0530

Please see in line.

Thanks,
Bharat

> > L2RA to remove option-82 from all packets:

We (author's of the l2ra draft) also think that DHCP replies containing RAIO should never reach the client. As Pavan mentioned in his reply, we had to add that paragraph because someone pointed out that there may be Layer 2 Relay Agents which are configured not to intercept unicast DHCP replies and hence would not be able to remove RAIO.

We can simply remove this point and make sure that draft clearly articulates the need of L2 RA to intercept all unicast/broadcast replies to remove RAIO option.

> This is complicated by the fact that the l2ra draft is informational, not standards-track.   So essentially it just reports what people are doing with regards to l2ra, rather than specifying how to…

A little bit of history may help here. We started with a Lease Query extension draft for L2 RA and at that point, we found out that the L2 RA term itself is not defined in IETF. Few DHC WG folks encouraged us to come up with an informational draft to define L2 RA so that the other draft can be understood in a better way. We were asked to explain various L2 RA implementations that exist. We kept it as informational draft as we were just providing information on how L2 RA behaves in existing network configurations.

> Personally, I'd like to see the l2ra draft aimed at standards track, and specifying the correct way to do l2ra, rather than, as it does now, simply documenting various implementation strategies, so…

We can surely do that if every body agrees to it.

> I'm curious to know what the authors of the current draft think about this.   I'm pretty sure we've talked about this before, so I apologize for re-visiting well-trod ground, but I'm seeing the pro…

There is no problem in re-visiting something, the only issue I feel is the time it generally takes :(

As mentioned above, we are fine with bringing out a standard track draft which aim to define the Layer 2 Relay Agent functionality. We will wait for people to respond before we do that.

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 27 Aug 2010 16:13:06 +0530

Ted/John/Others,

      If you guys can provide feedback on whether we should target L2 RA for standard track or Informational RFC. If everyone is fine with it being a standard track RFC, we will need to make few changes. If it can only be an informational one, we will add sufficient amount of text to fix the problem pointed out by Ted or remove that point all together.

Regards,
Bharat
________________________________________
From: Bharat Joshi
Sent: Tuesday, August 17, 2010 9:09 AM
To: Ted Lemon; Josh Littlefield
Cc: [email-masked] Group
Subject: RE: [dhcwg] Questions about layer two relay agents in dhcpv4...

Please see in line.

Thanks,
Bharat