IEEE 802.15.4 Information Element for IETF
The information below is for an old version of the document.
This is an older version of an Internet-Draft that was ultimately published as RFC 8137.
|Authors||Tero Kivinen , Pat Kinney|
OPSDIR Telechat review (of -04) by Scott Bradner Serious Issues
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Network Working Group T. Kivinen Internet-Draft INSIDE Secure Intended status: Standards Track P. Kinney Expires: September 17, 2016 Kinney Consulting LLC March 16, 2016 IEEE 802.15.4 Information Element for IETF draft-kivinen-802-15-ie-00.txt Abstract IEEE Std. 802.15.4-2015 has Information Elements (IE) that can be used to extend the 802.15.4 in interoperable manner. IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements, and this document requests ANA to allocate a number for IETF and provides the information how the IE is formatted to provide sub types. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 17, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Kivinen & Kinney Expires September 17, 2016 [Page 1] Internet-Draft IEEE 802.15.4 Information Element for IETF March 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Users of the IETF IE . . . . . . . . . . . . . . . . . . . . 3 4. IETF IE Subtype Format . . . . . . . . . . . . . . . . . . . 3 5. Request to allocate IETF IE . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The IEEE Std. 802.15.4-2015 [IEEE-802-15-4] has Information Elements (IE) that can be used to extended the 802.15.4 in interoperable manner. There are two different IE types, Header IE and Payload IE. The Header IEs are part of the Medium Access Control (MAC) header, and they are never encrypted, but they may be authenticated. Most of the Header IE processing is done by the MAC, and IETF protocols should not need to extend up with them. The Payload IEs are part of the MAC payload and they may be encrypted and authenticated. IETF protocols will need to include information in the 802.15.4 frames, and standard 802.15.4 way of doing that is to include payload IE in the frame that will contain the information. Because of this the IETF needs to obtain a dedicated Payload IE. The 802.15.4 operations manual provides information on how a standardization organization may request an allocation of the one IE to them. To make this request the standardization organization needs to: provide the reason for the request; a description of the protocol format that shows there is sufficient subtype capability; a statement that the external organization understands that only one ID number will be issued. This document provides the information needed for the request. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Kivinen & Kinney Expires September 17, 2016 [Page 2] Internet-Draft IEEE 802.15.4 Information Element for IETF March 2016 3. Users of the IETF IE There are several IETF working groups such as 6tisch, 6lo, core etc, which could benefit from the IETF IE. The 6tisch working group has already expressed the need for the IE, and this allocation should provide them a way forward. 4. IETF IE Subtype Format The maximum length of the Payload IE content is 2047 octets, and 802.15.4 frame contains a list of payload IEs, i.e. a single frame can have multiple payload IEs, terminated with the payload IE terminator, and may be followed by the payload. Because the frame contains a list of the payloads, there is no need to provide internal structure inside the IETF IE, and the Payload IE format of the 802.15.4 contains the Length field. The length of the Sub-Type Content can be calculated from the Length field of the IETF IE. The format of the IETF IE is as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type ID | | +-+-+-+-+-+-+-+-+ | ~ Sub-Type Content ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IETF IE Subtype Format o Sub-Type ID is the IANA allocated number specifying the sub-type of the IETF IE. Value 0 is reserved for future extensibility, i.e., in case a longer Sub-Type ID field is needed. o Sub-Type Content is the actual content of the information element, and its length can be calculated from the Length field of the IETF IE. One IEEE 802.15.4 frame can contain multiple IETF IEs for same or different sub types. Kivinen & Kinney Expires September 17, 2016 [Page 3] Internet-Draft IEEE 802.15.4 Information Element for IETF March 2016 5. Request to allocate IETF IE IETF would request the 802.15.4 Working Group to allocate a Payload IE for IETF use. Furthermore IETF understands that only one ID will be issued to it. 6. Security Considerations This document creates an IANA registry for IETF IE Sub-type IDs, and the security of the protocols using the IEs needs to be described in the actual documents allocating values from this registry. The IEEE Std. 802.15.4-2015 [IEEE-802-15-4] contains methods where security of the IE can be enforced when a frame is received, but this is only per IE type, thus all IETF IEs will have same security level requirements regardless of the Sub-Type ID used. This can cause issues if different security processing would be needed and any of those IEs would need to be processed in the MAC level. Fortunately everything IETF does should be in a higher level than the MAC level, thus the higher layer processing for these IEs needs to perform separate security policy checking based on the IETF IE Sub-Type ID in addition to the checks done by the MAC. 7. IANA Considerations This document creates a new registry for IETF IE Sub-type IDs registry: Value Sub-type ID 0 Reserved 1-200 Unassigned 201-255 Private Use 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. 8.2. Informative References [IEEE-802-15-4] "IEEE Standard for Low-Rate Wireless Personal Area Networks (WPANs)", IEEE Standard 802.15.4, 2015. Kivinen & Kinney Expires September 17, 2016 [Page 4] Internet-Draft IEEE 802.15.4 Information Element for IETF March 2016 Authors' Addresses Tero Kivinen INSIDE Secure Eerikinkatu 28 HELSINKI FI-00180 FI Email: email@example.com Pat Kinney Kinney Consulting LLC Email: firstname.lastname@example.org Kivinen & Kinney Expires September 17, 2016 [Page 5]