Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection

Ralph Droms <rdroms@cisco.com> Wed, 09 October 2002 19:00 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 PAA00172 for <dhcwg-archive@odin.ietf.org>; Wed, 9 Oct 2002 15:00:42 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g99J2NM10357 for dhcwg-archive@odin.ietf.org; Wed, 9 Oct 2002 15:02:23 -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 g99J2Mv10354 for <dhcwg-web-archive@optimus.ietf.org>; Wed, 9 Oct 2002 15:02: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 PAA00153 for <dhcwg-web-archive@ietf.org>; Wed, 9 Oct 2002 15:00: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 g99J09v10213; Wed, 9 Oct 2002 15:00: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 g99IxDv10139 for <dhcwg@optimus.ietf.org>; Wed, 9 Oct 2002 14:59:13 -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 OAA00021 for <dhcwg@ietf.org>; Wed, 9 Oct 2002 14:57:01 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (rtp-vpn2-282.cisco.com [10.82.241.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA25568; Wed, 9 Oct 2002 14:59:02 -0400 (EDT)
Message-Id: <4.3.2.7.2.20021009144203.03622970@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 09 Oct 2002 14:58:58 -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: <200210091835.g99IZa632120@rotala.raleigh.ibm.com>
References: <Message from Ralph Droms <rdroms@cisco.com> <4.3.2.7.2.20021008151605.00b72388@funnel.cisco.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>

The message from the relay agent to the server uses the relay agent's 
address as the source address.  The relay agent modifies and sends the DHCP 
message as the payload in a UDP message that appears to originate from the 
relay agent.  Section 4 of RFC1542 gives more details.  The difference 
between DHCPv4 and DHCPv6 is in the way in which the client message is 
processed by the relay agent (in DHCPv6, the message is encapsulated in a 
new message generated by the relay agent).

Yes, IPsec cannot be used from the client to the server.  The proposal for 
the use of IPsec under consideration here is to protect the message as it 
travels between the relay agent and the server.  The primary purpose is to 
protect any relay agent options, addressing an issue raised by the original 
relay option spec (RFC3046), which assumes no security is needed between 
the relay agent and the server.

- Ralph

At 02:35 PM 10/9/2002 -0400, Thomas Narten wrote:
> > If I squint my eyes and stand back far enough, I don't see that the DHCPv4
> > case is different.
>
>Conceptually similar, details are 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.
>
>Isn't the source address of the packet that of the client (and not the
>relay agent)? This makes a huge differences with regards to IPsec.
>
>Even worse, the client has no IP address yet, so the relayed packet
>has no source address...
>
>This can't be made to work trivially with stock IPsec. You'd need
>extensions I'd suspect, defeating much of the purpose of trying to use
>IPsec.
>
>Note that the above also factored into why DHC needed something
>specific to DHC rather than trying to somehow use IPsec.
>
>Thomas

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