Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection
Ralph Droms <rdroms@cisco.com> Tue, 08 October 2002 19:24 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 PAA27598 for <dhcwg-archive@odin.ietf.org>; Tue, 8 Oct 2002 15:24:42 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g98JQMX25346 for dhcwg-archive@odin.ietf.org; Tue, 8 Oct 2002 15:26:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JQMv25343 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 8 Oct 2002 15:26:22 -0400
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 PAA27583 for <dhcwg-web-archive@ietf.org>; Tue, 8 Oct 2002 15:24:11 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JO9v25258; Tue, 8 Oct 2002 15:24:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JMRv25173 for <dhcwg@optimus.ietf.org>; Tue, 8 Oct 2002 15:22:27 -0400
Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27460 for <dhcwg@ietf.org>; Tue, 8 Oct 2002 15:20:16 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (ch2-dhcp150-107.cisco.com [161.44.150.107]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01704; Tue, 8 Oct 2002 15:22:14 -0400 (EDT)
Message-Id: <4.3.2.7.2.20021008151605.00b72388@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 Oct 2002 15:22:11 -0400
To: Thomas Narten <narten@us.ibm.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection
Cc: Ted Lemon <Ted.Lemon@nominum.com>, "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, Kim Kinnear <kkinnear@cisco.com>, dhcwg@ietf.org
In-Reply-To: <200210081911.g98JBEK28127@rotala.raleigh.ibm.com>
References: <Message from Ted Lemon <Ted.Lemon@nominum.com> <061142C8-DAF0-11D6-A9B4-00039367340A@nominum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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>
If I squint my eyes and stand back far enough, I don't see that the DHCPv4 case is different. While the relay agent is relaying a message on behalf of the client, it really is relaying that message in an independent UDP message, in which the source address belongs to the relay agent. I don't think there is any reason the relay agent and server can't employ IPsec on the relay agent<->server messages. Of course, IPsec may be problematic if there are multiple relay agents in the path - which is the problem Mark Stapp is trying to solve, right? - Ralph At 03:11 PM 10/8/2002 -0400, Thomas Narten wrote: >Ted Lemon <Ted.Lemon@nominum.com> writes: > > > > Perhaps I shouldn't raise this, but it seems like we should be > > > worrying much > > > more about security on the first hop (client <-> server/relay) than the > > > relay <-> server hop. The latter is much easier to secure as IPsec, > > > tunneling, > > > and other fairly standard techniques could be used. > > > > > > Also, is the DHCPv6 draft strong enough in this area to satisfy the > > > IESG (at > > > least around the relay <-> server security)? > > > Right, the relay<->server hop is regular IP, so there's no reason not > > to use IPsec to secure it. > >In DHCPv6, using IPsec makes sense. The relay agent is originating a >new message that it sends to the DHC server. > >But DHCPv4 is different, in that it relays the client packet. So IPsec >can't really be used there. But certainly a DHC-specific >authentication option could be defined for covering the relay agent >option and/or portions of the client request. > >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- RE: [dhcwg] status of draft-ietf-dhc-agent-subnet… Bernie Volz (EUD)
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Ted Lemon
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Ralph Droms
- RE: [dhcwg] status of draft-ietf-dhc-agent-subnet… Bernie Volz (EUD)
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Ted Lemon
- RE: [dhcwg] status of draft-ietf-dhc-agent-subnet… Ralph Droms
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Ralph Droms
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Mark Stapp
- RE: [dhcwg] status of draft-ietf-dhc-agent-subnet… Kostur, Andre