[dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt

Ralph Droms <rdroms@cisco.com> Tue, 29 October 2002 18:04 UTC

Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16894 for <dhcwg-archive@odin.ietf.org>; Tue, 29 Oct 2002 13:04:59 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TI6ta28368 for dhcwg-archive@odin.ietf.org; Tue, 29 Oct 2002 13:06:55 -0500
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TI6tv28365 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 29 Oct 2002 13:06:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16872 for <dhcwg-web-archive@ietf.org>; Tue, 29 Oct 2002 13:04:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TI4jv28306; Tue, 29 Oct 2002 13:04:45 -0500
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TI3gv28270 for <dhcwg@optimus.ietf.org>; Tue, 29 Oct 2002 13:03:42 -0500
Received: from funnel.cisco.com (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16673 for <dhcwg@ietf.org>; Tue, 29 Oct 2002 13:01:14 -0500 (EST)
Received: from rdroms-w2k.cisco.com (rtp-vpn1-386.cisco.com []) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14388; Tue, 29 Oct 2002 13:03:34 -0500 (EST)
Message-Id: <>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 29 Oct 2002 10:22:16 -0500
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
From: Ralph Droms <rdroms@cisco.com>
Cc: dhcwg@ietf.org
In-Reply-To: <A1DDC8E21094D511821C00805F6F706B04AF93AB@eamrcnt715.exu.er icsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt
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>

Bernie - thanks for your review and feedback on the IPsec for relay agent 

I had not intended the text in section 4 to require an unbroken chain of 
IPsec forwarding (although not using IPsec over every link doesn't make 
much sense).  Are you referring to the following text:

    If a client message is relayed through multiple relay agents,
    each of the relay agents must have established independent, pairwise
    trust relationships.  That is, if messages from client C will be
    relayed by relay agent A to relay agent B and then to the server,
    relay agents A and B must be configured to use IPSec for the messages
    they exchange, and relay agent B and the server must be configured to
    use IPSec for the messages they exchange.

I intend the text to describe the use of hop-by-hop IPsec, without an 
absolute requirement that all hops use IPsec.  Not being able to anticipate 
every possible deployment, I suggest "SHOULD use IPsec on every hop", with 
some appropriate word-smithing of the spec for clarification.

- Ralph

At 02:33 PM 10/28/2002 -0600, Bernie Volz (EUD) wrote:

>Looks like you've been a bit busy!
>Regarding this draft, does it make sense when multiple relays are involved to
>disallow (MUST?) a relay agent from forwarding using IPSec if the relay
>received the relayed client message without IPSec? (This might also have been
>a good restriction to add to the DHCPv6 specification.) One potential issue
>with this is that it would require code changes in the relay or some 
>rules in the stack to assure non-protected relay messages are not 
>processed. But
>if you don't have it, security could easily be compromised since an 
>attacker can
>just set up a relay-chaining arrangement.
>Note that by your description in Section 4, this is already stated but 
>not as clearly as it should be.
>Also, we should move to make this a Working Group item. Any objections?
>- Bernie
>-----Original Message-----
>From: Internet-Drafts@ietf.org 
>Sent: Monday, October 28, 2002 6:27 AM
>Subject: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt
>A New Internet-Draft is available from the on-line Internet-Drafts 
>         Title           : Use of IPsec for Securing DHCPv4 Messages 
> Exchanged
>                           Between Relay Agents and Servers
>         Author(s)       : R. Droms
>         Filename        : draft-droms-dhcp-relay-agent-ipsec-00.txt
>         Pages           : 4
>         Date            : 2002-10-25
>'DHCP Relay Agent Information Option' (RFC 3046) assumes that DHCP
>messages exchanged between relay agents and servers are not subject
>to attack.  This document describes how IPsec can be used to protect
>messages exchanged between relay agents and servers.
>A URL for this Internet-Draft is:
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-droms-dhcp-relay-agent-ipsec-00.txt".
>A list of Internet-Drafts directories can be found in
>Internet-Drafts can also be obtained by e-mail.
>Send a message to:
>         mailserv@ietf.org.
>In the body type:
>         "FILE /internet-drafts/draft-droms-dhcp-relay-agent-ipsec-00.txt".
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the

dhcwg mailing list