idnits 2.17.1 draft-kivinen-802-15-ie-06.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 -- The document date (March 1, 2017) is 2610 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Kivinen 3 Internet-Draft INSIDE Secure 4 Intended status: Informational P. Kinney 5 Expires: September 2, 2017 Kinney Consulting LLC 6 March 1, 2017 8 IEEE 802.15.4 Information Element for IETF 9 draft-kivinen-802-15-ie-06.txt 11 Abstract 13 IEEE Std 802.15.4 defines Information Elements (IEs) that can be used 14 to extend 802.15.4 in an interoperable manner. The IEEE 802.15 15 Assigned Numbers Authority (ANA) manages the registry of the 16 Information Elements. This document formulates a request for ANA to 17 allocate a number from that registry for IETF, and describes how the 18 IE is formatted to provide subtypes. 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 September 2, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Working Groups Benefiting from the IETF 802.15.4 IE . . . . . 3 57 4. IETF IE Subtype Format . . . . . . . . . . . . . . . . . . . 3 58 5. Request to allocate IETF IE . . . . . . . . . . . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 8.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Appendix A. Vendor Specific IE in IEEE 802.15.4 . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 IEEE Std 802.15.4 [IEEE-802-15-4] is a standard, referred to by RFC 70 4944 ([RFC4944]), et al, that enables very low-cost, low-power 71 communications. The standard defines numerous optional physical 72 layers (PHYs),operating in many different frequency bands with a 73 simple and effective medium access control (MAC). 75 IEEE Std 802.15.4 defines Information Elements (IEs) that can be used 76 to extend 802.15.4 in an interoperable manner. An information 77 element (IE) provides a flexible, extensible, and easily 78 implementable method of encapsulating information. The general 79 format of an IE as defined in 7.4 of IEEE Std 802.15.4-2015 80 [IEEE-802-15-4], consists of an identification (ID) field, a length 81 field, and a content field. Multiple IEs may be concatenated, and 82 elements with unknown ID values in a list of IEs can be skipped since 83 their length is known. IEs provide a flexible container for 84 information that allows for adding new IE definitions in future 85 versions of the standard in a backwards-compatible manner. 87 There are two different IE types, Header IE and Payload IE. A Header 88 IE is part of the Medium Access Control (MAC) header; it is never 89 encrypted, but may be authenticated. Most of the Header IE 90 processing is done by the MAC, and IETF protocols should not have any 91 direct effect on that processing. A Payload IE is part of the MAC 92 payload, and may be encrypted and authenticated. 94 IETF protocols will need to insert information in the 802.15.4 95 frames; the 802.15.4 enables that by including one or more payload 96 IEs in the frame that will contain the information. For this purpose 97 the IETF requests a dedicated Payload IE from the IEEE 802.15 98 Assigned Numbers Authority (ANA) [IEEE-802-15-ANA]. The current 99 802.15 ANA database can be found at [IEEE-802-15-ANA-DB]. 101 The 802.15.4 operations manual [IEEE-802-15-OPS] describes how a 102 standardization organization (SDO) may request an allocation of one 103 IE. To make this request the SDO has to provide (i) the reason for 104 the request, (ii) a description of the protocol format that shows an 105 appropriate subtype capability, and (iii) an agreement that only one 106 IE number will be allocated for use by the SDO. 108 This document provides the information needed for the request. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Working Groups Benefiting from the IETF 802.15.4 IE 118 There are several IETF working groups such as 6TiSCH, 6lo, CoRE, etc, 119 which could benefit from the IETF IE. The 6TiSCH working group has 120 already expressed the need for the IE, and this allocation is 121 expected to satisfy that need. 123 4. IETF IE Subtype Format 125 The maximum length of the Payload IE content is 2047 octets, and 126 802.15.4 frame contains a list of payload IEs. A single frame can 127 have multiple payload IEs, terminated with the payload IE terminator, 128 which may then be followed by the payload. 130 Since the 802.15.4 standard defines a list of payload IEs along with 131 their structures, there is no need for this document to specify the 132 internal structure inside the IETF IE. The Payload IE format of IEEE 133 802.15.4 contains the Length field. The length of the subtype 134 content can be calculated from the IEEE 802.15.4 Payload IE Length 135 field of the IETF IE. 137 The format of the IETF IE is as follows: 139 1 2 3 140 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Subtype ID | | 143 +-+-+-+-+-+-+-+-+ | 144 ~ subtype content ~ 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 1: IETF IE Subtype Format 150 o Subtype ID is the IANA allocated number specifying the subtype of 151 the IETF IE. Value 0 is reserved for future extensibility, i.e., 152 in case a longer subtype ID field is needed. 154 o Subtype content is the actual content of the information element, 155 and its length can be calculated from the Length field of the IETF 156 IE. 158 One IEEE 802.15.4 frame MAY contain multiple IETF IEs with the same 159 or different subtypes. 161 5. Request to allocate IETF IE 163 The IETF requests that the 802.15 Working Group allocate an ID for a 164 Payload IE for IETF use. Furthermore the IETF understands that only 165 one ID will be issued to it. 167 6. Security Considerations 169 This document creates an IANA registry for IETF IE subtype ID (see 170 Section 7). The security of the protocols using the IEs MUST be 171 described in the documents requesting allocations from this registry. 173 The IEEE Std 802.15.4-2015 [IEEE-802-15-4] contains methods where 174 security of the IE can be enforced when a frame is received, but this 175 is only per IE type. Therefore, all IETF IEs will have same security 176 level requirements regardless of the subtype ID used. This can cause 177 issues if different security processing would be needed and any of 178 those IEs would need to be processed in the MAC level. Since all 179 IETF protocols should operate at a higher level than the MAC level, 180 the higher layer processing for these IEs SHOULD perform separate 181 security policy checking based on the IETF IE subtype ID in addition 182 to the checks done by the MAC. 184 7. IANA Considerations 186 This document creates a new registry for IEEE Std 802.15.4 IETF IE 187 subtype IDs registry: 189 Value Subtype ID 190 0 Reserved 191 1-200 Unassigned 192 201-255 Experimental Use 194 Any change or addition to this registry requires expert review. 196 Note, that there is Vendor specific IEs already defined in the IEEE 197 802.15.4 (see Appendix A), and because of this, there is no need to 198 reserve any subtype IDs for the vendor-specific uses. 200 8. References 202 8.1. Normative References 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, 206 DOI 10.17487/RFC2119, March 1997, 207 . 209 8.2. Informative References 211 [IEEE-802-15-4] 212 "IEEE Standard for Low-Rate Wireless Personal Area 213 Networks (WPANs)", IEEE Standard 802.15.4, 2015. 215 [IEEE-802-15-ANA] 216 "IEEE 802.15 Assigned Numbers Authority", 217 . 219 [IEEE-802-15-ANA-DB] 220 "IEEE 802.15 ANA database", 221 . 224 [IEEE-802-15-OPS] 225 "IEEE 802.15 Operations Manual", 226 . 229 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 230 "Transmission of IPv6 Packets over IEEE 802.15.4 231 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 232 . 234 Appendix A. Vendor Specific IE in IEEE 802.15.4 236 IEEE 802.15.4 has already several numbers for different Vendor 237 Specific IE types. There is one for the Vendor Specific Header IE 238 for Header IEs. There is one incorrectly named Vendor Specific 239 Nested IE for Payload IEs, and there is another one with exactly the 240 same name, but under the MLME Nested IE long format. All of the 241 Vendor Specific IEs start with a 3-octet vendor OUI to identify the 242 organization. 244 Authors' Addresses 246 Tero Kivinen 247 INSIDE Secure 248 Eerikinkatu 28 249 HELSINKI FI-00180 250 FI 252 Email: kivinen@iki.fi 254 Pat Kinney 255 Kinney Consulting LLC 257 Email: pat.kinney@kinneyconsultingllc.com