Internet DRAFT - draft-nieminen-core-service-discovery
draft-nieminen-core-service-discovery
CoRE Working Group J. Nieminen, Ed.
Internet-Draft B. Patil
Intended status: Standards Track T. Savolainen
Expires: September 13, 2012 M. Isomaki
Nokia
Z. Shelby
Sensinode
C. Gomez
Universitat Politecnica de
Catalunya/i2CAT
M. Ersue
Nokia Siemens Networks
March 12, 2012
Constrained Application Autoconfiguration
draft-nieminen-core-service-discovery-02
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Nieminen, et al. Expires September 13, 2012 [Page 1]
Internet-Draft CoAP Autoconfiguration March 2012
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Nieminen, et al. Expires September 13, 2012 [Page 2]
Internet-Draft CoAP Autoconfiguration March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Use cases and Requirements . . . . . . . . . . . . . . . . . . 5
3. CoAP Based Configuration Discovery and Delivery . . . . . . . 7
3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Nieminen, et al. Expires September 13, 2012 [Page 3]
Internet-Draft CoAP Autoconfiguration March 2012
1. Introduction
Communication via IP over radio links such as 802.15.4 (aka Zigbee)
[RFC4944] and Bluetooth Low Energy (BT-LE) [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) [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.
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 [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.
Various existing solutions could be considered. Protocols such as
DHCP [RFC2131] or Multicast DNS [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.
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
Nieminen, et al. Expires September 13, 2012 [Page 4]
Internet-Draft CoAP Autoconfiguration March 2012
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.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
1.2. Terminology
Constrained device
The host that obtains configuration infromation for its
application from the helper device. For this purpose it runs a
configuration client using CoAP protocol.
Helper device
The host that provides configuration information for an
application on the constrained device. For this purpose it runs a
configuration server using CoAP protocol.
Configuration client
A CoAP client program searching for, fetching and saving the
configuration data on the constrained device.
Configuration server
A CoAP server program having configuration data and responding to
the requests sent by configuration clients.
2. Use cases and Requirements
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.
The device could be for instance a Bluetooth Low Energy capable wrist
Nieminen, et al. Expires September 13, 2012 [Page 5]
Internet-Draft CoAP Autoconfiguration March 2012
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.
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.
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.
The requirements stemming from the use case and assumptions given
are:
1. 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.
2. 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.
Nieminen, et al. Expires September 13, 2012 [Page 6]
Internet-Draft CoAP Autoconfiguration March 2012
(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.)
3. It must be possible, after discovery, for the configuration
client to fetch the configuration information from the
configuration server.
4. 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.
3. CoAP Based Configuration Discovery and Delivery
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.
Discovery is based on CoRE link format [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 [RFC4627] as recommended in [I-D.bormann-core-links-json].
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.
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.
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
Nieminen, et al. Expires September 13, 2012 [Page 7]
Internet-Draft CoAP Autoconfiguration March 2012
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.
OPEN ISSUE: The query should also contain the application type and
potentially a device identifier. How should these be encoded?
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.
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.
3.1. Example
The constrained device searches for an available configuration
service and gets a response from a host having that resource:
REQ: GET /.well-known/core?rt=core-aconf
RES: 2.05 "Content"
</config/app>;rt="core-aconf"
The constrained device then fetches the configuration from the
resource it discovered:
REQ: GET /config/app
RES: 2.05 "Content"
[{ address : "host",
username : "Foo",
pwd : "S.%$"!"
}]
The value for "host" is interpreted as described in Section 6.1 of
[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
Nieminen, et al. Expires September 13, 2012 [Page 8]
Internet-Draft CoAP Autoconfiguration March 2012
identifier and the end-point might use a name resolution service,
such as DNS, to find the address of that host.
4. Security Considerations
NOTE: This section still needs more work.
The security considerations described throughout [I-D.ietf-core-coap]
apply here as well.
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:
1. 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.
2. 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.
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.
There are three approaches that can provide the necessary security,
each having their pros and cons:
1. CoAP over DTLS between the configuration client and server. This
is the default security mechanism for CoAP, as described in
Section 10.1 of [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
Nieminen, et al. Expires September 13, 2012 [Page 9]
Internet-Draft CoAP Autoconfiguration March 2012
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.
2. 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.
3. 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.
5. IANA Considerations
TBD. It may be that some kind of registry to identify the type of
applications the configuration is valid needs to be setup.
6. Acknowledgements
Salvatore Loreto, Cullen Jennings, Zach Shelby and Zhen Cao have
provided comments and support for this work.
7. References
Nieminen, et al. Expires September 13, 2012 [Page 10]
Internet-Draft CoAP Autoconfiguration March 2012
7.1. Normative References
[I-D.bormann-core-links-json]
Bormann, C., "Representing CoRE Link Collections in JSON",
draft-bormann-core-links-json-00 (work in progress),
February 2012.
[I-D.ietf-core-coap]
Frank, B., Bormann, C., Hartke, K., and Z. Shelby,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-08 (work in progress), October 2011.
[I-D.ietf-core-link-format]
Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-11 (work in progress),
January 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
7.2. Informative References
[I-D.cheshire-dnsext-multicastdns]
Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-15 (work in progress),
December 2011.
[I-D.ietf-6lowpan-btle]
Nieminen, J., Patil, B., Savolainen, T., Isomaki, M.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
over Bluetooth Low Energy", draft-ietf-6lowpan-btle-06
(work in progress), March 2012.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
Nieminen, et al. Expires September 13, 2012 [Page 11]
Internet-Draft CoAP Autoconfiguration March 2012
Authors' Addresses
Johanna Nieminen (editor)
Nokia
Itaemerenkatu 11-13
FI-00180 Helsinki
Finland
Email: johanna.1.nieminen@nokia.com
Basavaraj Patil
Nokia
6021 Connection drive
Irving, TX 75039
USA
Email: basavaraj.patil@nokia.com
Teemu Savolainen
Nokia
Hermiankatu 12 D
FI-33720 Tampere
Finland
Email: teemu.savolainen@nokia.com
Markus Isomaki
Nokia
Keilalahdentie 2-4
FI-02150 Espoo
Finland
Email: markus.isomaki@nokia.com
Zach Shelby
Sensinode
Hallituskatu 13-17D
FI-90100 Oulu
Finland
Email: zach.shelby@sensinode.com
Nieminen, et al. Expires September 13, 2012 [Page 12]
Internet-Draft CoAP Autoconfiguration March 2012
Carles Gomez
Universitat Politecnica de Catalunya/i2CAT
C/Esteve Terradas, 7
Castelldefels 08860
Spain
Email: carlesgo@entel.upc.edu
Mehmet Ersue
Nokia Siemens Networks
St.-Martin-Strasse 53
Munich 81541
Germany
Email: mehmet.ersue@nsn.com
Nieminen, et al. Expires September 13, 2012 [Page 13]