IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: DT Update on MIH L3 transport Date Submitted: September, 2007 Presented at IEEE session #NN in Hawaii Authors or Source(s): Gabor Bajko and the other DT members: Subir, Nada, JC, Sam, Tele Note: this presentation was not discussed with the other DT members

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

progress so far Agreed to separate Mobility Server (MoS) discovery and transport Mobility Server: a server hosting ES or CS or IS; or any combination of them There is one draft describing the scenarios, the discovery, the transport and the security (draft-melia-mipshop-mstp-solution-00.txt) Not published yet Current draft version zipped with this presentation One draft specifying the DHCP extensions needed for MoS discovery with DHCP (draft-bajko-mos-dhcp-options-00.txt) One draft specifying the DNS service tags needed for MoS discovery with DNS (draft-bajko-mos-dns-discovery-00.txt)

Scenarios - 1 MN at home and discovery of MoS in the home network Uses DNS SRV or NAPTR record to find a specific service (using a preferred transport protocol) Home Network Mo S MNMN

Scenarios -2- MN roaming and discovering MoS in visited network Use newly defined DHCP options for MoS discovery (there is a different DHCP option for each service, ie ES, CS and IS) If DHCP options are not supported, then the use of DNS should be attempted For DNS based discovery, the MN must first learn the name of the local network Either by using DHCP options 15 (for DHCPv4) or [draft-ietf-dhc-dhcpv6-opt-dnsdomain] for DHCPv6 Or use reverse DNS query (PTR query) –If there is a NAT, then first the external IP address on the NAT side must be found out »Either by using STUN, or »UPnP Network Access Authentication (with the home network) may or may not be required to be performed (does not make a difference from discovery point of view) Visited Network Mo S MNMN Home Network

Scenarios -3- MN roaming and discovering MoS in home network Very similar to MIP6 bootstrapping integrated scenario MN performs network access authentication with the home network, and the home AAA sends the MoS address to the NAS through the visitedAAA The MN uses DHCP options to learn the address of the MoS in the home network Requires DHCP and DHCP Relay extensions, not yet defined Intension to finalize this scenario in the next version of the draft Visited Network Mo S MN Home Network

Scenarios -4- MN either at home or in visited and discovering an MoS in a remote network The MN must know the name of the remote network Visited Network Mo S MN Home Network Remote Network

Scenarios -4- cont Step1: discover local MoS address using DHCP Step2: MIH IS query to find the fqdn of the remote network Step3: discover remote MoS using DNS Step4: contact remote MoS MNMN DHCP Server Mo S DNS MoS 4

Transport – facts (source: Nada) IS message size: up to 64k ES/CS message size: bytes (one udp/tcp segment) ES/CS rate: one every 100msec Retransmissions: TCP increases the retransmission timer exponentially after each retransmission of the same segment UDP does not retransmits, but MIH ACK may do it

Transport Assumption for the time being: either use UDP or TCP for transport Open issue: Should at least SCTP (and maybe DCCP?) considered? Current draft recommends the use of TCP for IS and UDP for ES/CS UDP has middlebox (NAT, FW, ALG) traversal issues, while TCP doesn’t If using UDP, then we would need to forget about power saving: middleboxes require keepalives every 30sec The DNS discovery draft allows for transport protocol discovery as well (using NAPTR records) There is one default UDP and TCP port request to IANA to each of the services (ES, CS, IS), ie. 6 default ports in total.

Security When TCP is used as transport, TLS should be used for message confidentiality and data integrity Does not talk about authentication, even anonymous TLS would be just fine for message confidentiality and data integrity purposes When UDP is used, DTLS is recommended The use of IPSec is also allowed

END

Gabor’s concern UDP is evil in a middlebox (NAT, FW) environment in what environment would ES, CS, IS be used? Middlebox free environment or not?