Transcript 21-07-0325-01-0000_DT_update

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
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 stated
outlined
in in
Section
Section
6 of
6.3the
of
the IEEE-SA
IEEE-SA
Standards
Standards
Board
Board
bylaws
Operations Manual
<http://standards.ieee.org/guides/opman/sect6.html#6.3> and
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6>
and in
in
Understanding Patent Issues During IEEE Standards Development
http://standards.ieee.org/board/pat/guide.html>
http://standards.ieee.org/board/pat/faq.pdf>
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)
21-07-325-01-0000
Scenarios - 1
Home
Network
Mo
S
• 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)
M
N
21-07-325-01-0000
Scenarios -2Home
Network
Visited
Network
Mo
S
• 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
•
•
M
N
21-07-325-01-0000
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)
Scenarios -3Home
Network
Visited
Network
Mo
S
• 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
MN
• Requires DHCP and DHCP Relay
extensions, not yet defined
• Intension to finalize this scenario in
the next version of the draft
21-07-325-01-0000
Scenarios -4• MN either at home or in visited
and discovering an MoS in a
remote network
Home
Network
Remote
Network
Visited
Network
MN
21-07-325-01-0000
Mo
S
• The MN must know the name of
the remote network
Scenarios -4- cont
DHCP
Server
M
N
Mo
S
DNS
1
• Step1: discover local MoS
address using DHCP
• Step2: MIH IS query to
find the fqdn of the remote
network
2
3
4
21-07-325-01-0000
MoS
• Step3: discover remote
MoS using DNS
• Step4: contact remote MoS
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
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.
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
21-07-325-01-0000
END
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?
21-07-325-01-0000