idnits 2.17.1 draft-gomez-6lo-optimized-fragmentation-header-00.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 : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 23, 2016) is 2742 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6282' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'I-D.minaburo-lpwan-gap-analysis' is defined on line 349, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo Working Group C. Gomez 3 Internet-Draft J. Paradells 4 Intended status: Standards Track UPC/i2CAT 5 Expires: April 26, 2017 J. Crowcroft 6 University of Cambridge 7 October 23, 2016 9 Optimized 6LoWPAN Fragmentation Header 10 draft-gomez-6lo-optimized-fragmentation-header-00 12 Abstract 14 RFC 4944 specifies 6LoWPAN fragmentation, in order to support the 15 IPv6 MTU requirement over IEEE 802.15.4-2003 networks. The 6LoWPAN 16 fragmentation header format comprises a 4-byte format for the first 17 fragment, and a 5-byte format for subsequent fragments. This 18 specification defines a more efficient 3-byte, optimized 6LoWPAN 19 fragmentation header for all fragments. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 26, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Conventions used in this document . . . . . . . . . . . . 3 57 2. 6LoFH rules and format . . . . . . . . . . . . . . . . . . . 3 58 3. Changes from RFC 4944 fragmentation header and rationale . . 4 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Annex A. Quantitative performance comparison of RFC 4944 63 fragmentation header with 6LoFH . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) was 72 originally designed as an adaptation layer intended to enable IPv6 73 over IEEE 802.15.4- 2003 networks [RFC4944]. One of the 6LoWPAN 74 protocol suite components is fragmentation, which fulfills the IPv6 75 MTU requirement of 1280 bytes [RFC2460] over a radio interface with a 76 layer two (L2) payload size around 100 bytes (in the best case) and 77 without fragmentation support [RFC4944]. 79 RFC 4944 defines the 6LoWPAN fragmentation header format, which 80 comprises a 4-byte format for the first fragment, and a 5-byte format 81 for subsequent fragments. This specification defines a more 82 efficient 3-byte, optimized 6LoWPAN Fragmentation Header (6LoFH). 83 The benefits of using 6LoFH are the following: 85 -- Reduced overhead for transporting an IPv6 packet that requires 86 fragmentation (see Annex A). This decreases consumption of energy 87 and bandwidth, which are typically limited resources in the scenarios 88 where 6LoWPAN fragmentation is used. 90 -- Because the datagram offset can be expressed in increments of a 91 single octet, 6LoFH enables the transport of IPv6 packets over L2 92 data units with a maximum payload size as small as only 4 bytes in 93 the most extreme case. Note that RFC 4944 fragmentation can only be 94 used over L2 technologies with a maximum L2 payload size of at least 95 13 bytes. 97 In comparison with the 6LoWPAN fragmentation header, parsing of the 98 6loFH format is also simplified, as the format has a constant size, 99 and a 'symmetric' shape for both the first fragment and subsequent 100 fragments. However, receiver buffer management will involve greater 101 complexity as explained in Section 3. 103 1.1. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119] 109 2. 6LoFH rules and format 111 If an entire payload (e.g., IPv6) datagram fits within a single L2 112 data unit, it is unfragmented and a fragmentation header is not 113 needed. If the datagram does not fit within a single L2 data unit, 114 it SHALL be broken into fragments. The first fragment SHALL contain 115 the first fragment header as defined in Figure 1. 117 1 2 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 |1 1 0 0 1| datagram_size | datagram_tag | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 Figure 1: First Fragment 125 The second and subsequent fragments (up to and including the last) 126 SHALL contain a fragmentation header that conforms to the format 127 shown in Figure 2. 129 1 2 130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 |1 1 0 1 0| datagram_offset | datagram_tag | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Figure 2: Subsequent Fragments 137 datagram_size: This 11-bit field encodes the size of the entire IP 138 packet before link-layer fragmentation (but after IP layer 139 fragmentation). For IPv6, the datagram size SHALL be 40 octets (the 140 size of the uncompressed IPv6 header) more than the value of Payload 141 Length in the IPv6 header [RFC4944] of the packet. Note that this 142 packet may already be fragmented by hosts involved in the 143 communication, i.e., this field needs to encode a maximum length of 144 1280 octets (the required by IPv6). 146 datagram_tag: The value of datagram_tag (datagram tag) SHALL be the 147 same for all fragments of a payload (e.g., IPv6) datagram. The 148 sender SHALL increment datagram_tag for successive, fragmented 149 datagrams. The incremented value of datagram_tag SHALL wrap from 255 150 back to zero. This field is 8 bits long, and its initial value is 151 not defined. 153 datagram_offset: This field is present only in the second and 154 subsequent fragments and SHALL specify the offset, in increments of 1 155 octet, of the fragment from the beginning of the payload datagram. 156 The first octet of the datagram (e.g., the start of the IPv6 header) 157 has an offset of zero; the implicit value of datagram_offset in the 158 first fragment is zero. This field is 11 bits long. 160 The recipient of link fragments SHALL use (1) the sender's L2 source 161 address, (2) the destination's L2 address, (3) datagram_size, and (4) 162 datagram_tag to identify all the fragments that belong to a given 163 datagram. 165 Upon receipt of a link fragment, the recipient starts constructing 166 the original unfragmented packet whose size is datagram_size. It 167 uses the datagram_offset field to determine the location of the 168 individual fragments within the original unfragmented packet. For 169 example, it may place the data payload (except the encapsulation 170 header) within a payload datagram reassembly buffer at the location 171 specified by datagram_offset. The size of the reassembly buffer 172 SHALL be determined from datagram_size. 174 If a fragment recipient disassociates from its L2 network, the 175 recipient MUST discard all link fragments of all partially 176 reassembled payload datagrams, and fragment senders MUST discard all 177 not yet transmitted link fragments of all partially transmitted 178 payload (e.g., IPv6) datagrams. Similarly, when a node first 179 receives a fragment with a given datagram_tag, it starts a reassembly 180 timer. When this time expires, if the entire packet has not been 181 reassembled, the existing fragments MUST be discarded and the 182 reassembly state MUST be flushed. The reassembly timeout MUST be set 183 to a maximum of TBD seconds). 185 3. Changes from RFC 4944 fragmentation header and rationale 187 The main changes introduced in this specification to the 188 fragmentation header format defined in RFC 4944 are listed below, 189 together with their rationale: 191 -- The datagram size field is only included in the first fragment. 192 Rationale: In the RFC 4944 fragmentation header, the datagram size 193 was included in all fragments to ease the task of reassembly at the 194 receiver, since in an IEEE 802.15.4 mesh network, the fragment that 195 arrives earliest to a destination is not necessarily the first 196 fragment transmitted by the source. Nevertheless, the fragmentation 197 format defined in this document supports reordering, at the expense 198 of additional complexity in this regard. 200 -- The datagram tag size is reduced from 2 bytes to 1 byte. 201 Rationale: Given the low bit rate, as well as the relatively low 202 message rate in IEEE 802.15.4 scenarios, ambiguities due to datagram 203 tag wrapping events are unlikely despite the reduced tag space. 205 -- The datagram offset size is increased from 8 bits to 11 bits. 206 Rationale: This allows to express the datagram offset in single-octet 207 increments. 209 4. IANA Considerations 211 This document allocates the following sixteen RFC 4944 Dispatch type 212 values: 214 11001 000 216 through 218 11001 111 220 and 222 11010 000 224 through 226 11010 111 228 5. Security Considerations 230 6LoWPAN fragmentation attacks have been analyzed in the literature. 231 Countermeasures to these have been proposed as well [HHWH]. 233 A node can perform a buffer reservation attack by sending a first 234 fragment to a target. Then, the receiver will reserve buffer space 235 for the whole packet on the basis of the datagram size announced in 236 that first fragment. Other incoming fragmented packets will be 237 dropped while the reassembly buffer is occupied during the reassembly 238 timeout. Once that timeout expires, the attacker can repeat the same 239 procedure, and iterate, thus creating a denial of service attack. 240 The (low) cost to mount this attack is linear with the number of 241 buffers at the target node. However, the cost for an attacker can be 242 increased if individual fragments of multiple packets can be stored 243 in the reassembly buffer. To further increase the attack cost, the 244 reassembly buffer can be split into fragment-sized buffer slots. 245 Once a packet is complete, it is processed normally. If buffer 246 overload occurs, a receiver can discard packets based on the sender 247 behavior, which may help identify which fragments have been sent by 248 an attacker. 250 In another type of attack, the malicious node is required to have 251 overhearing capabilities. If an attacker can overhear a fragment, it 252 can send a spoofed duplicate (e.g. with random payload) to the 253 destination. A receiver cannot distinguish legitimate from spoofed 254 fragments. Therefore, the original IPv6 packet will be considered 255 corrupt and will be dropped. To protect resource-constrained nodes 256 from this attack, it has been proposed to establish a binding among 257 the fragments to be transmitted by a node, by applying content- 258 chaining to the different fragments, based on cryptographic hash 259 functionality. The aim of this technique is to allow a receiver to 260 identify illegitimate fragments. 262 Further attacks may involve sending overlapped fragments (i.e. 263 comprising some overlapping parts of the original datagram) or 264 announcing a datagram size in the first fragment that does not 265 reflect the actual amount of data carried by the fragments. 266 Implementers should make sure that correct operation is not affected 267 by such events. 269 6. Acknowledgments 271 In section 2, the authors have reused extensive parts of text 272 available in section 5.3 of RFC 4944, and would like to thank the 273 authors of RFC 4944. 275 The authors would like to thank Carsten Bormann, Tom Phinney, Ana 276 Minaburo and Laurent Toutain for valuable comments that helped 277 improve the document. 279 Carles Gomez has been funded in part by the Spanish Government 280 (Ministerio de Educacion, Cultura y Deporte) through the Jose 281 Castillejo grant CAS15/00336. Part of his contribution to this work 282 has been carried out during his stay as a visiting scholar at the 283 Computer Laboratory of the University of Cambridge. 285 7. Annex A. Quantitative performance comparison of RFC 4944 286 fragmentation header with 6LoFH 288 +-------------------------------------------------------+ 289 | IPv6 datagram size (bytes) | 290 +-------------+-------------+-------------+-------------+ 291 | 40 | 100 | 640 | 1280 | 292 +------------------+-------------+-------------+-------------+-------------+ 293 |L2 payload (bytes)| 4944 |6LoFH | 4944 |6LoFH | 4944 |6LoFH | 4944 |6LoFH | 294 +------------------+-------------+-------------+-------------+-------------+ 295 | 10 | ---- | 18 | ---- | 45 | ---- | 276 | ---- | 549 | 296 +------------------+-------------+------+------+------+------+-------------+ 297 | 20 | 19 | 9 | 59 | 18 | 394 | 114 | 794 | 228 | 298 +------------------+-------------+------+------+------+------+-------------+ 299 | 40 | 0 | 0 | 19 | 9 | 99 | 54 | 199 | 105 | 300 +------------------+-------------+------+------+------+------+-------------+ 301 | 60 | 0 | 0 | 9 | 6 | 69 | 36 | 134 | 69 | 302 +------------------+-------------+------+------+------+------+-------------+ 303 | 80 | 0 | 0 | 9 | 6 | 44 | 27 | 89 | 51 | 304 +------------------+-------------+------+------+------+------+-------------+ 305 | 100 | 0 | 0 | 0 | 0 | 39 | 21 | 74 | 42 | 306 +------------------+-------------+------+------+------+------+-------------+ 308 Figure 3: Adaptation layer fragmentation overhead (in bytes) required 309 to transport an IPv6 datagram 311 Note 1: while IEEE 802.15.4-2003 allows a maximum L2 payload size 312 between 81 and 102 bytes, a range of L2 payload size between 10 and 313 100 bytes is considered in the study to illustrate the performance of 314 6LoFH also for other potential L2 technologies with short payload 315 size and without fragmentation support. 317 Note 2: with the RFC 4944 fragmentation header it is not possible to 318 transport IPv6 datagrams of the considered sizes over a 10-byte 319 payload L2 technology. 321 8. References 323 8.1. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, 327 DOI 10.17487/RFC2119, March 1997, 328 . 330 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 331 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 332 December 1998, . 334 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 335 "Transmission of IPv6 Packets over IEEE 802.15.4 336 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 337 . 339 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 340 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 341 DOI 10.17487/RFC6282, September 2011, 342 . 344 8.2. Informative References 346 [HHWH] Hummen et al, R., "6LoWPAN fragmentation attacks and 347 mitigation mechanisms", 2013. 349 [I-D.minaburo-lpwan-gap-analysis] 350 Minaburo, A., Gomez, C., Toutain, L., Paradells, J., and 351 J. Crowcroft, "LPWAN Survey and GAP Analysis", draft- 352 minaburo-lpwan-gap-analysis-02 (work in progress), October 353 2016. 355 Authors' Addresses 357 Carles Gomez 358 UPC/i2CAT 359 C/Esteve Terradas, 7 360 Castelldefels 08860 361 Spain 363 Email: carlesgo@entel.upc.edu 365 Josep Paradells 366 UPC/i2CAT 367 C/Jordi Girona, 1-3 368 Barcelona 08034 369 Spain 371 Email: josep.paradells@entel.upc.edu 373 Jon Crowcroft 374 University of Cambridge 375 JJ Thomson Avenue 376 Cambridge, CB3 0FD 377 United Kingdom 379 Email: jon.crowcroft@cl.cam.ac.uk