idnits 2.17.1 draft-kivinen-802-15-ie-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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 7, 2016) is 2933 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 9, 2016 Kinney Consulting LLC 6 April 7, 2016 8 IEEE 802.15.4 Information Element for IETF 9 draft-kivinen-802-15-ie-01.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 9, 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. Request to allocate IETF IE . . . . . . . . . . . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 8.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 The IEEE Std. 802.15.4 [IEEE-802-15-4] has Information Elements (IE) 69 that can be used to extended the 802.15.4 in interoperable manner. 70 There are two different IE types, Header IE and Payload IE. The 71 Header IEs are part of the Medium Access Control (MAC) header, and 72 they are never encrypted, but they may be authenticated. Most of the 73 Header IE processing is done by the MAC, and IETF protocols should 74 not need to extend up with them. The Payload IEs are part of the MAC 75 payload and they may be encrypted and authenticated. 77 IETF protocols will need to include information in the 802.15.4 78 frames, and standard 802.15.4 way of doing that is to include payload 79 IE in the frame that will contain the information. Because of this 80 the IETF needs to obtain a dedicated Payload IE from IEEE 802.15 81 Assigned Numbers Authority (ANA) [IEEE-802-15-ANA]. The up to date 82 802.15 ANA database can be found in [IEEE-802-15-ANA-DB]. 84 The 802.15.4 operations manual [IEEE-802-15-OPS] provides information 85 on how a standardization organization may request an allocation of 86 the one IE to them. To make this request the standardization 87 organization needs to: provide the reason for the request; a 88 description of the protocol format that shows there is sufficient 89 subtype capability; a statement that the external organization 90 understands that only one ID number will be issued. 92 This document provides the information needed for the request. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. Users of the IETF IE 102 There are several IETF working groups such as 6TiSCH, 6lo, CoRE etc, 103 which could benefit from the IETF IE. The 6TiSCH working group has 104 already expressed the need for the IE, and this allocation should 105 provide them a way forward. 107 4. IETF IE Subtype Format 109 The maximum length of the Payload IE content is 2047 octets, and 110 802.15.4 frame contains a list of payload IEs, i.e. a single frame 111 can have multiple payload IEs, terminated with the payload IE 112 terminator, and may be followed by the payload. 114 Because the frame contains a list of the payloads, there is no need 115 to provide internal structure inside the IETF IE. The Payload IE 116 format of the 802.15.4 contains the Length field, so the length of 117 the Sub-Type Content can be calculated from the Length field of the 118 IETF IE. 120 The format of the IETF IE is as follows: 122 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Sub-Type ID | | 126 +-+-+-+-+-+-+-+-+ | 127 ~ Sub-Type Content ~ 128 | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Figure 1: IETF IE Subtype Format 133 o Sub-Type ID is the IANA allocated number specifying the sub-type 134 of the IETF IE. Value 0 is reserved for future extensibility, 135 i.e., in case a longer Sub-Type ID field is needed. 137 o Sub-Type Content is the actual content of the information element, 138 and its length can be calculated from the Length field of the IETF 139 IE. 141 One IEEE 802.15.4 frame can contain multiple IETF IEs for same or 142 different sub types. 144 5. Request to allocate IETF IE 146 IETF would request the 802.15.4 Working Group to allocate a Payload 147 IE for IETF use. Furthermore IETF understands that only one ID will 148 be issued to it. 150 6. Security Considerations 152 This document creates an IANA registry for IETF IE Sub-type IDs, and 153 the security of the protocols using the IEs needs to be described in 154 the actual documents allocating values from this registry. 156 The IEEE Std 802.15.4-2015 [IEEE-802-15-4] contains methods where 157 security of the IE can be enforced when a frame is received, but this 158 is only per IE type, thus all IETF IEs will have same security level 159 requirements regardless of the Sub-Type ID used. This can cause 160 issues if different security processing would be needed and any of 161 those IEs would need to be processed in the MAC level. Fortunately 162 everything IETF does should be in a higher level than the MAC level, 163 thus the higher layer processing for these IEs needs to perform 164 separate security policy checking based on the IETF IE Sub-Type ID in 165 addition to the checks done by the MAC. 167 7. IANA Considerations 169 This document creates a new registry for IETF IE Sub-type IDs 170 registry: 172 Value Sub-type ID 173 0 Reserved 174 1-200 Unassigned 175 201-255 Experimental Use 177 Changes and additions to this registry is by expert review. 179 8. References 181 8.1. Normative References 183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 184 Requirement Levels", BCP 14, RFC 2119, 185 DOI 10.17487/RFC2119, March 1997, 186 . 188 8.2. Informative References 190 [IEEE-802-15-4] 191 "IEEE Standard for Low-Rate Wireless Personal Area 192 Networks (WPANs)", IEEE Standard 802.15.4, 2015. 194 [IEEE-802-15-ANA] 195 "IEEE 802.15 Assigned Numbers Authority", 196 . 198 [IEEE-802-15-ANA-DB] 199 "IEEE 802.15 ANA database", 200 . 203 [IEEE-802-15-OPS] 204 "IEEE 802.15 Operations Manual", 205 . 208 Authors' Addresses 210 Tero Kivinen 211 INSIDE Secure 212 Eerikinkatu 28 213 HELSINKI FI-00180 214 FI 216 Email: kivinen@iki.fi 218 Pat Kinney 219 Kinney Consulting LLC 221 Email: pat.kinney@kinneyconsultingllc.com