RE: [dhcwg] Methods of protecting DHCP relay-agent information op tions
"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Mon, 24 February 2003 23:28 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 SAA00121 for <dhcwg-archive@odin.ietf.org>; Mon, 24 Feb 2003 18:28:48 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ONbVv01873 for dhcwg-archive@odin.ietf.org; Mon, 24 Feb 2003 18:37:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ONbVp01870 for <dhcwg-web-archive@optimus.ietf.org>; Mon, 24 Feb 2003 18:37:31 -0500
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 SAA00117 for <dhcwg-web-archive@ietf.org>; Mon, 24 Feb 2003 18:28:16 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ONZsp01176; Mon, 24 Feb 2003 18:35:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ONYNp01099 for <dhcwg@optimus.ietf.org>; Mon, 24 Feb 2003 18:34:23 -0500
Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29981 for <dhcwg@ietf.org>; Mon, 24 Feb 2003 18:25:08 -0500 (EST)
Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h1ONSXJD028494; Mon, 24 Feb 2003 16:28:33 -0700 (MST)
Received: from 147.191.89.201 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Mon, 24 Feb 2003 16:28:24 -0600
Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id <FMZFTCJ8>; Mon, 24 Feb 2003 16:27:56 -0700
Message-ID: <6732623D2548D61193C90002A5C88DCC0566371C@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: 'John Schnizlein' <jschnizl@cisco.com>
cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Methods of protecting DHCP relay-agent information op tions
Date: Mon, 24 Feb 2003 16:28:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 12447512132962-01-01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
John, There might be one other minor consideration, that I stumbled across after the Atlanta meeting. If DHCP Lease Query messages are implemented by the relay agent, then IPSec encapsulation might be used to protect those messages. I cannot say that DHCP Lease Query is any more or less important than other protocols on the relay agent. But at least it is a protocol under consideration by *this* WG. ;^) -- Rich -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Monday, February 24, 2003 4:16 PM To: dhcwg@ietf.org Subject: [dhcwg] Methods of protecting DHCP relay-agent information options This is the summary I promised in Atlanta. Two methods to protect the contents of the relay-agent information option (RAIO) have been proposed: (1) encapsulating the DHCP message in IPsec (RA-IPsec) [draft-droms-dhcp-relay-agent-ipsec-00.txt] and (2) including a message authentication sub-option (AuthSO) [draft-ietf-dhc-auth-suboption-01.txt] similar to the authentication option for protecting options between clients and servers [RFC 3118]. Which method is suitable depends on different circumstances. Both methods employ keyed message authentication codes, and require distribution of key material. Both methods must also support the separate insertion of RAIO by a "trusted" device closer to the client and GIADDR by a subsequent relay agent, specified in section 2.1 of RFC 3046. AuthSO accommodates this separation the same way that RFC 3118 does, by excluding mutable fields from the integrity computation. Because RA-IPsec necessarily covers the entire message, it must establish IPsec security associations (SA) between each pair of relay agents in the path as well as the SA between the last relay agent and the DHC server. In circumstances where the deployment of DHCP involves this separation of relay-agent function, the RA-IPsec method would entail more configuration of these SAs than the equivalent key management for AuthSO. In circumstances where the "trusted" device requires protection for RAIO, and does not already have the machinery for IPsec Encapsulating Security Payload the AuthSO method might entail less implementation than RA-IPsec. Where IPsec is already in all relay agents, the IPsec method would avoid implementing AuthSO. IPsec is based on existing protocols and technology, and can leverage key distribution mechanisms and other future improvements. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- RE: [dhcwg] Methods of protecting DHCP relay-agen… Woundy, Richard