idnits 2.17.1 draft-bormann-lwig-guidance-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 940 has weird spacing: '...Counter lowp...' == Line 941 has weird spacing: '...Counter lowp...' == Line 942 has weird spacing: '...Counter ipv6...' -- The document date (January 24, 2012) is 4475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0x02' is mentioned on line 970, but not defined == Missing Reference: '0x01' is mentioned on line 970, but not defined == Missing Reference: '0x00' is mentioned on line 970, but not defined == Missing Reference: 'AVPs' is mentioned on line 1193, but not defined == Missing Reference: 'PRF-Algorithm' is mentioned on line 1141, but not defined == Missing Reference: 'Integrity-Algorithm' is mentioned on line 1141, but not defined == Missing Reference: 'Nonce' is mentioned on line 1200, but not defined == Missing Reference: 'EAP-Payload' is mentioned on line 1202, but not defined == Missing Reference: 'Key-Id' is mentioned on line 1206, but not defined == Missing Reference: 'AUTH' is mentioned on line 1206, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 == Outdated reference: A later version (-01) exists of draft-kivinen-ipsecme-ikev2-minimal-00 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group C. Bormann, Ed. 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational January 24, 2012 5 Expires: July 27, 2012 7 Guidance for Light-Weight Implementations of the Internet Protocol Suite 8 draft-bormann-lwig-guidance-01 10 Abstract 12 Implementation of Internet protocols on small devices benefits from 13 light-weight implementation techniques, which are often not 14 documented in an accessible way. 16 This document provides a first outline of and some initial content 17 for the Light-Weight Implementation Guidance document planned by the 18 IETF working group LWIG. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 27, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Call for contributions . . . . . . . . . . . . . . . . . . 6 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 58 2. Drawing the Landscape . . . . . . . . . . . . . . . . . . . . 7 59 2.1. Classes of Devices . . . . . . . . . . . . . . . . . . . . 7 60 2.2. Design Objectives . . . . . . . . . . . . . . . . . . . . 7 61 2.3. Implementation Styles . . . . . . . . . . . . . . . . . . 8 62 2.4. Roles of nodes . . . . . . . . . . . . . . . . . . . . . . 9 63 2.5. Overview over the document . . . . . . . . . . . . . . . . 9 64 3. Data Plane Protocols . . . . . . . . . . . . . . . . . . . . . 10 65 3.1. Link Adaptation Layer . . . . . . . . . . . . . . . . . . 10 66 3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration . 10 67 3.1.1.1. Implementation Considerations for 68 Not-So-Constrained Nodes . . . . . . . . . . . . . 11 69 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 11 70 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 11 71 3.4. Application Layer . . . . . . . . . . . . . . . . . . . . 12 72 3.4.1. General considerations about Application 73 Programming Interfaces (APIs) . . . . . . . . . . . . 12 74 3.4.2. Constrained Application Protocol (CoAP) . . . . . . . 12 75 3.4.2.1. Message Layer Processing . . . . . . . . . . . . . 13 76 3.4.2.2. Message Parsing . . . . . . . . . . . . . . . . . 14 77 3.4.2.3. Storing Used Message IDs . . . . . . . . . . . . . 15 78 3.4.3. (Other Application Protocols...) . . . . . . . . . . . 18 79 4. Control Plane Protocols . . . . . . . . . . . . . . . . . . . 19 80 4.1. Link Layer Support . . . . . . . . . . . . . . . . . . . . 19 81 4.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 19 82 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 4.4. Host Configuration and Lookup Services . . . . . . . . . . 19 84 4.5. Network Management . . . . . . . . . . . . . . . . . . . . 19 85 4.5.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 4.5.1.1. Background . . . . . . . . . . . . . . . . . . . . 20 87 4.5.1.2. Revisiting SNMP implementation for resource 88 constrained devices . . . . . . . . . . . . . . . 20 89 4.5.1.3. Proposed approach for building an memory 90 efficient SNMP agent . . . . . . . . . . . . . . . 21 91 4.5.1.4. Example . . . . . . . . . . . . . . . . . . . . . 21 92 4.5.1.5. Further improvements . . . . . . . . . . . . . . . 24 93 4.5.1.6. Conclusion . . . . . . . . . . . . . . . . . . . . 24 94 5. Security protocols . . . . . . . . . . . . . . . . . . . . . . 25 95 5.1. Cryptography for Constrained Devices . . . . . . . . . . . 25 96 5.2. Transport Layer Security . . . . . . . . . . . . . . . . . 25 97 5.3. Network Layer Security . . . . . . . . . . . . . . . . . . 25 98 5.4. Network Access Control . . . . . . . . . . . . . . . . . . 25 99 5.4.1. PANA . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 5.4.1.1. PANA AVPs . . . . . . . . . . . . . . . . . . . . 25 101 5.4.1.2. PANA Phases . . . . . . . . . . . . . . . . . . . 26 102 5.4.1.3. PANA session state parameters . . . . . . . . . . 28 103 6. Wire-Visible Constraints . . . . . . . . . . . . . . . . . . . 31 104 7. Wire-Invisible Constraints . . . . . . . . . . . . . . . . . . 32 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 107 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 108 10.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 35 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 110 11.1. Normative References . . . . . . . . . . . . . . . . . . . 36 111 11.2. Informative References . . . . . . . . . . . . . . . . . . 36 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 1. Introduction 116 Today's Internet is experienced by users as a set of applications, 117 such as email, instant messaging, and social networks. There are 118 substantial differences in performance between the various end 119 devices with these applications, but in general end devices 120 participating in the Internet today are considered to have relatively 121 high performance. 123 More and more communications technology is being embedded into our 124 environment. Different types of devices in our buildings, vehicles, 125 equipment and other objects have a need to communicate. It is 126 expected that most of these devices will employ the Internet Protocol 127 suite. The term "Internet of Things" denotes a trend where a large 128 number of devices directly benefit from communication services that 129 use Internet protocols. Many of these devices are not primarily 130 computing devices operated by humans, but exist as components in 131 buildings, vehicles, and the environment. There will be a lot of 132 variation in the computing power, available memory, communications 133 bandwidth, and other capabilities between different types of these 134 devices. With many low-cost, low-power and otherwise constrained 135 devices, it is not always easy to embed all the necessary features. 137 Historically, there has been a trend to invent special "light-weight" 138 _protocols_ to connect the most constrained devices. However, much 139 of this development can simply run on existing Internet protocols, 140 provided some attention is given to achieving light-weight 141 _implementations_. In some cases the new, constrained environments 142 can indeed benefit from protocol optimizations and additional 143 protocols that help optimize Internet communications and lower the 144 computational requirements. Examples of IETF standardization efforts 145 targeted for these environments include the "IPv6 over Low power WPAN 146 (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and 147 "Constrained RESTful Environments (CoRE)" working groups. More 148 generally, however, techniques are required to implement both these 149 optimized protocols as well as the other protocols of the Internet 150 protocol suite in a way that makes them applicable to a wider range 151 of devices. 153 1.1. Objectives 155 The present document, a product of the IETF Light-Weight 156 Implementation Guidance (LWIG) Working Group, focuses on helping the 157 implementers of the smallest devices. The goal is to be able to 158 build minimal yet interoperable IP-capable devices for the most 159 constrained environments. 161 Building a small implementation does not have to be hard. Many small 162 devices use stripped down versions of general purpose operating 163 systems and their TCP/IP stacks. However, there are implementations 164 that go even further in minimization and can exist in as few as a 165 couple of kilobytes of code, as on some devices this level of 166 optimization is necessary. Technical and cost considerations may 167 limit the computing power, battery capacity, available memory, or 168 communications bandwidth that can be provided. To overcome these 169 limitations the implementers have to employ the right hardware and 170 software mechanisms. For instance, certain types of memory 171 management or even fixed memory allocation may be required. It is 172 also useful to understand what is necessary from the point of view of 173 the communications protocols and the application employing them. For 174 instance, a device that only acts as a client or only requires one 175 connection can simplify its TCP implementation considerably. 177 The purpose of this document is to collect experiences from 178 implementers of IP stacks in constrained devices. The focus is on 179 techniques that have been used in actual implementations and do not 180 impact interoperability with other devices. The techniques shall 181 also not affect conformance to the relevant specifications. We 182 describe implementation techniques for reducing complexity, memory 183 footprint, or power usage. 185 The topics for this working group will be chosen from Internet 186 protocols that are in wide use today, such as IPv4 and IPv6; UDP and 187 TCP; ICMPv4/v6, MLD/IGMP and ND; DNS and DHCPv4/v6; TLS, DTLS and 188 IPsec; as well as from the optimized protocols that result from the 189 work of the 6LoWPAN, RPL, and CoRE working groups. This document 190 will be helpful for the implementers of new devices or for the 191 implementers of new general-purpose small IP stacks. It is also 192 expected that the document will increase our knowledge of what 193 existing small implementations do, and will help in the further 194 optimization of the existing implementations. In areas where the 195 considerations for small implementations have already been documented 196 in an accessible way, we will refer to those documents instead of 197 duplicating the material here. 199 Generic hardware design advice and software implementation techniques 200 are outside the scope of this document. Protocol implementation 201 experience, however, is the focus. There is no intention to describe 202 any new protocols or protocol behavior modifications beyond what is 203 already allowed by existing RFCs, because it is important to ensure 204 that different types of devices can work together. For example, 205 implementation techniques relating to security mechanisms are within 206 scope, but mere removal of security functionality from a protocol is 207 rarely an acceptable approach. 209 1.2. Call for contributions 211 The present draft of the document is an outline that will grow with 212 the contributions received, which are expressly invited. As this 213 document focuses on experience from existing implementations, this 214 requires implementer input; in particular, participation is required 215 from the implementers of existing small IP stacks. "Small" here is 216 intended to be applicable approximately to what is described in 217 Section 2 -- where it is more important that the technique described 218 is grounded in actual experience than that the experience is actually 219 from a (very) constrained system. 221 Only a few subsections are fleshed out in this initial draft; 222 additional subsections will quickly be integrated from additional 223 contributors. 225 1.3. Terminology 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC 2119. As this is 230 an informational document, the [RFC2119] keywords will only be used 231 to underscore requirements where similar key words apply in the 232 context of the specifications the light-weight implementation of 233 which is being discussed. 235 The term "byte" is used in its now customary sense as a synonym for 236 "octet". 238 2. Drawing the Landscape 240 There is not a single kind of constrained, Internet-connected device. 241 To the contrary, the trend is towards much more functional variety of 242 such devices than is customary today in the Internet. This section 243 introduces a number of terms that will be used to locate some of the 244 technique described in the following sections within certain areas of 245 applications. 247 2.1. Classes of Devices 249 Despite the overwhelming variety of Internet-connected devices that 250 can be envisioned, it may, be worthwhile to have some succinct 251 terminology for different classes of constrained devices. In this 252 document, the following class designations may be used as rough 253 indications of device capabilities: 255 +---------+-----------------------+-------------------------+ 256 | Name | data size (e.g., RAM) | code size (e.g., Flash) | 257 +---------+-----------------------+-------------------------+ 258 | Class 1 | ~ 10 KiB | ~ 100 KiB | 259 | | | | 260 | Class 2 | ~ 50 KiB | ~ 250 KiB | 261 +---------+-----------------------+-------------------------+ 263 As of the writing of this document, these characteristics correspond 264 to distinguishable sets of commercially available chips and design 265 cores for constrained devices. While it is expected that the 266 boundaries of these classes will move over time, Moore's law tends to 267 be less effective in the embedded space than in personal computing 268 devices: Gains made available by increases in transistor count and 269 density are more likely to be invested in reductions of cost and 270 power requirements than into continual increases in computing power. 272 2.2. Design Objectives 274 o Consideration for design or implementation approaches for 275 implementation of IP stacks for constrained devices will be 276 impacted by the RAM usage for these designs. Here the 277 consideration is what is the best approach to minimize overhead. 279 o In addition, the impact on throughput in terms of IP protocol 280 implementation must take into consideration the methods that 281 minimize overhead but balance performance requirements for the 282 light-weight constrained devices. 284 o Protocol implementation must consider its impact on CPU 285 utilization. Here guidance will be provided on how to minimize 286 tasks that require additional CPU execution time. 288 How does the implementation of the IP stack effect the application 289 both in terms of performance but also of those same attributes and 290 requirements (RAM, CPU usage, etc.) that we are examining for the IP 291 protocol stack? 293 From performing a synthesis of implementation experiences we will be 294 able to understand and document the benefits and consequences of 295 varied approaches. Scaling code and selected approaches in terms of 296 scaling from, say, a 8-bit micro to a 16-bit micro. Such scaling for 297 the approach will aid in the development of single code base when 298 possible. 300 2.3. Implementation Styles 302 Compared to personal computing devices, constrained devices tend to 303 make use of quite different classes of operating systems, if that 304 term is even applicable. 306 ... 308 o Single-threaded/giant mainloop 310 o Event-driven vs. threaded/blocking 312 * The usual multi-threaded model blocks a thread on primitives 313 such as connect(), accept() or read() until an external event 314 takes place. This model is often thought to consume too much 315 RAM and CPU processing. 317 * The event driven model uses a non-blocking approach: E.g., when 318 an application interface sends a message, the routine would 319 return immediately (before the message is sent). A call-back 320 facility notifies the application or calling code when the 321 desired processing is completed. Here the benefit is that no 322 thread context needs to be preserved for long periods of time. 324 o Single/multiple processing elements 326 o E.g., separate radio/network processor 328 Introduce these briefly: Some techniques may be applicable only to 329 some of these styles! 331 2.4. Roles of nodes 333 Constrained nodes are by necessity more specialized than general 334 purpose computing devices; they may have a quite specific role. Some 335 implementation techniques may also 337 o Constrained nodes 339 o Nodes talking to constrained nodes 341 o Gateways/Proxies 343 In all these cases, constrained nodes that are "sleepy" pose 344 additional considerations. (Explain sleepy...) E.g., a node talking 345 to a sleepy node may need to make special arrangements; this is even 346 more true where a gateway or proxy interfaces the general Internet 348 o Bandwidth/latency considerations 350 2.5. Overview over the document 352 The following sections will first go through a number of specific 353 protocol layers, starting from layers of the data plane (link 354 adaptation, network, transport, application), followed by control 355 plane protocol layers (link layer support, network layer and routing, 356 host configuration and lookup services). We then look at security 357 protocols (general cryptography considerations, transport layer 358 security, network layer security, network access control). Finally, 359 we discuss some specific, cross-layer concerns, some "wire-visible", 360 some of concern within a specific implementation. Clearly, many 361 topics could be discussed in more than one place in this structure. 362 The objective is not to have something for each of the potential 363 topics, but to document the most valuable experience that may be 364 available. 366 3. Data Plane Protocols 368 3.1. Link Adaptation Layer 370 6LoWPAN 372 3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration 374 Author: Carsten Bormann 376 6LoWPAN [RFC4944] is an adaptation layer that maps IPv6 with its 377 minimum MTU of 1280 bytes to IEEE 802.15.4, which has a physical 378 layer MTU of only 127 bytes (some of which are taken by MAC layer and 379 adaptation layer headers). Therefore, the adaptation layer provides 380 a fragmentation and reassembly scheme that can fragment a single IPv6 381 packet of up to 1280 bytes into multiple adaptation layer fragments 382 of up to 127 bytes each (including MAC and adaptation layer 383 overhead). 385 In a route-over configuration, implementing this adaptation layer 386 fragmentation scheme straightforwardly means that reassembly and then 387 fragmentation are performed at each forwarding hop. As fragments 388 from several packets may be arriving interleaved with each other, 389 this approach requires buffer space for multiple MTU-size IPv6 390 packets. 392 In a mesh-under configuration, adaptation layer fragments can be 393 forwarded independently of each other. It would be preferable if 394 something similar were possible for route-over. Complete 395 independence in forwarding of adaptation layer fragments is not 396 possible for route-over, however, as the layer-3 addresses needed for 397 forwarding are in the initial bytes of the IPv6 header, which is 398 present only in the first fragment of a larger packet. 400 Instead of performing a full reassembly, implementations may be able 401 to optimize this process by not keeping a full reassembly buffer, but 402 just a runt buffer (called "virtual reassembly buffer" in [WEI]) for 403 each IP packet. This buffer caches only the datagram_tag field (as 404 usual combined with the sender's link layer address, the 405 destination's link layer address and the datagram_size field) and the 406 IPv6 header including the relevant addresses. Initial fragments are 407 then forwarded independently (after header decompression/compression) 408 and create a runt reassembly buffer. Non-initial fragments (which 409 don't require header decompression/compression in 6LoWPAN) are 410 matched against the runt buffers by datagram_tag etc. and forwarded 411 if an IPv6 address is available. (This simple scheme may be 412 complicated a bit if header decompression/compression of the initial 413 fragment causes an overflow of the physical MTU; in this case some 414 overflow data may need to be stored in the runt buffers to be 415 combined with further fragments or may simply be forwarded as a 416 separate additional fragment.) 418 If non-initial fragments arrive out of order before the initial 419 fragment, a route-over router may want to keep the contents of the 420 non-initial fragments until the initial fragment is available, which 421 does need some buffer space. If that is not available, a more 422 constrained route-over router may simply discard out-of order non- 423 initial fragments, possibly taking note that there is no point in 424 forwarding any more fragments with the same combination of 6LoWPAN 425 datagram_tag field, L2 addresses and datagram_size. 427 Runt buffers should time out like full reassembly buffers, and may 428 either keep a map of fragments forwarded or they may simply be 429 removed upon forwarding the final fragment, assuming that no out-of- 430 order fragments will follow. 432 3.1.1.1. Implementation Considerations for Not-So-Constrained Nodes 434 [RFC4944] makes no explicit mandates about the order in which 435 fragments should be sent. Because it is heavily favored by the above 436 implementation techniques, it is highly advisable for all 437 implementations to always send adaptation layer fragments in natural 438 order, i.e., starting with the initial fragment, continuing with 439 increasing datagram_offset. 441 3.2. Network Layer 443 IPv4 and IPv6 445 3.3. Transport Layer 447 TCP and UDP 449 Both TCP and UDP employ 16-bit one's-complement checksums to protect 450 against transmission errors. A number of RFCs discuss efficient 451 implementation techniques for computing and updating Internet 452 Checksums [RFC1071] [RFC1141] [RFC1624]. (Updating the Internet 453 Checksum, as opposed to computing it from scratch, may be of interest 454 where a pre-computed packet is provided, e.g., in Flash ROM, and a 455 copy is made in RAM and updated with some current values, or when the 456 actual transmitted packet is composed from pre-defined parts in ROM 457 and new parts in RAM.) 459 3.4. Application Layer 461 3.4.1. General considerations about Application Programming Interfaces 462 (APIs) 464 Author: Carl Williams 466 Constrained devices are not necessarily in a position to use APIs 467 that would be considered "standard" for less constrained environments 468 (e.g., Berkeley sockets or those defined by POSIX). 470 When an API implements a protocol, this can be based on proxy methods 471 for remote invocations that underneath rely on the communication 472 protocol. One of the roles of the API can be exactly to hide the 473 detail of the transport protocol. 475 Changes to the lower layers will be made to implement light-weight 476 stacks so this impacts that implementation and inter-workings with 477 the API. Similar considerations such as RAM, CPU utilization and 478 performance requirements apply to the API and its use of the lower 479 layer resources (i.e., buffers). 481 Considerations for the proper approach for a developer to request 482 services from an application program need to be explored and 483 documented. Such considerations will allow the progression of a 484 common consistent networking paradigm without inventing a new way of 485 programming these devices. 487 In addition, such considerations will take into account the inter- 488 working of the API with the protocols. Protocols are more complex to 489 use as they are less direct and take a lot of serializing, de- 490 serializing and dispatching type logic. 492 So the connection of the API and the protocols on a constrained 493 device becomes even more important to balance the requirements of 494 RAM, CPU and performance. 496 _** Here we will proceed to collect and document ... insert 497 experiences from existing API on constrained devices (TBD) **_ 499 3.4.2. Constrained Application Protocol (CoAP) 501 Author: Olaf Bergmann 503 The Constrained Application Protocol [I-D.ietf-core-coap] has been 504 designed specifically for machine-to-machine communication in 505 networks with very constrained nodes. Typical application scenarios 506 therefore include building automation and the Internet of Things. 508 The major design objectives have been set on small protocol overhead, 509 robustness against packet loss, and high latency induced by small 510 bandwidth shares or slow request processing in end nodes. To 511 leverage integration of constrained nodes with the world-wide 512 Internet, the protocol design was led by the architectural style that 513 accounts for the scalability and robustness of the Hypertext Transfer 514 Protocol [RFC2616]. 516 Lightweight implementations benefit from this design in many 517 respects: First, the use of Uniform Resource Identifiers (URIs) for 518 naming resources and the transparent forwarding of their 519 representations in a server-stateless request/response protocol make 520 protocol-translation to HTTP a straightforward task. Second, the set 521 of protocol elements that are inevitable for the core protocol and 522 thus must be implemented on every node has been kept very small to 523 avoid unnecessary accumulation of optional features. Options that -- 524 when present -- are critical for message processing are explicitly 525 marked as such to force immediate rejection of messages with unknown 526 critical options. Third, the syntax of protocol data units is easy 527 to parse and is carefully defined to avoid creation of state in 528 servers where possible. 530 Although these features enable lightweight implementations of the 531 Constrained Application Protocol, there is still a trade-off between 532 robustness and latency of constrained nodes on one hand and resource 533 demands (such as battery consumption, dynamic memory needs and static 534 code-size) on the other. This section gives some guidance on 535 possible strategies to solve this trade-off for very constrained 536 nodes (Class 1 in Section 2.1). The main focus is on servers as this 537 is deemed the predominant case where CoAP applications are faced with 538 tight resource constraints. 540 Additional considerations for the implementation of CoAP on tiny 541 sensors are given in [I-D.arkko-core-sleepy-sensors]. 543 3.4.2.1. Message Layer Processing 545 For constrained nodes of Class 1 or even Class 2, limiting factors 546 for (wireless) network communication usually are RAM size and battery 547 lifetime. Most applications therefore try to avoid dealing with 548 fragmented packets on the network layer and minimize internal buffer 549 space for both transmit and receive operations. One of the most 550 expensive operations hence is the retransmission of messages as it 551 implies additional energy consumption for the (radio) network 552 interface and occupied RAM storage for the send buffer. 554 Where multi-threading is not an option at all because no full-fledged 555 operating system is present, all operations are triggered by a big 556 main loop in a send-receive-dispatch cycle. To implement the packet 557 retransmission, CoAP implementations at least need a separate send 558 buffer and a decent notion of time, e.g. as a strictly monotonic 559 increasing tick counter. For platforms that disable clock tick 560 interrupts in sleep states, the application must take into 561 consideration the clock deviation that occurs during sleep (or ensure 562 to remain in idle state until the message has been acknowledged or 563 the maximum number of retransmissions is reached). Since CoAP allows 564 up to four retransmissions with a binary exponential back-off it 565 could take up to 45 seconds until the send operation is complete. 566 Even in idle state, this means substantial energy consumption for 567 low-power nodes. Implementers therefore might choose a two-step 568 strategy: First, do one or two retransmissions and then, in the later 569 phases of back-off, go to sleep until the next retransmission is due. 570 In the meantime, the node could check for new messages including the 571 acknowledgement for any confirmable message to send. 573 A similar strategy holds for confirmable messages with separate 574 responses. This concept entitles CoAP servers to return an empty 575 acknowledgement to indicate that a confirmable request has been 576 understood and is being processed. Once a proper response has been 577 generate to fulfill the request, it is sent back as a confirmable 578 message as well. The server implementation in this case must be able 579 to map retransmissions of the original request to the ongoing 580 operation and provide the client-selected Token to map between 581 original request and the separate response. 583 Depending on the number of requests that can be handled in parallel, 584 an implementation might create a stub response filled with any option 585 that has to be copied from the original request to the separate 586 response, especially the Token option. The drawback of this 587 technique is that the server must be prepared to receive 588 retransmissions of the previous (confirmable) request to which a new 589 acknowledgement must be generated. If memory is an issue, a single 590 buffer can be used for both tasks: Only the message type and code 591 must be updated, changing the message id is optional. Once the 592 resource representation is known, it is added as new payload at the 593 end of the stub response. Acknowledgements still can be sent as 594 described before as long as no additional options are required to 595 describe the payload. 597 3.4.2.2. Message Parsing 599 Both CoAP clients and servers must construct outgoing CoAP PDUs and 600 parse incoming messages. The basic message header consists of only 601 four octets and thus can be mapped easily to an internal data 602 structure, considering the actual byte order of the host. Once the 603 message is accepted for further processing, the set of options 604 contained in the received message must be decoded to check for 605 unknown critical options. To avoid multiple passes through the 606 option list, the option parser might maintain a bit-vector where each 607 bit represents an option number that is present in the received 608 request. The delta-encoded option number indicates the number of 609 left-shift operations to apply on a bit mask to set the corresponding 610 bit. 612 In addition, the byte index of every option is added to a sparse list 613 (e.g. a one-dimensional array) for fast retrieval. This particularly 614 enables efficient reduced-function handling of options that might 615 occur more than once such as Uri-Path. In this implementation 616 strategy, the delta is zero for any subsequent path segment, hence 617 the stored byte index for option 9 (Uri-Path) will be overwritten to 618 hold a pointer to the last occurrence of that option, i.e., only the 619 last path component actually matters. (Of course, this requires 620 choosing resource names where the combination of (final Uri-Path 621 component, final Uri-Query component) is server-wide unique. 623 Note: Where skipping all but the last path segment is not feasible 624 for some reason, resource identification could be ensured by some 625 hash value calculated over the path segments. For each segment 626 encountered, the stored hash value is updated by the current 627 option value. This works if a cheap _perfect hashing_ scheme can 628 be found for the resource names. 630 Once the option list has been processed at least up to the highest 631 option number that is supported by the application, any known 632 critical option and all elective options can be masked out to 633 determine if any unknown critical option was present. If this is the 634 case, this information can be used to create a 4.02 response 635 accordingly. (Note that the remaining options also must be processed 636 to add further critical options included in the original request.) 638 3.4.2.3. Storing Used Message IDs 640 If CoAP is used directly on top of UDP (i.e., in NoSec mode), it 641 needs to cope with the fact that the UDP datagram transport can 642 reorder and duplicate messages. (In contrast to UDP, DTLS has its 643 own duplicate detection.) CoAP has been designed with protocol 644 functionality such that rejection of duplicate messages is always 645 possible. It is at the discretion of the receiver if it actually 646 wants to make use of this functionality. Processing of duplicate 647 messages comes at a cost, but so does the management of the state 648 associated with duplicate rejection. Hence, a receiver may have good 649 reasons to decide not to do the duplicate rejection. If duplicate 650 rejection is indeed necessary, e.g., for non-idempotent requests, it 651 is important to control the amount of state that needs to be stored. 653 Author: Esko Dijk 655 CoAP's duplicate rejection functionality can be straightforwardly 656 implemented in a CoAP end-point by storing, for each remote CoAP end- 657 point ("peer") that it communicates with, a list of recently received 658 CoAP Message IDs (MIDs) along with some timing information. A CoAP 659 message from a peer with a MID that is in the list for that peer can 660 simply be discarded. 662 The timing information in the list can then be used to time out 663 entries that are older than the _expected extent of the re-ordering_, 664 an upper bound for which can be estimated by adding the _potential 665 retransmission window_ ([I-D.ietf-core-coap] section "Reliable 666 Messages") and the time packets can stay alive in the network. 668 Such a straightforward implementation is suitable in case other CoAP 669 end-points generate random MIDs. However, this storage method may 670 consume substantial RAM in specific cases, such as: 672 o many clients are making periodic, non-idempotent requests to a 673 single CoAP server; 675 o one client makes periodic requests to a large number of CoAP 676 servers and/or requests a large number of resources; where servers 677 happen to mostly generate separate CoAP responses (not piggy- 678 backed); 680 For example, consider the first case where the expected extent of re- 681 ordering is 50 seconds, and N clients are sending periodic POST 682 requests to a single CoAP server during a period of high system 683 activity, each on average sending one client request per second. The 684 server would need 100 * N bytes of RAM to store the MIDs only. This 685 amount of RAM may be significant on a RAM-constrained platform. On a 686 number of platforms, it may be easier to allocate some extra program 687 memory (e.g. Flash or ROM) to the CoAP protocol handler process than 688 to allocate extra RAM. Therefore, one may try to reduce RAM usage of 689 a CoAP implementation at the cost of some additional program memory 690 usage and implementation complexity. 692 Some CoAP clients generate MID values by a using a Message ID 693 variable [I-D.ietf-core-coap] that is incremented by one each time a 694 new MID needs to be generated. (After the maximum value 65535 it 695 wraps back to 0.) We call this behavior "sequential" MIDs. One 696 approach to reduce RAM use exploits the redundancy in sequential MIDs 697 for a more efficient MID storage in CoAP servers. 699 Naturally such an approach requires, in order to actually reduce RAM 700 usage in an implementation, that a large part of the peers follow the 701 sequential MID behavior. To realize this optimization, the authors 702 therefore RECOMMEND that CoAP end-point implementers employ the 703 "sequential MID" scheme if there are no reasons to prefer another 704 scheme, such as randomly generated MID values. 706 Security considerations might call for a choice for 707 (pseudo)randomized MIDs. Note however that with truly randomly 708 generated MIDs the probability of MID collision is rather high in use 709 cases as mentioned before, following from the Birthday Paradox. For 710 example, in a sequence of 52 randomly drawn 16-bit values the 711 probability of finding at least two identical values is about 2 712 percent. 714 From here on we consider efficient storage implementations for MIDs 715 in CoAP end-points, that are optimized to store "sequential" MIDs. 716 Because CoAP messages may be lost or arrive out-of-order, a solution 717 has to take into account that received MIDs of CoAP messages are not 718 actually arriving in a sequential fashion, due to lost or reordered 719 messages. Also a peer might reset and lose its MID counter(s) state. 720 In addition, a peer may have a single Message ID variable used in 721 messages to many CoAP end-points it communicates with, which partly 722 breaks sequentiality from the receiving CoAP end-point's perspective. 723 Finally, some peers might use a randomly generated MID values 724 approach. Due to these specific conditions, existing sliding window 725 bitfield implementations for storing received sequence numbers are 726 typically not directly suitable for efficiently storing MIDs. 728 Table 1 shows one example for a per-peer MID storage design: a table 729 with a bitfield of a defined length _K_ per entry to store received 730 MIDs (one per bit) that have a value in the range [MID_i + 1 , MID_i 731 + K]. 733 +----------+----------------+-----------------+ 734 | MID base | K-bit bitfield | base time value | 735 +----------+----------------+-----------------+ 736 | MID_0 | 010010101001 | t_0 | 737 | | | | 738 | MID_1 | 111101110111 | t_1 | 739 | | | | 740 | ... etc. | | | 741 +----------+----------------+-----------------+ 743 Table 1: A per-peer table for storing MIDs based on MID\\_i 745 The presence of a table row with base MID_i (regardless of the 746 bitfield values) indicates that a value MID_i has been received at a 747 time t_i. Subsequently, each bitfield bit k (0...K-1) in a row i 748 corresponds to a received MID value of MID_i + k + 1. If a bit k is 749 0, it means a message with corresponding MID has not yet been 750 received. A bit 1 indicates such a message has been received already 751 at approximately time t_i. This storage structure allows e.g. with 752 k=64 to store in best case up to 130 MID values using 20 bytes, as 753 opposed to 260 bytes that would be needed for a non-sequential 754 storage scheme. 756 The time values t_i are used for removing rows from the table after a 757 preset timeout period, to keep the MID store small in size and enable 758 these MIDs to be safely re-used in future communications. (Note that 759 the table only stores one time value per row, which therefore needs 760 to be updated on receipt of another MID that is stored as a single 761 bit in this row. As a consequence of only storing one time value per 762 row, older MID entries typically time out later than with a simple 763 per-MID time value storage scheme. The end-point therefore needs to 764 ensure that this additional delay before MID entries are removed from 765 the table is much smaller than the time period after which a peer 766 starts to re-use MID values due to wrap-around of a peer's MID 767 variable. One solution is to check that a value t_i in a table row 768 is still recent enough, before using the row and updating the value 769 t_i to current time. If not recent enough, e.g. older than N 770 seconds, a new row with an empty bitfield is created.) [Clearly, 771 these optimizations would benefit if the peer were much more 772 conservative about re-using MIDs than currently required in the 773 protocol specification.] 775 The optimization described is less efficient for storing randomized 776 MIDs that a CoAP end-point may encounter from certain peers. To 777 solve this, a storage algorithm may start in a simple MID storage 778 mode, first assuming that the peer produces non-sequential MIDs. 779 While storing MIDs, a heuristic is then applied based on monitoring 780 some "hit rate", for example, the number of MIDs received that have a 781 Most Significant Byte equal to that of the previous MID divided by 782 the total number of MIDs received. If the hit rate tends towards 1 783 over a period of time, the MID store may decide that this particular 784 CoAP end-point uses sequential MIDs and in response improve 785 efficiency by switching its mode to the bitfield based storage. 787 3.4.3. (Other Application Protocols...) 788 4. Control Plane Protocols 790 4.1. Link Layer Support 792 ARP, ND; 6LoWPAN-ND 794 4.2. Network Layer 796 ICMP, ICMPv6, IGMP/MLD 798 4.3. Routing 800 RPL, AODV/DYMO, OLSRv2 802 4.4. Host Configuration and Lookup Services 804 DNS, DHCPv4, DHCPv6 806 4.5. Network Management 808 SNMP, netconf? 810 4.5.1. SNMP 812 Author: Brinda M C 814 This section describes an approach for developing a light-weight SNMP 815 agent for resource constrained devices running the 6LoWPAN/RPL 816 protocol stack. The motivation for the work is driven by two major 817 factors: 819 o SNMP plays a vital role in monitoring and managing any operational 820 network; 6LoWPAN based WSN is no exception to this. 822 o There is a need for building a light-weight SNMP agent which 823 consumes less memory and less computational resources. 825 The following subsections are organized as follows: 827 o Section 4.5.1.1 provides some background. 829 o In Section 4.5.1.2, we revisit existing SNMP implementation in the 830 context of memory constrained devices. 832 o In Section 4.5.1.3, we present our approach for building a memory 833 efficient SNMP agent. 835 o Using a realistic example, in Section 4.5.1.4, we illustrate how 836 the proposed method can be implemented. 838 o In Section 4.5.1.5, we explore a few ideas which can further help 839 in improving the memory utilization. 841 4.5.1.1. Background 843 Our initial SNMP agent implementation was completely based on Net- 844 SNMP, well-known open-source network monitoring and management 845 software. After porting the agent on to the TelosB mote, we observed 846 that it occupies a text program memory of more than 8 KiB on TinyOS 847 and Contiki OS platforms. (Note that both these platforms already 848 use compiler optimizations to minimize the memory footprint.) 8 KiB 849 is already non-negligible given the 48 KiB program memory limit of 850 TelosB. Added to this, the memory taken up by 6LoWPAN and the 851 related protocol stacks are ever growing, causing serious memory 852 crunch in the resource constrained devices. We reached a situation 853 where we could not build an image on the TinyOS/Contiki OS platforms 854 with our SNMP agent. 856 We came across SNMPv1 agent implementations elsewhere in the 857 literature which also report similar memory consumption. This 858 motivated us to have a re-look at the existing SNMP agent 859 implementation, and explore the possibility of an alternate 860 implementation using altogether a different approach. 862 4.5.1.2. Revisiting SNMP implementation for resource constrained 863 devices 865 If we look at a typical SNMP agent implementation, we can see that 866 much of the memory consuming code is pertaining to ASN.1 related SNMP 867 PDU parsing and SNMP PDU build operations. The SNMP parsing mainly 868 recovers various fields from the incoming PDU, such as the OIDs, 869 whereas the SNMP PDU build is the reverse operation of building the 870 response PDU from the OIDs. 872 The key observation is that, for a given MIB definition, an OID of 873 interest contained in the incoming SNMP PDU is already available, 874 albeit in an encoded form. This enables identifying the OID from the 875 packet in its "raw" form, simplifying parser operation. 877 We also can make use of this observation while building the response 878 SNMP PDU. For a given MIB definition, we can think of statically 879 having a pre-composed ASN.1 encoded version of OIDs, and use them 880 while constructing the response SNMP PDU. 882 4.5.1.3. Proposed approach for building an memory efficient SNMP agent 884 As noted in the previous section, since an SNMP OID is already 885 _contained_ in the incoming network PDU, we came up with a simple OID 886 signature identification method performed directly on the network PDU 887 through simple memory comparisons and table look-ups. Once the OID 888 has been identified from the packet "in situ", the corresponding per- 889 OID processing is carried out. Through this scheme we completely 890 eliminated expensive SNMP parse operations. 892 For the SNMP PDU build, we use _pre-encoded_ OID variables which can 893 simply be plugged into the network SNMP response packet directly 894 depending on the request OID. Now that the expensive build operation 895 is taken care, what remains is the construction of the overall SNMP 896 pdu which can be built through simple logic. Through this scheme we 897 completely eliminated expensive SNMP build operations. 899 Based on these ideas, we have re-architected our original SNMP agent 900 implementation and with our new implementation we were able to bring 901 down its text memory usage all the way down to 4 KiB from the native 902 SNMP agent implementation which occupied 8 KiB. 904 4.5.1.3.1. Discussion on memory usage 906 With respect to the memory usage, while we have achieved major 907 reduction in terms of text program memory, which occupies a major 908 chunk of memory, a question might come to mind with regard to the 909 static memory allocation for maintaining the tables. We found that 910 this is not very significant to start with. Through an efficient 911 table representation, we further optimized the memory consumption. 912 We could do so because a typical OID description is mainly dominated 913 by a fixed part of the hierarchy. This enables us to define few 914 static prefixes, each corresponding to a particular hierarchy level 915 of the OID. In the context of 6LoWPAN, it can be expected that the 916 number of hierarchy levels will be small. 918 4.5.1.4. Example 920 This section illustrates the simplicity and practicality of our 921 approach with an example. Let us consider the fragment of a 922 representative MIB definition depicted in Figure 1 923 iso 924 | 925 org 926 | 927 dod 928 | 929 internet 930 | 931 mgmt.mib-2 932 | 933 lowpanMIB 934 | 935 +--lowpanPrimaryStatistics(10) 936 | 937 +--PrimeStatsEntry(1) 938 | 939 +-- -R-- INTEGER lowpanMoteBatteryVoltageP(1) 940 +-- -R-- Counter lowpanFramesReceivedP(2) 941 +-- -R-- Counter lowpanFramesSentP(3) 942 +-- -R-- Counter ipv6ForwardedMsgP(4) 943 +-- -R-- Counter OUTSolicitationP(5) 944 +-- -R-- Counter OUTAdvertisementP(6) 946 Figure 1: A fragment of a MIB hierarchy 948 4.5.1.4.1. Optimized SNMP Parsing 950 Let us consider a GET request for the OIDs lowpanMoteBatteryVoltageP 951 and lowpanFramesSentP. Corresponding to these OIDs, a C array dump 952 of the network PDU of SNMP packet with two OIDs in a variable binding 953 would look as in Figure 2. 955 char snmp_get_req_pkt[] = { 956 0x30, 0x81, 0x3d, 0x02, 0x01, 0x00, 0x04, 0x06, 957 0x70, 0x75, 0x62, 0x6c, 0x69, 0x63, 0xa0, 0x30, 958 0x02, 0x04, 0x28, 0x29, 0xe4, 0x5d, 0x02, 0x01, 959 0x00, 0x02, 0x01, 0x00, 0x30, 0x22, 0x30, 0x0f, 960 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 961 0x90, 0x12, 0x0a, 0x01, 0x01, 0x05, 0x00, 0x30, 962 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 963 0x83, 0x90, 0x12, 0x0a, 0x01, 0x03, 0x05, 0x00 }; 965 Figure 2: An SNMP packet, represented in C 967 Inspecting the above packet, we see that the main components of the 968 PDU are: 970 1. Version (SNMPv1): [0x02, 0x01, 0x00] 972 2. Community Name ("public"): [0x04, 0x06, 0x70, 0x75, 0x62, 0x6c, 973 0x69, 0x63] 975 3. ASN.1 encoded OIDs for lowpanMoteBatteryVoltageP, and 976 lowpanFramesReceivedP: 978 * [0x30, 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 979 0x90, 0x12, 0x0a, 0x01, 0x01, 0x05, 0x00] 981 * [0x30, 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 982 0x90, 0x12, 0x0a, 0x01, 0x03, 0x05, 0x00] 984 There is a significant overlap between the two OIDs, which can be 985 used to simplify the parsing process. We can, for instance, define 986 one statically initialized array containing elements common between 987 these OIDs. Using this notion of common prefix idea, we can come up 988 with an optimized table and the OID identification then boils down to 989 simple memory comparisons within this table. The optimized table 990 construction will also result in scalability. 992 4.5.1.4.2. Optimized SNMP Build 994 Extending the same approach as described above, we can build the GET 995 response by plugging in pre-encoded OIDs into the response packets. 996 So, corresponding to the GET request for the OIDs as given in section 997 4.1, we can define C arrays containing pre-encoded OIDs which can go 998 into the response packet as in Figure 3. 1000 pdu_batt_volt[] = { 1001 0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 1002 0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x01, 0x02, 1003 0x02, 0x00, 0x00 }; 1005 pdu_frames_sent[] = { 1006 0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 1007 0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x03, 0x41, 1008 0x02, 0x00, 0x00 }; 1010 Figure 3: Pre-encoded OIDs 1012 Since the ASN.1 basic encoding rules are in TLV format, the offset 1013 within the encoded OID where the value needs to be filled-in can be 1014 obtained from the length field. 1016 The table size optimization discussed in the previous section can be 1017 applied here, too. 1019 Note: Though we have taken a simple example to illustrate the 1020 efficacy of the proposed approach, the ideas presented here can 1021 easily be extended to other scenarios as well. 1023 4.5.1.5. Further improvements 1025 A few simple methods can reduce the code size as well as generate 1026 computationally inexpensive code. These methods might sound obvious 1027 and trivial but are important for constrained devices. 1029 o If possible, avoid using memory consuming data types such as 1030 floating point while representing a monitored variable when an 1031 equivalent representation of the same that occupies less memory is 1032 adequate. For example, while a battery voltage indication could 1033 take a fractional value between 0 and 3 V, opt for an 8-bit 1034 quantized value. 1036 o Using meta data in the MIB definition instead of absolute numbers 1037 can bring down the memory and processing significantly and can 1038 improve scalability too especially for a large scale WSN 1039 deployments. Using the same example of battery voltage, one might 1040 think of an OID which represents fewer levels of the battery 1041 voltage signifying high, medium, low, very low. 1043 o While a multi-level hierarchy for MIB definition might improve OID 1044 segregation the flip side is that it increases the overall length 1045 of the OID and results in extra memory and processing overhead. 1046 One may have to make a judicious choice while coming up with the 1047 MIB. 1049 4.5.1.6. Conclusion 1051 This subsection proposes a simple SNMP packet processing based 1052 approach for building a light-weight SNMP agent. While there is 1053 scope for further improvement, we believe that the proposed method 1054 can be a reasonably good starting point for resource constrained 1055 6LoWPAN based networks. 1057 5. Security protocols 1059 5.1. Cryptography for Constrained Devices 1061 5.2. Transport Layer Security 1063 TLS, DTLS, ciphersuites, certificates 1065 5.3. Network Layer Security 1067 IPsec, IKEv2, transforms 1069 Advice for a minimal implementation of IKEv2 can be found in 1070 [I-D.kivinen-ipsecme-ikev2-minimal]. 1072 5.4. Network Access Control 1074 (PANA, EAP, EAP methods) 1076 5.4.1. PANA 1078 Author: Mitsuru Kanda 1080 PANA [RFC5191] provides network access authentication between clients 1081 and access networks. The PANA protocol runs between a PANA Client 1082 (PaC) and a PANA Authentication Agent (PAA). PANA carries UDP 1083 encapsulated EAP [RFC3748] and includes various operational options. 1084 From the point of view of minimal implementation, some of these are 1085 not necessary for constrained devices. This section describes a 1086 minimal PANA implementation for these devices. 1088 The minimization objective for this implementation mainly targets 1089 PaCs because constrained devices often are installed as network 1090 clients, such as sensors, metering devices, etc. 1092 5.4.1.1. PANA AVPs 1094 Each PANA message can carry zero or more AVPs (Attribute-Value Pairs) 1095 within its payload. [RFC5191] specifies nine types of AVPs (AUTH, 1096 EAP-Payload, Integrity-Algorithm, Key-Id, Nonce, PRF-Algorithm, 1097 Result-Code, Session-Lifetime, and Termination-Cause). All of them 1098 are required by all minimal implementations. But there are some 1099 notes. 1101 Integrity-Algorithm AVP and PRF-Algorithm AVP: 1103 All PANA implementations MUST support AUTH_HMAC_SHA1_160 for PANA 1104 message integrity protection and PRF_HMAC_SHA1 for pseudo-random 1105 function (PRF) specified in [RFC5191]. Both of these are based on 1106 SHA-1, which therefore needs to be implemented in a minimal 1107 implementation. 1109 Nonce AVP: 1111 As the basic hash function is SHA-1, including a nonce of 20 bytes in 1112 the Nonce AVP is appropriate ([RFC5191], section 8.5). 1114 5.4.1.2. PANA Phases 1116 A PANA session consists of four phases -- Authentication and 1117 authorization phase, Access phase, Re-Authentication phase, and 1118 Termination phase. 1120 Authentication and authorization phase: 1122 There are two types of PANA session initiation, PaC-initiated session 1123 and PAA-initiated session. The minimal implementation must support 1124 PaC-initiated session and does not need to support PAA-initiated 1125 session. Because a PaC (a constrained device) which may be a 1126 sleeping device, can not receive an unsolicited PANA-Auth-Request 1127 message from a PAA (PAA-initiated session). 1129 EAP messages can be carried in PANA-Auth-Request and PANA-Auth-Answer 1130 messages. In order to reduce the number of messages, "Piggybacking 1131 EAP" is useful. Both the PaC and PAA should include EAP-Payload AVP 1132 in each of PANA-Auth-Request and PANA-Auth-Answer messages as much as 1133 possible. Figure 4 shows an example "Piggybacking EAP" sequence of 1134 the Authentication and authorization phase. 1136 PaC PAA Message(sequence number)[AVPs] 1137 --------------------------------------------------------------------- 1138 -----> PANA-Client-Initiation(0) 1139 <----- PANA-Auth-Request(x)[PRF-Algorithm,Integrity-Algorithm] 1140 // The 'S' (Start) bit set 1141 -----> PANA-Auth-Answer(x)[PRF-Algorithm, Integrity-Algorithm] 1142 // The 'S' (Start) bit set 1143 <----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload] 1144 -----> PANA-Auth-Answer(x+1)[Nonce, EAP-Payload] 1145 <----- PANA-Auth-Request(x+2)[EAP-Payload] 1146 -----> PANA-Auth-Answer(x+2)[EAP-Payload] 1147 <----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload, 1148 Key-Id, Session-Lifetime, AUTH] 1149 // The 'C' (Complete) bit set 1150 -----> PANA-Auth-Answer(x+3)[Key-Id, AUTH] 1151 // The 'C' (Complete) bit set 1153 Figure 4: Example sequence of the Authentication and authorization 1154 phase for a PaC-initiated session (using "Piggybacking EAP") 1156 Note: It is possible to include an EAP-Payload in both the PANA-Auth- 1157 Request and PANA-Auth-Answer messages with the 'S' bit set. But the 1158 PAA should not include an EAP-Payload in the PANA-Auth-Request 1159 message with the 'S' bit set in order to stay stateless in response 1160 to a PANA-Client-Initiation message. 1162 Access phase: 1164 After Authentication and authorization phase completion, the PaC and 1165 PAA share a PANA Security Association (SA) and move Access phase. 1166 During Access phase, [RFC5191] describes both the PaC and PAA can 1167 send a PANA-Notification-Request message with the 'P' (Ping) bit set 1168 for the peer's PANA session liveness check (a.k.a "PANA ping"). From 1169 the minimal implementation point of view, the PAA should not send a 1170 PANA-Notification-Request message with the 'P' (Ping) bit set to 1171 initiate PANA ping since the PaC may be sleeping. The PaC does not 1172 need to send a PANA-Notification-Request message with the 'P' (Ping) 1173 bit set for PANA ping to the PAA periodically and may omit the PANA 1174 ping feature itself if the PaC can detect the PANA session failure by 1175 other methods, for example, network communication failure. In 1176 conclusion, the PaC does not need to implement the periodic liveness 1177 check feature sending PANA ping but a PaC that is awake should 1178 respond to a incoming PANA-Notification-Request message with the 'P' 1179 (Ping) bit set for PANA ping as possible. 1181 Re-Authentication phase: 1183 Before PANA session lifetime expiration, the PaC and PAA MUST re- 1184 negotiate to keep the PANA session. This means that the PaC and PAA 1185 enter Re-Authentication phase. Also in the Authentication and 1186 authorization phase, there are two types of re-authentication. The 1187 minimal implementation must support PaC-initiated re-authentication 1188 and does not need to support PAA-initiated re-authentication (again 1189 because the PaC may be a sleeping device). "Piggybacking EAP" is 1190 also useful here and should be used as well. Figure 5 shows an 1191 example "Piggybacking EAP" sequence of the Re-Authentication phase. 1193 PaC PAA Message(sequence number)[AVPs] 1194 --------------------------------------------------------------------- 1195 -----> PANA-Notification-Request(q)[AUTH] 1196 // The 'A' (re-Authentication) bit set 1197 <----- PANA-Notification-Answer(q)[AUTH] 1198 // The 'A' (re-Authentication) bit set 1199 <----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH] 1200 -----> PANA-Auth-Answer(p)[EAP-Payload, Nonce, AUTH] 1201 <----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH] 1202 -----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH] 1203 <----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload, 1204 Key-Id, Session-Lifetime, AUTH] 1205 // The 'C' (Complete) bit set 1206 -----> PANA-Auth-Answer(p+2)[Key-Id, AUTH] 1207 // The 'C' (Complete) bit set 1209 Figure 5: Example sequence of the Re-Authentication phase for a PaC- 1210 initiated session (using "Piggybacking EAP") 1212 Termination Phase: 1214 The PaC and PAA should not send a PANA-Termination-Request message 1215 except for explicitly terminating a PANA session within the lifetime. 1216 Both the PaC and PAA know their own PANA session lifetime expiration. 1217 This means the PaC and PAA should not send a PANA-Termination-Request 1218 message when the PANA session lifetime expired because of reducing 1219 message processing cost. 1221 5.4.1.3. PANA session state parameters 1223 All PANA implementations internally keep PANA session state 1224 information for each peer. At least, all minimal implementations 1225 need to keep PANA session state parameters below (in the second 1226 column storage sizes are given in bytes): 1228 +------------------+----------+-------------------------------------+ 1229 | State Parameter | Size | Comment | 1230 +------------------+----------+-------------------------------------+ 1231 | PANA Phase | 1 | Used for recording the current PANA | 1232 | Information | | phase. | 1233 | | | | 1234 | PANA Session | 4 | | 1235 | Identifier | | | 1236 | | | | 1237 | PaC's IP address | 6 or 18 | IP Address length (4 bytes for IPv4 | 1238 | and UDP port | | and 16 bytes for IPv6) plus 2 bytes | 1239 | number | | for UDP port number. | 1240 | | | | 1241 | PAA's IP address | 6 or 18 | IP Address length (4 bytes for IPv4 | 1242 | and UDP port | | and 16 bytes for IPv6) plus 2 bytes | 1243 | number | | for UDP port number. | 1244 | | | | 1245 | Outgoing message | 4 | Next outgoing request message | 1246 | sequence number | | sequence number. | 1247 | | | | 1248 | Incoming message | 4 | Next expected incoming request | 1249 | sequence number | | message sequence number. | 1250 | | | | 1251 | A copy of the | variable | Necessary to be able to retransmit | 1252 | last sent | | the message (unless it can be | 1253 | message payload | | reconstructed on the fly). | 1254 | | | | 1255 | Retransmission | 4 | | 1256 | interval | | | 1257 | | | | 1258 | PANA Session | 4 | | 1259 | lifetime | | | 1260 | | | | 1261 | PaC nonce | 20 | Generated by PaC and carried in the | 1262 | | | Nonce AVP. | 1263 | | | | 1264 | PAA nonce | 20 | Generated by PAA and carried in the | 1265 | | | Nonce AVP. | 1266 | | | | 1267 | EAP MSK | 4 | | 1268 | Identifier | | | 1269 | | | | 1270 | EAP MSK value | *) | Generated by EAP method and used | 1271 | | | for generating PANA_AUTH_KEY. | 1272 | | | | 1273 | PANA_AUTH_KEY | 20 | Necessary for PANA message | 1274 | | | protection. | 1275 | | | | 1276 | PANA PRF | 4 | Used for generating PANA_AUTH_KEY. | 1277 | algorithm number | | | 1278 | | | | 1279 | PANA Integrity | 4 | Necessary for PANA message | 1280 | algorithm number | | protection. | 1281 +------------------+----------+-------------------------------------+ 1283 *) (Storage size depends on the key derivation algorithm.) 1285 Note: EAP parameters except for MSK have not been listed here. These 1286 EAP parameters are not used by PANA and depend on what EAP method you 1287 choose. 1289 6. Wire-Visible Constraints 1291 o Checksum 1293 o MTU 1295 o Fragmentation and reassembly 1297 o Options -- implications of leaving some out 1299 o Simplified TCP optimized for LLNs 1301 o Out-of-order packets 1303 7. Wire-Invisible Constraints 1305 o Buffering 1307 o Memory management 1309 o Timers 1311 o Energy efficiency 1313 o API 1315 o Data structures 1317 o Table sizes (somewhat wire-visible) 1319 o Improved error handling due to resource overconsumption 1321 8. IANA Considerations 1323 This document makes no requirements on IANA. (This section to be 1324 removed by RFC editor.) 1326 9. Security Considerations 1328 (TBD.) 1330 10. Acknowledgements 1332 Much of the text of the introduction is taken from the charter of the 1333 LWIG working group and the invitation to the IAB workshop on 1334 Interconnecting Smart Objects with the Internet. Thanks to the 1335 numerous contributors. Angelo Castellani provided comments that led 1336 to improved text. 1338 10.1. Contributors 1340 The RFC guidelines no longer allow RFCs to be published with a large 1341 number of authors. As there are many authors that have contributed 1342 to the sections of this document, their names are listed in the 1343 individual section headings as well as alphabetically listed with 1344 their affiliations below. 1346 +-----------------+-----------------------------+ 1347 | Name | Affiliation | 1348 +-----------------+-----------------------------+ 1349 | Brinda M C | Indian Institute of Science | 1350 | | | 1351 | Carl Williams | MCSR Labs | 1352 | | | 1353 | Carsten Bormann | Universitaet Bremen TZI | 1354 | | | 1355 | Esko Dijk | Philips Research | 1356 | | | 1357 | Mitsuru Kanda | Toshiba | 1358 | | | 1359 | Olaf Bergmann | Universitaet Bremen TZI | 1360 | | | 1361 | ... | ... | 1362 +-----------------+-----------------------------+ 1364 11. References 1366 11.1. Normative References 1368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1369 Requirement Levels", BCP 14, RFC 2119, March 1997. 1371 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1372 "Transmission of IPv6 Packets over IEEE 802.15.4 1373 Networks", RFC 4944, September 2007. 1375 11.2. Informative References 1377 [I-D.arkko-core-sleepy-sensors] 1378 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 1379 Novo, "Implementing Tiny COAP Sensors", 1380 draft-arkko-core-sleepy-sensors-01 (work in progress), 1381 July 2011. 1383 [I-D.ietf-core-coap] 1384 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1385 "Constrained Application Protocol (CoAP)", 1386 draft-ietf-core-coap-08 (work in progress), October 2011. 1388 [I-D.kivinen-ipsecme-ikev2-minimal] 1389 Kivinen, T., "Minimal IKEv2", 1390 draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), 1391 February 2011. 1393 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1394 "Computing the Internet checksum", RFC 1071, 1395 September 1988. 1397 [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the 1398 Internet checksum", RFC 1141, January 1990. 1400 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 1401 Incremental Update", RFC 1624, May 1994. 1403 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1404 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1405 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1407 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1408 Levkowetz, "Extensible Authentication Protocol (EAP)", 1409 RFC 3748, June 2004. 1411 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1413 Yegin, "Protocol for Carrying Authentication for Network 1414 Access (PANA)", RFC 5191, May 2008. 1416 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 1417 Internet", ISBN 9780470747995, 2009. 1419 Author's Address 1421 Carsten Bormann (editor) 1422 Universitaet Bremen TZI 1423 Postfach 330440 1424 Bremen D-28359 1425 Germany 1427 Phone: +49-421-218-63921 1428 Fax: +49-421-218-7000 1429 Email: cabo@tzi.org