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

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 <mellon@fugue.com> 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
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>