[dhcwg] Editorial changes to DHCPv6 specification

Ralph Droms <rdroms@cisco.com> Tue, 10 December 2002 02:46 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 VAA14369 for <dhcwg-archive@odin.ietf.org>; Mon, 9 Dec 2002 21:46:16 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBA2mmP18640 for dhcwg-archive@odin.ietf.org; Mon, 9 Dec 2002 21:48:48 -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 gBA2mmv18637 for <dhcwg-web-archive@optimus.ietf.org>; Mon, 9 Dec 2002 21:48:48 -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 VAA14358 for <dhcwg-web-archive@ietf.org>; Mon, 9 Dec 2002 21:45:44 -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 gBA2kOv18567; Mon, 9 Dec 2002 21:46:24 -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 gBA2iAv18497 for <dhcwg@optimus.ietf.org>; Mon, 9 Dec 2002 21:44:10 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14257 for <dhcwg@ietf.org>; Mon, 9 Dec 2002 21:41:05 -0500 (EST)
Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBA2iTfr017799 for <dhcwg@ietf.org>; Mon, 9 Dec 2002 21:44:30 -0500 (EST)
Received: from rdroms-w2k.cisco.com (rtp-vpn2-266.cisco.com [10.82.241.10]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA15150 for <dhcwg@ietf.org>; Mon, 9 Dec 2002 21:43:57 -0500 (EST)
Message-Id: <4.3.2.7.2.20021209143603.01a32b10@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 09 Dec 2002 17:08:26 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_17384597==_.ALT"
Subject: [dhcwg] Editorial changes to DHCPv6 specification
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>

FYI...The IESG has requested changes in two sections of 
draft-ietf-dhc-dhcpv6-28.txt, prior to its acceptance as a Proposed 
Standard and publication as an RFC.  The changes are noted in the text 
included below from sections 21.1 and 23.  The change is motivated by the 
observation that manual keying does not prevent replay attacks.

The sentence identified in the first paragraph of 21.1 will be 
removed.  The list item labeled "Key Management" will be replaced with the 
text shown below.  The previous text mentioned only manual keying.  The 
indicated (last) paragraph in section 23 will be added.

- Ralph

=====

21.1. Security of Messages Sent Between Servers and Relay Agents

    Relay agents and servers that exchange messages securely use the
|  IPsec mechanisms for IPv6 [11].  Relay agents and servers MUST
|  support manual configuration and installation of static keys.  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.

    Relay agents and servers that support secure relay agent to server
    or relay agent to relay agent communication use IPsec under the
    following conditions:

       Selectors        Relay agents are manually configured with the
                        addresses of the relay agent or server to which
                        DHCP messages are to be forwarded.  Each relay
                        agent and server that will be using IPsec for
                        securing DHCP messages must also be configured
                        with a list of the relay agents to which messages
                        will be returned.  The selectors for the relay
                        agents and servers will be the pairs of addresses
                        defining relay agents and servers that exchange
                        DHCP messages on the DHCPv6 UDP ports 546 and
                        547.

       Mode             Relay agents and servers use transport mode and
                        ESP. The information in DHCP messages is not
                        generally considered confidential, so encryption
                        need not be used (i.e., NULL encryption can be
                        used).

|     Key management   Because the relay agents and servers are used
|                      within an organization, public key schemes are
|                      not necessary.  Because the relay agents and
|                      servers must be manually configured, manually
|                      configured key management may suffice, but
|                      doesn't provide defense against replayed
|                      messages.  Accordingly, IKE with preshared
|                      secrets SHOULD be supported.  IKE with public
|                      keys MAY be supported.

       Security policy  DHCP messages between relay agents and servers
                        should only be accepted from DHCP peers as
                        identified in the local configuration.

       Authentication   Shared keys, indexed to the source IP address of
                        the received DHCP message, are adequate in this
                        application.

       Availability     Appropriate IPsec implementations are likely to
                        be available for servers and for relay agents in
                        more featureful devices used in enterprise and
                        core ISP networks.  IPsec is less likely to be
                        available for relay agents in low end devices
                        primarily used in the home or small office
                        markets.

23. Security Considerations
    [...]

    Communication between a server and a relay agent and communication
    between relay agents can be secured through the use of IPSec, as
    described in section 21.1.  The use of manual configuration and
    installation of static keys are acceptable in this instance because
    relay agents and the server will belong to the same administrative
    domain and the relay agents will require other specific configuration
    (for example, configuration of the DHCP server address) as well as
    the IPSec configuration.

|  Use of manually configured preshared keys for IPsec
|  between relay agents and servers does not defend against
|  replayed DHCP messages.  Replayed messages can
|  represent a DOS attack through exhaustion of
|  processing resources, but not through mis-configuration
|  or exhaustion of other resources such as assignable addresses.