One document matched: draft-kivinen-802-15-ie-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category='std' ipr='trust200902'
     docName='draft-kivinen-802-15-ie-00.txt'>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc compact='yes' ?>
<?rfc strict='yes' ?>

<front>
  <title>IEEE 802.15.4 Information Element for IETF</title>
        
  <author initials='T.' surname='Kivinen' fullname='Tero Kivinen'>
    <organization>INSIDE Secure</organization>
    <address>
      <postal>
        <street>Eerikinkatu 28</street>
        <code>FI-00180</code>
        <city>HELSINKI</city>
        <country>FI</country>
      </postal>
      <email>kivinen@iki.fi</email>
    </address>
  </author>
  <author fullname="Pat Kinney" initials="P." surname="Kinney">
    <organization>Kinney Consulting LLC</organization>
    <address>
      <postal>
	<street/>
	<city/>
	<region/>
	<code/>
	<country/>
      </postal>
      <email>pat.kinney@kinneyconsultingllc.com</email>
    </address>
  </author>
  <date month='March' year='2016' />
  <area>Internet</area>
  <abstract>
    <t>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.</t>
  </abstract>
</front>

<middle>
  <section title='Introduction'>
    <t>The IEEE Std. 802.15.4-2015 <xref target="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.</t>

    <t>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.</t>

    <t>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.</t>

    <t>This document provides the information needed for the
    request.</t>

   </section>

   <section anchor="terminology" title="Terminology">

    <t>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 <xref
    target='RFC2119'/>.</t>
  </section>

  <section title="Users of the IETF IE" anchor="users">
    <t>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.</t>
  </section>

  <section title='IETF IE Subtype Format' anchor='ietf-ie'>

    <t>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.</t>

    <t>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.</t>

    <t>The format of the IETF IE is as follows:</t>
    
    <figure anchor="ietf-ie-figure" title="IETF IE Subtype Format" ><artwork><![CDATA[
                     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                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

    <t><list style="symbols">
      <t>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.</t>

      <t>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. </t>
    </list></t>

    <t>One IEEE 802.15.4 frame can contain multiple IETF IEs for same
    or different sub types.</t>
    
  </section>

  <section title="Request to allocate IETF IE">
    <t>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.</t>
  </section>

  <section title='Security Considerations'>

    <t>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.</t>

    <t>The IEEE Std. 802.15.4-2015 <xref target="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.</t>

  </section>
  
  <section title='IANA Considerations' anchor='iana'>

    <t>This document creates a new registry for IETF IE Sub-type IDs
    registry:</t>

    <figure><artwork><![CDATA[
Value     Sub-type ID
0         Reserved
1-200     Unassigned
201-255   Private Use
]]></artwork></figure>

  </section>

</middle>
<back>

  <references title="Normative References">
    &rfc2119;
  </references>

  <references title='Informative References'>
    <reference anchor='IEEE-802-15-4'>
      <front>
        <title>IEEE Standard for Low-Rate Wireless Personal Area
        Networks (WPANs)</title>
	<author></author>
        <date year='2015'/>
      </front>
      <seriesInfo name="IEEE" value="Standard 802.15.4" />
    </reference>
  </references>

</back>

</rfc>