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

Ted Lemon <mellon@fugue.com> Sat, 14 August 2010 18:27 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651093A68CB for <dhcwg@core3.amsl.com>; Sat, 14 Aug 2010 11:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl0V6FV3cAOq for <dhcwg@core3.amsl.com>; Sat, 14 Aug 2010 11:27:47 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 8D5113A689B for <dhcwg@ietf.org>; Sat, 14 Aug 2010 11:27:47 -0700 (PDT)
Received: from [IPv6:2001::53aa:64c:0:1908:525d:2925] (unknown [IPv6:2001:0:53aa:64c:0:1908:525d:2925]) by toccata.fugue.com (Postfix) with ESMTPSA id 6143834E44FC for <dhcwg@ietf.org>; Sat, 14 Aug 2010 14:28:38 -0400 (EDT)
From: Ted Lemon <mellon@fugue.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 14 Aug 2010 14:28:21 -0400
Message-Id: <8B2420CE-026D-465D-9256-B2DA76310CE1@fugue.com>
To: "dhcwg@ietf.org Group" <dhcwg@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [dhcwg] Questions about layer two relay agents in dhcpv4...
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Aug 2010 18:27:48 -0000

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?