| Network Working Group | T. Kivinen |
| Internet-Draft | INSIDE Secure |
| Intended status: Informational | P. Kinney |
| Expires: August 26, 2017 | Kinney Consulting LLC |
| February 22, 2017 |
IEEE 802.15.4 Information Element for IETF
draft-kivinen-802-15-ie-05.txt
IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements. This document formulates a request for ANA to allocate a number from that registry for IETF, and describes how the IE is formatted to provide subtypes.
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 August 26, 2017.
Copyright (c) 2017 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
IEEE Std 802.15.4 [IEEE-802-15-4] is a standard, referred to by RFC 4944 ([RFC4944]), et al, that enables very low-cost, low-power communications. The standard defines numerous optional physical layers (PHYs),operating in many different frequency bands with a simple and effective medium access control (MAC).
IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. An information element (IE) provides a flexible, extensible, and easily implementable method of encapsulating information. The general format of an IE as defined in 7.4 of IEEE Std 802.15.4-2015 [IEEE-802-15-4], consists of an identification (ID) field, a length field, and a content field. Multiple IEs may be concatenated, and elements with unknown ID values in a list of IEs can be skipped since their length is known. IEs provide a flexible container for information that allows for adding new IE definitions in future versions of the standard in a backwards-compatible manner.
There are two different IE types, Header IE and Payload IE. A Header IE is part of the Medium Access Control (MAC) header; it is never encrypted, but may be authenticated. Most of the Header IE processing is done by the MAC, and IETF protocols should not have any direct effect on that processing. A Payload IE is part of the MAC payload, and may be encrypted and authenticated.
IETF protocols will need to insert information in the 802.15.4 frames; the 802.15.4 enables that by including one or more payload IEs in the frame that will contain the information. For this purpose the IETF requests a dedicated Payload IE from the IEEE 802.15 Assigned Numbers Authority (ANA) [IEEE-802-15-ANA]. The current 802.15 ANA database can be found at [IEEE-802-15-ANA-DB].
The 802.15.4 operations manual [IEEE-802-15-OPS] describes how a standardization organization (SDO) may request an allocation of one IE. To make this request the SDO has to provide (i) the reason for the request, (ii) a description of the protocol format that shows an appropriate subtype capability, and (iii) an agreement that only one IE number will be allocated for use by the SDO.
This document provides the information needed for the request.
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].
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 is expected to satisfy that need.
The maximum length of the Payload IE content is 2047 octets, and 802.15.4 frame contains a list of payload IEs. A single frame can have multiple payload IEs, terminated with the payload IE terminator, which may then be followed by the payload.
Since the 802.15.4 standard defines a list of payload IEs along with their structures, there is no need for this document to specify the internal structure inside the IETF IE. The Payload IE format of IEEE 802.15.4 contains the Length field. The length of the subtype content can be calculated from the IEEE 802.15.4 Payload IE 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype ID | |
+-+-+-+-+-+-+-+-+ |
~ subtype content ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IETF IE Subtype Format
One IEEE 802.15.4 frame MAY contain multiple IETF IEs with the same or different subtypes.
The IETF requests that the 802.15 Working Group allocate an ID for a Payload IE for IETF use. Furthermore the IETF understands that only one ID will be issued to it.
This document creates an IANA registry for IETF IE subtype ID (see Section 7). The security of the protocols using the IEs MUST be described in the documents requesting allocations 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. Therefore, all IETF IEs will have same security level requirements regardless of the subtype 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. Since all IETF protocols should operate at a higher level than the MAC level, the higher layer processing for these IEs SHOULD perform separate security policy checking based on the IETF IE subtype ID in addition to the checks done by the MAC.
This document creates a new registry for IETF IE subtype IDs registry:
Value Subtype ID 0 Reserved 1-200 Unassigned 201-255 Experimental Use
Any change or addition to this registry requires expert review.
Note, that there is Vendor specific IEs already defined in the IEEE 802.15.4 (see Appendix A), and because of this, there is no need to reserve any subtype IDs for the vendor-specific uses.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [IEEE-802-15-4] | IEEE Standard for Low-Rate Wireless Personal Area Networks (WPANs)", IEEE Standard 802.15.4, 2015. | , "
| [IEEE-802-15-ANA] | IEEE 802.15 Assigned Numbers Authority" | , "
| [IEEE-802-15-ANA-DB] | IEEE 802.15 ANA database" | , "
| [IEEE-802-15-OPS] | IEEE 802.15 Operations Manual" | , "
| [RFC4944] | Montenegro, G., Kushalnagar, N., Hui, J. and D. Culler, Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007. |
IEEE 802.15.4 has already several numbers for different Vendor Specific IE types. There is one for the Vendor Specific Header IE for Header IEs. There is one incorrectly named Vendor Specific Nested IE for Payload IEs, and there is another one with exactly the same name, but under the MLME Nested IE long format. All of the Vendor Specific IEs start with a 3-octet vendor OUI to identify the organization.