IEEE MEDIA INDEPENDENT HANDOVER

Slides:



Advertisements
Similar presentations
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: MIIS and Its Higher Layer Transport Requirements: Ad hoc Update and Discussion on.
Advertisements

IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Utilizing terminal identifier to recognize the reserved resources.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Analysis on Identifiers Date Submitted: January 9, 2006 Presented.
21-07-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx Title: Multiple MIH User Issues Date Submitted: November, 12-16, 2007.
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: MuGM
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: bcast
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx
IEEE MEDIA INDEPENDENT HANDOVER SERVICES
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE DCN: Title: TG Opening Note Date Submitted: Mar 09, 2015
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx
IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER SERVICES
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: REVP Title: m Session #70 Opening Notes Date Submitted: September 14, 2015 IEEE
IEEE MEDIA INDEPENDENT HANDOVER DCN: bcast
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: srho
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Group management in MIHF Date Submitted: November 4, 2011 Presented at IEEE session #47 in Atlanta.
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: sec
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Your Title Here
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
IEEE MEDIA INDEPENDENT HANDOVER
Presentation transcript:

IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-08-0095-00-0sec-mih-security Title: Media-Independent Handover Security Issues For Discussion Date Submitted: March 20, 2008 Presented at IEEE 802.21 session #25 in Orlando Authors or Source(s):  Subir Das (Telcordia Technologies), Marc Meylemans (Intel), Shubhranshu Singh (Samsung) Abstract: This document provides Media-Independent Handover Protocol security issues for discussion 21-08-0095-0sec

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 <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf>  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>  21-08-0095-0sec

What is MIH Protocol? Collection of all MIHF messages sent between peer MIHF entities Includes Events, Commands and Information services message exchange Messages are REQUEST, RESPONSE and INDICATION Common message payload across different media 802.3, 802.11, 802.16, and others… Media specific Transport Use Management plane when Data plane is not available E.g., Management Frames in State 1 for 802.11 Media Independent Transport Use IP whenever data plane is available E.g., In State 3 for 802.11 21-08-0095-0sec

Who is doing What? MIH Protocol (MAC independent messages) defined in 802.21 Container for MIH messages for 802.11 defined in 802.11u Container for MIH messages for 802.16 defined in 802.16g Transport for MIH Protocol defined in IETF (MIPSHOP) 21-08-0095-0sec

MIH Security IEEE 802.21 defines services that peer MIHF entities can use via the MIH protocol Peer MIHF entity address may be preconfigured or needs to be discovered Since MIH Services impact the mobility and its performance, it is essential that the message exchanges happen over a secure link For media specific transport, the security is provided by respective link layers Exception: management Frames in State 1 for 802.11, management frame in pre-attachment for 802.16 (?) For IP transport, IETF MIPSHOP WG recommends to use the transport security to protect MIH messages 21-08-0095-0sec

What is the Problem? The case where media specific transport is not secured For example, management frames in State 1 for 802.11 Nothing much we can do here… 802.11w even does not address this.. The case where security is not enabled or supported for IP transport Security for UDP or TCP is either not available or enabled Current Specification does not define an explicit indication mechanism to propagate the transport security information at the MIH layer Neither the MIH user nor MIHF peer entities have any knowledge that messages are transported over a secure channel Identities used at transport and MIH layers for establishing security associations may be different Transport can be split hop-by-hop and lose the info about the origination point 21-08-0095-0sec

Discussion Points Recommendations or guidelines for MIH security Current draft specification is addressing on this issue Address the issue on how to provide the information about transport security to the MIH layer Address the issue for unsecured higher layer transports Is this a valid scenario? MIPSHOP recommends to use only TCP and UDP For both cases transport security exists today and is recommended by MIPSHOP (e.g., TLS, DTLS, IPSec) 21-08-0095-0sec