One document matched: draft-lear-mud-framework-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-lear-mud-framework-00" category="info">

  <front>
    <title abbrev="MUD">Manufacturer Usage Description Framework</title>

    <author initials="E." surname="Lear" fullname="Eliot Lear">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Richtistrasse 7</street>
          <city>Wallisellen</city>
          <code>CH-8304</code>
          <country>Switzerland</country>
        </postal>
        <phone>+41 44 878 9200</phone>
        <email>lear@cisco.com</email>
      </address>
    </author>

    <date year="2016" month="January" day="21"/>

    
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>A key presumption of the Internet architecture has been that devices
are general purpose computers.  By constraining the set of devices
that connect to the Internet to non-general purpose devices, we can
introduce a set of network capabilities that provides an additional
layer of protection to those devices.  One such capability is the
Manufacturer Usage Description (MUD).  This work builds on many
existing network capabilities so as to be easily deployable by all
involved.  The focus of this work is primarily, but not exclusively,
in the realm of security; and again primarily, but not exclusively,
relating to smart objects.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The Internet has largely been constructed on general purpose
computers; those devices that may be used for a purpose that is
specified by those who buy the device.  <xref target="RFC1984"/> presumed that an
end device would be most capable of protecting itself.  This made
sense when the typical device was a workstation or a mainframe, and it
continues to make sense for general purpose computing devices today,
including laptops, smart phones, and tablets.</t>

<t><xref target="RFC7452"/> discusses design patterns for, and poses questions about,
smart objects.  Let us then posit a group of objects that are
specifically not general purpose computers.  These devices therefore
have a purpose to their use.  By definition, therefore, all other
purposes are NOT intended.  The combination of these two statements
can be restated as a manufacturer usage description (MUD) that can
be applied at various points within a network.  Although this memo may
seem to stress access requirements, usage intent also consists of
quality of service needs a device may have.</t>

<t>We use the notion of “manufacturer” loosely in this context, to simply
mean the entity or organization that will state how a device is
intended to be used.  In the context of a lightbulb, this might indeed
be the lightbulb manufacturer.  In the context of a smarter device
that has a built in Linux stack, it might be integrator of that
device.  The key points are that the device itself is expected to
serve a limited purpose, and that there may exist an organization in
the supply chain of that device that will take responsibility for
informing the network about that purpose.</t>

<t>The converse statement holds that general computing systems will
benefit very little from MUD, as their manufacturers cannot envision a
specific communication pattern to describe.</t>

<t>The intent of MUD is to therefore solve for the following problems:</t>

<t><list style="symbols">
  <t>Substantially reduce the threat surface on a device entering a
network to those communications intended by the manufacturer.</t>
  <t>Provide for a means to scale network policies to the ever-increasing
number types of devices in the network.</t>
  <t>Provide a means to address at least some vulnerabilities in a way
that is faster than it might take to update systems.  This will be
particularly true for systems that are no longer supported by their
manufacturer.</t>
  <t>Keep the cost of implementation of such a system to the bare minimum.</t>
</list></t>

<t>No matter how good a MUD-enabled network is, it will never replace the
need for manufacturers to patch vulnerabilities.  It may, however,
provide network administrators with some additional protection when
those vulnerabilities exist.</t>

<section anchor="a-simple-example" title="A Simple Example">
<t>A light bulb is intended to light a room.  It may be remotely
controlled through the network; and it may make use of a rendezvous
service of some form that an app on smart phone accesses.  What we can
say about that light bulb, then, is that all other network access is
unwanted.  It will not contact a news service, nor speak to the
refrigerator, and it has no need of a printer or other devices.  It
has no Facebook friends.  Therefore, an access list applied to it that
states that it will only connect to the single rendezvous service will
not impede the light bulb in performing its function, while at the same
time allowing the network to provide both it and other devices an
additional layer of protection.</t>

</section>
<section anchor="determining-intended-use" title="Determining Intended Use">
<t>The notion of intended use is in itself not new.  Network
administrators apply access lists every day to allow for only such
use.  This notion of white listing was well described by Chapman and
Zwicky in <xref target="FW95"/>.  Programmatically profiling systems have existed
for years as well.  These systems make use of heuristics that take
at least some time to assert what a system is.</t>

<t>A system could just as easily tell the network what sort of protection
it requires without going into what sort of system it is.  This would,
in effect, be the converse of <xref target="RFC7488"/>.  In seeking a general
purpose solution, however, we assume that a device has so few
capabilities that it will implement the least necessary capabilities
to function properly.  This is a basic economic constraint.  Unless
the network would refuse access to such a device, its developers would
have no reason to implement such an approach.  To date, such an
assertion has held true.</t>

<t>If the network does not apply heuristics and a device is not capable
of articulating what it needs from the network, perhaps there is a
third approach that builds on capabilities already in both.  There are
four such potential capabilities for the network to determine what
sort of client it has:</t>

<t><list style="numbers">
  <t>For those devices that are meant to operate in a secure
environment <xref target="IEEE8021X"/> and <xref target="IEEE8021AR"/> provides a means
for certificate-based device identification.</t>
  <t>In the absense of DHCP in IPv6 (e.g., stateless address selection),
<xref target="IEEE8021AB"/> can be used to learn the same information.</t>
  <t>In the IP network context, every device needs an IP address.
<xref target="RFC2131"/> specifies the dynamic host configuraiton protocol,
necessary for all IPv4 and IPv6 implementations.  Client use of a
DHCP option would inform the network of what the device thinks it
is, and provide a pointer to additional policy information.</t>
  <t>Finally, for equipment that does not emit any information, 
it is possible for the access switch to proxy the information into
the system.</t>
</list></t>

<t>With these capabilities, a device may impart some piece of information
to the network.  In the immortal words of David John Wheeler, “All
problems in computer science can be solved by another level of
indirection, except of course for the problem of too many
indirections.”  Our means of providing this level of indirection is a
Universal Resource Identifier (URI) <xref target="RFC3986"/> that references a file
put in place by someone who knows something about the device – the
manufacturer.  As we will later discuss, we can later relax whether it
is indeed the manufacturer who is specifying the URI.</t>

<t>With a simple resolution of a URI, a file is retrieved.  We are now to
the point in the discussion where we have to decide how the
manufacturer expresses intent.  We have already stated that Things
themselves have limited capabilities.  Let us also assume that we in
the networking business wish to stand on the shoulders of giants and
also not reinvent the wheel.  While such a wheel is not <spanx style="emph">perfectly</spanx>
rounded for our purposes, YANG models <xref target="RFC6020"/> and their derivative
XML provide sufficient richness for the manufacturer to clearly state
at least simple intent.  They are thus our starting point.</t>

</section>
<section anchor="types-of-policies" title="Types of Policies">

<t>Once we know how to determine intended use and who can determine it,
there is still the question of what that sort of policies can in fact
be intended.  At least initially, we envision that as a beginning
host-level access policies.  The manufacturer may specify either
specific hosts or certain classes.  An example of a class might be
“devices of a specified manufacturer type”, where the manufacturer
type itself is indicated simply by the authority of the MUD-URI.
Another example might to allow or disallow local access.  Just like
other policies, these may be combined.  For example:</t>

<figure><artwork><![CDATA[
   Allow access to host controller.example.com with QoS AF11
   Allow access to devices of the same manufacturer
   Allow access to and from controllers who need to speak COAP
   Allow access to local DNS/DHCP
   Deny all other access
]]></artwork></figure>

<t>To add a bit more depth that should not be a stretch of anyone’s
imagination, one could also make use of port-based access lists.  Thus
a printer might have a description that states:</t>

<figure><artwork><![CDATA[
   Allow access for port IPP or port LPD
   Allow local access for port HTTP
   Deny all other access
]]></artwork></figure>

<t>In this way anyone can print to the printer, but local access would
be required for the management interface.</t>

<t>Other non-access policies may be possible as well.  For instance,
suppose a manufacturer is able to make use of an authentication
infrastructure.  That could be specified in the usage description such
that the details could be filled in by the controller.  In addition,
QoS policies are sufficiently mature and ubiquitous as to be valuable
in this context as well.  And so for instance, for voice/video
services:</t>

<figure><artwork><![CDATA[
   Set QoS AF13 to SIP-GW.EXAMPLE.COM
]]></artwork></figure>

<t>The converse highlights a design consideration: policies that are
articulated by the manufacturer must be ubiquitously understood, or
they may not be applied.  That is- applying half a policy is not safe.</t>

</section>
</section>
<section anchor="the-manufacturer-usage-description-architecture" title="The Manufacturer Usage Description Architecture">

<t>With these components laid out we now have the basis for an
archicture.  This leads us to ASCII art.</t>

<figure title="MUD Architecture" anchor="fig1"><artwork><![CDATA[
 .........................................
 .                      ____________     .           __________
 .                     |  Network   |    .          |          |
 .                     | Management |----->get URI->|   MFG    |
 .                     |  System    |    .          | Web Site |
 .  End system network |____________|<--MUD file<--<|__________|
 .                             .         .
 .                             .         .
 . _______                 _________     .
 .|       |               | router  |    .
 .| Thing |---->MUD URI-->|   or    |    .
 .|_______|               | switch  |    .
 .                        |_________|    .
 .........................................
]]></artwork></figure>

<t>In the above diagram, the switch or router collects MUD URIs and
forwards them to the network management system for processing.  This
happens in different ways, depending on how the URI is communicated.
For instance, in the case of DHCP, the DHCP server might receive the
URI and then process it.  In the case of IEEE 802.1X, the switch
would tunnel the URI to the authentication server, who would then
process it.</t>

<t>The information returned by the web site is valid for the duration of
the device’s connection, or as specified in the description.  Thus if the
device is mobile, when it moves on, any configuration in the switch is
removed.  Similarly, from time to time the description may be
refreshed, based on new capabilities or communication patterns or
vulnerabilities.</t>

<t>The web site is run by or on behalf of the manufacturer.  Its domain
name is that of the authority found in the MUD URI.  For legacy cases
where Things cannot emit a URI, if the switch is able to determine the
appropriate URI, it may proxy it, the trivial cases being a map
between some registered device or port and a URI.</t>

<section anchor="what-does-a-mud-uri-look-like" title="What does a MUD URI look like?">
<t>To begin with, MUD takes full advantage of both the https: scheme and
the use of .well-known.  HTTPS is important in this case because men
in the middle could otherwise harm the operation of a class of
devices.  .well-known is used because we wish to add additional
structure to the URI.  And so the URI is specified in
draft-lear-netmod-mud-pre0.  It looks like this:</t>

<figure><artwork><![CDATA[
 https://manufacturer.example.com/.well-known/mud/v1/model/version#extra

]]></artwork></figure>

<t>“model” represents a device model as the manufacturer wishes to
represent it.  It could be a brand name or something more specific.
“version” provides a means to indicate what version the product is.
Specifically if it has been updated in the field, this is the place
where evidence of that update would appear.  Once again, the field is
opaque.  From a controller standpoint, therefore, only comparison and
matching operations are safe.</t>

</section>
<section anchor="communicating-to-the-manufacturer" title="Communicating to the Manufacturer">
<t>We assume that the the manufacturer has at its disposal a web service
running atop port 443 with standard HTTPS semantics, and that its
capabilities are at par with today’s web servers.  We further assume
that this web server has no semantic understanding itself of MUD.
This poses us a particular challenge: either we are to cast in stone
the model that is put in place, or we must find a mechanism by which
the switch or its controller can choose an appropriate set of
capabilities.</t>

</section>
<section anchor="using-yang-based-xml" title="Using YANG-based XML">
<t>Because NETCONF is well distributed within network infrastructure and
YANG has become the accepted way to generate schema for NETCONF, these
we attempt to adapt the protocol and the modeling language,
respectively.  At some point in the near future, it will likely be the
case that XML gives way to JSON<xref target="RFC7159"/>.  YANG can be used for
either, and so it seems even more appropriate to make good use of it.
This work makes use of XML because of the breadth of toolsets
available, and not for any love of angle brackets.  That is subject to
change.</t>

<t>The descriptions specified in MUD files should be based on relatively
ubiquitous network capabilities.  Access lists are such an example,
and QoS policies follow closely behind.  For security purposes, these
policies must only apply to the device that is connecting, and should
not modify other parts of a network element’s configuration.  The key
scaling properties here are as follows:</t>

<t><list style="symbols">
  <t>A manufacturer should only have to maintain and distributer one file
per device model.</t>
  <t>A network management system need not retrieve that same file when
the same model appears in multiple places in its network.</t>
  <t>Updates should occur at periods specified by the manufacturer to
manage load.</t>
</list></t>

</section>
<section anchor="instantiating-policy" title="Instantiating Policy">
<t>The network management system receiving the MUD file must convert it
into an access list that a network element understands, and apply it
to an appropriate interface, limiting its applicability only to the
device in question.  In some cases, the policies will be abstract.
For example, “local” would be translated to the set of networks that
are within the same administrative domain.  It is the network
management system’s responsibility to see that the configuration is
removed when the device detaches, and that the configuration is
consistent with other policies that might apply to that device.
Importantly, network management systems should always defer to the
network administrator’s wishes.  As such, a conflicting policy should
not be deployed, but rather logged.</t>

<t>Human interaction may be required in some cases.  In the home, one
could imagine description simply being instantiated, whereas in the
enterprise, someone may need to review the description before it is
applied.</t>

<t>It is distinctly possible that a highly advanced enterprise would
ignore any manufacturer recommendations altogether but still use the
URI received from devices as a classifier.</t>

</section>
<section anchor="when-configuration-cant-change" title="When Configuration Can’t Change">
<t>In some environments it may not be possible for policy reasons to make
changes to network elements to instantiate usage descriptions as a
means of enforcement.  These very same descriptions may be used as a
means to audit activity of a device to determine whether or not it is
acting in accordance with the the manufacturer’s intent.</t>

</section>
</section>
<section anchor="related-work" title="Related Work">

<section anchor="relationship-to-anima" title="Relationship to ANIMA">
<t><xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> specifies a means by which a
device is configured with appropriate credentials for a given
network.  This work specifies a means to configure the network rather
than the device.  In fact, one key assumption of MUD is that it will be
extremely painful to make any end system changes.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>The three mentioned means for a device to emit a MUD URI each have
their own security properties, and will be discussed in separate
drafts.  A risk they share in common, however, is that the URI could
point to to a site that contains malware.  To avoid such problems,
several countermeasures are suggested:</t>

<t><list style="symbols">
  <t>All XML should be well formed and validated against appropriate
schema.</t>
  <t>Only XML whose capability name spaces are known should be processed
at all.</t>
  <t>Any names within the XML (such as access-list or ACE names) should
be replaced with local instances, so as to avoid overwriting
existing configuration.</t>
  <t>Controllers are encouraged to validate the reputation of the
authority of the web site.</t>
</list></t>

<t>By emitting a URI the device may identify itself to an interloper. As
it happens, most devices can be relatively easily fingerprinted based
on their communications patterns.  However, if this is of concern,
devices should emit the URI to network controllers over secure
channels.</t>

<t>Use of certain operations, such as SameManufacturer scale less well
than others.  Frequent connects and disconnects could cause
configuration storms.  To address this risk, as the number of changes
increase, modifications to devices other than the one connecting
should decrease or simply be scheduled.  In as much as this is an
attack, it can also be mitigated through device authorization
mechanisms such as 802.1X.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>The IANA is requested to enjoy a coffee or tea, as there is nothing in
this document that otherwise requires their attention.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>The author thanks Bernie Volz, Eric Vyncke, and Cullen Jennings for
their helpful suggestions.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor='RFC1984' target='http://www.rfc-editor.org/info/rfc1984'>
<front>
<title>IAB and IESG Statement on Cryptographic Technology and the Internet</title>
<author><organization>IAB</organization></author>
<author initials='IESG' surname='' fullname='IESG'><organization /></author>
<date year='1996' month='August' />
<abstract><t>The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t></abstract>
</front>
<seriesInfo name='BCP' value='200'/>
<seriesInfo name='RFC' value='1984'/>
<seriesInfo name='DOI' value='10.17487/RFC1984'/>
</reference>



<reference  anchor='RFC7452' target='http://www.rfc-editor.org/info/rfc7452'>
<front>
<title>Architectural Considerations in Smart Object Networking</title>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='J.' surname='Arkko' fullname='J. Arkko'><organization /></author>
<author initials='D.' surname='Thaler' fullname='D. Thaler'><organization /></author>
<author initials='D.' surname='McPherson' fullname='D. McPherson'><organization /></author>
<date year='2015' month='March' />
<abstract><t>The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols.  Many of these devices, often called "smart                    objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be                      connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.</t><t>This document offers guidance to engineers designing Internet- connected smart objects.</t></abstract>
</front>
<seriesInfo name='RFC' value='7452'/>
<seriesInfo name='DOI' value='10.17487/RFC7452'/>
</reference>



<reference  anchor='RFC7488' target='http://www.rfc-editor.org/info/rfc7488'>
<front>
<title>Port Control Protocol (PCP) Server Selection</title>
<author initials='M.' surname='Boucadair' fullname='M. Boucadair'><organization /></author>
<author initials='R.' surname='Penno' fullname='R. Penno'><organization /></author>
<author initials='D.' surname='Wing' fullname='D. Wing'><organization /></author>
<author initials='P.' surname='Patil' fullname='P. Patil'><organization /></author>
<author initials='T.' surname='Reddy' fullname='T. Reddy'><organization /></author>
<date year='2015' month='March' />
<abstract><t>This document specifies the behavior to be followed by a Port Control Protocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured.</t><t>This document updates RFC 6887.</t></abstract>
</front>
<seriesInfo name='RFC' value='7488'/>
<seriesInfo name='DOI' value='10.17487/RFC7488'/>
</reference>


<reference anchor="FW95" >
  <front>
    <title>Building Internet Firewalls</title>
    <author initials="D.B." surname="Chapman" fullname="D. Brent Chapman">
      <organization></organization>
    </author>
    <author initials="E." surname="Zwicky" fullname="Elizabeth Zwicky">
      <organization></organization>
    </author>
    <date year="1995" month="January"/>
  </front>
</reference>




<reference  anchor='RFC2131' target='http://www.rfc-editor.org/info/rfc2131'>
<front>
<title>Dynamic Host Configuration Protocol</title>
<author initials='R.' surname='Droms' fullname='R. Droms'><organization /></author>
<date year='1997' month='March' />
<abstract><t>The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network.  DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2131'/>
<seriesInfo name='DOI' value='10.17487/RFC2131'/>
</reference>


<reference anchor="IEEE8021AB" >
  <front>
    <title>Link Layer Discovery Protocol</title>
    <author >
      <organization>Institute for Electrical and Electronics Engineers</organization>
    </author>
    <date year="2005"/>
  </front>
</reference>
<reference anchor="IEEE8021X" >
  <front>
    <title>Port Based Network Access Control</title>
    <author >
      <organization>Institute for Electrical and Electronics Engineers</organization>
    </author>
    <date year="1998"/>
  </front>
</reference>
<reference anchor="IEEE8021AR" >
  <front>
    <title>Secure Device Identity</title>
    <author >
      <organization>Institute for Electrical and Electronics Engineers</organization>
    </author>
    <date year="1998"/>
  </front>
</reference>




<reference  anchor='RFC3986' target='http://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>



<reference  anchor='RFC6020' target='http://www.rfc-editor.org/info/rfc6020'>
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'><organization /></author>
<date year='2010' month='October' />
<abstract><t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6020'/>
<seriesInfo name='DOI' value='10.17487/RFC6020'/>
</reference>



<reference  anchor='RFC7159' target='http://www.rfc-editor.org/info/rfc7159'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organization /></author>
<date year='2014' month='March' />
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='RFC' value='7159'/>
<seriesInfo name='DOI' value='10.17487/RFC7159'/>
</reference>



<reference anchor='I-D.ietf-anima-bootstrapping-keyinfra'>
<front>
<title>Bootstrapping Key Infrastructures</title>

<author initials='M' surname='Pritikin' fullname='Max Pritikin'>
    <organization />
</author>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='M' surname='Behringer' fullname='Michael Behringer'>
    <organization />
</author>

<author initials='S' surname='Bjarnason' fullname='Steinthor Bjarnason'>
    <organization />
</author>

<date month='October' day='19' year='2015' />

<abstract><t>This document specifies automated bootstrapping of an key infrastructure using vendor installed IEEE 802.1AR manufacturing installed certificates, in combination with a vendor based service on the Internet.  Before being authenticated, a new device has only link-local connectivity, and does not require a routable address. When a vendor provides an Internet based service, devices can be forced to join only specific domains but in limited/disconnected networks or legacy environments we describe a variety of options that allow bootstrapping to proceed.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-anima-bootstrapping-keyinfra-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-01.txt' />
</reference>




    </references>



  </back>
</rfc>