21-07-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Addressing Comment #2142 Date Submitted: March, 18, 2008 Presented at IEEE session #NN in Orlando, Florida Authors or Source(s): David Johnston Abstract: This document outlines possible approaches to resolving comment #2142, principally through augmentation of the standard to clarify operation over and through generic 802 media that do not provide media specific transport options for the MIH protocol.

21-07-xxxx IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. 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. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. 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. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6

21-07-xxxx Comment #2142 In comment #650 on the initial ballot, I made the comment: "The draft pays lip service to security, yet a large part of the discussion within and ongoing as part of P802.1af is concerned with optimizing the number of exchanges involved and rapidly obtaining the necessary information to re- establish prior security associations/and or make use of previously distributed keys. The separation of handoff/handover/roaming/discovery concerns from those of security is unrealistic and calls into question issues that range from the architectural placement of the handoff function to the detailed design of messages and information elements. It is completely unclear how the functions and information provided by this draft would fit within the framework of the established 802.1X standard, the EAPOL protocol and its use of EAP, and the P802.1af amendment. Security of information transfer is required, but a major issue in handover/roaming/discovery in secured networks is determining the policy for making tentative decisions on unsecured information and confirming those decisions later.“The response to this was "The security sub- clause in section 5 has been deleted. All security related issues will be handled by the security Study Group in a future revision of the standard." I consider this response to be totally inadequate; without a clear statement in the standard of how it fits within the 802 architecture and with existing/developing security mechanisms such as 802.1X, 802.1AE, and P802.1af, I believe that the standard will be unusable.

21-07-xxxx Proposed Resolution from Commenter The standard must address the issue of how it fits within the 802 architecture and with existing/developing security mechanisms such as 802.1X, 802.1AE, and P802.1af. In order to achieve that, it will be necessary for the WG to engage in a dialogue with the security task group in The fact that this dialogue has not taken place, and yet the project is already at Sponsor ballot, is a major concern. Did the commenter mean “with the security task group in ”

21-07-xxxx Specific Deficiencies The primary functionality of depends on three primary transport options for the MIH protocol Management Frames Management Frames IP There is no description of the means by which MIH protocol messages are encapsulated and transported over any generic 802 media that supports the generic 802 MAC service. The list should be: 802 MAC service Management Frames Management Frames IP

21-07-xxxx Specific Deficiencies Interaction with security protocols is not explicitly defined. This is a consequence of: The lack of direct support for transport over the generic MAC service. The long term instability of security protocols (802.1X with its incomplete revisions, 802.1AE and the unfinished 802.1af). Interaction between other 802 security protocols (802.11i, PKMv2) is well defined The respective transport specifications for the MIH protocol offered in those media are sufficiently complete to determine the before/after authentication behavior of the MIH protocol over those media. The situation is different for { & } vs. the generic 802 MAC service. Use of the management frames of and required specific text in the and standards. Use of the generic MAC service can be defined in However direct support of the MIH protocol in security specifications need not be rules out.

21-07-xxxx High Level Resolution Proposal

21-07-xxxx Provide 802 Reference Model Section MIHF reference model for IEEE closely models the generic 802 MAC service (except for handling of priority bits). To call out specifically, unnecessarily excludes all the other media that closely model the generic 802 MAC service but do not describe media specific transport for the MIH protocol. E.G , , and yet to be published standards. Update section to be MIHF reference model for IEEE 802 MAC service. Write this in a way that will work for all 802 media, without requiring the deployment of media specific behaviors described elsewhere in , or This is not a significant change from the case.

21-07-xxxx Clarify SAPs in Generic MAC Service Section Media dependent SAPs Contains both the media dependent SAPs and the LSAP over case. The LSAP over case should be generalized to the generic 802 architecture case. The media dependent cases should come second. I.E Media Independent SAPs –MIH_NET_SAP –MIH_LINK_SAP with 802 MAC service Media Independent SAPs –All the rest. »MIH_LINK_SAP is a term for any of the media specific SAPs available. Show this hierarchical relationship Make I.2.1 apply to generic MAC service, not 802.3

21-07-xxxx Correct 5.72 “5.7.2 Transport Considerations For IEEE and IEEE networks, L2 transport in unassociated, unauthenticated state is provided by MAC management frames. For other networks, L2 transport is not available. In associated state with either authenticated or open access, L3 transport is available on all networks.” This section should be expanded to cover the cases: The generic MAC service without link security. The generic MAC service with 802.1X and/or 802.1AE,af Port open state Port closed state using PKMv2 & negotiated cipher suite Before and RNG-REQ/RSP After RNG-REQ/RSP but before authentication After authentication Before “open system” association Before not “open system” association (I.E. WEP needed) After not “open system” association (I.E. post WEP) After association, before 4 way handshake completion After 4 way handshake completion

21-07-xxxx Define 802 Transport Add section Transport Define transport over 802, one or more of: 1) Ethertype and encapsulation in 802 MAC service payload. 2) Some way of squeezing MIH payloads into LLDP or 802.1af messages (this needs input from experts to identify right/wrong mechanisms) 3) Something else I haven’t thought of. Describe and/or Reference the other transports IP Others?