LWIG Working Group C. Bormann, Ed.
Internet-Draft Universitaet Bremen TZI
Intended status: Informational July 4, 2011
Expires: January 5, 2012
Guidance for Light-Weight Implementations of the Internet Protocol Suite
draft-bormann-lwig-guidance-00
Abstract
Implementation of Internet protocols on small devices benefits from
light-weight implementation techniques, which are often not
documented in an accessible way.
This document provides a first outline of and some initial content
for the Light-Weight Implementation Guidance document planned by the
IETF working group LWIG.
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-
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 January 5, 2012.
Copyright Notice
Copyright (c) 2011 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
Bormann Expires January 5, 2012 [Page 1]
Internet-Draft Guidance for Light-Weight Implementations July 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Call for contributions . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Drawing the Landscape . . . . . . . . . . . . . . . . . . . . 6
2.1. Classes of Devices . . . . . . . . . . . . . . . . . . . . 6
2.2. Design Objectives . . . . . . . . . . . . . . . . . . . . 6
2.3. Implementation Styles . . . . . . . . . . . . . . . . . . 7
2.4. Roles of nodes . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Overview over the document . . . . . . . . . . . . . . . . 8
3. Data Plane Protocols . . . . . . . . . . . . . . . . . . . . . 9
3.1. Link Adaptation Layer . . . . . . . . . . . . . . . . . . 9
3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration . 9
3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 10
3.4. Application Layer . . . . . . . . . . . . . . . . . . . . 10
3.4.1. General considerations about Application
Programming Interfaces (APIs) . . . . . . . . . . . . 10
3.4.2. Constrained Application Protocol (CoAP) . . . . . . . 11
3.4.3. (Other Application Protocols...) . . . . . . . . . . . 14
4. Control Plane Protocols . . . . . . . . . . . . . . . . . . . 15
4.1. Link Layer Support . . . . . . . . . . . . . . . . . . . . 15
4.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Host Configuration and Lookup Services . . . . . . . . . . 15
5. Security protocols . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Cryptography for Constrained Devices . . . . . . . . . . . 16
5.2. Transport Layer Security . . . . . . . . . . . . . . . . . 16
5.3. Network Layer Security . . . . . . . . . . . . . . . . . . 16
5.4. Network Access Control . . . . . . . . . . . . . . . . . . 16
5.4.1. PANA . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Wire-Visible Constraints . . . . . . . . . . . . . . . . . . . 22
7. Wire-Invisible Constraints . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
Bormann Expires January 5, 2012 [Page 2]
Internet-Draft Guidance for Light-Weight Implementations July 2011
1. Introduction
Today's Internet is experienced by users as a set of applications,
such as email, instant messaging, and social networks. There are
substantial differences in performance between the various end
devices with these applications, but in general end devices
participating in the Internet today are considered to have relatively
high performance.
More and more communications technology is being embedded into our
environment. Different types of devices in our buildings, vehicles,
equipment and other objects have a need to communicate. It is
expected that most of these devices will employ the Internet Protocol
suite. The term "Internet of Things" denotes a trend where a large
number of devices directly benefit from communication services that
use Internet protocols. Many of these devices are not primarily
computing devices operated by humans, but exist as components in
buildings, vehicles, and the environment. There will be a lot of
variation in the computing power, available memory, communications
bandwidth, and other capabilities between different types of these
devices. With many low-cost, low-power and otherwise constrained
devices, it is not always easy to embed all the necessary features.
Historically, there has been a trend to invent special "light-weight"
_protocols_ to connect the most constrained devices. However, much
of this development can simply run on existing Internet protocols,
provided some attention is given to achieving light-weight
_implementations_. In some cases the new, constrained environments
can indeed benefit from protocol optimizations and additional
protocols that help optimize Internet communications and lower the
computational requirements. Examples of IETF standardization efforts
targeted for these environments include the "IPv6 over Low power WPAN
(6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and
"Constrained RESTful Environments (CoRE)" working groups. More
generally, however, techniques are required to implement both these
optimized protocols as well as the other protocols of the Internet
protocol suite in a way that makes them applicable to a wider range
of devices.
1.1. Objectives
The present document, a product of the IETF Light-Weight
Implementation Guidance (LWIG) Working Group, focuses on helping the
implementers of the smallest devices. The goal is to be able to
build minimal yet interoperable IP-capable devices for the most
constrained environments.
Building a small implementation does not have to be hard. Many small
Bormann Expires January 5, 2012 [Page 3]
Internet-Draft Guidance for Light-Weight Implementations July 2011
devices use stripped down versions of general purpose operating
systems and their TCP/IP stacks. However, there are implementations
that go even further in minimization and can exist in as few as a
couple of kilobytes of code, as on some devices this level of
optimization is necessary. Technical and cost considerations may
limit the computing power, battery capacity, available memory, or
communications bandwidth that can be provided. To overcome these
limitations the implementers have to employ the right hardware and
software mechanisms. For instance, certain types of memory
management or even fixed memory allocation may be required. It is
also useful to understand what is necessary from the point of view of
the communications protocols and the application employing them. For
instance, a device that only acts as a client or only requires one
connection can simplify its TCP implementation considerably.
The purpose of this document is to collect experiences from
implementers of IP stacks in constrained devices. The focus is on
techniques that have been used in actual implementations and do not
impact interoperability with other devices. The techniques shall
also not affect conformance to the relevant specifications. We
describe implementation techniques for reducing complexity, memory
footprint, or power usage.
The topics for this working group will be chosen from Internet
protocols that are in wide use today, such as IPv4 and IPv6; UDP and
TCP; ICMPv4/v6, MLD/IGMP and ND; DNS and DHCPv4/v6; TLS, DTLS and
IPsec; as well as from the optimized protocols that result from the
work of the 6LoWPAN, RPL, and CoRE working groups. This document
will be helpful for the implementers of new devices or for the
implementers of new general-purpose small IP stacks. It is also
expected that the document will increase our knowledge of what
existing small implementations do, and will help in the further
optimization of the existing implementations. In areas where the
considerations for small implementations have already been documented
in an accessible way, we will refer to those documents instead of
duplicating the material here.
Generic hardware design advice and software implementation techniques
are outside the scope of this document. Protocol implementation
experience, however, is the focus. There is no intention to describe
any new protocols or protocol behavior modifications beyond what is
already allowed by existing RFCs, because it is important to ensure
that different types of devices can work together. For example,
implementation techniques relating to security mechanisms are within
scope, but mere removal of security functionality from a protocol is
rarely an acceptable approach.
Bormann Expires January 5, 2012 [Page 4]
Internet-Draft Guidance for Light-Weight Implementations July 2011
1.2. Call for contributions
The present draft of the document is an outline that will grow with
the contributions received, which are expressly invited. As this
document focuses on experience from existing implementations, this
requires implementer input; in particular, participation is required
from the implementers of existing small IP stacks. "Small" here is
intended to be applicable approximately to what is described in
Section 2 -- where it is more important that the technique described
is grounded in actual experience than that the experience is actually
from a (very) constrained system.
Only a few subsections are fleshed out in this initial draft;
additional subsections will quickly be integrated from additional
contributors.
1.3. Terminology
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. As this is
an informational document, the [RFC2119] keywords will only be used
to underscore requirements where similar key words apply in the
context of the specifications the light-weight implementation of
which is being discussed.
The term "byte" is used in its now customary sense as a synonym for
"octet".
Bormann Expires January 5, 2012 [Page 5]
Internet-Draft Guidance for Light-Weight Implementations July 2011
2. Drawing the Landscape
There is not a single kind of constrained, Internet-connected device.
To the contrary, the trend is towards much more functional variety of
such devices than is customary today in the Internet. This section
introduces a number of terms that will be used to locate some of the
technique described in the following sections within certain areas of
applications.
2.1. Classes of Devices
Despite the overwhelming variety of Internet-connected devices that
can be envisioned, it may, be worthwhile to have some succinct
terminology for different classes of constrained devices. In this
document, the following class designations may be used as rough
indications of device capabilities:
+---------+-----------------------+-------------------------+
| Name | data size (e.g., RAM) | code size (e.g., Flash) |
+---------+-----------------------+-------------------------+
| Class 1 | ~ 10 KiB | ~ 100 KiB |
| | | |
| Class 2 | ~ 50 KiB | ~ 250 KiB |
+---------+-----------------------+-------------------------+
As of the writing of this document, these characteristics correspond
to distinguishable sets of commercially available chips and design
cores for constrained devices. While it is expected that the
boundaries of these classes will move over time, Moore's law tends to
be less effective in the embedded space than in personal computing
devices: Gains made available by increases in transistor count and
density are more likely to be invested in reductions of cost and
power requirements than into continual increases in computing power.
2.2. Design Objectives
o Consideration for design or implementation approaches for
implementation of IP stacks for constrained devices will be
impacted by the RAM usage for these designs. Here the
consideration is what is the best approach to minimize overhead.
o In addition, the impact on throughput in terms of IP protocol
implementation must take into consideration the methods that
minimize overhead but balance performance requirements for the
light-weight constrained devices.
o Protocol implementation must consider its impact on CPU
utilization. Here guidance will be provided on how to minimize
Bormann Expires January 5, 2012 [Page 6]
Internet-Draft Guidance for Light-Weight Implementations July 2011
tasks that require additional CPU execution time.
How does the implementation of the IP stack effect the application
both in terms of performance but also of those same attributes and
requirements (RAM, CPU usage, etc.) that we are examining for the IP
protocol stack?
From performing a synthesis of implementation experiences we will be
able to understand and document the benefits and consequences of
varied approaches. Scaling code and selected approaches in terms of
scaling from, say, a 8-bit micro to a 16-bit micro. Such scaling for
the approach will aid in the development of single code base when
possible.
2.3. Implementation Styles
Compared to personal computing devices, constrained devices tend to
make use of quite different classes of operating systems, if that
term is even applicable.
...
o Single-threaded/giant mainloop
o Event-driven vs. threaded/blocking
* The usual multi-threaded model blocks a thread on primitives
such as connect(), accept() or read() until an external event
takes place. This model is often thought to consume too much
RAM and CPU processing.
* The event driven model uses a non-blocking approach: E.g., when
an application interface sends a message, the routine would
return immediately (before the message is sent). A call-back
facility notifies the application or calling code when the
desired processing is completed. Here the benefit is that no
thread context needs to be preserved for long periods of time.
o Single/multiple processing elements
o E.g., separate radio/network processor
Introduce these briefly: Some techniques may be applicable only to
some of these styles!
Bormann Expires January 5, 2012 [Page 7]
Internet-Draft Guidance for Light-Weight Implementations July 2011
2.4. Roles of nodes
Constrained nodes are by necessity more specialized than general
purpose computing devices; they may have a quite specific role. Some
implementation techniques may also
o Constrained nodes
o Nodes talking to constrained nodes
o Gateways/Proxies
In all these cases, constrained nodes that are "sleepy" pose
additional considerations. (Explain sleepy...) E.g., a node talking
to a sleepy node may need to make special arrangements; this is even
more true where a gateway or proxy interfaces the general Internet
o Bandwidth/latency considerations
2.5. Overview over the document
The following sections will first go through a number of specific
protocol layers, starting from layers of the data plane (link
adaptation, network, transport, application), followed by control
plane protocol layers (link layer support, network layer and routing,
host configuration and lookup services). We then look at security
protocols (general cryptography considerations, transport layer
security, network layer security, network access control). Finally,
we discuss some specific, cross-layer concerns, some "wire-visible",
some of concern within a specific implementation. Clearly, many
topics could be discussed in more than one place in this structure.
The objective is not to have something for each of the potential
topics, but to document the most valuable experience that may be
available.
Bormann Expires January 5, 2012 [Page 8]
Internet-Draft Guidance for Light-Weight Implementations July 2011
3. Data Plane Protocols
3.1. Link Adaptation Layer
6LoWPAN
3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration
Author: Carsten Bormann
6LoWPAN [RFC4944] is an adaptation layer that maps IPv6 with its
minimum MTU of 1280 bytes to IEEE 802.15.4, which has a physical
layer MTU of only 127 bytes (some of which are taken by MAC layer and
adaptation layer headers). Therefore, the adaptation layer provides
a fragmentation and reassembly scheme that can fragment a single IPv6
packet of up to 1280 bytes into multiple adaptation layer fragments
of up to 127 bytes each (including MAC and adaptation layer
overhead).
In a route-over configuration, implementing this adaptation layer
fragmentation scheme straightforwardly means that reassembly and then
fragmentation are performed at each forwarding hop. As fragments
from several packets may be arriving interleaved with each other,
this approach requires buffer space for multiple MTU-size IPv6
packets.
In a mesh-under configuration, adaptation layer fragments can be
forwarded independently of each other. It would be preferable if
something similar were possible for route-over. Complete
independence in forwarding of adaptation layer fragments is not
possible for route-over, however, as the layer-3 addresses needed for
forwarding are in the initial bytes of the IPv6 header, which is
present only in the first fragment of a larger packet.
Instead of performing a full reassembly, implementations may be able
to optimize this process by not keeping a full reassembly buffer, but
just a runt buffer (called "virtual reassembly buffer" in [WEI]) for
each IP packet. This buffer caches only the datagram_tag field (as
usual combined with the sender's link layer address, the
destination's link layer address and the datagram_size field) and the
IPv6 header including the relevant addresses. Initial fragments are
then forwarded independently (after header decompression/compression)
and create a runt reassembly buffer. Non-initial fragments (which
don't require header decompression/compression in 6LoWPAN) are
matched against the runt buffers by datagram_tag etc. and forwarded
if an IPv6 address is available. (This simple scheme may be
complicated a bit if header decompression/compression of the initial
fragment causes an overflow of the physical MTU; in this case some
Bormann Expires January 5, 2012 [Page 9]
Internet-Draft Guidance for Light-Weight Implementations July 2011
overflow data may need to be stored in the runt buffers to be
combined with further fragments or may simply be forwarded as a
separate additional fragment.)
If non-initial fragments arrive out of order before the initial
fragment, a route-over router may want to keep the contents of the
non-initial fragments until the initial fragment is available, which
does need some buffer space. If that is not available, a more
constrained route-over router may simply discard out-of order non-
initial fragments, possibly taking note that there is no point in
forwarding any more fragments with the same combination of 6LoWPAN
datagram_tag field, L2 addresses and datagram_size.
Runt buffers should time out like full reassembly buffers, and may
either keep a map of fragments forwarded or they may simply be
removed upon forwarding the final fragment, assuming that no out-of-
order fragments will follow.
3.1.1.1. Implementation Considerations for Not-So-Constrained Nodes
[RFC4944] makes no explicit mandates about the order in which
fragments should be sent. Because it is heavily favored by the above
implementation techniques, it is highly advisable for all
implementations to always send adaptation layer fragments in natural
order, i.e., starting with the initial fragment, continuing with
increasing datagram_offset.
3.2. Network Layer
IPv4 and IPv6
3.3. Transport Layer
TCP and UDP
3.4. Application Layer
3.4.1. General considerations about Application Programming Interfaces
(APIs)
Author: Carl Williams
Constrained devices are not necessarily in a position to use APIs
that would be considered "standard" for less constrained environments
(e.g., Berkeley sockets or those defined by POSIX).
When an API implements a protocol, this can be based on proxy methods
for remote invocations that underneath rely on the communication
Bormann Expires January 5, 2012 [Page 10]
Internet-Draft Guidance for Light-Weight Implementations July 2011
protocol. One of the roles of the API can be exactly to hide the
detail of the transport protocol.
Changes to the lower layers will be made to implement light-weight
stacks so this impacts that implementation and inter-workings with
the API. Similar considerations such as RAM, CPU utilization and
performance requirements apply to the API and its use of the lower
layer resources (i.e., buffers).
Considerations for the proper approach for a developer to request
services from an application program need to be explored and
documented. Such considerations will allow the progression of a
common consistent networking paradigm without inventing a new way of
programming these devices.
In addition, such considerations will take into account the inter-
working of the API with the protocols. Protocols are more complex to
use as they are less direct and take a lot of serializing, de-
serializing and dispatching type logic.
So the connection of the API and the protocols on a constrained
device becomes even more important to balance the requirements of
RAM, CPU and performance.
_** Here we will proceed to collect and document ... insert
experiences from existing API on constrained devices (TBD) **_
3.4.2. Constrained Application Protocol (CoAP)
Author: Olaf Bergmann
The Constrained Application Protocol [I-D.ietf-core-coap] has been
designed specifically for machine-to-machine communication in
networks with very constrained nodes. Typical application scenarios
therefore include building automation and the Internet of Things.
The major design objectives have been set on small protocol overhead,
robustness against packet loss, and high latency induced by small
bandwidth shares or slow request processing in end nodes. To
leverage integration of constrained nodes with the world-wide
Internet, the protocol design was led by the architectural style that
accounts for the scalability and robustness of the Hypertext Transfer
Protocol [RFC2616].
Lightweight implementations benefit from this design in many
respects: First, the use of Uniform Resource Identifiers (URIs) for
naming resources and the transparent forwarding of their
representations in a server-stateless request/response protocol make
protocol-translation to HTTP a straightforward task. Second, the set
Bormann Expires January 5, 2012 [Page 11]
Internet-Draft Guidance for Light-Weight Implementations July 2011
of protocol elements that are inevitable for the core protocol and
thus must be implemented on every node has been kept very small to
avoid unnecessary accumulation of optional features. Options that --
when present -- are critical for message processing are explicitly
marked as such to force immediate rejection of messages with unknown
critical options. Third, the syntax of protocol data units is easy
to parse and is carefully defined to avoid creation of state in
servers where possible.
Although these features enable lightweight implementations of the
Constrained Application Protocol, there is still a trade-off between
robustness and latency of constrained nodes on one hand and resource
demands (such as battery consumption, dynamic memory needs and static
code-size) on the other. This section gives some guidance on
possible strategies to solve this trade-off for very constrained
nodes (Class 1 in Section 2.1). The main focus is on servers as this
is deemed the predominant case where CoAP applications are faced with
tight resource constraints.
Additional considerations for the implementation of CoAP on tiny
sensors are given in [I-D.arkko-core-sleepy-sensors].
3.4.2.1. Message Layer Processing
For constrained nodes of Class 1 or even Class 2, limiting factors
for (wireless) network communication usually are RAM size and battery
lifetime. Most applications therefore try to avoid dealing with
fragmented packets on the network layer and minimize internal buffer
space for both transmit and receive operations. One of the most
expensive operations hence is the retransmission of messages as it
implies additional energy consumption for the (radio) network
interface and occupied RAM storage for the send buffer.
Where multi-threading is not an option at all because no full-fledged
operating system is present, all operations are triggered by a big
main loop in a send-receive-dispatch cycle. To implement the packet
retransmission, CoAP implementations at least need a separate send
buffer and a decent notion of time, e.g. as a strictly monotonic
increasing tick counter. For platforms that disable clock tick
interrupts in sleep states, the application must take into
consideration the clock deviation that occurs during sleep (or ensure
to remain in idle state until the message has been acknowledged or
the maximum number of retransmissions is reached). Since CoAP allows
up to four retransmissions with a binary exponential back-off it
could take up to 45 seconds until the send operation is complete.
Even in idle state, this means substantial energy consumption for
low-power nodes. Implementers therefore might choose a two-step
strategy: First, do one or two retransmissions and then, in the later
Bormann Expires January 5, 2012 [Page 12]
Internet-Draft Guidance for Light-Weight Implementations July 2011
phases of back-off, go to sleep until the next retransmission is due.
In the meantime, the node could check for new messages including the
acknowledgement for any confirmable message to send.
A similar strategy holds for confirmable messages with separate
responses. This concept entitles CoAP-servers to return an empty
acknowledgement to indicate that a confirmable request has been
understood and is being processed. Once a proper response has been
generate to fulfill the request, it is sent back as a confirmable
message as well. The server implementation in this case must be able
to map retransmissions of the original request to the ongoing
operation and provide the client-selected Token to map between
original request and the separate response.
Depending on the number of requests that can be handled in parallel,
an implementation might create a stub response filled with any option
that has to be copied from the original request to the separate
response, especially the Token option. The drawback of this
technique is that the server must be prepared to receive
retransmissions of the previous (confirmable) request to which a new
acknowledgement must be generated. If memory is an issue, a single
buffer can be used for both tasks: Only the message type and code
must be updated, changing the message id is optional. Once the
resource representation is known, it is added as new payload at the
end of the stub response. Acknowledgements still can be sent as
described before as long as no additional options are required to
describe the payload.
3.4.2.2. Message Parsing
Both CoAP clients and servers must construct outgoing CoAP PDUs and
parse incoming messages. The basic message header consists of only
four octets and thus can be mapped easily to an internal data
structure, considering the actual byte order of the host. Once the
message is accepted for further processing, the set of options
contained in the received message must be decoded to check for
unknown critical options. To avoid multiple passes through the
option list, the option parser might maintain a bit-vector where each
bit represents an option number that is present in the received
request. The delta-encoded option number indicates the number of
left-shift operations to apply on a bit mask to set the corresponding
bit.
In addition, the byte index of every option is added to a sparse list
(e.g. a one-dimensional array) for fast retrieval. This particularly
enables efficient reduced-function handling of options that might
occur more than once such as Uri-Path. In this implementation
strategy, the delta is zero for any subsequent path segment, hence
Bormann Expires January 5, 2012 [Page 13]
Internet-Draft Guidance for Light-Weight Implementations July 2011
the stored byte index for option 9 (Uri-Path) will be overwritten to
hold a pointer to the last occurrence of that option, i.e., only the
last path component actually matters. (Of course, this requires
choosing resource names where the combination of (final Uri-Path
component, final Uri-Query component) is server-wide unique.
Note: Where skipping all but the last path segment is not feasible
for some reason, resource identification could be ensured by some
hash value calculated over the path segments. For each segment
encountered, the stored hash value is updated by the current
option value. This works if a cheap _perfect hashing_ scheme can
be found for the resource names.
Once the option list has been processed at least up to the highest
option number that is supported by the application, any known
critical option and all elective options can be masked out to
determine if any unknown critical option was present. If this is the
case, this information can be used to create a 4.02 response
accordingly. (Note that the remaining options also must be processed
to add further critical options included in the original request.)
3.4.3. (Other Application Protocols...)
Bormann Expires January 5, 2012 [Page 14]
Internet-Draft Guidance for Light-Weight Implementations July 2011
4. Control Plane Protocols
4.1. Link Layer Support
ARP, ND; 6LoWPAN-ND
4.2. Network Layer
ICMP, ICMPv6, IGMP/MLD
4.3. Routing
RPL, AODV/DYMO, OLSRv2
4.4. Host Configuration and Lookup Services
DNS, DHCPv4, DHCPv6
Bormann Expires January 5, 2012 [Page 15]
Internet-Draft Guidance for Light-Weight Implementations July 2011
5. Security protocols
5.1. Cryptography for Constrained Devices
5.2. Transport Layer Security
TLS, DTLS, ciphersuites, certificates
5.3. Network Layer Security
IPsec, IKEv2, transforms
Advice for a minimal implementation of IKEv2 can be found in
[I-D.kivinen-ipsecme-ikev2-minimal].
5.4. Network Access Control
(PANA, EAP, EAP methods)
5.4.1. PANA
Author: Mitsuru Kanda
PANA [RFC5191] provides network access authentication between clients
and access networks. The PANA protocol runs between a PANA Client
(PaC) and a PANA Authentication Agent (PAA). PANA carries UDP
encapsulated EAP [RFC3748] and includes various operational options.
From the point of view of minimal implementation, some of these are
not necessary for constrained devices. This section describes a
minimal PANA implementation for these devices.
The minimization objective for this implementation mainly targets
PaCs because constrained devices often are installed as network
clients, such as sensors, metering devices, etc.
5.4.1.1. PANA AVPs
Each PANA message can carry zero or more AVPs (Attribute-Value Pairs)
within its payload. [RFC5191] specifies nine types of AVPs (AUTH,
EAP-Payload, Integrity-Algorithm, Key-Id, Nonce, PRF-Algorithm,
Result-Code, Session-Lifetime, and Termination-Cause). All of them
are required by all minimal implementations. But there are some
notes.
Integrity-Algorithm AVP and PRF-Algorithm AVP:
All PANA implementations MUST support AUTH_HMAC_SHA1_160 for PANA
message integrity protection and PRF_HMAC_SHA1 for pseudo-random
Bormann Expires January 5, 2012 [Page 16]
Internet-Draft Guidance for Light-Weight Implementations July 2011
function (PRF) specified in [RFC5191]. Both of these are based on
SHA-1, which therefore needs to be implemented in a minimal
implementation.
Nonce AVP:
As the basic hash function is SHA-1, including a nonce of 20 bytes in
the Nonce AVP is appropriate ([RFC5191], section 8.5).
5.4.1.2. PANA Phases
A PANA session consists of four phases -- Authentication and
authorization phase, Access phase, Re-Authentication phase, and
Termination phase.
Authentication and authorization phase:
There are two types of PANA session initiation, PaC-initiated session
and PAA-initiated session. The minimal implementation must support
PaC-initiated session and does not need to support PAA-initiated
session. Because a PaC (a constrained device) which may be a
sleeping device, can not receive an unsolicited PANA-Auth-Request
message from a PAA (PAA-initiated session).
EAP messages can be carried in PANA-Auth-Request and PANA-Auth-Answer
messages. In order to reduce the number of messages, "Piggybacking
EAP" is useful. Both the PaC and PAA should include EAP-Payload AVP
in each of PANA-Auth-Request and PANA-Auth-Answer messages as much as
possible. Figure 1 shows an example "Piggybacking EAP" sequence of
the Authentication and authorization phase.
Bormann Expires January 5, 2012 [Page 17]
Internet-Draft Guidance for Light-Weight Implementations July 2011
PaC PAA Message(sequence number)[AVPs]
---------------------------------------------------------------------
-----> PANA-Client-Initiation(0)
<----- PANA-Auth-Request(x)[PRF-Algorithm,Integrity-Algorithm]
// The 'S' (Start) bit set
-----> PANA-Auth-Answer(x)[PRF-Algorithm, Integrity-Algorithm]
// The 'S' (Start) bit set
<----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload]
-----> PANA-Auth-Answer(x+1)[Nonce, EAP-Payload]
<----- PANA-Auth-Request(x+2)[EAP-Payload]
-----> PANA-Auth-Answer(x+2)[EAP-Payload]
<----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload,
Key-Id, Session-Lifetime, AUTH]
// The 'C' (Complete) bit set
-----> PANA-Auth-Answer(x+3)[Key-Id, AUTH]
// The 'C' (Complete) bit set
Figure 1: Example sequence of the Authentication and authorization
phase for a PaC-initiated session (using "Piggybacking EAP")
Note: It is possible to include an EAP-Payload in both the PANA-Auth-
Request and PANA-Auth-Answer messages with the 'S' bit set. But the
PAA should not include an EAP-Payload in the PANA-Auth-Request
message with the 'S' bit set in order to stay stateless in response
to a PANA-Client-Initiation message.
Access phase:
After Authentication and authorization phase completion, the PaC and
PAA share a PANA Security Association (SA) and move Access phase.
During Access phase, [RFC5191] describes both the PaC and PAA can
send a PANA-Notification-Request message with the 'P' (Ping) bit set
for the peer's PANA session liveness check (a.k.a "PANA ping"). From
the minimal implementation point of view, the PAA should not send a
PANA-Notification-Request message with the 'P' (Ping) bit set to
initiate PANA ping since the PaC may be sleeping. The PaC does not
need to send a PANA-Notification-Request message with the 'P' (Ping)
bit set for PANA ping to the PAA periodically and may omit the PANA
ping feature itself if the PaC can detect the PANA session failure by
other methods, for example, network communication failure. In
conclusion, the PaC does not need to implement the periodic liveness
check feature sending PANA ping but a PaC that is awake should
respond to a incoming PANA-Notification-Request message with the 'P'
(Ping) bit set for PANA ping as possible.
Re-Authentication phase:
Before PANA session lifetime expiration, the PaC and PAA MUST re-
Bormann Expires January 5, 2012 [Page 18]
Internet-Draft Guidance for Light-Weight Implementations July 2011
negotiate to keep the PANA session. This means that the PaC and PAA
enter Re-Authentication phase. Also in the Authentication and
authorization phase, there are two types of re-authentication. The
minimal implementation must support PaC-initiated re-authentication
and does not need to support PAA-initiated re-authentication (again
because the PaC may be a sleeping device). "Piggybacking EAP" is
also useful here and should be used as well. Figure 2 shows an
example "Piggybacking EAP" sequence of the Re-Authentication phase.
PaC PAA Message(sequence number)[AVPs]
---------------------------------------------------------------------
-----> PANA-Notification-Request(q)[AUTH]
// The 'A' (re-Authentication) bit set
<----- PANA-Notification-Answer(q)[AUTH]
// The 'A' (re-Authentication) bit set
<----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH]
-----> PANA-Auth-Answer(p)[EAP-Payload, Nonce, AUTH]
<----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH]
-----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH]
<----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload,
Key-Id, Session-Lifetime, AUTH]
// The 'C' (Complete) bit set
-----> PANA-Auth-Answer(p+2)[Key-Id, AUTH]
// The 'C' (Complete) bit set
Figure 2: Example sequence of the Re-Authentication phase for a PaC-
initiated session (using "Piggybacking EAP")
Termination Phase:
The PaC and PAA should not send a PANA-Termination-Request message
except for explicitly terminating a PANA session within the lifetime.
Both the PaC and PAA know their own PANA session lifetime expiration.
This means the PaC and PAA should not send a PANA-Termination-Request
message when the PANA session lifetime expired because of reducing
message processing cost.
5.4.1.3. PANA session state parameters
All PANA implementations internally keep PANA session state
information for each peer. At least, all minimal implementations
need to keep PANA session state parameters below (in the second
column storage sizes are given in bytes):
Bormann Expires January 5, 2012 [Page 19]
Internet-Draft Guidance for Light-Weight Implementations July 2011
+------------------+----------+-------------------------------------+
| State Parameter | Size | Comment |
+------------------+----------+-------------------------------------+
| PANA Phase | 1 | Used for recording the current PANA |
| Information | | phase. |
| | | |
| PANA Session | 4 | |
| Identifier | | |
| | | |
| PaC's IP address | 6 or 18 | IP Address length (4 bytes for IPv4 |
| and UDP port | | and 16 bytes for IPv6) plus 2 bytes |
| number | | for UDP port number. |
| | | |
| PAA's IP address | 6 or 18 | IP Address length (4 bytes for IPv4 |
| and UDP port | | and 16 bytes for IPv6) plus 2 bytes |
| number | | for UDP port number. |
| | | |
| Outgoing message | 4 | Next outgoing request message |
| sequence number | | sequence number. |
| | | |
| Incoming message | 4 | Next expected incoming request |
| sequence number | | message sequence number. |
| | | |
| A copy of the | variable | Necessary to be able to retransmit |
| last sent | | the message (unless it can be |
| message payload | | reconstructed on the fly). |
| | | |
| Retransmission | 4 | |
| interval | | |
| | | |
| PANA Session | 4 | |
| lifetime | | |
| | | |
| PaC nonce | 20 | Generated by PaC and carried in the |
| | | Nonce AVP. |
| | | |
| PAA nonce | 20 | Generated by PAA and carried in the |
| | | Nonce AVP. |
| | | |
| EAP MSK | 4 | |
| Identifier | | |
| | | |
| EAP MSK value | *) | Generated by EAP method and used |
| | | for generating PANA_AUTH_KEY. |
| | | |
| PANA_AUTH_KEY | 20 | Necessary for PANA message |
| | | protection. |
| | | |
Bormann Expires January 5, 2012 [Page 20]
Internet-Draft Guidance for Light-Weight Implementations July 2011
| PANA PRF | 4 | Used for generating PANA_AUTH_KEY. |
| algorithm number | | |
| | | |
| PANA Integrity | 4 | Necessary for PANA message |
| algorithm number | | protection. |
+------------------+----------+-------------------------------------+
*) (Storage size depends on the key derivation algorithm.)
Note: EAP parameters except for MSK have not been listed here. These
EAP parameters are not used by PANA and depend on what EAP method you
choose.
Bormann Expires January 5, 2012 [Page 21]
Internet-Draft Guidance for Light-Weight Implementations July 2011
6. Wire-Visible Constraints
o Checksum
o MTU
o Fragmentation and reassembly
o Options -- implications of leaving some out
o Simplified TCP optimized for LLNs
o Out-of-order packets
Bormann Expires January 5, 2012 [Page 22]
Internet-Draft Guidance for Light-Weight Implementations July 2011
7. Wire-Invisible Constraints
o Buffering
o Memory management
o Timers
o Energy efficiency
o API
o Data structures
o Table sizes (somewhat wire-visible)
o Improved error handling due to resource overconsumption
Bormann Expires January 5, 2012 [Page 23]
Internet-Draft Guidance for Light-Weight Implementations July 2011
8. IANA Considerations
This document makes no requirements on IANA. (This section to be
removed by RFC editor.)
Bormann Expires January 5, 2012 [Page 24]
Internet-Draft Guidance for Light-Weight Implementations July 2011
9. Security Considerations
(TBD.)
Bormann Expires January 5, 2012 [Page 25]
Internet-Draft Guidance for Light-Weight Implementations July 2011
10. Acknowledgements
Much of the text of the introduction is taken from the charter of the
LWIG working group and the invitation to the IAB workshop on
Interconnecting Smart Objects with the Internet. Thanks to the
numerous contributors.
10.1. Contributors
The RFC guidelines no longer allow RFCs to be published with a large
number of authors. As there are many authors that have contributed
to the sections of this document, their names are listed in the
individual section headings as well as alphabetically listed with
their affiliations below.
+-----------------+-------------------------+
| Name | Affiliation |
+-----------------+-------------------------+
| Carl Williams | MCSR Labs |
| | |
| Carsten Bormann | Universitaet Bremen TZI |
| | |
| Mitsuru Kanda | Toshiba |
| | |
| Olaf Bergmann | Universitaet Bremen TZI |
| | |
| ... | ... |
+-----------------+-------------------------+
Bormann Expires January 5, 2012 [Page 26]
Internet-Draft Guidance for Light-Weight Implementations July 2011
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
11.2. Informative References
[I-D.arkko-core-sleepy-sensors]
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
Novo, "Implementing Tiny COAP Sensors",
draft-arkko-core-sleepy-sensors-00 (work in progress),
July 2011.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-06 (work in progress), May 2011.
[I-D.kivinen-ipsecme-ikev2-minimal]
Kivinen, T., "Minimal IKEv2",
draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress),
February 2011.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
Internet", ISBN 9780470747995, 2009.
Bormann Expires January 5, 2012 [Page 27]
Internet-Draft Guidance for Light-Weight Implementations July 2011
Author's Address
Carsten Bormann (editor)
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Fax: +49-421-218-7000
Email: cabo@tzi.org
Bormann Expires January 5, 2012 [Page 28]