Internet DRAFT - draft-ietf-mif-mpvd-dhcp-support

draft-ietf-mif-mpvd-dhcp-support







DHC Working Group                                            S. Krishnan
Internet-Draft                                                  Ericsson
Intended status: Standards Track                             J. Korhonen
Expires: April 21, 2016                             Broadcom Corporation
                                                             S. Bhandari
                                                           Cisco Systems
                                                        October 19, 2015


          Support for multiple provisioning domains in DHCPv6
                  draft-ietf-mif-mpvd-dhcp-support-02

Abstract

   The MIF working group is producing a solution to solve the issues
   that are associated with nodes that can be attached to multiple
   networks.  One part of the solution requires associating
   configuration information with provisioning domains.  This document
   details how configuration information provided through DHCPv6 can be
   associated with provisioning domains.

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 April 21, 2016.

Copyright Notice

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



Krishnan, et al.         Expires April 21, 2016                 [Page 1]

Internet-Draft             DHCPv6 mPVD support              October 2015


   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  PVD Container option  . . . . . . . . . . . . . . . . . . . .   3
   4.  PVD Identity option . . . . . . . . . . . . . . . . . . . . .   3
   5.  PVD Authentication and Authorization option . . . . . . . . .   4
     5.1.  Authentication is optional  . . . . . . . . . . . . . . .   5
   6.  Set of allowable options  . . . . . . . . . . . . . . . . . .   5
   7.  Behaviour of DHCPv6 entities  . . . . . . . . . . . . . . . .   5
     7.1.  Client and Requesting Router Behavior . . . . . . . . . .   5
     7.2.  Relay Agent Behavior  . . . . . . . . . . . . . . . . . .   6
     7.3.  Server and Delegating Router Behavior . . . . . . . . . .   6
   8.  Redistributing configuration information  . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     12.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The MIF working group is producing a solution to solve the issues
   that are associated with nodes that can be attached to multiple
   networks based on the Multiple Provisioning Domains (MPVD)
   architecture work [RFC7556].  One part of the solution requires
   associating configuration information with provisioning domains.
   This document describes a DHCPv6 mechanism for explicitly indicating
   provisioning domain information along with any configuration that
   will be provided.  The proposed mechanism uses a DHCPv6 option that
   indicates the identity of the provisioning domain and encapsulates
   the options that contain the configuration information as well as any
   accompanying authentication/authorization information.

2.  Terminology

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





Krishnan, et al.         Expires April 21, 2016                 [Page 2]

Internet-Draft             DHCPv6 mPVD support              October 2015


3.  PVD Container option

   The PVD container option is used to encapsulate and group together
   all the configuration options that belong to the explicitly
   identified provisioning domain.  The PVD container option MUST
   encapsulate exactly one OPTION_PVD_ID.  The PVD container option MAY
   occur multiple times in the same message, but each of these PVD
   container options MUST have a different PVD identity specified under
   its PVD identity option.  The PVD container option SHOULD contain at
   most one (i.e. zero or one) OPTION_PVD_AUTH.

    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_PVD             |         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +            encapsulated-options (variable length)             .
   .                                                               .
   +---------------------------------------------------------------+

                      Figure 1: PVD Container Option

    o  option-code: OPTION_PVD (TBA1)

    o  option-length: Length of encapsulated options

    o  encapsulated-options: options associated with this provisioning
       domain.

4.  PVD Identity option

   The PVD identity option is used to explicitly indicate the identity
   of the provisioning domain that is associated with the configuration
   information encapsulated by the PVD container option.

    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_PVD_ID           |         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   PVD identity information                    |
   +                       (variable length)                       +
   +                                                               +
   .                                                               .
   +---------------------------------------------------------------+

                          Figure 2: PVD ID Option



Krishnan, et al.         Expires April 21, 2016                 [Page 3]

Internet-Draft             DHCPv6 mPVD support              October 2015


    o  option-code: OPTION_PVD_ID (TBA2)

    o  option-length: Length of PVD identity information

    o  PVD identity information:  The provisioning domain identity.
       The contents of this field is defined in
       a separate document [I-D.ietf-mif-mpvd-id].

5.  PVD Authentication and Authorization option

   The PVD authentication and authorization option contains information
   that could be used by the DHCPv6 client to verify whether the
   configuration information provided was not tampered with by the
   DHCPv6 server as well as establishing that the DHCPv6 server was
   authorized to advertise the information on behalf of the PVD per
   OPTION_PVD basis.  The contents of the authentication/authorization
   information is provided by the owner of the provisioning domain and
   is completely opaque to the DHCPv6 server that passes along the
   information unmodified.  Every OPTION_PVD option SHOULD contain at
   most one (i.e. zero or one) OPTION_PVD_AUTH option.  If present, the
   OPTION_PVD_AUTH option MUST be the last option inside the OPTION_PVD
   option.

    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_PVD_AUTH          |         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
   |   name-type   |               key-hash                        :  |
   +-+-+-+-+-+-+-+-+                                               :  |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth
   :                                                               : info
   :                      digital-signature                        :  |
   :                                                               :  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+

                         Figure 3: PVD Auth Option


    o  option-code: OPTION_PVD_AUTH (TBA3)

    o  option-length: Length of the Auth info

    o  name-type: Names the algorithm used to identify a specific
       X.509 certificate using the method defined for the Subject Key
       Identifier (SKI) extension for the X.509 certificates. The
       usage and the Name Type registry aligns with the mechanism



Krishnan, et al.         Expires April 21, 2016                 [Page 4]

Internet-Draft             DHCPv6 mPVD support              October 2015


       defined for SeND [RFC6494][RFC6495].
       Name Type values starting
       from 3 are supported and an implementation MUST at least support
       SHA-1 (value 3).

    o  key-hash: A hash of the public key using the algorithm
       identified by the Name Type. The procedure how the Key Hash is
       calculated is defined in [RFC3971] and [RFC6495].

    o  digital-signature: A signature calculated over the encapsulating
       OPTION_PVD including all option data from the beginning of the
       option while setting the digital-signature field to zero. The
       procedure of calculating the signature is identical to the one
       defined for SeND [RFC3971].

5.1.  Authentication is optional

   The OPTION_PVD_AUTH will be sent only if it is requested in the
   ORO.If the client does not request this option, it will not get a
   signed PVD option.  Clients that request the OPTION_PVD with the
   intention of redistributing configuration information to other
   clients (e.g. CPE routers) SHOULD NOT request the OPTION_PVD_AUTH in
   the ORO.  This allows them to send out a subset of the received
   options to their clients and also allows them to support PVD unaware
   clients by sending out the options without PVD information.

6.  Set of allowable options

   The PVD container option MAY be used to encapsulate any allocated
   DHCPv6 options but MUST NOT be used to encapsulate another OPTION_PVD
   option.

7.  Behaviour of DHCPv6 entities

   This section describes role of DHCPv6 entities involved in requesting
   and receiving DHCPv6 configuration or prefix and address allocation.

7.1.  Client and Requesting Router Behavior

   DHCPv6 client or requesting router can request for configuration from
   provisioning domain in the following ways:

   o  In the SOLICIT message it MAY include OPTION_PVD_ID requesting
      configuration for the specific PVD ID indicated in the
      OPTION_PVD_ID option.  It can include multiple OPTION_PVD_ID
      options to indicate its preference for more than one provisioning
      domain.  The PVD ID it requests is learnt via configuration or any
      other out of band mechanism not defined in this document.



Krishnan, et al.         Expires April 21, 2016                 [Page 5]

Internet-Draft             DHCPv6 mPVD support              October 2015


   o  In the SOLICIT message include an OPTION_ORO option with the
      OPTION_PVD option code to request configuration from all the PVDs
      that the DHCPv6 server can provide.

   The client or requesting router parses OPTION_PVD options in the
   response message.  The Client or Requesting router MUST then include
   all or subset of the received OPTION_PVD options in the REQUEST
   message so that it will be responsible for the configuration
   information selected.

   If DHCPv6 client or requesting router receives OPTION_PVD options but
   does not support PVD, it SHOULD ignore the received option(s).

7.2.  Relay Agent Behavior

   If the relay agent supports both the Relay-Supplied DHCP Option
   (RSOO) [RFC6422] and the PVD, and it is configured to request
   configuration data for clients in one or more provisioning domains,
   then the relay agent MAY include the RSOO in the Relay-Forward
   message.  The RSOO MAY contain zero or more OPTION_PVD options.  The
   relay agent MUST NOT include any OPTION_PVD options into the RSOO
   unless the client has indicated support for the PVD as described in
   Section Section 7.1.

7.3.  Server and Delegating Router Behavior

   If the Server or Delegating router supports PVD and it is configured
   to provide configuration data in one or more provisioning domains, it
   selects configuration for the PVD based allocation in the following
   way:

   o  If OPTION_PVD option code within OPTION_ORO is not present in the
      request, it MUST NOT include provisioning domain based
      configuration.  It MAY select configuration and prefix allocation
      from a default PVD defined.

   o  If OPTION_PVD_ID is included, it selects information to be offered
      from that specific PVD if available.

   o  If OPTION_PVD option code within OPTION_ORO is included, then
      based on its configuration and policy it MAY offer configuration
      from the available PVD(s).

   When PVD information and configuration are selected for address and
   prefix allocation the server or delegating router responds with an
   ADVERTISE message after populating OPTION_PVD.





Krishnan, et al.         Expires April 21, 2016                 [Page 6]

Internet-Draft             DHCPv6 mPVD support              October 2015


   If OPTION_PVD is not included, then the server or delegating router
   MAY allocate the prefix and provide configuration as specified in
   [RFC3315] and[RFC3633] and MUST NOT include OPTION_PVD option in the
   response.

   If OPTION_ORO option includes the OPTION_PVD option code but the
   server or delegating router does not support PVD, then it SHOULD
   ignore the OPTION_PVD and OPTION_PVD_ID options received.

   If both client/requesting router and server/delegating router support
   PVD but cannot offer configuration with PVD for any other reason, it
   MUST respond to client/requesting router with appropriate status code
   as specified in [RFC3315] and [RFC3633].

   Similarly, if the OPTION_PVD is received in the RSOO from the relay
   agent the above described procedures apply for including the PVD
   specific configuration information back to the client.

8.  Redistributing configuration information

   Clients that redistribute configuration information further to legacy
   clients (e.g. homenet CPEs) after stripping out the PVD information
   need to exercise caution when removing information from the PVD
   containers and distributing them as top level options.  Configuration
   information that is consistent within a PVD container may not work
   equally well when mixed with other top level configuration
   information or information from other PVD containers. e.g. Using DNS
   server information from one PVD container while using address/prefix
   from another may lead to unexpected results.

9.  Security Considerations

   An attacker may attempt to modify the information provided inside the
   PVD container option.  These attacks can easily be prevented by using
   the DHCPv6 AUTH option [RFC3315] that would detect any form of
   tampering with the DHCPv6 message contents.

   A compromised DHCPv6 server or relay agent may insert configuration
   information related to PVDs it is not authorized to advertise. e.g. A
   coffee shop DHCPv6 server may provide configuration information
   purporting to be from an enterprise and may try to attract enterprise
   related traffic.  The only real way to avoid this is that the PVD
   container contains embedded authentication and authorization
   information from the owner of the PVD.  Then, this attack can be
   detected by the client by verifying the authentication and
   authorization information provided inside the PVD container option
   after verifying its trust towards the PVD owner (e.g. a certificate
   with a well-known/common trust anchor).



Krishnan, et al.         Expires April 21, 2016                 [Page 7]

Internet-Draft             DHCPv6 mPVD support              October 2015


   A compromised configuration source or an on-link attacker may try to
   capture advertised configuration information and replay it on a
   different link or at a future point in time.  This can be avoided by
   including some replay protection mechanism such as a timestamp or a
   nonce inside the PVD container to ensure freshness of the provided
   information.

10.  IANA Considerations

   This document defines three new DHCPv6 options to be allocated out of
   the registry at http://www.iana.org/assignments/dhcpv6-parameters/

      OPTION_PVD (TBA1)
      OPTION_PVD_ID (TBA2)
      OPTION_PVD_AUTH (TBA3)

   This document also adds OPTION_PVD (TBA1) into the "Options Permitted
   in the Relay-Supplied Options Option" registry at http://www.iana.org
   /assignments/dhcpv6-parameters/

11.  Acknowledgements

   The authors would like to thank the members of the MIF architecture
   design team for their comments that led to the creation of this
   draft.  The authors would also thank Ian Farrer and Steven Barth for
   their reviews and comments.

12.  References

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

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI
              10.17487/RFC4122, July 2005,
              <http://www.rfc-editor.org/info/rfc4122>.





Krishnan, et al.         Expires April 21, 2016                 [Page 8]

Internet-Draft             DHCPv6 mPVD support              October 2015


   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, DOI 10.17487/
              RFC4282, December 2005,
              <http://www.rfc-editor.org/info/rfc4282>.

   [RFC6422]  Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC
              6422, DOI 10.17487/RFC6422, December 2011,
              <http://www.rfc-editor.org/info/rfc6422>.

   [RFC6494]  Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
              Profile and Certificate Management for SEcure Neighbor
              Discovery (SEND)", RFC 6494, DOI 10.17487/RFC6494,
              February 2012, <http://www.rfc-editor.org/info/rfc6494>.

   [RFC6495]  Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key
              Identifier (SKI) SEcure Neighbor Discovery (SEND) Name
              Type Fields", RFC 6495, DOI 10.17487/RFC6495, February
              2012, <http://www.rfc-editor.org/info/rfc6495>.

12.2.  Informative References

   [RFC7556]  Anipko, D., Ed., "Multiple Provisioning Domain
              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
              <http://www.rfc-editor.org/info/rfc7556>.

Authors' Addresses

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com


   Jouni Korhonen
   Broadcom Corporation
   3151 Zanker Road
   San Jose, CA  95134
   USA

   Email: jouni.nospam@gmail.com







Krishnan, et al.         Expires April 21, 2016                 [Page 9]

Internet-Draft             DHCPv6 mPVD support              October 2015


   Shwetha Bhandari
   Cisco Systems
   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
   Bangalore, KARNATAKA  560 087
   India

   Phone: +91 80 4426 0474
   Email: shwethab@cisco.com











































Krishnan, et al.         Expires April 21, 2016                [Page 10]