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