Re: [dhcwg] IPsec for DHCPv6 client ?

Ted Lemon <> Tue, 10 September 2002 08:24 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id EAA07218 for <>; Tue, 10 Sep 2002 04:24:53 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id g8A8Q8s09717 for; Tue, 10 Sep 2002 04:26:08 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g8A8Q8v09714 for <>; Tue, 10 Sep 2002 04:26:08 -0400
Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id EAA07213 for <>; Tue, 10 Sep 2002 04:24:22 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id g8A8N6v09559; Tue, 10 Sep 2002 04:23:06 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g8A8LCv09486 for <>; Tue, 10 Sep 2002 04:21:12 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id EAA07135 for <>; Tue, 10 Sep 2002 04:19:26 -0400 (EDT)
Received: from ( []) by (8.11.6/8.6.11) with ESMTP id g8A8Evv13061; Tue, 10 Sep 2002 03:14:57 -0500 (CDT)
Received: from dechen (localhost []) by (8.12.2/8.6.11) with ESMTP id g8A8KwUa000788; Tue, 10 Sep 2002 03:20:58 -0500 (CDT)
Date: Tue, 10 Sep 2002 04:20:57 -0400
Subject: Re: [dhcwg] IPsec for DHCPv6 client ?
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v543)
To: Jean-Mickael Guerin <>
From: Ted Lemon <>
In-Reply-To: <>
Message-Id: <>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.543)
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> My point concerns the possibility of using IPsec in scenario where 
> DHCP Authentication is proposed. Because DHCP Authentication relies on 
> shared secret, I think the draft should have a section about this, 
> even if it would be limited to client and relays or client and server 
> on same link.

Your reasoning is flawed.   IPsec is not shared-secret authentication.  
  It is an entire security infrastructure, carefully designed to solve a 
certain class of problems.   It happens to support the use of 
shared-secret authentication, among other authentication schemes.  The 
DHCP security option also supports shared-secret authentication.   This 
is nothing more than a coincidence - it does not mean that DHCP 
security can work with IPsec.

The DHCP server and clients need to see packets with "bad" 
authentication keys in order for DHCP authentication to work, because 
they can't really prepare in advance for all the possible uses of keys 
by roaming clients and servers in locations to which they may roam.   
If the packet is signed with the wrong key with IPsec, it will simply 
be dropped by the DHCP agent's IP stack.   This is not what we want.

Intuitively it seems obvious that one should use IPsec for DHCP 
authentication.   Personally, I'd *love* to be able to claim that IPsec 
was a solution to securing DHCP transactions.   But this working group 
has a long history of trying to solve this problem with IPsec.   Every 
time we've tried to figure out a good way to do it, we've come up 
either with nothing, or with an unworkable kludge.   So there's a good 
reason why we didn't do it - it's not an oversight.

If you think that there is a way to make IPsec work with DHCP 
authentication, please take the extra time to actually sit down and 
reason it through before insisting that we make changes.   What happens 
when a server sees a new client for the first time?   What happens when 
a client that's got a security association with a server at one site 
roams to a different site?   Does the server at the other site even see 
packets from that client?   How does it get them?   How does all this 
work with relay agents?   Like it or not, DHCP *requires* relay agents, 
so the protocol has to work when the DHCP client is talking to a relay 
agent rather than a server.   If you put the signature in the payload, 
all these problems go away.   That's why we've put the signature in the 

dhcwg mailing list