Draft 1 Security change proposal

1
Project IEEE P802.15 Working Group for Wireless
Personal Area Networks (WPANs) Submission Title
Draft 2 group addressing text synopsis Date
Submitted 17 March, 2005 Source Robert
Cragie Company Jennic Ltd. Address Furnival
Street, Sheffield, S1 4QT, UK Voice44 114 281
4512, FAX [phone],
EMailrcc_at_jennic.com Re Response to the call
for proposal of IEEE 802.15.4b Abstract Discuss
ion for several potential enhancements for
current IEEE 802.15.4 MAC Purpose For the
discussion at IEEE 802.15.4b Study Group
Notice This document has been prepared to
assist the IEEE P802.15. 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 P802.15.
2
Draft 2 group addressing text synopsis

• Robert Cragie
• Jennic Limited

3
Introduction

• A synopsis of the text which will be in draft 2
  outlining the content of the sections with regard
  to group addressing
• Based on discussions between members of a
  subgroup consisting of
• Phil Beecher, CompXs
• Robert Cragie, Jennic
• Øyvind Janbu, Chipcon
• Joseph Soma Reddy, Figure 8 Wireless
• Zachary Smith, Ember
• Rene Struik, Certicom

4
Background

• Document 15-05-0169-00
• Draft 1 all section, figure and table references
  refer to Draft 1
• Document 15-05-0134-01 is a proposal for a change
  in auxiliary security header which would
  accommodate the proposals in this document
• Acceptance of this document as the basis for
  group addressing text does not imply that
  document 15-05-0134-01 will also be accepted
• Additional points follow

5
Group addressing only for data frames

• Beacon is implicitly broadcast and contains no
  destination address, so is not eligible for group
  addressing
• Ack contains no destination address, so is not
  eligible for group addressing
• Currently only two command frames which use
  broadcast
• Beacon request
• Coordinator realignment
• Both command frames need to be implicitly
  broadcast because of their nature
• If they need to be secured, explicit key
  identifier can be used
• The mechanism proposed must however not be
  restricted to data frames as it is conceivable
  that all frame types in future revisions may be
  eligible for group addressing

6
Addressing modes

• Use of group addressing bit redefines the meaning
  of the destination address
• Current proposal is to use destination address
  modes 2 and 3 for group addressing, i.e. this
  would allow 16-bit and 64-bit group identifiers
• Current proposal is to exclude the use of
  destination address modes 0 and 1 for group
  addressing
• Questionable whether a 64-bit group would ever be
  used due to excessive storage and frame
  occupation, however one case has been identified
  where a 64-bit address of a device originating a
  key is used as its identifier

7
LB28 comments

• There are a number of comments for LB28 referring
  to draft 1 group addressing text which need to be
  addressed
• Naturally the outcome of these comments will also
  affect the resulting text

8
Section 7.1 MAC sublayer service specification

• No need to consider current MLME primitives as
  group addressing applies to data frames only
• Currently supports all the parameters required
  for group addressing
• MCPS-DATA.request TxOptions parameter contains
  group addressing bit (change option to 0x10, not
  0x08)
• MCPS-DATA.indication contains GrpAddress
  parameter
• For security process, additional group sequence
  number can be passed through KeyIdAddress
  (KeyIdentifier) (see also 15-05-0134-01)
• May need to add address mode checking for
  MCPS-DATA.request

9
Section 7.2 MAC frame format

• Figure 35 already supports group addressing
• Section 7.2.1.1.6 already supports group
  addressing
• Table 66 will need revising for group addressing
  support
• Sections describing addressing modes will need
  revising for group addressing support
• Section 7.2.2.2.1 probably supports group
  addressing sufficiently

10
Section 7.2 MAC frame format (2)

• Need to ensure frame types other than data frame
  clearly show group addressing bit is set to 0
• Need to specify that data frames using group
  addressing shall not be acknowledged

11
Section 7.3 MAC command frames

• Draft 1 text supports group addressing in the
  sense that group addressing does not apply to
  command frames
• Need to ensure text is there which states that
  group addressing bit is set to zero

12
Section 7.4 MAC constants and PIB attributes

• Need to add definition of Destination Address
  Filter Table (DAFT) ?
• Format not decided but will be a lookup table
  with the same operation in essence as DeviceTable
  and KeyTable.
• The lookup operations of DeviceTable and KeyTable
  are comprehensively described in 7.5.8
• Could be simplified if address mode is restricted
  to mode 2 only, i.e. 16-bit only

13
Section 7.4 MAC constants and PIB attributes (2)

• DAFT needs to be optional
• Logical solution is to have a boolean PIB
  attribute, e.g. macDestFilterTableEnabled
• FALSE no destination address filtering is
  applied
• TRUE destination address filtering is applied
  according to section X.X
• Default FALSE
• Alternative 1 Default is to have zero entries,
  and that zero entries means no destination
  address filtering is applied, i.e. a wildcard
  and all data frames are passed for further
  processing

14
Section 7.4 MAC constants and PIB attributes (3)

• Alternative 2 Default is to have zero entries,
  and that zero entries means all group addressed
  frames are silently discarded.
• This would mean the mechanism to set up the DAFT
  would be done using unicast frames

15
Section 7.5.6.1 Transmission

• Will need revising to accommodate group addressing

16
Section 7.5.6.2 Reception and rejection

• Need to add text to clarify that if the group
  addressing bit is set, the (data) frame should be
  processed according to the section which
  describes using the destination address filter
  table
• This section is missing and needs to be added but
  doesnt necessarily fit into this section
• Suggest using the format used in 7.5.8 which
  although arguably terse, is precise and
  unambiguous

17
Section 7.5.6.4 Use of acknowledgements

• Need to specify that group addressed data frames
  are not acknowledged
• This may not be the section to do it in but it
  should be referenced here

18
Section 7.5.8 Frame security

• Section 7.5.8.3.2 and 7.5.8.3.4 need to include
  text to accommodate the implicit key lookup based
  on group address if group addressing is specified
• There will also be a single key sequence number
  accommodated in a single octet KeyIdAddress
  (KeyIdentifier) field which is used in addition
  to the group address for key lookup