1. Nov 2013 Robert Moskowitz, Verizon
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: KMP tg9 proposed document changes
Date Submitted: Nov 12, 2013
Source: Robert Moskowitz, Verizon
Address 1000 Bent Creek Blvd, MechanicsBurg, PA, USA
Voice:+1 (248) ,
Re: KMP TG9 Opening Report for November 2013 Session
Abstract: tg9 proposed document changes
Purpose: To focus activities during the meeting
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
Robert Moskowitz, Verizon

2. TG9 Proposed document changes
Nov 2013
TG9 Proposed document changes
Dallas, TX
November 12, 2013
Robert Moskowitz, Verizon

3. Address Format Current Proposed Nov 2013
Long addresses SHOULD be used when the KMP is performed to establish an SA. Short address MAY be used when the KMP updates an existing SA.
Proposed
The SA is associated with the long addresses. Thus long addresses SHOULD be transmitted when the KMP is performed to establish an SA. Short address MAY be transmitted when the KMP updates an existing SA.
Robert Moskowitz, Verizon

4. ACK is no proof of processing
Nov 2013
ACK is no proof of processing
Current
As Key Management payloads may exceed the MPDU, a simple frame chaining method using Forced ACKs will provide the needed fragmentation support. The use of the Forced ACKs allow the sending device to be assured the receiving device has all the frames to reassemble the Key Management payload. Sending lost frames is handled within the MAC and not apparent to the KMP transport. The receiving side MUST anticipate duplicate frames if its ACK was lost. This behavior is accommodated within state machines.
Robert Moskowitz, Verizon

5. ACK is no proof of processing
Nov 2013
ACK is no proof of processing
Additional text
If a fragment is lost, that is, the inbound state machine registers a skipped fragment, then the inbound processing fails; this is considered an acceptable behavior. A KMP SHOULD be able to handle a lost message, therefore no effort will be made to recover a loss fragment.
Robert Moskowitz, Verizon

6. Security Associations
Nov 2013
Security Associations
Additional text
Many types of security associations are possible as described in the Security-related MAC PIB attributes section in and An implementer of this recommended practice will select from the options allowed to request the KMP higher layer to establish the desired SA and provide the necessary keys to the MAC PIB.
Robert Moskowitz, Verizon

7. More on ACKs Current Proposed Nov 2013
a simple frame chaining method using Forced ACKs will provide the needed fragmentation support. The use of the Forced ACKs allow the sending device to be assured the receiving device has all the frames to reassemble
Proposed
a simple frame chaining method using the MAC Acknowledgment Frame will provide the needed fragmentation support. The use of the MAC Acknowledgment Frame allow the sending device to be assured the receiving device has received all the MAC frames.
Robert Moskowitz, Verizon

8. More on ACKs in Inbound Machine
Nov 2013
More on ACKs in Inbound Machine
Current
Firstly there MAY be duplicate frames if the ACK was lost and the packet was resent.
Proposed
Firstly there MAY be duplicate frames if the MAC Acknowledgment Frame was lost and the packet was resent.
Robert Moskowitz, Verizon

9. More on ACKs in Outbound Machine
Nov 2013
More on ACKs in Outbound Machine
Current
fragment accordingly and set transmission with Forced ACK.
Proposed
fragment accordingly and set transmission with the Acknowledgment Request (AR) field in the Frame Control to require a MAC Acknowledgment Frame.
Robert Moskowitz, Verizon

10. KMP rekey Current Proposed Nov 2013
The KMP rekey is triggered by the MacSecurityRekey PIB. If this is true then the KMP will be instructed to rekey the SA.
Proposed
An MLME SAP will monitor both the MacSecurityRekey and the MacFrameCounter. If the MacSecurityRekey is true, then the KMP will be instructed to rekey the SA. If the MacFrameCounter > 0xffffffff – n, the MacSecurityRekey is set to true and the KMP will be instructed to rekey the SA.
N is some value large enough such that the MacFrameCounter will not wrap by other uses during rekeying. A value of at least 1000 is recommended.
Robert Moskowitz, Verizon

11. MacSecurityRekey Replace text with Outstanding question Nov 2013
Used in the Rekey SAP to indicate when rekeying is required. May be set by an upper layer to force rekeying.
Is set to false after KMP successfully completes and after KMP successfully rekeys.
Outstanding question
What happens if rekey fails. It seems that you can get caught in a continuous rekey attempt loop.
Robert Moskowitz, Verizon

12. MacFrameCounter Added text Nov 2013
Set to 0 by KMP service after successfully setting keys.
Robert Moskowitz, Verizon

13. Information Element Shim
Nov 2013
System View
DATA higher layer
Other IE processes
KMP Service
Key Request
Key Request
Keys
Key and rekey Request
Data Traffic
Information Element Shim
Data MCPS
IE frames
MAC Services
PHY Services
Robert Moskowitz, Verizon

14. System View Add text after Figure Nov 2013
The only direct communication between the KMP Information Element Shim and the KMP Service is the KMP ID Value and KMP payload. Any other MAC information needed by the KMP Service should be obtained through existing MLME calls.
Robert Moskowitz, Verizon

15. MLME KMP-Data.request Add section Nov 2013
The KMP-Data.request primitive requests the transfer of a KMP payload to another device.
The semantics of this primitive are:
KMP-Data.request ( <question: are more fields need>
SrcExtAddr,
DstExtAddr,
KmpIdValue,
KmpLength,
KmpPayload )
Robert Moskowitz, Verizon

16. MLME KMP-Data.indication
Nov 2013
MLME KMP-Data.indication
Add section
The KMP-Data.indication primitive delivers a KMP payload from another device.
The semantics of this primitive are:
KMP-Data.indication ( <question: are more fields need>
SrcExtAddr,
DstExtAddr,
KmpIdValue,
KmpLength,
KmpPayload )
Robert Moskowitz, Verizon

17. More on MLME Do we need confirm calls? Nov 2013
Did the payload go out?
Did we receive the MAC Acknowledgment Frame?
Robert Moskowitz, Verizon