idnits 2.17.1 draft-kivinen-802-15-ie-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 : ---------------------------------------------------------------------------- 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 (March 16, 2016) is 2935 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: September 17, 2016 Kinney Consulting LLC 6 March 16, 2016 8 IEEE 802.15.4 Information Element for IETF 9 draft-kivinen-802-15-ie-00.txt 11 Abstract 13 IEEE Std. 802.15.4-2015 has Information Elements (IE) that can be 14 used to extend the 802.15.4 in interoperable manner. IEEE 802.15 15 Assigned Numbers Authority (ANA) manages the registry of the 16 Information Elements, and this document requests ANA to allocate a 17 number for IETF and provides the information how the IE is formatted 18 to provide 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 September 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . 4 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 The IEEE Std. 802.15.4-2015 [IEEE-802-15-4] has Information Elements 69 (IE) that can be used to extended the 802.15.4 in interoperable 70 manner. There are two different IE types, Header IE and Payload IE. 71 The Header IEs are part of the Medium Access Control (MAC) header, 72 and they are never encrypted, but they may be authenticated. Most of 73 the Header IE processing is done by the MAC, and IETF protocols 74 should not need to extend up with them. The Payload IEs are part of 75 the MAC 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. 82 The 802.15.4 operations manual provides information on how a 83 standardization organization may request an allocation of the one IE 84 to them. To make this request the standardization organization needs 85 to: provide the reason for the request; a description of the protocol 86 format that shows there is sufficient subtype capability; a statement 87 that the external organization understands that only one ID number 88 will be issued. 90 This document provides the information needed for the request. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Users of the IETF IE 100 There are several IETF working groups such as 6tisch, 6lo, core etc, 101 which could benefit from the IETF IE. The 6tisch working group has 102 already expressed the need for the IE, and this allocation should 103 provide them a way forward. 105 4. IETF IE Subtype Format 107 The maximum length of the Payload IE content is 2047 octets, and 108 802.15.4 frame contains a list of payload IEs, i.e. a single frame 109 can have multiple payload IEs, terminated with the payload IE 110 terminator, and may be followed by the payload. 112 Because the frame contains a list of the payloads, there is no need 113 to provide internal structure inside the IETF IE, and the Payload IE 114 format of the 802.15.4 contains the Length field. The length of the 115 Sub-Type Content can be calculated from the Length field of the IETF 116 IE. 118 The format of the IETF IE is as follows: 120 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Sub-Type ID | | 124 +-+-+-+-+-+-+-+-+ | 125 ~ Sub-Type Content ~ 126 | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Figure 1: IETF IE Subtype Format 131 o Sub-Type ID is the IANA allocated number specifying the sub-type 132 of the IETF IE. Value 0 is reserved for future extensibility, 133 i.e., in case a longer Sub-Type ID field is needed. 135 o Sub-Type Content is the actual content of the information element, 136 and its length can be calculated from the Length field of the IETF 137 IE. 139 One IEEE 802.15.4 frame can contain multiple IETF IEs for same or 140 different sub types. 142 5. Request to allocate IETF IE 144 IETF would request the 802.15.4 Working Group to allocate a Payload 145 IE for IETF use. Furthermore IETF understands that only one ID will 146 be issued to it. 148 6. Security Considerations 150 This document creates an IANA registry for IETF IE Sub-type IDs, and 151 the security of the protocols using the IEs needs to be described in 152 the actual documents allocating values from this registry. 154 The IEEE Std. 802.15.4-2015 [IEEE-802-15-4] contains methods where 155 security of the IE can be enforced when a frame is received, but this 156 is only per IE type, thus all IETF IEs will have same security level 157 requirements regardless of the Sub-Type ID used. This can cause 158 issues if different security processing would be needed and any of 159 those IEs would need to be processed in the MAC level. Fortunately 160 everything IETF does should be in a higher level than the MAC level, 161 thus the higher layer processing for these IEs needs to perform 162 separate security policy checking based on the IETF IE Sub-Type ID in 163 addition to the checks done by the MAC. 165 7. IANA Considerations 167 This document creates a new registry for IETF IE Sub-type IDs 168 registry: 170 Value Sub-type ID 171 0 Reserved 172 1-200 Unassigned 173 201-255 Private Use 175 8. References 177 8.1. Normative References 179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 180 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 181 RFC2119, March 1997, 182 . 184 8.2. Informative References 186 [IEEE-802-15-4] 187 "IEEE Standard for Low-Rate Wireless Personal Area 188 Networks (WPANs)", IEEE Standard 802.15.4, 2015. 190 Authors' Addresses 192 Tero Kivinen 193 INSIDE Secure 194 Eerikinkatu 28 195 HELSINKI FI-00180 196 FI 198 Email: kivinen@iki.fi 200 Pat Kinney 201 Kinney Consulting LLC 203 Email: pat.kinney@kinneyconsultingllc.com