1. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
November 17, 2009
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Security and Efficiency Enhancements – Status Report]
Date Submitted: [November 17, 2009]
Source: [Rene Struik]
Company [Certicom Research]
Address [5520 Explorer Drive, Fourth Floor, Mississauga, ON, L4W 5L1, Canada]
Voice: [+1 (905) ], FAX: [+1 (905) ],
Re: [Security and Efficiency Enhancements for IEEE e ]
Abstract: [This document provides an overview of security and efficiency enhancements for e, based on the streamlined version of Clauses 7.2, , and 7.6 of IEEE ]
Purpose: [Security and efficiency enhancements of IEEE ]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
René Struik (Certicom Research)
<author>, <company>

2. doc.: IEEE 802.15-<doc#> René Struik (Certicom Research)
<month year>
doc.: IEEE <doc#>
November 17, 2009
Security and Efficiency Enhancements for IEEE e - Discussion Topics
René Struik (Certicom Research)
René Struik (Certicom Research)
<author>, <company>

3. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
November 17, 2009
Status Edits
Draft edits originally submitted in FrameMaker (August 15, 2009)
Edits currently converted into Word, as requested by Editor (Ludwig Winkel)
No available in Word, so “hand-conversions”
René Struik (Certicom Research)
<author>, <company>

4. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
November 17, 2009
ACK mechanism
Clause :
ACK sent after third level filtering, but prior to incoming security processing (since
ACKs not secured) e:
ACK sent after third level filtering and incoming security processing (no matter
whether secured or not)
Time delay for ACKs:
unsecured: keep as is
Secured: 1ms
Notes: This should allow sufficient time for incoming processing and securing ACK)
Clause incoming security processing for all frame types, including ACKs
René Struik (Certicom Research)
<author>, <company>

5. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
November 17, 2009
Security processing
Clause :
Incoming security frame processing does not treat devices with diplomatic immunity
(“Exempt status”) properly. e:
Incoming security frame processing does correct this error.
Cf. also 08/849r0.
Question for discussion:
There seem to be two options:
Address in Corrigendum to (after which e is Addendum);
Address via versioning (which would keep this an Addendum).
René Struik (Certicom Research)
<author>, <company>

6. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
November 17, 2009
Headers
Clause 7.2 :
Frame header includes some addressing fields
Frame header has 2-octet FCF field. e:
Frame header without addressing fields possible
Frame header may have 1-octet or 2-octet FCF field.
Ref: 09/233r4, 09/604r3, 09/701r1, 09/768r0
Topic for discussion:
Unify underlying objectives header reduction {4e, 4f}.
Keep functionality supported by ;
Allow as broad applicability of 1-octet FCF as possible;
Keep reserved frame types for future use;
Allow muting addressing fields {4f, ACK, low latency}
René Struik (Certicom Research)
<author>, <company>