idnits 2.17.1 draft-kivinen-802-15-ie-02.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 (April 22, 2016) is 2924 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: October 24, 2016 Kinney Consulting LLC 6 April 22, 2016 8 IEEE 802.15.4 Information Element for IETF 9 draft-kivinen-802-15-ie-02.txt 11 Abstract 13 IEEE Std 802.15.4 has Information Elements (IE) that can be used to 14 extend the 802.15.4 in interoperable manner. 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 17 IETF and provides the information 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 October 24, 2016. 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 The IEEE Std. 802.15.4 [IEEE-802-15-4] has Information Elements (IE) 70 that can be used to extended the 802.15.4 in interoperable manner. 71 There are two different IE types, Header IE and Payload IE. The 72 Header IEs are part of the Medium Access Control (MAC) header, and 73 they are never encrypted, but they may be authenticated. Most of the 74 Header IE processing is done by the MAC, and IETF protocols should 75 not need to extend up with them. The Payload IEs are part of the MAC 76 payload and they may be encrypted and authenticated. 78 IETF protocols will need to include information in the 802.15.4 79 frames, and standard 802.15.4 way of doing that is to include payload 80 IE in the frame that will contain the information. Because of this 81 the IETF needs to obtain a dedicated Payload IE from IEEE 802.15 82 Assigned Numbers Authority (ANA) [IEEE-802-15-ANA]. The up to date 83 802.15 ANA database can be found in [IEEE-802-15-ANA-DB]. 85 The 802.15.4 operations manual [IEEE-802-15-OPS] provides information 86 on how a standardization organization may request an allocation of 87 the one IE to them. To make this request the standardization 88 organization needs to: provide the reason for the request; a 89 description of the protocol format that shows there is sufficient 90 subtype capability; a statement that the external organization 91 understands that only one ID number will be issued. 93 This document provides the information needed for the request. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Users of the IETF IE 103 There are several IETF working groups such as 6TiSCH, 6lo, CoRE etc, 104 which could benefit from the IETF IE. The 6TiSCH working group has 105 already expressed the need for the IE, and this allocation should 106 provide them a way forward. 108 4. IETF IE Subtype Format 110 The maximum length of the Payload IE content is 2047 octets, and 111 802.15.4 frame contains a list of payload IEs, i.e. a single frame 112 can have multiple payload IEs, terminated with the payload IE 113 terminator, and may be followed by the payload. 115 Because the frame contains a list of the payloads, there is no need 116 to provide internal structure inside the IETF IE. The Payload IE 117 format of the 802.15.4 contains the Length field, so the length of 118 the Sub-Type Content can be calculated from the Length field of the 119 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 for same or 143 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 Specifc Header IE for 149 Header IEs. There is one incorrectly named Vendor Specific Nested IE 150 for Payload IEs, and there is also another one with exactly same 151 name, but under the MLME Nested IE long format. All of the Vendor 152 Specific IEs have 3 octet vendor OUI in beginning to identify the 153 organization. 155 Because of this there is no need to reserve the specific Sub-Type IDs 156 for the vendor specific uses, as those other IE types can be used for 157 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 232 Pat Kinney 233 Kinney Consulting LLC 235 Email: pat.kinney@kinneyconsultingllc.com