Customer Edge Router Identification Option
draft-donley-dhc-cer-id-option-03

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Chris Donley  , Michael Kloberdans  , John Brzozowski  , Chris Grundemann 
Last updated 2014-02-14
Stream (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          C. Donley
Internet-Draft                                             M. Kloberdans
Intended status: Informational                                 CableLabs
Expires: August 18, 2014                                   J. Brzozowski
                                                                 Comcast
                                                           C. Grundemann
                                                                    ISOC
                                                       February 14, 2014

               Customer Edge Router Identification Option
                   draft-donley-dhc-cer-id-option-03

Abstract

   Addressing mechanisms supporting DHCPv6 Prefix Delegation in home
   networks such as those described in CableLabs' eRouter specification
   and the HIPnet Internet-Draft require identification of the customer
   edge router (CER) as the demarcation between the customer network and
   the service provider network.  This document reserves a DHCPv6 option
   to identify the CER.

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 August 18, 2014.

Copyright Notice

   Copyright (c) 2014 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

Donley, et al.           Expires August 18, 2014                [Page 1]
Internet-Draft                cer-id-option                February 2014

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  CER Identification Option . . . . . . . . . . . . . . . . . .   2
   3.  Authentication  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Null Authentication . . . . . . . . . . . . . . . . . . .   4
     3.2.  Simple Password Authentication  . . . . . . . . . . . . .   4
     3.3.  Cryptographic Authentication  . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Some addressing mechanisms supporting DHCPv6 Prefix Delegation in
   home networks such as those described in [I-D.grundemann-hipnet] and
   [EROUTER] require identification of the customer edge router as the
   demarcation between the customer network and the service provider
   network.  For prefix delegation purposes, it is desirable for other
   routers within the home to know which device is the CER so that the
   customer nome network only requests a single prefix from the ISP
   DHCPv6 server, and efficiently distributes this prefix within the
   home.  This document reserves a DHCPv6 option to be used to identify
   the CER.

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].

2.  CER Identification Option

   A Customer Edge Router (CER) sets the CER_ID to the IPv6 address of
   its LAN interface.  If it has more than one LAN IPv6 address, it
   selects one of its LAN or loopback IPv6 addresses to be used in the
   CER_ID.  An ISP server does not respond with the CER_ID or sets the

Donley, et al.           Expires August 18, 2014                [Page 2]
Internet-Draft                cer-id-option                February 2014

   CER_ID to ::. Such a response or lack of response indicates to the
   DHCPv6 client that it is the CER.

   The format of the CER Identification option is:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      option-code              |      option-len               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      reserved                 |  Auth type                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Authentication                            |
|                                                               |
|                                                               |                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           CER_ID                              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    option-code          OPTION_CER_ID (TBD).
    option-len           36
    reserved             16-bit set to 0
    Auth Type            see section 3
    Authentication       see section 3
    CER_ID value         IPv6 address of CER or ::

   Figure 1.

   A DHCPv6 client SHOULD include the CER Identification option code in
   an Option Request option [RFC3315] in its DHCP Solicit messages.

   The DHCPv6 server MAY include the CER Identification option in any
   response it sends to a client that has included the CER
   Identification option code in an Option Request option.  The CER
   Identification option is sent in the main body of the message to
   client, not as a sub-option in, e.g., an IA_NA, IA_TA
   [RFC3315]option.

   When sending the CER Identification option, the DHCPv6 server MUST
   set the CER_ID value to either one of its IPv6 addresses or ::. If a
   device does not receive the CER Identification Option or receives a
   CER ID of :: from the DHCPv6 server, it MUST include one of its
   Globally Unique IPv6 address(es) in the CER_ID value in response to
   DHCPv6 messages received by its DHCPv6 server that contains the CER
   Identification option code in an Option Request option.  If the

Donley, et al.           Expires August 18, 2014                [Page 3]
Internet-Draft                cer-id-option                February 2014

   device has only one LAN interface, it SHOULD use its LAN IPv6 address
   as the CER_ID value.  If the device has more than one LAN interface,
   it SHOULD use the lowest Globally Unique address not assigned to its
   WAN interface.

3.  Authentication

   All CER-ID messages are authenticated.  The CER-ID option header
   includes an authentication type field, and 128 bits of data for use
   by the appropriate authentication scheme (determined by the type
   field).

   The authentication type is configurable on a per-DHCP-scope basis.
   Additional authentication data is also configurable on a per-scope
   basis.

   Authentication types 0, 1 and 2 are defined by this document.  All
   other authentication types are reserved for definition by the IANA
   (iana@ISI.EDU).  The current list of authentication types is
   described below.

             Authentication Type     |       Description
      -------------------------------+--------------------------------
                  0                      Null Authentication
                  1                      Simple Password
                  2                      Cryptographic authentication
               All Others                Reserved for assignment by IANA

   Authentication Type Description
   ___________________________________________ 0 Null authentication 1
   Simple password 2 Cryptographic authentication All others Reserved
   for assignment by the IANA (iana@ISI.EDU) D.1 Null authentication D.2
   Simple password authentication D.3 Cryptographic authentication

3.1.  Null Authentication

   Use of this authentication type means that the CER-ID option exchange
   is not authenticated.  The 128-bit authentication field in the option
   header can contain anything; it is not examined on packet reception.

3.2.  Simple Password Authentication

   Using this authentication type, a 128-bit field is configured on a
   per-network basis.  All packets sent by DHCP servers on a particular
   home network will have this configured value in their CER-ID option
   128-bit authentication field.  This essentially serves as a "clear"
   128-bit password.  Simple password authentication guards against home
   routers inadvertently joining the home IP network (HIPnet); each

Donley, et al.           Expires August 18, 2014                [Page 4]
Internet-Draft                cer-id-option                February 2014

   router must first be configured with its attached networks' passwords
   before it can participate in the hipnet (e.g., by extending trust to
   the CER for prefix delegation, service discovery, and firewall
   services).  However, simple password authentication is vulnerable to
   passive attacks widespread on the Internet.  Anyone with physical
   access to the network can learn the password and compromise the
   security of the hipnet.

3.3.  Cryptographic Authentication

   Using this authentication type, a shared secret key is configured in
   all routers within the hipnet.  For each CER-ID option, the key is
   used to generate/verify a MD5 "message digest" that is inserted into
   the authentication field.  The message digest is a one-way function
   of the 128-bit CER ID and the secret key.  Since the secret key is
   never sent over the network in the clear, protection is provided
   against passive attacks.

4.  IANA Considerations

   IANA is requested to assign an option code from the "DHCP Option
   Codes" Registry for OPTION_CER_ID.  IANA is also requested to
   maintain a list of authentication options.

5.  Security Considerations

   The security of a home network is an important consideration.  Both
   the HIPNet [I-D.grundemann-hipnet] and Homenet
   [I-D.ietf-homenet-arch] approaches change the operational model of
   the home network vs. today's IPv4-only paradigm.  Specifically, these
   networks eliminate NAT inside the home network (and only enable it
   for IPv4 at the edge router, if required), support global
   addressability of devices, and thus need to consider firewall and/or
   filter support in various home routers.  As the security profile of
   these home routers can shift based on their position in the network
   (e.g., edge vs. internal), security can be severely compromised if
   routers misidentify their border and mistakenly reduce or eliminate
   firewall rules.  If the CER-ID option is used as part of the border
   detection algorithm, a malicious actor with network access to a home
   router could trick the router into lowering its security perimeter by
   providing DHCP prefix delegation and adding its address in the CER-ID
   option.  However, this risk could be mitigated by adding simple
   password authentication or cryptographic authentication.  However, as
   home router devices auto-provision out of the box, and are often not
   configured directly by customers, the possibility exists that these
   routers come pre-configured for null authentication, which lessens
   the security.  This is equivalent to routing protocol options such as
   RIP(v2) or OSPF, which can be run with comparable authentication

Donley, et al.           Expires August 18, 2014                [Page 5]
Internet-Draft                cer-id-option                February 2014

   options and often default to null authentication.  Customers
   interested in security should ensure that they enable stronger
   authentication during initial provisioning.

6.  Acknowledgements

7.  References

7.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.

7.2.  Informative References

   [EROUTER]  CableLabs, "CableLabs IPv4 and IPv6 eRouter Specification
              (CM-SP-eRouter-I11-131120)", November 2013.

   [I-D.grundemann-hipnet]
              Grundemann, C., Donley, C., Brzozowski, J., Howard, L.,
              and V. Kuarsingh, "A Near Term Solution for Home IP
              Networking (HIPnet)", draft-grundemann-hipnet-00 (work in
              progress), July 2013.

   [I-D.ietf-homenet-arch]
              Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
              "IPv6 Home Networking Architecture Principles", draft-
              ietf-homenet-arch-11 (work in progress), October 2013.

Authors' Addresses

   Chris Donley
   CableLabs
   858 Coal Creek Cir.
   Louisville, CO  80027
   US

   Email: c.donley@cablelabs.com

Donley, et al.           Expires August 18, 2014                [Page 6]
Internet-Draft                cer-id-option                February 2014

   Michael Kloberdans
   CableLabs
   858 Coal Creek Cir
   Louisville, CO  80027
   US

   Email: m.kloberdans@cablelabs.com

   John Brzozowski
   Comcast
   1306 Goshen Parkway
   West Chester, PA  19380
   US

   Email: john_brzozowski@cable.comcast.com

   Chris Grundemann
   ISOC
   Denver  CO

   Email: cgrundemann@gmail.com

Donley, et al.           Expires August 18, 2014                [Page 7]