idnits 2.17.1 draft-kivinen-802-15-ie-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 11, 2016) is 2754 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: Standards Track P. Kinney 5 Expires: April 14, 2017 Kinney Consulting LLC 6 October 11, 2016 8 IEEE 802.15.4 Information Element for IETF 9 draft-kivinen-802-15-ie-03.txt 11 Abstract 13 IEEE Std 802.15.4 has Information Elements (IE) that can be used to 14 extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned 15 Numbers Authority (ANA) manages the registry of the Information 16 Elements, and this document requests ANA to allocate a number for the 17 IETF, and provides information on how the IE is formatted to provide 18 sub types. 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 April 14, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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. Users of the IETF IE . . . . . . . . . . . . . . . . . . . . 3 57 4. IETF IE Subtype Format . . . . . . . . . . . . . . . . . . . 3 58 5. Vendor Specific IE . . . . . . . . . . . . . . . . . . . . . 4 59 6. Request to allocate IETF IE . . . . . . . . . . . . . . . . . 4 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 9.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 IEEE Std. 802.15.4 [IEEE-802-15-4] has Information Elements (IE) that 70 can be used to extend 802.15.4 in an interoperable manner. There are 71 two different IE types, Header IE and Payload IE. The Header IEs are 72 part of the Medium Access Control (MAC) header, and are never 73 encrypted, but they may be authenticated. Most of the Header IE 74 processing is done by the MAC, and IETF protocols should not need to 75 extend them. The Payload IEs are part of the MAC payload and they 76 may be encrypted and authenticated. 78 IETF protocols will need to include information in the 802.15.4 79 frames; the standard 802.15.4 way of doing this is to include one or 80 more payload IEs in the frame that will contain the information. 81 Because of this, the IETF needs to obtain a dedicated Payload IE from 82 the IEEE 802.15 Assigned Numbers Authority (ANA) [IEEE-802-15-ANA]. 83 The up-to-date 802.15 ANA database can be found at 84 [IEEE-802-15-ANA-DB]. 86 The 802.15.4 operations manual [IEEE-802-15-OPS] provides information 87 on how a standardization organization may request an allocation of an 88 IE. To make this request the standardization organization needs to: 89 provide the reason for the request; a description of the protocol 90 format that shows there is sufficient subtype capability; a statement 91 that the external organization understands that only one ID number 92 will be issued. 94 This document provides the information needed for the request. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Users of the IETF IE 104 There are several IETF working groups such as 6TiSCH, 6lo, CoRE etc, 105 which could benefit from the IETF IE. The 6TiSCH working group has 106 already expressed the need for the IE, and this allocation should 107 provide them a way forward. 109 4. IETF IE Subtype Format 111 The maximum length of the Payload IE content is 2047 octets, and 112 802.15.4 frame contains a list of payload IEs, i.e. a single frame 113 can have multiple payload IEs, terminated with the payload IE 114 terminator, and may be followed by the payload. 116 Because the frame contains a list of payloads, there is no need to 117 provide internal structure inside the IETF IE. The Payload IE format 118 of the 802.15.4 contains the Length field, so the length of the Sub- 119 Type Content can be calculated from the Length field of the IETF IE. 121 The format of the IETF IE is as follows: 123 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Sub-Type ID | | 127 +-+-+-+-+-+-+-+-+ | 128 ~ Sub-Type Content ~ 129 | | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Figure 1: IETF IE Subtype Format 134 o Sub-Type ID is the IANA allocated number specifying the sub-type 135 of the IETF IE. Value 0 is reserved for future extensibility, 136 i.e., in case a longer Sub-Type ID field is needed. 138 o Sub-Type Content is the actual content of the information element, 139 and its length can be calculated from the Length field of the IETF 140 IE. 142 One IEEE 802.15.4 frame can contain multiple IETF IEs with the same 143 or different sub types. 145 5. Vendor Specific IE 147 IEEE 802.15.4 has already several numbers for different Vendor 148 Specific IE types. There is one for the Vendor Specific Header IE 149 for Header IEs. There is one incorrectly named Vendor Specific 150 Nested IE for Payload IEs, and there is another one with exactly the 151 same name, but under the MLME Nested IE long format. All of the 152 Vendor Specific IEs start with a 3-octet vendor OUI to identify the 153 organization. 155 Because of this, there is no need to reserve the specific Sub-Type 156 IDs for the vendor-specific uses, as those other IE types can be used 157 for that. 159 6. Request to allocate IETF IE 161 IETF would request the 802.15.4 Working Group to allocate a Payload 162 IE for IETF use. Furthermore IETF understands that only one ID will 163 be issued to it. 165 7. Security Considerations 167 This document creates an IANA registry for IETF IE Sub-type IDs, and 168 the security of the protocols using the IEs needs to be described in 169 the actual documents allocating values from this registry. 171 The IEEE Std 802.15.4-2015 [IEEE-802-15-4] contains methods where 172 security of the IE can be enforced when a frame is received, but this 173 is only per IE type, thus all IETF IEs will have same security level 174 requirements regardless of the Sub-Type ID used. This can cause 175 issues if different security processing would be needed and any of 176 those IEs would need to be processed in the MAC level. Fortunately, 177 everything IETF does should be in a higher level than the MAC level, 178 thus the higher layer processing for these IEs needs to perform 179 separate security policy checking based on the IETF IE Sub-Type ID in 180 addition to the checks done by the MAC. 182 8. IANA Considerations 184 This document creates a new registry for IETF IE Sub-type IDs 185 registry: 187 Value Sub-type ID 188 0 Reserved 189 1-200 Unassigned 190 201-255 Experimental Use 192 Changes and additions to this registry is by expert review. 194 9. References 196 9.1. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, 200 DOI 10.17487/RFC2119, March 1997, 201 . 203 9.2. Informative References 205 [IEEE-802-15-4] 206 "IEEE Standard for Low-Rate Wireless Personal Area 207 Networks (WPANs)", IEEE Standard 802.15.4, 2015. 209 [IEEE-802-15-ANA] 210 "IEEE 802.15 Assigned Numbers Authority", 211 . 213 [IEEE-802-15-ANA-DB] 214 "IEEE 802.15 ANA database", 215 . 218 [IEEE-802-15-OPS] 219 "IEEE 802.15 Operations Manual", 220 . 223 Authors' Addresses 225 Tero Kivinen 226 INSIDE Secure 227 Eerikinkatu 28 228 HELSINKI FI-00180 229 FI 231 Email: kivinen@iki.fi 233 Pat Kinney 234 Kinney Consulting LLC 236 Email: pat.kinney@kinneyconsultingllc.com