IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-06-0348-05-0000 Title: MIIS and Its Higher Layer Transport Requirements Date Submitted: February 23, 2006 Authors or Source(s): IS Team Abstract: This document describes brief summary of IETF draft on MIIS and Its Higher Layer Transport requirements

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 <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> 

Outline of the Draft Introduction Information Service Reference Model Scenarios for IS Transport over IP Information Service Reference Model and Interfaces 3.1 Transport Layer Issues 3.2 Information Service Discovery Issues 3.3 Reliability Issues 3.4 Congestion Control Issues 3.5 Security Issues Requirements for Transport over IP Security Considerations

Information Service (IS) Reference Model (Section 2) IS-Server IS-Client R1/R3 Single hop Model IS-Proxy IS-Server IS-Client R4/R5 R1/R3 Multi hop Model

Use-Cases (Section 3) Case 1: IS-Server on the Access Point Case 2: IS-Server on the Access Router Case 3: IS-Server on the Core Network (Home) Case 4: IS-Server on the Core Network (Visited)

Case 1: IS-Server on Access Point IS-Client Access Point Access Router Host Core Network Access Router

Case 2: IS-Server on Access Router IS-Client Access Point Access Router Host IS-Server Core Network Access Router

Case 3: IS-Server on Core Network (Home) IS-Client IS-Server Access Point Access Router Host Core Network (Home) Access Point Access Router Visited Network (Core)

Case 4: IS-Server on Core Network (Visited) IS-Client Access Point Access Router Host Core Network (Home) IS-Server Access Router Access Point Core Network (Visited)

Requirements for Transport Over IP (Section 4) The IS transport MUST work both for IPv4 and IPv6 networks The choice of transport mechanism should work with both IPv4 and IPv6 networks. The IS protocol requires that security MUST be provided at the transport layer The MIIS message exchanges are critical to handover decision process. Therefore it has to be trusted. However, IS protocol framework does not add security at every message level. Thus it relies upon the underlying security. In such cases, the transport mechanism MUST support the necessary security. The IS transport MUST provide peer authentication The IS transport MUST provide message authentication and may provide confidentiality The IS transport MUST provide replay protection

Requirements for Transport Over IP (Section 4) The IS transport MUST support the NAT traversal The transport protocol should allow the communication between MIHFs if they are behind the NAT box. The IS transport MUST support the firewall traversal The transport protocol should allow the communication between MIHFs if they are behind the firewall. Changes to the header fields, IEs and structure messages should not affect the security mechanisms defined for underlying transmission. MIIS defines the IE and MIH protocol formats that are processed by only MIHF peer entities. Any changes to these formats and fields MUST not require modifying the underlying security mechanisms in future.