RFC 5677
IEEE 802.21 Mobility Services Framework Design (MSFD)
RFC 5677: IEEE 802.21 Mobility Services Framework Design (MSFD) 🎀
okay bestie, this one is the IEEE 802.21 Mobility Services Framework Design, and it's a Standards Track doc, so it's an official Internet protocol spec 💅 It's from December 2009 and it's part of the Network Working Group. T. Melia (Ed.) from Alcatel-Lucent is the editor, and G. Bajko (Nokia), S. Das (Telcordia Technologies Inc.), N. Golmie (NIST), and JC. Zuniga (InterDigital Communications, LLC) are the other authors 🫶 The original doesn't say it obsoletes or updates any other RFC, so I'm not making that up for you ✨
Abstract ✨
okay so the abstract is giving "here's the whole vibe" 🦋 It describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol. The goal is to fix some known problems with how MIH messages get transported 🔥 It also covers how to discover Mobility Services (MoS) and transport-layer ways to make sure MIH messages get delivered reliably 💖
Here's the spicy part: this doc does not give you a way to secure the chat between a mobile node (MN) and the Mobility Server 💀 Instead it just assumes you're using either lower-layer security (like link-layer stuff) or some system-specific proprietary security solution 🙈
Status of This Memo 🌸
this section is the "what kind of doc is this" part, and it's an Internet standards track protocol for the Internet community. It's basically inviting everyone to talk about it and suggest improvements 🧚 If you want the official standardization state, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited, so share away 🍓
IESG Note 🔥
this is the important warning section, so read it carefully bestie 🙈
The IESG wants you to know that this protocol does not provide security mechanisms 💀 In some deployments, lower-layer security might be enough. Other situations need proprietary mechanisms or standard mechanisms that aren't finished yet, like the ones IEEE is currently looking at 🦋 Because of all that, the spec recommends careful analysis before considering any deployment 🌈
The IESG really emphasizes how important these recommendations are 💜 They also point out that this spec goes against the usual IETF rule that security support is a mandatory part of any Standards Track protocol 😭 They made an exception for this one, but that does not mean future specs get to skip that requirement 👑
Copyright Notice 🌈
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. ✨
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the day this doc was published. Please read these carefully, because they explain your rights and restrictions for this document 🫶 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the BSD License 💅
Table of Contents 🧚
1. Introduction ....................................................4
2. Terminology .....................................................4
2.1. Requirements Language ......................................7
3. Deployment Scenarios ............................................7
3.1. Scenario S1: Home Network MoS ..............................8
3.2. Scenario S2: Visited Network MoS ...........................8
3.3. Scenario S3: Third-Party MoS ...............................9
3.4. Scenario S4: Roaming MoS ...................................9
4. Solution Overview ..............................................10
4.1. Architecture ..............................................11
4.2. MIHF Identifiers (FQDN, NAI) ..............................12
5. MoS Discovery ..................................................12
5.1. MoS Discovery When MN and MoSh Are in the Home
Network (Scenario S1) .....................................13
5.2. MoS Discovery When MN and MoSv Both Are in Visited
Network (Scenario S2) .....................................14
5.3. MoS Discovery When MIH Services Are in a
Third-Party Remote Network (Scenario S3) ..................14
5.4. MoS Discovery When the MN Is in a Visited Network
and Services Are at the Home Network (Scenario S4) ........15
6. MIH Transport Options ..........................................15
6.1. MIH Message Size ..........................................16
6.2. MIH Message Rate ..........................................17
6.3. Retransmission ............................................17
6.4. NAT Traversal .............................................18
6.5. General Guidelines ........................................18
7. Operation Flows ................................................19
8. Security Considerations ........................................21
8.1. Security Considerations for MoS Discovery .................21
8.2. Security Considerations for MIH Transport .................21
9. IANA Considerations ............................................22
10. Acknowledgements ..............................................23
11. References ....................................................23
11.1. Normative References .....................................23
11.2. Informative References ...................................231. Introduction ✨
okay so this doc is a solution to the problems listed in the problem statement doc, [RFC5164] 🦋 The whole point is the layer 3 transport of IEEE 802.21 MIH protocols 🌸
The MIH Layer 3 transport problem is split into two big pieces 💅 First, you have to discover a node that supports specific Mobility Services (MoS). Second, you have to transport the info between a mobile node (MN) and the node you found 🫶 The discovery step is required so the MN can get what it needs to talk MIH with a peer node. That info includes the peer's transport address (like its IP address) and which MoS types that peer offers 💖
This doc lists the main MoS deployment scenarios 🧚 It describes the solution architecture, which includes the MSFD reference model and MIHF identifiers ✨ The MoS discovery procedures explain how the MN finds Mobility Servers in its home network, in a visited network, or in a third-party network 🎀 The rest of the doc covers the MIH transport architecture, example message flows for a bunch of signaling scenarios, and security issues 🔥
bestie, the security situation is the big catch here 😭
This doc does not provide mechanisms for securing the communication between a mobile node and the Mobility Server 💀 Instead, it assumes you're using either lower layer (like link layer) security mechanisms, or overall system-specific proprietary security solutions 🙈 The details of those lower layer and/or proprietary mechanisms are out of scope for this doc 🌈 It is RECOMMENDED against using this protocol without careful analysis that these mechanisms meet the desired requirements, and the doc encourages future standardization work in this area 👑 The IEEE 802.21a Task Group has recently started work on MIH security issues, which may give some solution in this area 💜 For more info, check Section 8 ✨
2. Terminology ✨
okay bestie, this is the glossary section and it's giving alphabet soup 🍜 but every acronym here has a job, so let's go through them 🎀
- Media Independent Handover (MIH): the handover support architecture from the IEEE 802.21 working group. It's made up of the MIH Function (MIHF), MIH Network Entities, and MIH protocol messages 🦋
- Media Independent Handover Function (MIHF): a switching function that hands out handover services, including the Event Service (ES), Information Service (IS), and Command Service (CS). You reach these through service access points (SAPs) defined by IEEE 802.21 [IEEE80221] 💅
- MIHF User: an entity that uses the MIH SAPs to reach MIHF services. It's the one in charge of starting and ending MIH signaling 🫶
- Media Independent Handover Function Identifier (MIHFID): an identifier that's required to uniquely identify MIHF endpoints when delivering mobility services (MoS). It's implemented as either a FQDN or a NAI 🔥
- Mobility Services (MoS): the combo of Information Service, Command Service, and Event Service that the network gives to mobile nodes to help with handover preparation and handover decision. See [IEEE80221] and [RFC5164] 👑
- MoSh: Mobility Services provided by the mobile node's Home Network 🏠
- MoSv: Mobility Services provided by the Visited Network ✈️
- MoS3: Mobility Services provided by a third-party network. That's a network that's neither the Home Network nor the current Visited Network 🧚
- Mobile Node (MN): an Internet device whose location changes, along with its point of connection to the network 🌸
- Mobility Services Transport Protocol (MSTP): the protocol that delivers MIH protocol messages from an MIHF to other MIH-aware nodes in a network 🚚
- Information Service (IS): a MoS that starts at the lower or upper layers of the protocol stack and sends information to the local or remote upper or lower layers. Its whole purpose is swapping information elements (IEs) about neighboring network info 📡
- Event Service (ES): a MoS that starts at a remote MIHF or the lower layers of the local protocol stack and sends info up to the local MIHF or local higher layers. It reports link status changes (like Link Going Down messages) and various lower layer events 🚨
- Command Service (CS): a MoS that sends commands from a remote MIHF or local upper layers down to the remote or local lower layers, either to switch links or to check link status 🎮
- Fully Qualified Domain Name (FQDN): a complete domain name for a host on the Internet. It shows the full delegation path, in reverse order, from the DNS root and top-level domain down to the host name (e.g., myexample.example.org) 🌐
- Network Access Identifier (NAI): the user ID a user submits during network access authentication [RFC4282]. For mobile users, the NAI identifies the user and helps route the authentication request message 🪪
- Network Address Translator (NAT): a device that does the Network Address Translation function described in [RFC3022]. It maps local or private network layer addresses to routable (outside the NAT domain) network addresses and port numbers 🔀
- Dynamic Host Configuration Protocol (DHCP): the protocols described in [RFC2131] and [RFC3315]. They let Internet devices grab IPv4 and IPv6 addresses, subnet masks, default gateway addresses, and other IP config info from DHCP servers 🎁
- Domain Name System (DNS): the protocol described in [RFC1035] that translates domain names into IP addresses 🗺️
- Authentication, Authorization, and Accounting (AAA): a set of network management services. They respectively figure out whether a user's ID is valid, whether a user is allowed to use network resources, and track how users use those resources 🕵️♀️
- Home AAA (AAAh): an AAA server located on the MN's home network 🏡
- Visited AAA (AAAv): an AAA server located in a visited network that isn't the MN's home network 🧳
- MIH Acknowledgement (MIH ACK): an MIH signaling message that an MIHF sends back in response to an MIH message from a sending MIHF 💌
- Point of Service (PoS): a network-side MIHF instance that swaps MIH messages with an MN-based MIHF 🤝
- Network Access Server (NAS): the server an MN first connects to when it's trying to get onto a network. It decides whether the MN is allowed to connect to that NAS's network 🚪
- User Datagram Protocol (UDP): a connectionless transport-layer protocol for sending datagrams between a source and a destination at a given port, defined in RFC 768 📦
- Transmission Control Protocol (TCP): a stream-oriented transport-layer protocol that gives you reliable delivery with congestion control, defined in RFC 793 🧵
- Round-Trip Time (RTT): an estimate of how long it takes a segment to travel from source to destination and for an acknowledgement to come back. TCP uses it, along with timer expirations, to decide when a segment is considered lost and should be resent ⏱️
- Maximum Transmission Unit (MTU): the biggest IP packet that can be sent on a network segment without needing fragmentation [RFC1191] 📏
- Path MTU (PMTU): the biggest IP packet that can be sent along an end-to-end network path without needing IP fragmentation 🛣️
- Transport Layer Security Protocol (TLS): an application layer protocol that mainly provides privacy and data integrity between two communicating network entities [RFC5246] 🔐
- Sender Maximum Segment Size (SMSS): the size of the largest segment the sender can transmit, as per [RFC5681] 📐
2.1. Requirements Language
okay so here's the rule for reading the requirement words in this doc 💅 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" get read the way RFC 2119 [RFC2119] describes. Those capital words are the ones with the official meaning, so pay attention to them 🫶
3. Deployment Scenarios 🗺️
this section is the tour of where the MN and the Mobility Server can live, and honestly it matters a lot 💖 Where they sit relative to each other changes how MoS discovery works and how well the MIH signaling service performs. This document covers the scenarios listed in [RFC5164] and specifies transport options for carrying the MIH protocol over IP 🚀
3.1. Scenario S1: Home Network MoS 🏠
in this one, the MN and the services are both in the home network. We call that set of services MoSh, as you can see in Figure 1 🌸 The MoSh can sit at the access network the MN uses to connect to the home network, or it can live somewhere else entirely 🧚
+--------------+ +====+
| HOME NETWORK | |MoSh|
+--------------+ +====+
/\
||
\/
+--------+
| MN |
+--------+
Figure 1: MoS in the Home Network3.2. Scenario S2: Visited Network MoS ✈️
here the MN is out in the visited network and the visited network is the one giving the mobility services. We call this MoSv, as shown in Figure 2 🦋
+--------------+
| HOME NETWORK |
+--------------+
/\
||
\/
+====+ +-----------------+
|MoSv| | VISITED NETWORK |
+====+ +-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 2: MoSv in the Visited Network3.3. Scenario S3: Third-Party MoS 🎀
in this scenario, the MN is either in its home network or in a visited network, and the services come from a third-party network. We call this MoS3, as shown in Figure 3 💜 (Quick side note: MoS can exist both in home and in visited networks 👑)
+--------------+
| HOME NETWORK |
+====+ +--------------+ +--------------+
|MoS3| | THIRD PARTY | <===> /\
+====+ +--------------+ ||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 3: MoS from a Third Party3.4. Scenario S4: Roaming MoS 🌍
in this one, the MN is hanging out in the visited network while all the MIH services come from the home network, as shown in Figure 4 ✨
+====+ +--------------+
|MoSh| | HOME NETWORK |
+====+ +--------------+
/\
||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 4: MoS Provided by the Home While in Visitedokay, here's the tea 🫖 Different types of MoS can be provided independently of each other, and there's no strict relationship between ES, CS, and IS. The entities giving those services don't have to be in the same place either 🙌 That said, IS tends to deal with a big pile of static info, while ES and CS are dynamic. So some relationship between them can be expected. For example, a handover command (CS) could get issued after a link event (ES) comes in 🔥 This document doesn't assume anything about where the MoS lives (there might be some preferred setups though 💅), and it aims for flexible MSFD so you can discover different services in different locations and make handover performance better 🚀 MoS discovery gets a deeper dive in Section 5 🧚
4. Solution Overview ✨
Okay bestie, remember how Section 1 split the solution space into two functional domains? 🦋 It's discovery and transport! Here are the assumptions the whole thing is built on:
- The solution is primarily aimed at supporting IEEE 802.21 MIH services -- namely, Information Service (IS), Event Service (ES), and Command Service (CS). 💖
- If the MIHFID is available, FQDN or NAI's realm is used for mobility service discovery. 🎀
- The solutions are chosen to cover all possible deployment scenarios as described in Section 3. 🌈
- MoS discovery can be performed during initial network attachment or at any time thereafter. ⏰
The MN may know the realm of the Mobility Server to be discovered. 🧚 The MN may also be pre-configured with the address of the Mobility Server to be used. In case the MN does not know what realm / Mobility Server to query, dynamic assignment methods are described in Section 5. 🫶
Discovering the Mobility Server (and the related configuration at MIHF level) is required to bind two MIHF peers (e.g., MN and Mobility Server) with their respective IP addresses. 🔗 Discovery MUST be executed in the following conditions:
- Bootstrapping: upon successful Layer 2 network attachment, the MN MAY be required to use DHCP for address configuration. These procedures can carry the required information for MoS configuration in specific DHCP options. 🍓
- If the MN does not receive MoS information during network attachment and the MN does not have a pre-configured Mobility Server, it MUST run a discovery procedure upon initial IP address configuration. 🔍
- If the MN changes its IP address (e.g., upon handover), it MUST refresh MIHF peer bindings (i.e., MIHF registration process). In case the Mobility Server used is not suitable anymore (e.g., too large RTT experienced), the MN MAY need to perform a new discovery procedure. 🔄
- If the MN is a multi-homed device and it communicates with the same Mobility Server via different IP addresses, it MAY run discovery procedures if one of the IP addresses changes. 💜
Once the MIHF peer has been discovered, MIH information can be exchanged between MIH peers over a transport protocol such as UDP or TCP. The usage of transport protocols is described in Section 6, and packing of the MIH messages does not require extra framing since the MIH protocol defined in [IEEE80221] already contains a length field. 📦
4.1. Architecture
Figure 5 depicts the MSFD reference model and its components within a node. 🗺️ The topmost layer is the MIHF user. This set of applications consists of one or more MIH clients that are responsible for operations such as generating query and response, processing Layer 2 triggers as part of the ES, and initiating and carrying out handover operations as part of the CS. Beneath the MIHF user is the MIHF itself. This function is responsible for MoS discovery, as well as creating, maintaining, modifying, and destroying MIH signaling associations with other MIHFs located in MIH peer nodes. Below the MIHF are various transport-layer protocols as well as address discovery functions. 🏗️
+--------------------------+
| MIHF User |
+--------------------------+
||
+--------------------------+
| MIHF |
+--------------------------+
|| || ||
|| +------+ +-----+
|| | DHCP | | DNS |
|| +------+ +-----+
|| || ||
+--------------------------+
| TCP/UDP |
+--------------------------+
Figure 5: MN StackThe MIHF relies on the services provided by TCP and UDP for transporting MIH messages, and relies on DHCP and DNS for peer discovery. 🤝 In cases where the peer MIHF IP address is not pre-configured, the source MIHF needs to discover it either via DHCP or DNS as described in Section 5. Once the peer MIHF is discovered, the MIHF must exchange messages with its peer over either UDP or TCP. Specific recommendations regarding the choice of transport protocols are provided in Section 6. 🚀
There are no security features currently defined as part of the MIH protocol level. 😬 However, security can be provided either at the transport or IP layer where it is necessary. Section 8 provides guidelines and recommendations for security. 🔐
4.2. MIHF Identifiers (FQDN, NAI)
MIHFID is required to uniquely identify the MIHF end points for delivering the mobility services (MoS). Thus an MIHF identifier needs to be unique within a domain where mobility services are provided and independent of the configured IP address(es). 🪪 An MIHFID MUST be represented either in the form of an FQDN [RFC2181] or NAI [RFC4282]. An MIHFID can be pre-configured or discovered through the discovery methods described in Section 5. ✨
5. MoS Discovery 🔎
The MoS discovery method depends on whether the MN attempts to discover a Mobility Server in the home network, in the visited network, or in a third-party remote network that is neither the home network nor the visited network. 🏠 In the case where the MN already has a Mobility Server address pre-configured, it is not necessary to run the discovery procedure. If the MN does not have pre-configured Mobility Server, the following procedure applies.
In the case where a Mobility Server is provided locally (scenarios S1 and S2), the discovery techniques described in [RFC5678] and [RFC5679] are both applicable as described in Sections 5.1 and 5.2. 🎯
In the case where a Mobility Server is located in the home network while the MN is in the visited network (scenario S4), the DNS-based discovery described in [RFC5679] is applicable. 🌍
In the case where a Mobility Server is located in a third-party network that is different from the current visited network (scenario S3), only the DNS-based discovery method described in [RFC5679] is applicable. 🧩
It should be noted that authorization of an MN to use a specific Mobility Server is neither in scope of this document nor is currently specified in [IEEE80221]. We further assume all devices can access discovered MoS. 🙈 In case future deployments will implement authorization policies, the mobile nodes should fall back to other learned MoS if authorization is denied. 🔁
5.1. MoS Discovery When MN and MoSh Are in the Home Network (Scenario S1)
To discover a Mobility Server in the home network, the MN SHOULD use the DNS-based MoS discovery method described in [RFC5679]. In order to use that mechanism, the MN MUST have its home domain pre-configured (i.e., subscription is tied to a network). The DNS query option is shown in Figure 6a. Alternatively, the MN MAY use the DHCP options for MoS discovery [RFC5678] as shown in Figure 6b (in some deployments, a DHCP relay may not be present). 🏡
(a) +-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
(b)
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
Figure 6: MOS Discovery (a) Using DNS Query, (b) Using DHCP Option5.2. MoS Discovery When MN and MoSv Both Are in Visited Network (Scenario S2)
To discover a Mobility Server in the visited network, the MN SHOULD attempt to use the DHCP options for MoS discovery [RFC5678] as shown in Figure 7. 🛫
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
Figure 7: MoS Discovery Using DHCP Options5.3. MoS Discovery When MIH Services Are in a Third-Party Remote Network (Scenario S3)
To discover a Mobility Server in a remote network other than home network, the MN MUST use the DNS-based MoS discovery method described in [RFC5679]. The MN MUST first learn the domain name of the network containing the MoS it is searching for. 🕵️♀️ The MN can query its current Mobility Server to find out the domain name of a specific network or the domain name of a network at a specific location (as in Figure 8a). IEEE 802.21 defines information elements such as OPERATOR ID and SERVICE PROVIDER ID that can be a domain name. An IS query can provide this information, see [IEEE80221].
Alternatively, the MN MAY query a Mobility Server previously known to learn the domain name of the desired network. Finally, the MN MUST use DNS-based discovery mechanisms to find a Mobility Server in the remote network as in Figure 8b. It should be noted that step b can only be performed upon obtaining the domain name of the remote network. 🧭
(a)
+------------+
+----+ | |
| | |Information |
| MN |-------->| Server |
| | |(previously |
+----+ |discovered) |
+------------+
(b)
+-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
Figure 8: MOS Discovery Using (a) IS Query to a Known IS Server,
(b) DNS Query5.4. MoS Discovery When the MN Is in a Visited Network and Services Are at the Home Network (Scenario S4)
To discover a Mobility Server in the visited network when MIH services are provided by the home network, the DNS-based discovery method described in [RFC5679] is applicable. To discover the Mobility Server at home while in a visited network using DNS, the MN SHOULD use the procedures described in Section 5.1. 🏃♀️💨
Part 3 wrapped! 🌈 Keep going, bestie. 💅
6. MIH Transport Options ✨
Okay bestie, once the MoS have been discovered, MIH peers run a capability discovery and subscription procedure as specified in [IEEE80221]. MIH peers MAY exchange information over TCP, UDP, or any other transport supported by both the server and the client. The client MAY use the DNS discovery mechanism to find out which transport protocols the server supports, on top of the TCP and UDP that this document recommends 💅. Both protocols can do the basic transport job, but they have different performance trade-offs and quirks that you need to think about for the MIH services under different network loss and congestion conditions 🌧️. This section talks through those trade-offs for different MIH settings, like the MIH message size and rate and the retransmission parameters. It also covers stuff like NAT traversal 🦋. Because the MIH transport has to be reliable, this discussion assumes that the MIH ACK mechanism gets used with UDP, while it MUST NOT be used with TCP, since TCP already includes acknowledgement and retransmission functionality 🫶.
6.1. MIH Message Size
Okay so MIH message sizes vary a LOT, from about 30 bytes (for a capability discovery request) up to around 65000 bytes (for an IS MIH_Get_Information response primitive) 😭. A typical MIH message size for the ES or CS ranges between 50 to 100 bytes [IEEE80221]. Considering how message size affects the transport protocol brings us to two main issues: fragmentation of long messages with UDP, and concatenation of short messages with TCP 🧩.
Since transporting long MIH messages may require fragmentation that UDP doesn't have, if MIH is using UDP, a limit MUST be set on the size of the MIH message based on the path MTU to the destination (or the Minimum MTU where PMTU is not implemented) 🎀. The Minimum MTU depends on the IP version being used for transmission. It's the lesser of the first hop MTU and 576 or 1280 bytes for IPv4 [RFC1122] or for IPv6 [RFC2460], respectively, although applications may reduce these values to guard against the presence of tunnels 🚇.
According to [IEEE80221], when an MIH message is sent using an L3 or higher-layer transport, L3 takes care of any fragmentation issues and the MIH protocol does not handle fragmentation in such cases. So MIH layer fragmentation MUST NOT be used together with IP layer fragmentation, and MUST not be used when MIH packets are carried over TCP 🙅♀️.
The loss of one IP fragment leads to retransmission of the entire MIH message, which means poor end-to-end delay performance plus wasted bandwidth 💀. Additional recommendations in [RFC5405] apply for limiting the size of the MIH message when using UDP and assuming IP layer fragmentation. On the short message side, TCP can concatenate very short messages to cut down the overall bandwidth overhead. The catch is that this saving costs extra delay to finish an MIH transaction, which may not be acceptable for CS and ES 🐢. Also, TCP is stream-oriented and measures data flow in bytes, not messages, so messages can get split across multiple TCP segments if they're long enough. Even short messages can be split across two segments 🌊. That can cause unacceptable delays too, especially when link quality is badly degraded, which is likely to happen when the MN is leaving a wireless access coverage area 📉. The use of the TCP_NODELAY option can help with this by triggering transmission of a segment smaller than the SMSS. (It should be noted that [RFC4960] addresses both of these problems, but discussion of SCTP is omitted here, as it is generally not used for the mobility services discussed in this document 💜.)
6.2. MIH Message Rate
The frequency of MIH messages depends on the MIH service type. CS and ES messages are expected to arrive about one every hundreds of milliseconds, so the environment changes get captured quickly and handover commands can be processed in time ⏱️. IS messages, on the other hand, are exchanged mainly every time a new network is visited, which could be on the order of hours or days 🗓️. So a burst of either short CS/ES messages or long IS message exchanges (say, when multiple MIH nodes request information) may lead to network congestion 🚨. TCP's built-in rate-limiting controls may be well suited for these congestion conditions, but they can cause large transmission delays that may be unacceptable for the timely delivery of ES or CS messages 😬. If UDP is used instead, a rate-limiting effect similar to the one TCP gives SHOULD be obtained by adequately adjusting the parameters of a token bucket regulator, as defined in the MIH specifications [IEEE80221]. Here are the recommendations for token bucket parameter settings:
- If the MIHF knows the RTT (e.g., based on the request/response MIH protocol exchange between two MIH peers), the rate can be based upon this, as specified in [IEEE80221].
- If not, then on average it SHOULD NOT send more than one UDP message every 3 seconds.
6.3. Retransmission
For TCP, the retransmission timeout gets adjusted according to the measured RTT. However, because of the exponential backoff mechanism, the delay associated with retransmission timeouts may increase significantly as packet loss goes up 📈.
If UDP is being used to carry MIH messages, MIH MUST use MIH ACKs 🎀. An MIH message is retransmitted if its corresponding MIH ACK isn't received by the generating node within a timeout interval set by the MIHF. The maximum number of retransmissions is configurable, and the value of the retransmission timer is computed according to the algorithm defined in [RFC2988]. The default maximum number of retransmissions is set to 2, and the initial retransmission timer (TMO) is set to 3s when the RTT is not known. The maximum TMO is set to 30s ⏰.
6.4. NAT Traversal
There are no known issues for NAT traversal when using TCP 🙌. The default connection timeout of 2 hours 4 minutes [RFC5382] (assuming a 2-hour TCP keep-alive) is considered adequate for MIH transport purposes ✨.
Issues with NAT traversal using UDP, though, are documented in [RFC5405]. Communication failures happen when middleboxes destroy the per-flow state associated with an application session during periods when the application isn't exchanging any UDP traffic 🫠. So communication between the MN and the Mobility Server SHOULD be able to gracefully handle such failures and implement mechanisms to re-establish their UDP sessions. To avoid these failures in the first place, MIH messages MAY be sent periodically, similar to keep-alive messages, to try to refresh middlebox state 🔄. Since [RFC4787] requires a minimum state timeout of 2 minutes or more, MIH messages using UDP as transport SHOULD be sent once every 2 minutes ⏳. Re-registration or event indication messages as defined in [IEEE80221] MAY be used for this purpose 🧚.
6.5. General Guidelines
The ES and CS messages are small and have tight latency requirements 🏃♀️. IS messages, on the other hand, are way more resilient when it comes to latency, and some long IS messages could exceed the MTU of the path to the destination. TCP SHOULD be used as the default transport for all messages 💖. However, UDP combined with MIH acknowledgement SHOULD be used for transporting ES and CS messages that are shorter than or equal to the path MTU, as described in Section 6.1 🌸.
For both UDP and TCP cases, if a port number isn't explicitly assigned (e.g., by the DNS SRV), MIH messages sent over UDP, TCP, or another supported transport MUST use the default port number defined in Section 9 for that particular transport 🔢.
A Mobility Server MUST support both UDP and TCP for MIH transport, and the MN MUST support TCP 👑. Additionally, the server and MN MAY support additional transport mechanisms. The MN MAY use the procedures defined in [RFC5679] to discover additional transport protocols supported by the server (e.g., SCTP) 🌈.
7. Operation Flows ✨
Okay bestie, let's walk through a full operation flow 🦋 Figure 9 shows what happens when an MIH user asks for an IS, and both the MN and the Mobility Server live in the MN's home network 🏠 DHCP handles Mobility Services (MoS) discovery, and TCP sets up the transport connection that carries the IS messages 💌 If the Mobility Server isn't pre-configured, the MIH user needs to find its IP address before it can talk to the remote MIHF. So the MIH user sends a discovery request message to the local MIHF, as defined in [IEEE80221] 🔍
In this example, we assume MoS discovery happens before the transport connection with the remote MIHF is set up, and the DHCP client process gets kicked off through some internal APIs 🧚 (You could draw up similar mechanisms with DHCPv6, too.) The DHCP client sends a DHCP INFORM message following standard DHCP, with the MoS option defined in [RFC5678] 📨 The DHCP server replies with a DHCP ACK message that carries the IP address of the Mobility Server 🎀 The address then gets handed to the MIHF locally through some internal APIs. The MIHF builds the discovery response and passes it along to the MIH user 💅
Next, the MIH user writes an IS query addressed to the remote Mobility Server 📝 The MIHF invokes the underlying TCP client, which sets up a transport connection with the remote peer 🔗 Once that connection is up, the MIHF sends the IS query in an MIH protocol REQUEST message 🚀 The message and the query reach the destination MIHF and MIH user, respectively 🌸 The Mobility Server's MIH user answers the IS query, and the Mobility Server's MIHF sends the IS response back in an MIH protocol RESPONSE message 💜 The response lands at the source MIHF, which passes the IS response to the corresponding MIH user 🫶
MN MoS
|===================================| |======| |===================|
+ ---------+ +---------+
| MIH USER | +------+ +------+ +------+ +------+ | MIH USER|
| +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+|
| | MIHF | | |Client| |Client| |Server| |Server| | | MIHF ||
+----------+ +------+ +------+ +------+ +------++----------+
| | | | | |
MIH Discovery | | | | |
Request | | | | |
| | | | | |
|Invoke DHCP Client | | | |
|(Internal process with MoS)|DHCP INFORM| | |
|==========================>|==========>| | |
| | | | | |
| Inform Mobility Server | DHCP ACK | | |
| Address |<==========| | |
|<==========================| | | |
| (internal process) | | | |
| | | | | |
MIH Discovery | | | | |
Response | | | | |
| | | | | |
IS Query | | | | |
MIH User-> MIHF | | | | |
| | | | | |
|Invoke TCP Client| | | | |
|================>| TCP connection established | |
Internal process |<=============================>| |
| | | | | |
| IS QUERY REQUEST (via MIH protocol) |
|===========================================================>|
| | | | | IS QUERY|
| | | | | REQUEST|
| | | | MIHF-> MIH User |
| | | | | QUERY|
| | | | | RESPONSE|
| | | | MIHF <-MIH User |
| | | | | |
| | IS QUERY RESPONSE (via MIH protocol) |
|<===========================================================|
| | | | | |
IS RESPONSE | | | | |
MIH User <-MIHF | | | | |
| | | | | |Figure 9: Example Flow of Operation Involving MIH User
8. Security Considerations 🔐
Security has two parts: MoS discovery and MIH transport 🛡️ For MoS discovery, we give DHCP and DNS recommendations, following IETF guidelines. For MIH transport, we describe the security threats and expect the system deployment to have ways of mitigating them when sensitive information gets exchanged between the mobile node and the Mobility Server 😭 IEEE 802.21's base specification doesn't provide MIH protocol level security, so it's assumed that either lower layer security (for example, link layer) or overall system-specific (for example, proprietary) security solutions are available. This document doesn't give any guidelines on that front 🙈 It's worth knowing that the IEEE 802.21a Task Group has recently started work on MIH security issues, which may bring some solutions in this area ✨ Finally, authorizing an MN to use a specific Mobility Server, as stated in Section 5, is neither in scope for this document nor currently specified in [IEEE80221] 💀
8.1. Security Considerations for MoS Discovery
Node discovery comes with a bunch of security issues to keep in mind 👀 When DHCP is used for node discovery, and you need to authenticate the source and content of DHCP messages, network administrators SHOULD use the DHCP authentication option described in [RFC3118], where available, or rely upon link layer security 🔒 [RFC3118] offers mechanisms for both entity authentication and message authentication 🫶 If the DHCP authentication mechanism isn't available, administrators may need to rely on the underlying link layer security instead. In that case, the link between the DHCP client and the Layer 2 termination point may be protected, but the DHCP message source and its messages can't be authenticated, and their integrity can't be checked, unless there exits a security binding between the link layer and the DHCP layer 🥺
When DNS is used to discover MoS, fake DNS requests and responses can cause denial of service (DoS) and stop the MN from handing over properly, respectively 😱 In networks exposed to that kind of DoS, it is RECOMMENDED that DNS service providers use the Domain Name System Security Extensions (DNSSEC), as described in [RFC4033] 💜 If you want to dig into DNSSEC operational practices, you can also check out [RFC4641] 🧚
8.2. Security Considerations for MIH Transport
The communication between an MN and a Mobility Server is exposed to a number of security threats 🚨
- Mobility Server identity spoofing. A fake Mobility Server could provide the MNs with bogus data and force them to select the wrong network or make a wrong handover decision 🙃
- Tampering. Tampering with the information provided by a Mobility Server may result in the MN making a wrong network selection or handover decision 🍓
- Replay attack. Since Mobility Services as defined in [IEEE80221] support a 'PUSH model', they can send large amounts of data to the MNs whenever the Mobility Server thinks the data is relevant for the MN 📦 An attacker may intercept the data sent by the Mobility Server to the MNs and replay it later, causing the MNs to make network selection or handover decisions that aren't valid at that point in time ⏰
- Eavesdropping. By snooping on the communication between an MN and a Mobility Server, an attacker may be able to trace a user's movement between networks or cells, or predict future movements, by inspecting handover service messages 👁️
There are lots of deployment-specific system security solutions out there that can counter the threats above 💖 For example, in the MoSh and MoSv scenarios (including roaming scenarios), link layer security may be enough to protect the communication between the MN and the Mobility Server 🌈 That's a typical mobile operator environment, where link layer security provides authentication, data confidentiality, and integrity 👑 In other scenarios, like the third-party MoS, link layer security may not be enough to protect the communication path between the MN and the Mobility Server. The communication channel between the MN and the Mobility Server needs to be secured by other means 🫣
This document doesn't give any specific guidelines on how these security solutions should be deployed 🤷♀️ However, if the IEEE 802.21 Working Group amends the specification with MIH protocol level security in the future, or recommends deployment scenarios, the IETF may revisit the security considerations and recommend specific transport-layer security as appropriate 🦋
9. IANA Considerations 📋
This document registers the following TCP and UDP ports with IANA 🎀
Keyword Decimal Description
-------- --------------- ------------
ieee-mih 4551/tcp MIH Services
ieee-mih 4551/udp MIH Services10. Acknowledgements 💌
The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin Noll, Vijay Devarapalli, Patrick Stupar, and Sam Xia for their valuable comments, reviews, and fruitful discussions 🌸 Iconic squad, honestly 👑
11. References 📚
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
- [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
- [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [RFC5678] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery", RFC 5678, December 2009.
- [RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using DNS", RFC 5679, December 2009.
11.2. Informative References 📚
okay so these are the "good to know" reads, bestie, not the must-reads 🤓
[IEEE80221]"IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/MAN Std 802.21-2008, January 2009,http://www.ieee802.org/21/private/Published%20Spec/802.21-2008.pdf(access to the document requires membership). 📄[RFC1035]Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 🌐[RFC1122]Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. 🧱[RFC1191]Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. 📏[RFC2131]Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. 🏠[RFC2460]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. ✨[RFC2988]Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. ⏱️[RFC3022]Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 🔀[RFC4641]Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. 🔐[RFC4787]Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. 🦋[RFC4960]Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007. 🌊[RFC5164]Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008. 🚀[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 🔒[RFC5382]Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. 🎀[RFC5405]Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. 💜[RFC5681]Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009. 🌸
Authors' Addresses 🫶
the crew who wrote this, with their contact details. bestie, you can totally reach out to them 💌
Telemaco Melia (editor)
Alcatel-Lucent
Route de Villejust
Nozay 91620
France
EMail: telemaco.melia@alcatel-lucent.com
Gabor Bajko
Nokia
EMail: Gabor.Bajko@nokia.com
Subir Das
Telcordia Technologies Inc.
EMail: subir@research.telcordia.com
Nada Golmie
NIST
EMail: nada.golmie@nist.gov
Juan Carlos Zuniga
InterDigital Communications, LLC
EMail: j.c.zuniga@ieee.orgthat's the whole RFC, bestie 🌈👑✨
📦 where this page comes from
- ietf: rfc5677 2009-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms