<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc4861 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY rfc4862 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY rfc2460 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY rfc4122 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml">
<!ENTITY rfc4282 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4282.xml">
<!ENTITY rfc3971 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY rfc6495 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6495.xml">
<!ENTITY rfc6494 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6494.xml">
<!ENTITY rfc6487 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml">
<!ENTITY rfc7556 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7556.xml">
<!ENTITY I-D.ietf-mif-mpvd-id PUBLIC ""
 "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-id.xml">


]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-mif-mpvd-ndp-support-03"
     ipr="trust200902"
     submissionType="IETF">
  <front>
    <title abbrev="NDP PVD support">Support for multiple provisioning domains in IPv6
     Neighbor Discovery Protocol</title>


  <author fullname="Jouni Korhonen" initials="J." surname="Korhonen" >
   <organization abbrev="Broadcom Limited">Broadcom Limited</organization>
   <address>
    <postal>
     <street>3151 Zanker Road</street>
     <city>San Jose</city>
     <code>95134</code>
     <region>CA</region>
     <country>USA</country>
    </postal>
    <email>jouni.nospam@gmail.com</email>
   </address>
  </author>

    <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8400 Decarie Blvd.</street>
          <city>Town of Mount Royal</city>
          <region>QC</region>
          <country>Canada</country>
        </postal>
        <phone>+1 514 345 7900 x42871</phone>
        <email>suresh.krishnan@ericsson.com</email>
      </address>
    </author>

    <author fullname="Sri Gundavelli" initials="S.G." surname="Gundavelli">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>USA</country>
        </postal>
        <email>sgundave@cisco.com</email>
      </address>
    </author>

    <date />
    <workgroup>MIF</workgroup>


  <abstract>
   <t>
    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.
   </t>
  </abstract>
 </front>

<middle>
 <section anchor="intro" title="Introduction">
  <t>
   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 <xref
   target="RFC7556"/>. One part of the solution requires associating
   configuration information with Provisioning Domains (PVD).  This document
   describes an IPv6 Neighbor Discovery Protocol (NDP) <xref target="RFC4861"/>
   mechanism for explicitly indicating provisioning domain information along
   with any configuration which is associated with that provisioning domain. 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 optional 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) <xref target="RFC3971"/>.
  </t>
 </section>

 <section title="Terminology">
  <t>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 <xref
   target="RFC2119"></xref>.</t>
 </section>

 <section title="PVD Container option" anchor="opt_pvd_co">
  <t>
   The PVD container option (PVD_CO) is used to encapsulate the configuration
   options that belong to the explicitly identified provisioning domain. The PVD
   container option always encapsulates exactly one PVD identity.  The PVD
   container option MAY occur multiple times in a Router Advertisement (RA)
   message. In this case each PVD container MUST belong to a different
   provisioning domain. The PVD container options MUST NOT be nested.  The PVD
   Container option is defined only for the RA NDP message.
  </t>
  <t>
   Since implementations are required to ignore any unrecognized options <xref
   target="RFC4861"/>, the backward compatibility and the reuse of existing NDP
   options is implicitly enabled. Implementations that do not recognize the PVD
   container option will ignore it, and any PVD container option "encapsulated"
   NDP options without associating them into any provisioning domain (since the
   implementation has no notion of provisioning domains). For example, the PVD
   container could "encapsulate" a Prefix Information Option (PIO), which would
   mark that this certain advertised IPv6 prefix belongs and originates from a
   specific provisioning domain. However, if the implementation does not
   understand provisioning domains, then this specific PIO is also skipped and
   not configured on the interface.
  </t>
  <t>
   The optional security for the PVD container is based on X.509 certificates
   <xref target="RFC6487"/> and reuses mechanisms already defined for SeND <xref
   target="RFC3971"/> <xref target="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. See
   <xref target="RFC6494"/> for discussion how to enable deployments where the
   certificates needed to sign PVD containers belong to different administrative
   domains i.e., to different provisioning domains.
  </t>
<figure anchor="fig_pvdco" title="PVD Container Option">
<artwork><![CDATA[
 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     |   Name Type   | r |   Sec    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Length |     ID Length       |     Key Hash (optional)       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                Digital Signature (optional)                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          PVD Identity                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~       Possible zero padding to ensure 8 octets alignment      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~           Zero or more  "encapsulated" NDP options            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

  <t><list style="hanging" hangIndent="4">
   <t hangText="Type"><vspace blankLines="1"/>
    PVD Container; Set to TBD1.
   <vspace blankLines="0"/></t>

   <t hangText="Length"><vspace blankLines="1"/>
    Length of the PVD_CO. The actual length depends on the number of
    "encapsulated" NDP options, length of the PVD Identity, and the
    optional Key Hash/Digital Signature/Padding.
   <vspace blankLines="0"/></t>

   <t hangText="Name Type"><vspace blankLines="1"/>
    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 <xref target="RFC6495"/>. Name Type values starting from 3
    are supported and an implementation MUST at least support SHA-1 (value 3).
    Note that if Sec Length=0 the Name field serves no use and MUST be set to 0.
   <vspace blankLines="0"/></t>

   <t hangText="r"><vspace blankLines="1"/>
    Reserved. MUST be set to 0 and ignored when received.
    <vspace blankLines="0"/></t>

   <t hangText="Sec Length"><vspace blankLines="1"/>
    11-bit length of the Key Hash and Digital Signature in a units of 1 octet.
    When no security is enabled the Sec Length MUST be set to value of 0.
   <vspace blankLines="0"/></t>
   
   <t hangText="ID Length"><vspace blankLines="1"/>
    11-bit length of the PVD Identity in a units of 1 octet. The ID Length MUST
    be greater than 0.
   <vspace blankLines="0"/></t>
   
   <t hangText="Key Hash"><vspace blankLines="1"/>
    This field is only present when Sec Length>0.  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 <xref target="RFC3971"/> and <xref
    target="RFC6495"/>.
   <vspace blankLines="0"/></t>
   
   <t hangText="Digital Signature"><vspace blankLines="1"/>
    This field is only present when Sec Length>0.  A signature calculated over
    the PVD_CO option including all option data from the beginning of the option
    until to the end of the container.  The procedure of calculating the
    signature is identical to the one defined for SeND <xref target="RFC3971"/>.
    During the signature calculation the contents of the Digital Signature
    option MUST be treated as all zero. 
   <vspace blankLines="0"/></t>
   
   <t hangText="PVD Identity"><vspace blankLines="1"/>
    The provisioning domain identity. The contents of this field is
    defined in a separate document <xref target="I-D.ietf-mif-mpvd-id"/>.
   </t>
  </list>
  </t> 
  <t>
   Implementations MUST ensure that the PVD container option meets the 8 octets
   NDP option alignment requirement as described in <xref target="RFC4861"/>. 
  </t>
  <t>
   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.
  </t>
  <t>
   If the PVD_CO contains a signature and the verification fails, then the whole
   PVD_CO option MUST be silently ignored and the event SHOULD be logged.
  </t>
</section>

  <section title="Set of allowable options">
   <t>
    The PVD container option MAY be used to encapsulate any allocated IPv6 NDP
    options, which may appear more than once in a NDP message. The PVD container
    option MUST NOT be used to encapsulate other PVD_CO option(s).
   </t>
  </section>

  <section anchor="security" title="Security Considerations">
   <t>
    An attacker may attempt to modify the information provided inside the PVD
    container option. These attacks can easily be prevented by using SeND <xref
    target="RFC3971"></xref> or per PVD container signature that would detect
    any form of tampering with the IPv6 NDP message contents.
   </t>
   <t>
    A compromised router may advertise configuration information related to
    provisioning domains 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 provisioning domain container contains
    embedded authentication and authorization information from the owner of the
    provisioning domain.  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 provisioning
    domain owner (e.g. a certificate with a well-known/common trust anchor).
   </t>
   <t>
    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. This specification does not define a replay protection
    solution. Rather it is assumed that if replay protection is required, the
    access network and hosts also deploy existing security solutions such as
    SeND <xref target="RFC3971"/>.
   </t>
  </section>

  <section anchor="iana" title="IANA Considerations">
   <t>
    This document defines two new IPv6 NDP options into the "IPv6 Neighbor
    Discovery Option Formats" registry. Option TBD1 is described in
    <xref target="opt_pvd_co"/>.
   </t>
  </section>

  <section anchor="acks" title="Acknowledgements">
   <t>
    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.</t>
  </section>
 </middle>

 <back>
  <references title="Normative References">
   &rfc2119;
   &rfc4861;
   &rfc6494;
   &rfc6495;
   &I-D.ietf-mif-mpvd-id;
   &rfc3971;
  </references>
  <references title="Informative References">
   &rfc6487;
   &rfc7556;
  </references>

  <section title="Examples">
   <section title="One implicit PVD and one explicit PVD">
    <t>
     <xref target="fig_ex1"/> shows how the NDP options are laid out in an RA
     for one implicit provisioning domain and one explicit provisioning domain.
     The example does not include security (and signing of the PVD
     container).  The assumption is the PVD identity consumes total 18
     octets (for example encoding a NAI Realm string "dana.example.com").
    </t>
    <t>
     The explicit provisioning domain contains a specific PIO for
     2001:db8:abad:cafe::/64 and the MTU of 1337 octets. The implicit
     provisioning domain configures a prefix 2001:db8:cafe:babe::/64 and the
     link MTU of 1500 octets. There are two cases: 1) the host receiving the RA
     implements provisioning domains and 2) the host does not understand
     provisioning domains.
     <vspace blankLines="1"/>
     <list style="numbers">
      <t>
       The host recognizes the PVD_CO and "starts" a provisioning domain
       specific configuration. Security is disabled, thus there are no Key Hash
       or Digital Signature fields to process. The prefix
       2001:db8:abad:cafe::/64 is found and configured on the interface.  Once
       the PVD_ID option is located the interface prefix configuration for
       2001:db8:abad:cafe::/64 and the MTU of 1337 octets can be associated to
       the provisioning domain found in the PVD_CO option. 
       <vspace blankLines="1"/>
       The rest of the options are parsed and configured into the implicit
       provisioning domain since there is no encapsulating provisioning domain.
       The interface is configured with prefix 2001:db8:cafe:babe::/64. The
       implicit provisioning domain uses the link MTU of 1500 octets, whereas
       the "dana.example.com" provisioning domain uses the MTU of 1337 octets
       (this means when packets are sourced using 2001:db8:abad:cafe::/64 prefix
       the link MTU is different than when sourcing packets using
       2001:db8:cafe:babe::/64 prefix).
      <vspace blankLines="1"/></t>
      <t>
       The host ignores the PVD_CO  and ends up configuring one prefix on its
       interface ( 2001:db8:cafe:babe::/64) with a link MTU of 1500 octets.
      </t>
     </list>
    </t>     
<figure anchor="fig_ex1" title="An RA with one implicit PVD and one explicit PVD">
<artwork><![CDATA[    
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      134      |       0       |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |0|1|  Reserved |       Router Lifetime         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Reachable Time                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Retrans Timer                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
|  Type=PVD_CO  |       8       |      0        | 0 |     0     ~  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
~         |        18           | PVD_ID consuming 18 octets    |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|       3       |       4       |      64       |1|1| Reserved1 |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
|                         Valid Lifetime                        |  P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  V
|                       Preferred Lifetime                      |  D
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
|                           Reserved2                           |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                      2001:db8:abad:cafe::                     ~  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|        5      |       1       |           Reserved            |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                            1337                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
|       3       |       4       | Prefix Length |1|1| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Valid Lifetime                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Preferred Lifetime                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved2                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      2001:db8:cafe:babe::                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        5      |      1        |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            1500                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
]]></artwork></figure>    
   </section>
  </section>

 </back>
</rfc>

