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

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Tue, 29 October 2002 18:35 UTC

Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18355 for <dhcwg-archive@odin.ietf.org>; Tue, 29 Oct 2002 13:35:28 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TIbOR30669 for dhcwg-archive@odin.ietf.org; Tue, 29 Oct 2002 13:37:24 -0500
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TIbOv30666 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 29 Oct 2002 13:37:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18328 for <dhcwg-web-archive@ietf.org>; Tue, 29 Oct 2002 13:34:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TIZDv29994; Tue, 29 Oct 2002 13:35:13 -0500
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TIYtv29971 for <dhcwg@optimus.ietf.org>; Tue, 29 Oct 2002 13:34:55 -0500
Received: from imr1.ericy.com (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18168 for <dhcwg@ietf.org>; Tue, 29 Oct 2002 13:32:26 -0500 (EST)
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com []) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9TIYnd14729; Tue, 29 Oct 2002 12:34:49 -0600 (CST)
Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se []) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9TIYn801672; Tue, 29 Oct 2002 12:34:49 -0600 (CST)
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PDW15G>; Tue, 29 Oct 2002 12:34:48 -0600
Message-ID: <A1DDC8E21094D511821C00805F6F706B0499F91F@eamrcnt715.exu.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: 'Ralph Droms' <rdroms@cisco.com>
Cc: dhcwg@ietf.org
Date: Tue, 29 Oct 2002 12:33:47 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27F78.E36C5148"
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>


Yes, that was the text I was referring to. And, I think we are in agreement. I just
feel it is better to state it the other way around - a relay agent SHOULD NOT relay a
relayed message (giaddr field is no-zero) using IPsec unless the relay received
that message secured by IPsec.

Without this requirement, what value is there in securing the traffic at a later

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, October 29, 2002 10:22 AM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt

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