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

Mark Stapp <> Wed, 09 October 2002 19:31 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id PAA01039 for <>; Wed, 9 Oct 2002 15:31:54 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id g99JXaf12452 for; Wed, 9 Oct 2002 15:33:36 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g99JXav12449 for <>; Wed, 9 Oct 2002 15:33:36 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA01030 for <>; Wed, 9 Oct 2002 15:31:24 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id g99JVRv12384; Wed, 9 Oct 2002 15:31:27 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g99JUIv12329 for <>; Wed, 9 Oct 2002 15:30:18 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA00909 for <>; Wed, 9 Oct 2002 15:28:05 -0400 (EDT)
Received: from (localhost []) by (8.12.2/8.12.2) with ESMTP id g99JUGqd017726; Wed, 9 Oct 2002 15:30:16 -0400 (EDT)
Received: from ( []) by (Mirapoint) with ESMTP id ABW96925; Wed, 9 Oct 2002 15:30:08 -0400 (EDT)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 09 Oct 2002 15:29:46 -0400
To: Ralph Droms <>
From: Mark Stapp <>
Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection
Cc: Thomas Narten <>, Ted Lemon <>, "Bernie Volz (EUD)" <>, Kim Kinnear <>,
In-Reply-To: <>
References: <> <Message from Ralph Droms <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

I had thought that the progressing relay-agent-authentication draft was the 
response to Thomas's issue. That seemed to me to be targetted at the 
specific problem of relay<->server communication, and to require relatively 
light-weight implementation and configuration changes while providing an 
appropriate level of security. That path still seems to me to offer the 
best cost/benefit/deployment balance. Will it be more difficult to deploy 
and configure an ipsec solution in heterogeneous or complex networks? Will 
any additional configuration work required provide any additional security? 
Will relays need separate SAs to all the dhcp failover server pairs? Will 
all the kinds of v4 devices that act as relays and servers be able to 
implement ipsec? I'm concerned that choosing ipsec may lead to reduced 
adoption of relay-agent security.

-- Mark

At 02:58 PM 10/9/2002 -0400, Ralph Droms wrote:
>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
>>Note that the above also factored into why DHC needed something
>>specific to DHC rather than trying to somehow use IPsec.
>dhcwg mailing list

dhcwg mailing list