1. 21-07-325-01-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-325-01-0000 Title: DT Update on MIH L3 transport Date Submitted: September, 2007 Presented at IEEE 802.21 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

2. 21-07-325-01-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-325-01-0000 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)

4. 21-07-325-01-0000 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

5. 21-07-325-01-0000 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

6. 21-07-325-01-0000 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

7. 21-07-325-01-0000 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

8. 21-07-325-01-0000 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 1 3 2 MoS 4

9. 21-07-325-01-0000 Transport – facts (source: Nada) IS message size: up to 64k ES/CS message size: 50-100 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

10. 21-07-325-01-0000 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.

11. 21-07-325-01-0000 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

12. 21-07-325-01-0000 END

13. 21-07-325-01-0000 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?