One document matched: draft-ietf-mif-mpvd-id-01.xml

<?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 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 rfc4122 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml">
<!ENTITY rfc3971 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY rfc4282 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4282.xml">
<!ENTITY I-D.ietf-mif-mpvd-arch PUBLIC ""
 "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-arch.xml">

<!ENTITY I-D.ietf-mif-mpvd-ndp-support PUBLIC ""
 "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-ndp-support.xml">
<!ENTITY I-D.ietf-mif-mpvd-dhcp-support PUBLIC ""
 "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-dhcp-support.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-id-01" ipr="trust200902">
  <front>
    <title abbrev="PVD Identification">Identification of provisioning domains</title>

    <author fullname="Suresh Krishnan" initials="S.K." 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="Jouni Korhonen" initials="J.K." surname="Korhonen">
      <organization abbrev="Broadcom Corporation">Broadcom Corporation</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="Shwetha Bhandari" initials="S.B." surname="Bhandari">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Sarjapura Marathalli Outer Ring
          Road</street>
          <city>Bangalore</city>
          <region>KARNATAKA</region>
          <code>560 087</code>
          <country>India</country>
        </postal>

        <phone>+91 80 4426 0474</phone>

        <email>shwethab@cisco.com</email>
      </address>
    </author>

<author initials="S" surname="Gundavelli" fullname="Sri Gundavelli">
<organization abbrev="">Cisco</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 />

    <area>Internet</area>

    <workgroup>mif Working Group</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. This document describes several methods of
      generating identification information for provisioning them and
      a format for carrying such identification in configuration
      protocols.</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="I-D.ietf-mif-mpvd-arch"/>.  This document describes a
      format for carrying identification information along with a few
      alternatives for reasonable sources for Provisioning Domain (PVD) 
      identification. Since the PVD identities (PVD ID) are expected to be unique, the
      identification sources provide some level of uniqueness using
      either a hierarchical structure (e.g. FQDNs and OIDs) or some
      form of randomness (e.g. UUID and ULAs). Any source that does
      not provide either guaranteed or probabilistic uniqueness is
      probably not a good candidate for identifying provisioning
      domains.</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="Provisioning domain identity format">
      <t>The identity of the PVD is independent of the configuration
      protocol used to communicate it. Furthermore, the PVD identity
      SHOULD only contain information related to the identification
      purposes and not encode additional provisioning domain specific
      configuration information. The used configuration protocol and
      its extensions are meant for that purpose
      <xref target="I-D.ietf-mif-mpvd-dhcp-support"/>
      <xref target="I-D.ietf-mif-mpvd-ndp-support"/>.
      The PVD identity is formatted as follows.</t>

      <figure title="PVD ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    id-type    |   id-length   |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+                    PVD identity information                   +
.                       (variable length)                       .
+---------------------------------------------------------------+
]]></artwork>
      </figure>

      <figure title="">
        <artwork><![CDATA[

 o  id-type: Describes the type of identification information. 
    This document defines six types of PVD identity information
      0x01: UUID [RFC4122]
      0x02: UTF-8 string
      0x03: OID [OID]
      0x04: NAI Realm [RFC4282]
      0x05: FQDN
      0x06: ULA Prefix [RFC4193]
      Further types can be added by IANA action.

 o  id-length: Length of the PVD identification  in octets 
    not including the id-type and id-length fields.

 o  PVD identity information: The PVD identification that is 
    based on the id-type.
]]></artwork>
      </figure>

      
    </section>
    <section anchor="security" title="Security Considerations">
      <t>An attacker may attempt to modify the PVD identity provided
      in a configuration protocol. These attacks can be
      prevented by using the configuration protocol mechanisms such as
      SEND <xref target="RFC3971"/> and DHCPv6 AUTH option <xref
      target="RFC3315"></xref> that  detect any form of tampering
      with the configuration.</t>
      <t>A compromised configuration source, on the other hand, cannot
      easily be detected by a configuration client. The only real way
      to avoid this is that the PVD identification is directly
      associable to some form of authentication and authorization
      information from the owner of the PVD (e.g. an FQDN can be
      associated with a DANE cert). Then, this attack can be detected
      by the client by verifying the authentication and authorization
      information provided inside the PVD container option 
      after <xref target="I-D.ietf-mif-mpvd-dhcp-support"/>
      <xref target="I-D.ietf-mif-mpvd-ndp-support"/>
      verifying its trust towards the PVD owner (e.g. a certificate
      with a well-known/common trust anchor that).</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document creates a new registry for PVD id types. The initial values are listed below</t>
<figure>
<artwork>
      0x01: UUID [RFC4122]
      0x02: UTF-8 string
      0x03: OID [OID]
      0x04: NAI Realm [RFC4282]
      0x05: FQDN
      0x06: ULA Prefix [RFC4193]
</artwork>
</figure>
    </section>

    <section anchor="acks" title="Acknowledgements">
      <t>The authors would like to thank the members of the MIF
      architecture design team, Ted Lemon, Brian Carpenter, Bernie
      Volz and Alper Yegin for their contributions to this draft.
      The authors also thank Ian Farrer for his reviews and comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc3315;
      &rfc3971;
      &rfc4122;
      &rfc4282;

      <reference anchor="OID">
        <front>
          <title>PRIVATE ENTERPRISE NUMBERS</title>

          <author>
            <organization>IANA</organization>
          </author>

          <date day='7' month='March' year='2013' />
        </front>

        <seriesInfo name="SMI Network Management Private Enterprise Codes, "
                    value="http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers" />

        <!--format type='HTML' target='http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers' /-->
      </reference>
    </references>
    <references title="Informative References">
      &I-D.ietf-mif-mpvd-arch;
      &I-D.ietf-mif-mpvd-dhcp-support;
      &I-D.ietf-mif-mpvd-ndp-support;
    </references>
  </back>
</rfc>