Nov 2013 Robert Moskowitz, Verizon 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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