dhc                                                             T. Lemon
Internet-Draft                                                   Nominum
Intended status: Standards Track                                   Q. Wu
Expires: March 22, April 2, 2011                                            Huawei
                                                      September 18, 29, 2010

                      Relay-Supplied DHCP Options
            draft-ietf-dhc-dhcpv6-relay-supplied-options-01
            draft-ietf-dhc-dhcpv6-relay-supplied-options-02

Abstract

   This document describes a general mechanism whereby a DHCPv6 relay
   agent can provide options to a DHCPv6 server that the DHCPv6 server
   can then provide to the DHCPv6 client.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 22, April 2, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Protocol Summary  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  RSOO-enabled options  . . . . . . . . . . . . . . . . . . . . . 4
   5.  DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 4
   5.
   6.  DHCP Server Behavior  . . . . . . . . . . . . . . . . . . . . . 4
   6.
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   8. 6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1. 6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2. 6
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6

1.  Introduction

   The DHCPv6 specification [RFC3315] allows DHCP relay agents to
   forward DHCPv6 messages between clients and servers that are not on
   the same IPv6 link.  In some cases the DHCP relay agent has
   information the DHCP server does not have that would be useful to
   provide to a DHCP client.  For example, the DHCP client may need to
   learn the EAP local domain name [I.D-ietf-hokey-ldn-discovery] for
   use in EAP re-authentication [RFC5296], which is known to the relay
   agent but not the server.  The DHCPv6 protocol specification does not
   provide a mechanism whereby the relay agent can provide options to
   the client.  This document extends DHCP with a mechanism that allows
   DHCP relay agents to propose options for the server to send to DHCP
   clients.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Terminology

   The following terms and acronyms are used in this document:

   DHCP  - Dynamic Host Configuration Protocol Version 6 [RFC3315]

   RSOO  - Relay-Supplied Options option

2.  Protocol Summary

   DHCP clients do not support a mechanism for receiving options from
   relay agents--the function of the relay agent is simply to deliver
   the payload from the server.  Consequently, in order for the DHCP
   relay agent to provide options to the client, it sends those options
   to the DHCP server, encapsulated in a Relay-Supplied Options option.
   The DHCP server can then choose to place those options in the
   response it sends to the client.

3.  Encoding

   In order to supply options for the DHCP server, the relay agent sends
   a Relay-Supplied Options option in the Relay-Forward message.  This
   option encapsulates whatever options the relay agent wishes to
   provide to the DHCPv6 server.

   +----+----+----+----+--------------+
   +   TBD

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  length         OPTION_RSOO         | suboptions...|
   +----+----+----+----+--------------+

   TBD         option-length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | suboptions...
      +-+-+-+-+-+-+-+-+-+-+-+

   OPTION_RSOO  Relay-Supplied Options code

   length (TBD).

   option-length  Length of Relay-Supplied Options option option.

   suboptions  One or more DHCPv6 options options.

4.  RSOO-enabled options

   Unless specifically called out as an RSOO-enabled option, no DHCP
   option should appear in an RSOO.  Specifications that describe RSOO-
   enabled options MUST reference this specification, and MUST state
   that the option they define is RSOO-enabled.

5.  DHCP Relay Agent Behavior

   Relay agents MAY include a Relay-Supplied Options option in the
   option payload of a Relay-Forward message.  Relay agents MUST NOT
   modify the contents of any message before forwarding it to the DHCP
   client.

5.

6.  DHCP Server Behavior

   A

   DHCP server servers that implements implement this spec must have a user-configurable
   setting which determines whether or not specification MUST examine each
   option contained in an RSOO to see if it accepts a Relay-Supplied
   Options is an RSOO-enabled option.  If the
   DHCP server is configured not to accept the
   RSOO, it servers MUST silently discard any such options option contained in an RSOO
   that it receives. is not RSOO-enabled.  DHCP server implementations SHOULD have a
   user-configurable list of RSOO-enabled options, so that new RSOO-
   enabled options do not require software to be updated.

   DHCP servers normally construct a list of options that are candidates
   to send to the DHCP client, and then constructs construct the DHCP packet
   according to section 17.2.2 of DHCPv6 [RFC3315].

   If the server receives an RSOO and is configured to accept it, it
   SHOULD add any options that appear in the RSOO for which it has no
   internal candidate to the list of options that are candidates to send
   to the DHCP client.  The server SHOULD discard any options that
   appear in the RSOO for which it already has one or more candidates.
   If the server receives more than one RSOO, it SHOULD not foward
   multiple versions of the same option from different RSOOs to the DHCP
   client.

   Aside from the addition of options from the RSOO, the DHCP server
   should then construct a DHCP packet as it normally would, and
   transmit it to the DHCP client as described in DHCPv6 [RFC3315].

   DHCP Server implementations MAY discard options deemed inappropriate
   to forward.  For example, it would never be appropriate for the DHCP
   server to forward an IA option.  The list of options that will be
   discarded SHOULD be configurable by the administrator.

6.

7.  Security Considerations

   This document provides a mechanism whereby a relay agent can inject
   options into the response the DHCP server sends to the DHCP client.
   Because the DHCP server prefers its own configured options to those
   supplied by the relay agent, this can't be used as a means for
   overriding server-supplied options.  However, it is still possible in
   some configurations for a rogue DHCP relay agent to supply additional
   options to the DHCP client.

   Because the relay agent is supplying options which the DHCP server
   might then sign, this provides a mechanism whereby an attacker could
   get the DHCP server to authenticate a message that the attacker could
   not itself forge to the client.

   For this reason, DHCP servers in environments where a rogue relay
   could interpose itself into the packet flow SHOULD authenticate the
   relay agent as described in section 21.1 of DHCPv6 [RFC3315].

   Note, however, that this attack is only useful if the DHCP server is
   using the DHCPv6 authentication mechanism; in mechanism to authenticate the absence of DHCPv6
   authentication, message
   that it sends to the DHCP client.  If the message from the server to
   the client is not authenticated, the relay agent could more easily forge a message can simply add
   whatever options it wants to the message for the client, rather than
   using this more complicated mechanism to cause provide the server same option by
   way of the server.

   Furthermore, because DHCP servers will discard non-RSOO-enabled
   options provided by relay agents, the risk is limited to
   produce a message containing forged information.

7. options that
   are specifically designed to be provided by relay agents, so the set
   of options that could be provided in such an attack is very
   restricted.

8.  IANA Considerations

   We request that IANA assign one new option code from the registry of
   DHCP Option Codes maintained at
   http://www.iana.org/assignments/dhcpv6-parameters.  This option code
   will be assigned to the Relay-Supplied Options option.

8.

9.  References

8.1.

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

8.2.

9.2.  Informative References

   [I.D-ietf-hokey-ldn-discovery]
              Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name
              DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in
              progress), September 2010.

   [RFC5296]  Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
              authentication Protocol (ERP)", RFC 5296, August 2008.

Authors' Addresses

   Ted Lemon
   Nominum
   2000 Seaport Blvd
   Redwood City, CA  94063
   USA

   Phone: +1 650 381 6000
   Email: mellon@nominum.com
   Qin Wu
   Huawei Technologies Co., Ltd.
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: sunseawq@huawei.com