May 2011 doc IEEE 802 15 11 0387

<May 2011> doc. : IEEE 802. 15 -11 -0387 -01 -0 hip Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: HIPIG Closing Report for May 2011 Date Submitted: May 10, 2011 Source: Robert Moskowitz, Verizon Address 1000 Bent Creek Blvd, Mechanics. Burg, PA, USA Voice: +1 (248) 968 -9809, e-mail: rgm@labs. htt-consult. com Re: Key Managementn over 4 e Multipurpose Frames Abstract: Closing report for HIPIG May 2001 session Purpose: To inform 802. 15 members on progress Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15. Submission 1 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0387 -01 -0 hip HIPIG Closing Report for May 2011 Robert Moskowitz Palm Springs May 10, 2011 Submission 2 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0387 -01 -0 hip Resolution 1 Work is on Key Management Protocol support for 802. 15 – For which it is preferred that the default is HIP DEX Study group SHOULD be named – – WPAN KMP SG And we are ready for a Study Group • Submission A draft PAR SHOULD be ready for July 3 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0387 -01 -0 hip Resolution 2 The Multipurpose Frame from 802. 15. 4 e provides the needed MAC framework for a KMP and basic MAC changes are not needed for KMP support by using it. – Submission KMP will be via a specific IE in a Multipurpose Frame exchange 4 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0387 -01 -0 hip Resolution 3 The KMP will assume the MTU is large enough for the KMP payloads. It will be up to the IE encapsulating component to manage 'fragmentation' through a 'frame chaining' process. – Submission The MAC has better knowledge of what size MTUs can successfully be transmitted at any given time. 5 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0387 -01 -0 hip Resolution 4 The KMP SHOULD be capable of determining and assigning the WPAN short addresses – – Submission For example the HIT's (Host Identity Tag) lower 16 bits so R 1 and on can be over short addresses Collision resolution WILL be included 6 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0387 -01 -0 hip Resolution 5 802. 15. 4 only defines single hop operations even though the concept of multi-hop is defined – Submission Any 802. 15 KMP recommended practice can only define a single hop KMP, as there is no MAC frame forwarding mechanism. End-to-end KMP for meshes MUST be defined elsewhere (e. g. IETF core or roll wg) 7 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0387 -01 -0 hip Resolution 5 a Multi-hop KMP can be specified via a liasoning process with the IETF – Submission We tell them how to use the KMP IE, they provide us with some parameter values 8 Robert Moskowitz,

<May 2011> doc. : IEEE 802. 15 -11 -0387 -01 -0 hip Conclusion A document will be prepared for the July Plenary session fleshing out these items to be used to for a KMP Study Group that will produce the KMP PAR Submission 9 Robert Moskowitz,