One document matched: draft-nieminen-core-service-discovery-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3610 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3610.xml">
<!ENTITY RFC2464 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2464.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4994 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4994.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC4279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC4627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml">
<!ENTITY I-D.ietf-6lowpan-hc SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6lowpan-hc.xml'>
<!ENTITY I-D.ietf-6lowpan-nd SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6lowpan-nd.xml'>
<!ENTITY I-D.ietf-6lowpan-btle SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6lowpan-btle.xml'>
<!ENTITY I-D.ietf-core-coap SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap'>
<!ENTITY I-D.cheshire-dnsext-multicastdns SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-multicastdns'>
<!ENTITY I-D.ietf-core-link-format SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-link-format'>
<!ENTITY I-D.bormann-core-links-json SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-core-links-json'>
<!ENTITY I-D.badra-netconf-rfc5539bis SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.badra-netconf-rfc5539bis'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-nieminen-core-service-discovery-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="CoAP Autoconfiguration">Constrained Application Autoconfiguration</title>
<author role="editor" fullname="Johanna Nieminen" initials="J.N" surname="Nieminen">
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>Itämerenkatu 11-13</street>
<code>FI-00180 Helsinki</code>
<country>Finland</country>
</postal>
<email>johanna.1.nieminen@nokia.com</email>
</address>
</author>
<author initials='B.P' surname="Patil" fullname='Basavaraj Patil'>
<organization>Nokia</organization>
<address>
<postal>
<street>6021 Connection drive</street>
<city>Irving</city>
<region>TX</region>
<code>75039</code>
<country>USA</country>
</postal>
<email>basavaraj.patil@nokia.com</email>
</address>
</author>
<author initials='T.S' surname="Savolainen" fullname='Teemu Savolainen'>
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>Hermiankatu 12 D</street>
<code>FI-33720 Tampere</code>
<country>Finland</country>
</postal>
<email>teemu.savolainen@nokia.com</email>
</address>
</author>
<author initials='M.I.' surname="Isomaki" fullname='Markus Isomaki'>
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>Keilalahdentie 2-4</street>
<code>FI-02150 Espoo</code>
<country>Finland</country>
</postal>
<email>markus.isomaki@nokia.com</email>
</address>
</author>
<author initials='Z.S.' surname="Shelby" fullname='Zach Shelby'>
<organization abbrev="Sensinode">Sensinode</organization>
<address>
<postal>
<street>Hallituskatu 13-17D</street>
<code>FI-90100 Oulu</code>
<country>Finland</country>
</postal>
<email>zach.shelby@sensinode.com</email>
</address>
</author>
<author initials='C.G.' surname="Gomez" fullname='Carles Gomez'>
<organization abbrev="Universitat Politecnica de Catalunya/i2CAT">Universitat Politecnica de Catalunya/i2CAT</organization>
<address>
<postal>
<street>C/Esteve Terradas, 7</street>
<code>08860</code>
<city>Castelldefels</city>
<country>Spain</country>
</postal>
<email>carlesgo@entel.upc.edu</email>
</address>
</author>
<author initials='M.' surname="Ersue" fullname='Mehmet Ersue'>
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>St.-Martin-Strasse 53</street>
<code>81541</code>
<city>Munich</city>
<country>Germany</country>
</postal>
<email>mehmet.ersue@nsn.com</email>
</address>
</author>
<date year="2012" />
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>CoRE Working Group</workgroup>
<keyword>Bluetooth Low Energy</keyword>
<keyword>6lowpan</keyword>
<keyword>IPv6</keyword>
<keyword>Low power</keyword>
<keyword>Service discovery</keyword>
<keyword>Configuration</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
The number and types of devices that are Internet connected
continues to grow. Sensors, appliances, utility meters, medical
devices etc. are Internet connected for various reasons. Many of
these newer devices are constrained in terms of processing
power, memory, communication capability and, available
power. Devices such as sensors and similar very small devices
often lack a proper user interface and hence configuring even
the most basic parameters for enabling Internet connectivity on
these is extremely difficult. Some of the existing configuration
protocols can help in autoconfiguring various parameters of the
IP stack needed for Internet connectivity. However this is not
sufficient if the devices are using a web service
application. There is a need for additional information such as
service provider name and username/password etc. for
authentication etc. A configuration protocol solution for
resource constrained devices is needed in order to enable the
potential enabled by Internet connectivity. This document
outlines the use cases and requirements for user friendly
configuration of such information on a constrained device, and
specifies a Constrained Application Protocol (CoAP) based
mechanism to meet the requirements.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Communication via IP over radio links such as 802.15.4 (aka Zigbee)
<xref target="RFC4944"/> and Bluetooth Low Energy (BT-LE) <xref
target="I-D.ietf-6lowpan-btle"/> have been specified. This has
enabled very constrained devices such as sensors and various types
of gadgets to become Internet connected. Various types of web
services and applications leverage the information and capability of
such devices. The 6LoWPAN working group in the IETF has defined an
optimized approach to the transmission of IPv6 over low power radio
links. Additionally the Constrained Application Protocol (CoAP)
<xref target="I-D.ietf-core-coap"/> provides a standard way of
implementing web services in a compact manner in environments
wherein the device is constrained in terms of processing power,
memory, communication capability and, energy.
</t>
<t>
Devices such as sensors or other types of appliances may not have a proper user interface (UI). There may
be no display, keyboard, buttons or other ways to interact in order
to configure them. Some form of external configuration capability is
needed for such devices. The IP stack itself can be autoconfigured
via IPv6 stateless autoconfiguration <xref
target="RFC4862"/>. However in addition to the IP stack, the
application running in the constrained device, such as a CoAP client
reporting temperature measurements, needs some amount of
configuration. Typically it needs to know at least a (CoAP) servers
IP address or a Uniform Resource Locator (URL), and often also the
credentials to authenticate with to the server (in the simplest form a
username and password). This type of configuration is usually
impossible to perform without some kind of user intervention. For
instance, the user may need to decide which temperature collection
service provider and account to use.
</t>
<t>
Various existing solutions could be considered. Protocols such as
DHCP <xref target="RFC2131"/> or Multicast DNS <xref
target="I-D.cheshire-dnsext-multicastdns"/> could be used to
discover and deliver configuration information within the local
domain. Often, devices without a UI, such as Wi-Fi access points or
home routers, are configured via a web browser. WiFi APs/routers run
a simple web (HTTP) server with a set of HTML forms which are used
for configuring them via a browser client from a UI capable device
such as computer or tablet. This type of approach to configuration
may be very good for many types of devices. It may however not
be feasible to support such protocols and mechanisms in the most
extremely constrained devices, that have just enough room for a
simple CoAP implementation.
</t>
<t>
This document outlines the use cases and requirements for user
friendly application configuration for constrained devices. It
defines a CoAP based mechanism for automatic configuration discovery
and delivery between a constrained device and another host in its
local network. It also defines a standard format for the basic
application configuration information. Finally, it discusses the
applicability of this solution, describing the requirements of the
environment where it can be securely used.
</t>
<section title="Requirements Language">
<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">RFC 2119</xref>.</t>
</section>
<section title="Terminology">
<t>
<list style="hanging">
<t hangText="Constrained device">
<vspace blankLines="1"/>
The host that obtains configuration infromation for its application from the helper device.
For this purpose it runs a configuration client using CoAP protocol.
</t>
<t hangText="Helper device">
<vspace blankLines="1"/>
The host that provides configuration information for an application on the constrained device.
For this purpose it runs a configuration server using CoAP protocol.
</t>
<t hangText="Configuration client">
<vspace blankLines="1"/>
A CoAP client program searching for, fetching and saving the configuration data on the constrained device.
</t>
<t hangText="Configuration server">
<vspace blankLines="1"/>
A CoAP server program having configuration data and responding to the requests sent by configuration clients.
</t>
</list>
</t>
</section>
</section>
<section title="Use cases and Requirements">
<t>
The main use cases lie with devices that are sold directly to consumers and
are supposed to be able to communicate over the Internet with any service provider
of user's choice. This means that the device
can't be pre-configured to work with a particular service provider when the consumer
purchases it. This is analogous with installing a new IMAP mail client or
buying a generic SIP phone. One of the first things the user needs to do
is to configure them to work with her chosen service provider.
</t>
<t>
The device could be for instance a Bluetooth Low Energy capable wrist unit,
that supports some kind of a standard application protocol agreed by the sport
wrist vendors, so it could talk to any compliant Internet service. The user
would pair it with her smartphone for Internet connectivity. Or, the device
could be a temperature sensor connected to a home access point that supports
some open temperature reporting protocol supported by more than one
service provider. Before these devices can do anything useful, they need
information about the service provider and credentials for the user account.
</t>
<t>
One assumption made is that the device is extremely constrained. It uses
CoAP as the protocol to communicate with its server, but can't afford to
support many additional protocol stacks. For instance, running an HTTP server
with HTML forms just for configuration would be impractical.
</t>
<t>
Another assumption is that the consumer has another device at her use
that does have a user interface and can be used in the configuration
process. For instance, she can have a smartphone or a tablet. In the wrist
unit example this is quite clear, as something like a smartphone is
used as a router for Internet connectivity. In the home network case,
the user would likely have other devices connected to the network
via Wi-Fi, for instance. It is assumed that the configuration can
be either manually entered or delivered in some way to this helper
device. The exact method how tha is done is out of scope of this document, but there
are ways such as Short Message Service (SMS) or Open Mobile Alliance
Device Management to deliver configuration for mobile phones. It would
also be very simple for a service provider to have a website where the
user could save the configuration information on the helper
device via its browser. If the service provider has a dedicated application,
that could be used. Entering the information manually should not be
discluded either. After all, this is how many people manage to
configure their IMAP accounts.
</t>
<t>
The requirements stemming from the use case and assumptions given are:
</t>
<t>
<list style="numbers">
<t>
There must be a way for the configuration client in the constrained device to search and discover whether
any of the hosts in its local network running a configuration server that is able provide the client with suitable
application configuration information.
</t>
<t>
It must be possible to identify the type of application for which the
configuration is valid. (This is to avoid the case where a refridgerator
is accidentally given the configuration meant for a coffee machine.)
Also, it must be possible to identify the exact device/application instance
for which the configuration is valid. (This is to deal with cases
such as that the user has two similar wrist units, but wants them to use
different service providers or user accounts.)
</t>
<t>
It must be possible, after discovery, for the configuration client to fetch
the configuration information from the configuration server.
</t>
<t>
It must be possible for the configuration client in the constrained device and the configuration server in the helper device to
authenticate and authorize each other, and ensure the confidentiality and integrity of the
configuration request and the configuration information transfered between the two.
The configuration server should only provide the configuration information for an authenticated and authorized
client, and the client should only accept configuration information from an authenticated and authorized server.
Authorization may require user interaction.
</t>
</list>
</t>
</section>
<section title="CoAP Based Configuration Discovery and Delivery">
<t>
This Section defines how a constrained device running a configuration client uses CoAP to discover
and fetch configuration for a CoAP based application from a helper device running a configuration server.
</t>
<t>
Discovery is based on CoRE link format <xref target="I-D.ietf-core-link-format"/>.
To perform discovery, the configuration client sends a CoAP GET request either
to the IP address of its default gateway, or to a well known multicast address.
The request is targeted to URI /.well-known/core and the Resource Type parameter
is set with the value "core-aconf" in the query string. Upon success, the
response will contain a link format entry for a suitable configuration
formatted in JSON <xref target="RFC4627"/> as recommended in <xref target="I-D.bormann-core-links-json"/>.
</t>
<t>
Implementations MUST support the discovery request to the default gateway, where
sending the discovery request to a well known multicast address is seen as OPTIONAL.
</t>
<t>
OPEN ISSUE: It could be possible to contact a configuration outside the local network as well,
but that would presumably require some preconfiguration in the client.
</t>
<t>
It is mostly an implementation issue, when exactly the configuration client searches for configuration.
It MUST do it when the constrained device is booted up, and the configuration client starts,
and it determines it has no existing configuration. It SHOULD do it at start-up also when it
does have existing configuration, to check if there is a new version available. It SHOULD also
do it if the actual CoAP application is not able to connect to its server or access its user
account, to make sure configuration is still valid. It is RECOMMENDED that the constrained device
also has some kind of a mechanism for the user to explictly ask for a new configuration to be
fetched. This could be a physical button or some other procedure.
</t>
<t>
OPEN ISSUE: The query should also contain the application type and potentially a
device identifier. How should these be encoded?
</t>
<t>
After the constrained device has received a CoAP response with the link for the configuration
information in the payload, it issues a CoAP GET request to the URI in the link to retrieve
the actual configuration information. A successful response will include the configuration
information in its payload.
</t>
<t>
Basic configuration information contains three pieces: Server IP address, username and
password. Only the server IP address is mandatory. The configuration information is
encoded in JSON as shown in the example below.
</t>
<section title="Example">
<t>
The constrained device searches for an available configuration service and gets a response from
a host having that resource:
</t>
<t>
<figure><artwork><![CDATA[
REQ: GET /.well-known/core?rt=core-aconf
RES: 2.05 "Content"
</config/app>;rt="core-aconf"
]]></artwork></figure>
</t>
<t>
The constrained device then fetches the configuration from the resource it discovered:
</t>
<t>
<figure><artwork><![CDATA[
REQ: GET /config/app
RES: 2.05 "Content"
[{ address : "host",
username : "Foo",
pwd : "§%$"!"
}]
]]></artwork></figure>
</t>
<t>The value for "host" is interpreted as described in Section 6.1 of
<xref target="I-D.ietf-core-coap"/>. If host is provided as an IP-literal
or IPv4address, then the server is located at that IP address. If host
is a registered name, then that name is considered an indirect identifier
and the end-point might use a name resolution service, such as DNS, to
find the address of that host.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>
NOTE: This section still needs more work.
</t>
<t>
The security considerations described throughout <xref target="I-D.ietf-core-coap"/>
apply here as well.
</t>
<t>
User and device specific configuration information is highly sensitive. At least the
following types of attacks are possible against the CoAP based configuration mecahnism,
unless proper protection is in place:
</t>
<t>
<list style="numbers">
<t>
An attacker can reply to configuration client's requests, pretending to be a valid
configuration server, and provide the client with false configuration information. This
can make the actual application client to connect to a wrong service or a wrong user
account. False configuration can also be entered by an active man-in-the-middle with
an access to the communication medium and ability to alter messages between the client
and the server.
</t>
<t>
An attacker can send out configuration requests and obtain configuration information
that it is not supposed to get. With this information, the attacker may be to access
user's account for the service the configuration is valid. Congfiguration can also be
obtained by a passive eavesdropper with access to the communication medium between the
client and the server.
</t>
</list>
</t>
<t>
To protect against these attacks, the configuration client and server need to have a
mechanism to autenticate each other and protect both integrity and confidentiality of
the configuration information.
</t>
<t>
There are three approaches that can provide the necessary security, each having their pros and cons:
</t>
<t>
<list style="numbers">
<t>
CoAP over DTLS between the configuration client and server. This is the default security mechanism for
CoAP, as described in Section 10.1 of <xref target="I-D.ietf-core-coap"/>.
The challenge lies with the provision of keys. It is possible to use either pre-shared key,
raw public keys, or certificates. It can be assumed that a pre-shared key or client's public key can
be set on the server as part of the configuration process. However, setting the pre-shared key or
server's public key on the constrained device is more problematic due to its limitations. It may also
be impractical to have a DTLS stack with X.509 certificate check to be implemented in the types of
devices this configuration scheme is targeting to. With client's public key, the server could
authenticate the client and communications could be secured. This would still leave it unresolved
how the client could authenticate the server. One option is that the constrained device comes
pre-configured with some DTLS key just for the configuration purpose, that the user has to keep
secret.
</t>
<t>
CoAP over DTLS between the configuration client and server, with additional JSON object security
for the configuration information carried as CoAP payload. This differs from the previous option so
that the configuration information would be encrypted and signed separately.
</t>
<t>
Link layer security between the constrained device and the helper device. This can be only
used in environments where the constrained device is actually directly connected to the helper
device over a single link. An example of such environment is an accessory connected to a smartphone
over BT-LE. In that case BT-LE's link layer pairing and security mechanism can be applied
to authenticate the devices and protect integrity and confidentiality of all communications
between them. The initial pairing requires some amount of user interaction, but once it is done,
the two devices can securely communicate with each other. What is then needed is a binding from
the CoAP/UDP/IP level to the link layer security, so that the configuration client and server
know they are communicating over a secure channel. Authentication is based on device identities.
</t>
</list>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
TBD. It may be that some kind of registry to identify the type of applications the configuration
is valid needs to be setup.
</t>
</section>
<!-- <section title="Additional contributors"> -->
<!-- </section> -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Salvatore Loreto, Cullen Jennings, Zach Shelby and Zhen Cao have provided comments and support for this work.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC4627;
&I-D.ietf-core-coap;
&I-D.ietf-core-link-format;
&I-D.bormann-core-links-json;
</references>
<references title="Informative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2131;
&RFC4862;
&RFC4944;
&I-D.cheshire-dnsext-multicastdns;
&I-D.ietf-6lowpan-btle;
</references>
<!-- Change Log
v00 2011-10-20 JNi initial version
v01 2011-10-20 BPa Added Abstract, Problem statemnt, IANA and
Security considerations sections.
v02 2011-10-31 MIs Changed some terminology and rewrote Section "Sensor Configuration".
Submitted as -01 to IETF.
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:04:43 |