[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 8137

Network Working Group                                         T. Kivinen
Internet-Draft                                             INSIDE Secure
Intended status: Informational                                 P. Kinney
Expires: September 2, 2017                         Kinney Consulting LLC
                                                           March 1, 2017


               IEEE 802.15.4 Information Element for IETF
                     draft-kivinen-802-15-ie-06.txt

Abstract

   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.

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 2, 2017.

Copyright Notice

   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



Kivinen & Kinney        Expires September 2, 2017               [Page 1]


Internet-Draft IEEE 802.15.4 Information Element for IETF     March 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Working Groups Benefiting from the IETF 802.15.4 IE . . . . .   3
   4.  IETF IE Subtype Format  . . . . . . . . . . . . . . . . . . .   3
   5.  Request to allocate IETF IE . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Vendor Specific IE in IEEE 802.15.4  . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   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



Kivinen & Kinney        Expires September 2, 2017               [Page 2]


Internet-Draft IEEE 802.15.4 Information Element for IETF     March 2017


   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.

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].

3.  Working Groups Benefiting from the IETF 802.15.4 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 is
   expected to satisfy that need.

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.  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:










Kivinen & Kinney        Expires September 2, 2017               [Page 3]


Internet-Draft IEEE 802.15.4 Information Element for IETF     March 2017


                        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

   o  Subtype ID is the IANA allocated number specifying the subtype of
      the IETF IE.  Value 0 is reserved for future extensibility, i.e.,
      in case a longer subtype ID field is needed.

   o  Subtype 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 MAY contain multiple IETF IEs with the same
   or different subtypes.

5.  Request to allocate IETF IE

   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.

6.  Security Considerations

   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.







Kivinen & Kinney        Expires September 2, 2017               [Page 4]


Internet-Draft IEEE 802.15.4 Information Element for IETF     March 2017


7.  IANA Considerations

   This document creates a new registry for IEEE Std 802.15.4 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.

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.

   [IEEE-802-15-ANA]
              "IEEE 802.15 Assigned Numbers Authority",
              <http://www.ieee802.org/15/ANA.html>.

   [IEEE-802-15-ANA-DB]
              "IEEE 802.15 ANA database",
              <https://mentor.ieee.org/802.15/
              documents?is_dcn=257&is_group=0000>.

   [IEEE-802-15-OPS]
              "IEEE 802.15 Operations Manual",
              <https://mentor.ieee.org/802.15/
              documents?is_dcn=235&is_group=0000>.







Kivinen & Kinney        Expires September 2, 2017               [Page 5]


Internet-Draft IEEE 802.15.4 Information Element for IETF     March 2017


   [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,
              <http://www.rfc-editor.org/info/rfc4944>.

Appendix A.  Vendor Specific IE in IEEE 802.15.4

   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.

Authors' Addresses

   Tero Kivinen
   INSIDE Secure
   Eerikinkatu 28
   HELSINKI  FI-00180
   FI

   Email: kivinen@iki.fi


   Pat Kinney
   Kinney Consulting LLC

   Email: pat.kinney@kinneyconsultingllc.com





















Kivinen & Kinney        Expires September 2, 2017               [Page 6]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/