doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 1 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

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 2 TG9 Proposed document changes Dallas, TX November 12, 2013

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 3 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.

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 4 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.

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 5 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.

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 6 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.

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 7 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

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 8 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.

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 9 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.

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 10 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.

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 11 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.

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 12 System View PHY Services MAC Services Data MCPS Information Element Shim Other IE processes KMP Service DATA higher layer Key Request Keys Data Traffic IE frames Key and rekey Request Key Request

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 13 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.

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 14 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 )

doc.: IEEE tg9-proposed-document-changes Submission Nov 2013 Robert Moskowitz, VerizonSlide 15 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 )