One document matched: draft-lear-ietf-dhc-mud-option-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-ietf-dhc-mud-option-00" category="std">
<front>
<title abbrev="MUD">Manufacturer Usage Description URI and DHCP Option</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>
<author initials="R." surname="Droms" fullname="Ralph Droms">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>55 Cambridge Parkway</street>
<city>Cambridge</city>
<code>1057</code>
<country>United States</country>
</postal>
<phone>+1 617 621 1904</phone>
<email>rdroms@cisco.com</email>
</address>
</author>
<date year="2016" month="January" day="21"/>
<area>Internet</area>
<workgroup>DHC</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>The ability of smart objects to protect themselves will vary. A good
source of information about a device’s capabilities is the
manufacturer. This document specifies a means by which devices can
communicate a URI that the network can use to retrieve simple
network-relevant information.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>A Manufacturer Usage Description (mud) refers to a YANG-based
XML file that is intended for use by a management station or
controller, but is very close to directly parsable by a
NETCONF-enabled device.<xref target="RFC6020"/>,<xref target="RFC6241"/>. The basic concept is
that a device will emit a uniform resource identifier (URI)
<xref target="RFC3986"/> that is associated with that file, and the network may do
various things with that knowledge, including apply access lists or
quality of service policies. A complete overview of MUD can be
found in draft-lear-mud-overview.
XXX add informative reference after -00 posting.</t>
<t>In this memo a single means is defined to emit the MUD URI, which is a
DHCP option<xref target="RFC2131"/>,<xref target="RFC3315"/> that the DHCP client uses to inform
the DHCP server. The DHCP server may take further actions, such as
retrieve the URI or otherwise pass it along to network management
system or controller.</t>
<t>The format of the mud URI is specified in draft-lear-netmod-mud.
XXX add normative reference after -00s are posted.</t>
<t>An example would be as follows:</t>
<figure title="URI example" anchor="ex1"><artwork><![CDATA[
https://www.vendor.example.com/.well-known/mud/v1/BudsLight/m2000
]]></artwork></figure>
<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"/>.</t>
</section>
<section anchor="dhcpopt" title="The MUD URI DHCP Option">
<t>The IPv4 MUD URI client option has the following format:</t>
<figure><artwork><![CDATA[
+------+-----+------------------------------
| code | len | MUD URI
+------+-----+------------------------------
]]></artwork></figure>
<t>Code OPTION_MUD_URI_V4 (TBD) is assigned by IANA. len is a single
octet that indicates the length of the URI in octets. MUD URI is a
URI. The length of a MUD URI does not exceed 255 bytes.</t>
<t>The IPv6 MUD URI client option has the following format:</t>
<figure><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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MUD_URI_V6 | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUD URI |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>OPTION_MUD_URI_V6 (TBD; assigned by IANA).</t>
<t>option-length contains the length of the URI in octets. The length
MUST NOT exceed 255 octets.</t>
<t>The MUD URI is a URI.</t>
</section>
<section anchor="how-the-option-is-processed" title="How the Option Is Processed">
<t>The intent of this option is to provide both a new classifier to the
network as well as some recommended configuration to the routers that
implement policy. However, it is entirely the purview of the network
system as managed by the network administrator to decide what to do
with this information. The key function of this option is simply to
identify the type of device to the network in a structured way such
that the policy can be easily found with existing toolsets.</t>
<section anchor="client-behavior" title="Client Behavior">
<t>A client MAY emit a DHCP v4 or DHCPv6 option or both. This is a
singleton option, as specified in <xref target="RFC7227"/>. Because clients are
intended to have at most one MUD URI associated with them, they may
emit at most one MUD URI option via DHCPv4 and one MUD URI option via
DHCPv6. In the case where both v4 and v6 DHCP options are emitted,
the same URI MUST be used.</t>
<t>Clients SHOULD log or otherwise report improper acknowledgments from
servers, but they MUST NOT modify their MUD URI configuration based on
a server’s response. The server’s response is only an acknowledgment
that the server has processed the option, and promises no specific
network behavior to the client. In particular, it may not be possible
for the server to retrieve the file associated with the MUD URI,
or the local network administration may not wish to use the usage
description. Neither of these situations should be considered in any
way exceptional.</t>
</section>
<section anchor="server-behavior" title="Server Behavior">
<t>DHCP servers MAY ignore or process the option. For purposes of
debugging, if a server
successfully parses the option and the URI, it MUST return the option
with the same URI as an acknowledgment. Even in this circumstance, no
specific network behavior is guaranteed. When a server consumes this
option, it will either forward the URI and relevant client information
to a network management system (such as the giaddr), or it will
retrieve the usage description by resolving the URI.</t>
<t>DHCP servers may implement MUD functionality themselves or they may
pass along appropriate information to a network management system or
controller. The server that does process the MUD URI MUST adhere to
the process specified in <xref target="RFC2818"/> and <xref target="RFC5280"/> to validate the
TLS certificate of the web server hosting the MUD file. Those servers
will retrieve the file, process it, create and install the necessary
configuration on the relevant gateway. Servers SHOULD monitor the
gateway for state changes on a given interface. DHCP servers that are
NOT providing MUD functionality themselves will forward to the network
management system(s) that are any RELEASEs they receive for any
DHCPREQUESTs that they previously processed, so that the network
management systems may then retire any lingering state.</t>
</section>
<section anchor="relay-requirements" title="Relay Requirements">
<t>There are no additional requirements for relays.</t>
</section>
</section>
<section anchor="seccon" title="Security Considerations">
<t>Emission of a MUD URI will provide an interloper with knowledge about
a device. However, an interloper may gain most of this same
information through classical fingerprinting techniques. That is,
device behavior patterns are generally easy to determine. In
environments where this would be a concern, use of devices with this
option is NOT RECOMMENDED. Instead other more secure means should be
considered.</t>
<t>It may be possible for a man in the middle to modify the DHCP request
so that a different URI is queried. To address this threat,
controllers SHOULD NOT query a site based on the authority component
of the MUD URI when it has noted that the authority section has
changed. For example, if the MAC address is the same and the
authority portion of the URI is different from the last query,
something probably has gone wrong. Such a situation SHOULD be logged
and reported. As of this writing, one of the authors is aware of
ongoing work to address DHCP message integrity
protection<xref target="I-D.ietf-dhc-sedhcpv6"/>.</t>
<t>A malicious device could emit a URI to malware. Servers or other
network management systems should only process valid MUD URIs, and
MUST apply strict validation rules to the content that is returned,
making use of the Accept: header, and rejecting any content that does
not have an acceptable type. In addition, servers MAY ignore URIs to
unknown manufacturers. In order to prevent modification of content in
flight, all communication to web sites MUST make use of TLS, and all
certificates MUST be validated.</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>IANA is requested to allocated the DHCPv4 and v6 options as specified
in <xref target="dhcpopt"/>.</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The authors thank Bernie Volz for his helpful suggestions.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</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='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='RFC3315' target='http://www.rfc-editor.org/info/rfc3315'>
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author initials='R.' surname='Droms' fullname='R. Droms' role='editor'><organization /></author>
<author initials='J.' surname='Bound' fullname='J. Bound'><organization /></author>
<author initials='B.' surname='Volz' fullname='B. Volz'><organization /></author>
<author initials='T.' surname='Lemon' fullname='T. Lemon'><organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<author initials='M.' surname='Carney' fullname='M. Carney'><organization /></author>
<date year='2003' month='July' />
</front>
<seriesInfo name='RFC' value='3315'/>
<seriesInfo name='DOI' value='10.17487/RFC3315'/>
</reference>
<reference anchor='RFC5280' target='http://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>
<date year='2008' month='May' />
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>
</references>
<references title='Informative References'>
<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='RFC6241' target='http://www.rfc-editor.org/info/rfc6241'>
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials='R.' surname='Enns' fullname='R. Enns' role='editor'><organization /></author>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'><organization /></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder' role='editor'><organization /></author>
<author initials='A.' surname='Bierman' fullname='A. Bierman' role='editor'><organization /></author>
<date year='2011' month='June' />
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6241'/>
<seriesInfo name='DOI' value='10.17487/RFC6241'/>
</reference>
<reference anchor='RFC7227' target='http://www.rfc-editor.org/info/rfc7227'>
<front>
<title>Guidelines for Creating New DHCPv6 Options</title>
<author initials='D.' surname='Hankins' fullname='D. Hankins'><organization /></author>
<author initials='T.' surname='Mrugalski' fullname='T. Mrugalski'><organization /></author>
<author initials='M.' surname='Siodelski' fullname='M. Siodelski'><organization /></author>
<author initials='S.' surname='Jiang' fullname='S. Jiang'><organization /></author>
<author initials='S.' surname='Krishnan' fullname='S. Krishnan'><organization /></author>
<date year='2014' month='May' />
<abstract><t>This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.</t></abstract>
</front>
<seriesInfo name='BCP' value='187'/>
<seriesInfo name='RFC' value='7227'/>
<seriesInfo name='DOI' value='10.17487/RFC7227'/>
</reference>
<reference anchor='I-D.ietf-dhc-sedhcpv6'>
<front>
<title>Secure DHCPv6</title>
<author initials='S' surname='Jiang' fullname='Sheng Jiang'>
<organization />
</author>
<author initials='L' surname='Li' fullname='Lishan Li'>
<organization />
</author>
<author initials='Y' surname='Cui' fullname='Yong Cui'>
<organization />
</author>
<author initials='T' surname='Jinmei' fullname='Tatuya Jinmei'>
<organization />
</author>
<author initials='T' surname='Lemon' fullname='Ted Lemon'>
<organization />
</author>
<author initials='D' surname='Zhang' fullname='Dacheng Zhang'>
<organization />
</author>
<date month='December' day='10' year='2015' />
<abstract><t>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not being secured, DHCPv6 is vulnerable to various attacks. This document analyzes the security issues of DHCPv6 and specifies a secure DHCPv6 mechanism for the authentication and encryption between DHCPv6 client and DHCPv6 server.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dhc-sedhcpv6-10' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dhc-sedhcpv6-10.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:25:39 |