Skip to main content

Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol
draft-kk-mpvd-ndp-support-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jouni Korhonen , Suresh Krishnan
Last updated 2013-10-21
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kk-mpvd-ndp-support-00
IPv6 Maintenance                                             J. Korhonen
Internet-Draft                                                  Broadcom
Intended status: Standards Track                             S. Krishnan
Expires: April 24, 2014                                         Ericsson
                                                        October 21, 2013

  Support for multiple provisioning domains in IPv6 Neighbor Discovery
                                Protocol
                      draft-kk-mpvd-ndp-support-00

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 IPv6 Neighbor
   Discovery Protocol 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 24, 2014.

Copyright Notice

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

Korhonen & Krishnan      Expires April 24, 2014                 [Page 1]
Internet-Draft               NDP PVD support                October 2013

   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  PVD Container option  . . . . . . . . . . . . . . . . . . . . . 3
   4.  PVD Identity option . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Set of allowable options  . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Korhonen & Krishnan      Expires April 24, 2014                 [Page 2]
Internet-Draft               NDP PVD support                October 2013

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 [I-D.anipko-mif-mpvd-arch].  One part of the
   solution requires associating configuration information with
   Provisioning Domains (PVD).  This document describes an IPv6 Neighbor
   Discovery Protocol (NDP) [RFC4861] mechanism for explicitly
   indicating provisioning domain information along with any
   configuration that will be provided.  The proposed mechanism uses an
   NDP 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.
   The solution defined in this document aligns as much as possible with
   the existing IPv6 Neighbor Discovery security, namely with Secure
   Neighbor Discovery (SeND) [RFC3971].

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

3.  PVD Container option

   The PVD container option (PVD_CO) 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 PVD identifier option (PVD_ID).  The PVD
   container option MAY occur multiple times in the same NDP message but
   each of these PVD container options MUST have a different PVD
   identity specified under its PVD identity option.  A PVD container is
   intended to be used in IPv6 Router Advertisement (RA) NDP messages.
   However, including a PVD container inside a Router Solicitation (RS)
   NDP messages is also possible (actually, a host can in this way
   solicit for information from a specific PVD).

   For the backward compatibility and the reuse of existing NDP options,
   the PVD container can encapsulate any (meaningful) existing IPv6 NDP
   options.  For example, the PVD container could encapsulate a Prefix
   Information Option (PIO), which would mark that a certain advertised
   IPv6 prefix belongs and originates from a specific PVD.  Furthermore,
   for the backward compatibility reasons, it is RECOMMENDED that
   options critical for establishing IP communication (such as the
   prefix and DNS information) are encapsulated inside the PVD container

Korhonen & Krishnan      Expires April 24, 2014                 [Page 3]
Internet-Draft               NDP PVD support                October 2013

   as well as in the RA (although this will cause duplication of
   information is most cases).  This ensures hosts that do not
   understand provisioning domain concept, will at least receive the
   implicit provisioning domain configuration.  Hosts that understand
   provisioning domain SHOULD always give configuration information
   encapsulated inside the PVD container a higher priority than the ones
   outside the PVD container(s).  It should be noted that a router can
   do smart advertisement of "legacy" configuration information and the
   PVD container encapsulated.  The router MAY leave some of the
   provisioning domain specific information outside the "legacy
   [RFC4861] way" of advertising them in RAs.

   The optional security for the PVD container is based on X.509
   certificates [RFC6487] and reuses mechanisms already defined for SeND
   [RFC3971] [RFC6495].  However, the use of PVD containers does not
   assume or depend on SeND being deployed or even implemented.  The PVD
   containers SHOULD be signed per PVD certificates, which provides both
   integrity protection and proves that the configuration information
   source is authorized for advertising the given information.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type=PVD_CO  |    Length     | Options Count |   Name Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :         Suboptions (padded to 8 octet boundary)               :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
   :                                                               :  |
   :                           Key Hash                            :  o
   :                                                               :  p
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  t
   :                                                               :  i
   :                      Digital Signature                        :  o
   :                                                               :  n
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  a
   :                       Padding (zeroes)                        :  l
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+

                      Figure 1: PVD Container Option

   Type

       PVD Container; Set to TBA1.

Korhonen & Krishnan      Expires April 24, 2014                 [Page 4]
Internet-Draft               NDP PVD support                October 2013

   Length

       Length of the PVD_CO.  The actual length depends on the number of
       suboptions and the optional Key Hash/Digital Signature/Padding.

   Options Count

       The number of suboptions in this PVD container.  MUST be 1 or
       greater.

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

   Suboptions

       One or more suboptions that describe properties and other meta
       data attached to the provisioning domain.  See Section 4 for
       description of the PVD_ID suboption.  All suboptions MUST be
       multiple of 8 octets and provide required padding with '\0'
       octets, when needed.  Unknown suboptions MUST be silently
       discarded.

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

   Digital Signature

       A signature calculated over the PVD_CO option including all
       option data from the beginning of the option until the Key Hash
       field.  The procedure of calculating the signature is identical
       to the one defined for SeND [RFC3971].

   Padding

       Zero or more '\0' octets to make the PVD_CO to multiple of 8
       octets.

   The presence of the optional Key Hash and Digital Signature field is

Korhonen & Krishnan      Expires April 24, 2014                 [Page 5]
Internet-Draft               NDP PVD support                October 2013

   determined from the Length field, i.e. the option length is greater
   than 0 after subtracting 'Options Count' times suboptions from it,
   then the signature part of the option is present.  If the PVD_CO does
   not contain a digital signature, then other means to secure the
   integrity of the NDP message SHOULD be provided, such as utilizing
   SeND.  However, the security provided by SeND is for the entire NDP
   message and does not allow verifying whether the sender of the NDP
   message is actually authorized for the information for the
   provisioning domain.

   If the PVD_CO contains a signature and the verification fails, then
   the whole PVD_CO MUST be silently discarded and the event SHOULD be
   logged.

4.  PVD Identity option

   The PVD identity option (PVD_ID) is used to explicitly indicate the
   identity of the provisioning domain that is associated with the
   configuration information encapsulated by the PVD container option.
   A PVD container MUST have exactly one PVD identity 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type=PVD_ID  |    Length     | ID-Type       | ID-Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Provisioning Domain Identifier               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 2: PVD_ID Option

   Type

       PVD identifier; Set to TBA2.

   Length

       Length of the PVD_ID.

   ID-Type

       Describes the type of identification information.  This document
       defines four types of PVD identity information:

Korhonen & Krishnan      Expires April 24, 2014                 [Page 6]
Internet-Draft               NDP PVD support                October 2013

           0x01: UUID [RFC4122]
           0x02: UTF-8 string
           0x03: OID [OID]
           0x03: NAI Realm [RFC4282]

   ID-Length

       Length of the Provisioning Domain Identifier in octets.

   Provisioning Domain Identifier

       The PVD identification that is based on the id-type.  The
       identifier MUST be '\0' octet padded until the PVD_ID option
       length is multiple of 8 octet.

   If the receiver of the PVD_ID option does not understand any of the
   ID-Types, then the whole encapsulating PVD_CO MUST be silently
   discarded.

5.  Set of allowable options

   The PVD container option MAY be used to encapsulate any allocated
   IPv6 NDP options but MUST NOT be used to encapsulate another PVD_CO
   option.  [TODO: Should we add any other exclusions?].

6.  Security Considerations

   An attacker may attempt to modify the information provided inside the
   PVD container option.  These attacks can easily be prevented by using
   SeND [RFC3971] or per PVD container signature that would detect any
   form of tampering with the IPv6 NDP message contents.

   A compromised router may advertise configuration information related
   to PvDs it is not authorized to advertise. e.g.  A coffee shop router
   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).

   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

Korhonen & Krishnan      Expires April 24, 2014                 [Page 7]
Internet-Draft               NDP PVD support                October 2013

   including some replay protection mechanism such as a timestamp or a
   nonce inside the PvD container to ensure freshness of the provided
   information.

7.  IANA Considerations

   This document defines new IPv6 Neighbor discovery options from the
   registry at http://www.iana.org/assignments/icmpv6-parameters/
   icmpv6-parameters.xhtml#icmpv6-parameters-5

         PVD_CO: TBA1
         PVD_ID: TBA2

   This document reuses information from a new registry for PVD Identity
   types

   http://www.iana.org/assignments/dhcpv6-parameters/

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

9.  References

9.1.  Normative References

   [OID]      IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management
              Private Enterprise Codes,  http://www.iana.org/
              assignments/enterprise-numbers/enterprise-numbers.

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

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July 2005.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

Korhonen & Krishnan      Expires April 24, 2014                 [Page 8]
Internet-Draft               NDP PVD support                October 2013

   [RFC6494]  Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
              Profile and Certificate Management for SEcure Neighbor
              Discovery (SEND)", RFC 6494, February 2012.

   [RFC6495]  Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key
              Identifier (SKI) SEcure Neighbor Discovery (SEND) Name
              Type Fields", RFC 6495, February 2012.

9.2.  Informative References

   [I-D.anipko-mif-mpvd-arch]
              Anipko, D., "Multiple Provisioning Domain Architecture",
              draft-anipko-mif-mpvd-arch-04 (work in progress),
              October 2013.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", RFC 6487,
              February 2012.

Authors' Addresses

   Jouni Korhonen
   Broadcom
   Porkkalankatu 24
   FIN-00180 Helsinki
   Finland

   Email: jouni.nospam@gmail.com

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

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

Korhonen & Krishnan      Expires April 24, 2014                 [Page 9]