Mobile IP Registration
|
| When the Mobile Node determines that is has moved, whether roaming across different FAs or returning home, it initiates a Mobile IP handover by entering into the Mobile IP registration phase. During this phase, the Mobile Node signals this location update to its Home Agent. This signaling is accomplished through a Mobile IP RRQs, one of the most important messages in Mobile IP. RRQ messages are the equivalent of a routing update, because they inform the network how to deliver traffic to the Mobile Node (through the CoA). A RRP is a positive or negative acknowledgment of the RRQ, and can be originated by either the Home Agent or FA. A depiction of the registration message exchange when the Mobile Node is in a Foreign Network is shown in Figure 2-13. Figure 2-13. Registration Message Exchange in Foreign Network For a Mobile IP handover other than returning home, upon successful exchange of a Mobile IP RRQ and Mobile IP RRP, the Mobile Node is said to be registered with the Home Agent (and FA if one is used) for the lifetime specified by the Home Agent in the RRP. Thus, in addition to sending RRQs as location updates, the Mobile Node must also send a RRQ to continue its registration if the lifetime is about to expire. For a Mobile IP handover when returning home, the Mobile Node is said to be deregistering during the RRQ and RRP message exchange. The RRQ and RRP messages are center to the Mobile IP registration phase. They are sent through User Datagram Protocol (UDP) signaling with destination port number 434. NOTE The UDP transport layer protocol is chosen over Transmission Control Protocol (TCP) because it is lighter-weight than TCP. The overhead and retransmission mechanism in TCP is unwarranted, because the RRQ messages can be retransmitted by the Mobile Node if an RRP is not received. The message exchange must be unambiguous and secure because it alters routing to the Mobile Node. To this end, the messages are comprised of major components as follows. RRQs are comprised of the following three major components:
Registration Replies are also comprised of the following three major components:
In the next sections, we look into the details of each message and describe how they impact behavior on the different Mobile IP entities. After you gain an understanding of what the messages look like and what they convey, we look into message delivery and how the messages accomplish the Mobile IP handovers outlined in the section "Mobile IP Handover," in this chapter. IdentificationA crucial aspect of the Mobile IP registration message exchange is that the messages must be unique and specific in their identity. Two types of identification appear in each RRQ and RRP message: one to identify the Mobile Node and one to identify the registration or reply message itself. A unique Mobile Node identifier is required to determine who the request is coming from, what services are available for this Mobile Node, and which authentication tokens should be used for this Mobile Node. Mobile Node identification is either through a statically allocated Home Address (Home Address field) or a Network Access Identifier (NAI) extension, defined in RFC 3846, which can be used with dynamic Home Address allocation, as described in Chapter 8, "Deployment Scalability and Management." NOTE The NAI concept was first introduced as a way to support PPP roaming. Users are identified by either a username or a username and a realm, represented in the form user@realm. While an NAI looks similar to an e-mail address, the realm portion does not need to be a fully qualified domain name. The use of a realm allows users to be classified into groups; the groups can signify different administrative domains, different service classes, or both. The username portion uniquely identifies the individual within that group. The second identifier in the Mobile IP messages uniquely identifies the registration or reply message. This field is referred to as the identification field in the RRQ and RRP, and is chosen by the Mobile Node to uniquely distinguish each registration attempt. The identification field allows the Mobile Node to correlate each RRQ with its corresponding received RRP. Several pending RRQs can exist for a Mobile Node at a given time, and hence, the Mobile Node can match each outstanding RRQ with its RRP. The identification field prevents replay attacks of the RRQ specifically, because it is unique in each RRQ and thus thwarts a bad-intentioned node from keeping a copy of an RRQ and replaying it at a later time. Use of the identification field is covered in depth in Chapter 3, "Mobile IP Security." ServicesA key outcome of the Mobile IP registration phase is for the Mobile Node and Home Agent to agree on the Mobile IP services that are to be provided during the lifetime of the registration. You might have already pieced together how this "negotiation" occurs, but we risk stating the obvious. A Mobility Agent advertises the Mobile IP services that it is willing to provide in its agent advertisements. The Mobile Node then requests particular services in its RRQ. The FA and Home Agent either accept or reject these requests in the RRP. Most of the services that a Mobile Node can request center around the Mobile IP tunnel and associated delivery options. For example, a Mobile Node can request that a specific CoA be used as the tunnel endpoint, and a particular encapsulation be used for the tunnel. Services can be requested either by setting specified option bits in the RRQ or by appending appropriate Mobile IP extensions. The use of extensions allows new services to be added to the Mobile IP protocol at any time. (Mobile IP includes provisions for 256 types of extensions, but extension subtypes can add an unlimited number of extensions.) All Mobility Agents must understand extensions of type 0127 (considered critical extensions), or the entire RRQ that contains the extension must be silently discarded. This is because Mobile IP connectivity can depend on the nonoptional parameters conveyed in these extensions, and if an agent does not understand what is being requested, simply ignoring the extension and processing the rest of the request are likely to result in problems. On the other hand, options that do not critically affect connectivity, namely, extensions of type 128255, might be ignored if they are not understood, with the rest of the RRQ, including all extensions, processed as normal. Service Fields and BitsThe standard services offered in Mobile IP are best described by the different option bits and relevant fields in the RRQ, which are as follows:
The options bits are S, B, D, M, G, and T; when set to 1, the bits mean the following:
To perform a Mobile IP handover other than returning home, the Mobile Node sends a RRQ, requesting relevant Mobile IP services and requesting that the Home Agent tunnel its packets to the CoA specified for the lifetime requested. If the RRQ and requested services are accepted by the FA and Home Agent, a RRP indicating success is received by the Mobile Node, with the registration lifetime specified in the lifetime field. The actual lifetime of the registration is determined by the Home Agent in the RRP and can differ from the lifetime requested by the Mobile Node in the RRQ. On the other hand, if the RRQ is rejected, a RRP with a failure code (as outlined in the section "Registration Reply Codes," later in this chapter) is received by the Mobile Node. Many Mobile IP services are negotiated in this manner, that is, the Mobility Agent rejecting the RRQ sends a RRP with an appropriate error code, indicating to the Mobile Node how to amend its request. If a Mobile Node commences a Mobile IP handover to return home or if it decides to power down, it sends a RRQ with the lifetime field set to 0 and the CoA field set to its Home Address. This type of RRQ is known as a deregistration. Broadcast SupportIf the Mobile Node requests that broadcast datagrams (by setting the B bit) be forwarded from its Home Network, care must be taken to ensure that the broadcasts do not appear on the visited network, but are delivered directly to the Mobile Node. The action that the Home Agent takes to ensure this depends on where the Mobile IP tunnel is terminating in the Foreign Network. In the case that the tunnel terminates on the FA, the Home Agent encapsulates the broadcast datagram in a unicast IP packet destined for the Mobile Node's Home Address. This encapsulated packet is then sent through the Mobile IP tunnel as any other datagram, resulting in double encapsulation. The outer encapsulation allows the packet to be sent down the Mobile IP tunnel, and the inner encapsulation allows the FA to know which Mobile Node to forward the inner broadcast datagram. It is the responsibility of the Mobile Node to remove this inner encapsulation header to receive the broadcast datagram. This implies that the Mobile Node must be able to decapsulate packets to request broadcast support. When the Mobile Node is using a CCoA and registering directly with the Home Agent, the Home Agent simply tunnels the broadcast datagram as any other packet destined for the Mobile Node. The extra inner encapsulation is not necessary because datagrams are tunneled directly to the Mobile Node. Simultaneous BindingsWhen the Mobile Node requests simultaneous bindings (by setting the S bit), it is requesting that the Home Agent maintain this mobility binding in addition to mobility binding(s) that the Home Agent might already have for it. If the Home Agent accepts the request, it duplicates each data packet and sends a copy to the CoA in each of the mobility bindings simultaneously, as shown in Figure 2-14. Figure 2-14. Simultaneous Bindings Simultaneous binding support is often interpreted as a feature necessary to have a Mobile IP handover occur without packet loss. Mobile IP is often perceived as a "break before make" protocol, that is, the current Mobile IP connection is lost before a new Mobile IP registration is made. Using simultaneous bindings is perceived as making Mobile IP a make before break protocol because the bindings seem to provide a good communication path before the old path goes away. In practice, these characterizations are, for the most part, link-layer phenomena, and while simultaneous bindings can achieve a Mobile IP handover without packet loss, to leverage it with a single roaming interface, the underlying link layer must be designed for proper support. However, even then, a significant advantage over a standard Mobile IP handover would be unlikely. Regardless of whether simultaneous bindings are used, Mobile IP generally switches over instantly without packets being discarded by the Home Agent. This can be clearly seen when two different link types are being used and a Mobile Node is handing over from one active link to another active link. Packets to the Mobile Node are tunneled through the initial link until a reregistration is accepted by the Home Agent. At this point, the Home Agent immediately starts forwarding packets to the new CoA. As long as both links are active, no packets are lost, providing a Mobile IP handover without packet loss and without simultaneous bindings, as illustrated in Figure 2-15. Figure 2-15. Mobile IP Handover Without Simultaneous Bindings NOTE Here is the worst case: If the initial link is slower than the new link, some packets can arrive out of sequence. However, this problem is not solved with simultaneous binding support, because it is an effect of the link speed, not the Mobile IP routing. However, if the link-layer capabilities of the Mobile Node were such that it could associate with two lossy links at the same time, simultaneous bindings can improve the probability that the Mobile Node can correctly receive its packets, because they are tunneled to both locations. AuthenticationMobile IP authentication is covered in depth in Chapter 3, but you should understand the authentication concepts at this stage to understand the full capability of the Mobile IP registration messages and any appended Mobile IP extensions. To this end, we provide an overview of the concepts and refer you to Chapter 3 for more details. Like other routing protocols, Mobile IP uses digital signaturestyle authentication to protect routing updates (that is, the RRQ and RRP) and is accomplished using authentication extensions (AEs). Different types of authentication extensions exist, each used to establish a bidirectional trust relationship between two specific Mobile IP entities. The critical purpose of the authentication extensions is to verify the sender of the message or portion of the message and to ensure that the message (or portion) was not altered while in transit. Unlike other routing protocols, authentication between the Mobile Node and its Home Agent is mandatory for all routing updates. Because the registration messages alter routing to the Mobile Node, the information exchanged during the registration phase must be protected. To accomplish this, the Mobile NodetoHome Agent Authentication Extension (MHAE) provides a bidirectional trust relationship between the Mobile Node and its Home Agent. It is the only authentication extension that is required in every RRQ and RRP. Other authentication extensions facilitate a bidirectional trust relationship between the Mobile Node and the FA (MFAE), the FA and the Home Agent (FHAE), and the Mobile Node and an authentication, authorization, and accounting (AAA) server (Mobile Node-AAA), as seen in Chapter 3. The security of any appended Mobile IP service extensions depends on their placement relative to the authentication extensions present in the Mobile IP messages. For example, the FA can append a service extension after the mandatory MHAE and then secure it with an FHAE. Thus, controlling the placement of service extensions in this way allows extensions to be added and removed by individual Mobile IP entities in the path without impacting the integrity of the data protected by other authentication extensions. For example, Figure 2-16 shows how the MHAE authenticates only the information between the UDP header and the MHAE, while the FHAE protects the information between the UDP header and the FHAE, that is, including the FA-appended extensions. Figure 2-16. Use of Mobile IP Authentication Extensions
Relevant Address FieldsThe different IP address fields within the Mobile IP RRQ message and the IP tunnel header depend on the registration situation and Mobile IP handover. Although it might seem confusing at first, it is quite straightforward. The possible Mobile IP handovers lead to the following four main registration scenarios:
In scenarios 13, the Mobile Node can operate either with a statically allocated Home Address or it can request a dynamically allocated Home Address. If the Mobile Node is requesting a dynamically allocated address, the Home Address field of the RRQ is 0.0.0.0. Table 2-1 outlines the different scenarios and IP address values.
Example 2-2 shows the RRQ message in detail. In this example, the Mobile Node has an NAI (user@example.com) and is requesting that a Home Address be dynamically allocated. The Mobile Node is registering through a FA (192.168.100.28) with its Home Agent (192.168.101.1). It is requesting a registration lifetime of 2 hours and is appending an mobile foreign challenge extension (MFCE) and Mobile Node-AAA extension on top of the mandatory MHAE. (The MFCE and Mobile Node-AAA extensions are described in Chapter 3.) Example 2-2 is a packet capture and decode of a RRQ taken with Ethereal, a network protocol analyzer. Protocol analyzers are widely used for troubleshooting and provide a field-by-field view of the packet. Example 2-2. Mobile IP Registration Request Protocol DetailInternet Protocol, Src Addr: 0.0.0.0 (0.0.0.0), Dst Addr: 192.168.100.28 (192.168.100.28) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 118 Identification: 0x6c41 Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 255 Protocol: UDP (0x11) Header checksum: 0x2a71 (correct) Source: 0.0.0.0 (0.0.0.0) Destination: 192.168.100.28 (192.168.100.28) User Datagram Protocol, Src Port: mobileip-agent (434), Dst Port: mobileip-agent (434) Source port: mobileip-agent (434) Destination port: mobileip-agent (434) Length: 98 Checksum: 0xe7f7 (correct) Mobile IP Message Type: Registration Request (1) Flags: 0x00 0... .... = Simultaneous Bindings: False .0.. .... = Broadcast Datagrams: False ..0. .... = Co-lcated Care-of Address: False ...0 .... = Minimal Encapsulation: False .... 0... = GRE: False .... .0.. = Van Jacobson: False .... ..0. = Reverse Tunneling: False Lifetime: 7200 Home Address: 0.0.0.0 (0.0.0.0) Home Agent: 192.168.101.1 (192.168.101.1) Care of Address: 192.168.100.28 (192.168.100.28) Identification: Jan 13, 2003 12:52:34.389797056 Extensions Extension: Mobile Node NAI Extension Extension Type: Mobile Node NAI Extension (131) Extension Length: 12 NAI: user@example Extension: Mobile-Home Authentication Extension Extension Type: Mobile-Home Authentication Extension (32) Extension Length: 20 SPI: 0x00000100 Authenticator: CF62301B0031DB59959A12B3E0AC939C Extension: Mobile Node-FA Challenge Extension Extension Type: MN-FA Challenge Extension (132) Extension Length: 4 Extension: 179823C4 Extension: Generalized Mobile-IP Authentication Extension Extension Type: Generalized Mobile-IP Authentication Extension (36) Gen Auth Ext SubType: MN AAA Extension (1) Extension Length: 20 SPI: 0x00000002 Authenticator: DF0461262E7DDB651E2C68B9180EC3AC Here are the descriptions of the fields in the IP Header:
Here are the descriptions of the fields in the Mobile IP Registration:
Registration Reply CodesA RRP is sent either by a FA or a Home Agent in response to a RRQ. In the case of an FA-CoA, if the FA accepts the RRQ from the Mobile Node, it forwards the request to the Home Agent. However, if the FA rejects the RRQ or cannot forward the request to the Home Agent, it immediately sends a RRP with an appropriate error code, and does not propagate the reply to the Home Agent. Similarly, if the FA receives a RRP from the Home Agent and deems the reply to be invalid, it generates a new RRP with the appropriate error code. The possible FA reply codes are as follows: 64 reason unspecified 65 administratively prohibited 66 insufficient resources 67 mobile node failed authentication 68 home agent failed authentication 69 requested Lifetime too long 70 poorly formed Request 71 poorly formed Reply 72 requested encapsulation unavailable 73 reserved and unavailable 77 invalid care-of address 78 registration timeout 80 home network unreachable (ICMP error received) 81 home agent host unreachable (ICMP error received) 82 home agent port unreachable (ICMP error received) 88 home agent unreachable (other ICMP error received) The FA attempts to use a specific reply code so that the Mobile Node knows why the registration was rejected. For example, the FA can send back error code 72 to indicate that the requested encapsulation [is] unavailable so that the Mobile Node can request a different encapsulation type in its next registration attempt. When the Home Agent receives the RRQ, it generates a RRP. The Home Agent either responds with a successful reply code or an appropriate error code. The possible Home Agent reply codes are as follows: Registration successful: 0 registration accepted 1 registration accepted, but simultaneous mobility bindings unsupported Registration rejected by the home agent: 128 reason unspecified 129 administratively prohibited 130 insufficient resources 131 mobile node failed authentication 132 foreign agent failed authentication 133 registration Identification mismatch 134 poorly formed Request 135 too many simultaneous mobility bindings 136 unknown home agent address Registration DeliveryBy this timealthough this might fall into the same category as saying that a stop sign says "STOP"a Mobile IP RRQ is initiated by a Mobile Node to commence a Mobile IP handover. The delivery details of the RRQ and RRP messages during the Mobile IP handover depend on whether a FA is being used. A Mobile Node can either forward a RRQ directly to the Home Agent if it is operating in CCoA mode without a FA or it is deregistering from its Home Network; otherwise, it forwards the request to the FA. The behavior of the Mobility Agents depends on the success of the messages and the type of Mobile IP handover being performed. Regardless of the Mobile IP handover, when a FA receives a RRQ, it first verifies any necessary security associations. It then verifies that it is capable and allows the Mobile IP services requested by the Mobile Node. If the FA cannot or does not provide the requested services, it generates a RRP with an appropriate failure code, as described in the previous section. If the FA can provide all the requested services, it creates an entry in its pending registration table. The pending registration table tracks RRQs that have not yet received a reply from the Home Agent. A pending registration is held by the FA for a maximum of 7 seconds before assuming that the Home Agent is unavailable. If an RRP is not received from the Home Agent, the FA generates a RRP with a registration timeout error code. When the Home Agent receives the RRQ, either from the FA or directly from the Mobile Node, it begins by verifying the relevant security associations, as covered in Chapter 3. After the authenticity of the RRQ has been verified, the Home Agent begins to process the request, and if at any time the Home Agent cannot successfully support the request of the Mobile Node, it sends a RRP with an appropriate error code, as described in the previous section. After this point, the behavior of the Mobility Agents depends on the type of Mobile IP handover being initiated in the RRQ. Mobile IP Handover Other Than Returning HomeFor a RRQ initiating a Mobile IP handover other than returning home, as the first step in processing the RRQ, the Home Agent determines whether a Home Address must be allocated for the Mobile Node by examining the home address field of the RRQ. (If the Mobile Node is requesting that a Home Address be dynamically assigned, it sets the Home Address field of the RRQ to 0.0.0.0, as described in the section "Relevant Address Fields," earlier in this chapter.) If a dynamic Home Address is needed, the Home Agent allocates an address to the Mobile Node that can be retained for as long as the Mobile Node is registered with the Home Agent. Details of dynamic Home Address allocation can be found in Chapter 8. The Home Agent then updates the Mobile Node's mobility binding, if it already exists, or creates a new mobility binding for the Mobile Node. The mobility binding is a structure that keeps track of the attributes of an active Mobile Node. The Home Agent uses the binding to monitor which Mobile IP services are in use by the Mobile Node, the current CoA, and the lifetime of the registration. The Home Agent maintains the mobility binding in a binding table, which is a database of all the active Mobile Nodes and is a similar concept to the database in OSPF. Mobility bindings are uniquely indexed within the binding table by the Mobile Node's Home Address and are removed if the lifetime of the binding expires. The Home Agent uses the information in the mobility binding to create a Mobile IP tunnel between itself and the CoA. It updates its routing table so that traffic for the Mobile Node is sent on the tunnel. The Home Agent then sends a gratuitous ARP on the Home Network to attract all traffic for the Mobile Node. This ensures that the Mobile Node's traffic is delivered to the Home Agent and, thus, can be sent down the Mobile IP tunnel to the Mobile Node. The result of the registration message exchange can be seen in Figure 2-17. Figure 2-17. Result of a Successful Mobile IP Registration Finally, the Home Agent sends a RRP to the Mobile Node, either through a FA, if one is used, or directly. If the Home Agent allocated a dynamic Home Address for the Mobile Node, it includes the assigned address in the home address field of the RRP. When the FA receives the RRP and deems the reply valid, it considers the Mobile Node to be visiting on its network. It moves the pending registration entry for the Mobile Node into its visitor table. The visitor table keeps track of all the Mobile Nodes with active sessions and is analogous to the binding table in the Home Agent. The visitor entry is not removed until the lifetime expires or until a Deregistration Reply, as described in the next section, is received. Mobile IP Handover Returning HomeUpon successful receipt of a Deregistration Request by a Mobile Node initiating a Mobile IP handover to return home or powering down, the Home Agent tears down the Mobile IP tunnels and dismantles (removes) the mobility binding. At this point, Mobile IP is no longer used for routing to the Mobile Node. The Home Agent sends a RRP, in this case known as a Deregistration Reply, to the Mobile Node. If the FA receives the Deregistration Reply, it removes the corresponding Deregistration Request from its pending registration table and removes the Mobile Node's visitor table entry. The FA can only receive a Deregistration Reply for a Deregistration Request that it forwards. The FA forwards the Deregistration Reply to the Mobile Node. Upon deregistration, the Mobile Node sends out a gratuitous ARP on the Home Network to ensure that its traffic is delivered to it and is no longer delivered to the Home Agent. Typically, the Mobile Node surrenders a dynamically allocated Home Address at this point. Mobile IP ExampleWe now look at a Mobile IP example to get a good feel for the protocol. Consider a Mobile Node with a single interface whose Home Address is 192.168.10.30 and Home Agent is 192.168.10.1. In this example, the Mobile Node roams away from home to FA 192.168.100.6, and then to another FA, 192.168.200.6. It then finds itself still roaming, but not within the domain of a FA. At this point, it obtains a Colocated CoA and continues to roam. After some time, it returns home. The example is as follows:
| ||||||||||||||||||||||||||||||
|
EAN: 2147483647
Pages: 124