Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 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) 968-9809, e-mail: rgm@labs.htt-consult.com 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 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. Robert Moskowitz, Verizon

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

3. Robert Moskowitz, Verizon Address Format • Current 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.

4. Robert Moskowitz, Verizon 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.

5. Robert Moskowitz, Verizon 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.

6. Robert Moskowitz, Verizon Security Associations • Additional text Many types of security associations are possible as described in the Security-related MAC PIB attributes section in 802.15.4 and 802.15.7. 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.

7. Robert Moskowitz, Verizon More on ACKs • Current 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 all the frames to reassemble

8. Robert Moskowitz, Verizon 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.

9. Robert Moskowitz, Verizon 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.

10. Robert Moskowitz, Verizon KMP rekey • Current 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 MLNE 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.

11. Robert Moskowitz, Verizon MacSecurityRekey • Replace text with Used in the Rekey SAP to indicate when rekeying is required. May be set by an upper layer to force rekeying.

12. Robert Moskowitz, Verizon 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

13. Robert Moskowitz, Verizon System View • Add text after Figure 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.

14. Robert Moskowitz, Verizon MLME KMP-Data.send • Add section The KMP-Data.send primitive requests the transfer of a KMP payload to another device. The semantics of this primitive are: KMP-Data.send ( KMP ID Value, KMP Payload )

15. Robert Moskowitz, Verizon MLME KMP-Data.recv • Add section The KMP-Data.recv primitive delivers a KMP payload from another device. The semantics of this primitive are: KMP-Data.recv ( KMP ID Value, KMP Payload )