1. 21-07-xxxx-00-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-08-0086-00-0000 Title: Addressing Comment #2142 Date Submitted: March, 18, 2008 Presented at IEEE 802.21 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 802.21 MIH protocol.

2. 21-07-xxxx-00-0000 IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 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 802.21. 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 http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 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 802.21. 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 http://standards.ieee.org/board/pat/faq.pdf> Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6 http://standards.ieee.org/board/pat/faq.pdf

3. 21-07-xxxx-00-0000 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 802.11 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 802.21 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 802.21 standard will be unusable.

4. 21-07-xxxx-00-0000 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 802.21 WG to engage in a dialogue with the security task group in 802.21. 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 802.1. ”

5. 21-07-xxxx-00-0000 Specific Deficiencies The primary functionality of 802.21 depends on three primary transport options for the MIH protocol 802.11 Management Frames 802.16 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 802.11 Management Frames 802.16 Management Frames IP

6. 21-07-xxxx-00-0000 Specific Deficiencies Interaction with 802.1 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 802.1 security protocols (802.1X with its incomplete revisions, 802.1AE and the unfinished 802.1af). Interaction between other 802 security protocols (802.11i, 802.16 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 {802.11 & 802.16} vs. the generic 802 MAC service. Use of the management frames of 802.11 and 802.16 required specific text in the 802.11 and 802.16 standards. Use of the generic MAC service can be defined in 802.21 However direct support of the MIH protocol in 802.1 security specifications need not be rules out.

7. 21-07-xxxx-00-0000 High Level Resolution Proposal

8. 21-07-xxxx-00-0000 Provide 802 Reference Model Section 5.5.3 MIHF reference model for IEEE 802.3 802.3 closely models the generic 802 MAC service (except for handling of priority bits). To call out 802.3 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. 802.5, 802.15, 802.17 and yet to be published standards. Update section 5.5.3 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 802.21, 802.11 or 802.16. This is not a significant change from the 802.3 case.

9. 21-07-xxxx-00-0000 Clarify SAPs in Generic MAC Service Section 5.6.2 Media dependent SAPs Contains both the media dependent SAPs and the LSAP over 802.3 case. The 802.2 LSAP over 802.3 case should be generalized to the generic 802 architecture case. The media dependent cases should come second. I.E. 5.6.2 Media Independent SAPs –MIH_NET_SAP –MIH_LINK_SAP with 802 MAC service 5.6.3 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

10. 21-07-xxxx-00-0000 Correct 5.72 “5.7.2 Transport Considerations For IEEE 802.11 and IEEE 802.16 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 802.16 using PKMv2 & negotiated cipher suite Before and RNG-REQ/RSP After RNG-REQ/RSP but before authentication After authentication. 802.11 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

11. 21-07-xxxx-00-0000 Define 802 Transport Add section 5.7.3 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 802.1 experts to identify right/wrong mechanisms) 3) Something else I haven’t thought of. Describe and/or Reference the other transports 802.11 802.16 IP Others?