Re: [dhcwg] Can a DHCPv4 server REPLY to non-standard port.

Bud Millwood <budm@weird-solutions.com> Tue, 04 February 2003 15:06 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24523 for <dhcwg-archive@odin.ietf.org>; Tue, 4 Feb 2003 10:06:57 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14FCSk00512 for dhcwg-archive@odin.ietf.org; Tue, 4 Feb 2003 10:12:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FCRJ00509 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 4 Feb 2003 10:12:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24519 for <dhcwg-web-archive@ietf.org>; Tue, 4 Feb 2003 10:06:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FAUJ00429; Tue, 4 Feb 2003 10:10:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14F7gJ32762 for <dhcwg@optimus.ietf.org>; Tue, 4 Feb 2003 10:07:42 -0500
Received: from intermail.se.dataphone.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24435 for <dhcwg@ietf.org>; Tue, 4 Feb 2003 10:01:40 -0500 (EST)
Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.0.5) with ESMTP id 800028; Tue, 04 Feb 2003 16:05:14 +0100
Content-Type: text/plain; charset="iso-8859-1"
From: Bud Millwood <budm@weird-solutions.com>
Reply-To: Bud Millwood <budm@weird-solutions.com>
Organization: Weird Solutions, Inc.
To: "Vasu, Vallabhaneni" <vasu@austin.ibm.com>, dhcwg@ietf.org
Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to non-standard port.
Date: Tue, 04 Feb 2003 16:06:27 +0100
User-Agent: KMail/1.4.3
References: <3E3F8B23.CF70A9A1@india.hp.com> <3E3FC2AD.6F75FC1C@austin.ibm.com>
In-Reply-To: <3E3FC2AD.6F75FC1C@austin.ibm.com>
Cc: Senthil Kumar B <ksenthil@india.hp.com>
MIME-Version: 1.0
Message-Id: <200302041606.27750.budm@weird-solutions.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14F7gJ32763
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

On Tuesday 04 February 2003 14.39, Vasu, Vallabhaneni wrote:

> This problem can happen even if the client uses the standard ports. All you
> need to do is write c code to generate different client id's (MAC or option
> 61). This issue is  being handled in RFC 3118.

We respond to the source port the client is using, but allow the administrator 
to override this at the server. It seemed like a bad idea to respond to a 
fixed port if no communication had been initiated from that port.

The best way to handle spoofing today, to my knowledge, is to use the trusted 
values found in option 82 for identifying the client. If your server supports 
resource limiting using option 82, and your relay agents support option 82, 
you should be fine.

Otherwise, some sort of pre-registration works, although that's a bit of a 
pain to manage.

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:budm@weird-solutions.com

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg