11.7. Processing Bindings 11.7.1. Sending Binding Updates to the Home Agent In order to change its primary care-of address as described in Sections 11.5.1 and 11.5.3, a mobile node MUST register this care-of address with its home agent in order to make this its primary care-of address. Also, if the mobile node wants the services of the home agent beyond the current registration period, the mobile node should send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. However, if the home agent returned a Binding Acknowledgement for the current registration with the Status field set to 1 (accepted but prefix discovery necessary), the mobile node should not try to register
again before it has learned the validity of its home prefixes through mobile prefix discovery. This is typically necessary every time this Status value is received, because information learned earlier may have changed. To register a care-of address or to extend the lifetime of an existing registration, the mobile node sends a packet to its home agent containing a Binding Update, with the packet constructed as follows: o The Home Registration (H) bit MUST be set in the Binding Update. o The Acknowledge (A) bit MUST be set in the Binding Update. o The packet MUST contain a Home Address destination option, giving the mobile node's home address for the binding. o The care-of address for the binding MUST be used as the Source Address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Update. This option MUST be included in all home registrations, as the ESP protocol will not be able to protect care-of addresses in the IPv6 header. (Mobile IPv6 implementations that know they are using IPsec AH to protect a particular message might avoid this option. For brevity the usage of AH is not discussed in this document.) o If the mobile node's link-local address has the same interface identifier as the home address for which it is supplying a new care-of address, then the mobile node SHOULD set the Link-Local Address Compatibility (L) bit. o If the home address was generated using RFC 4941 , then the link local address is unlikely to have a compatible interface identifier. In this case, the mobile node MUST clear the Link- Local Address Compatibility (L) bit. o If the IPsec security associations between the mobile node and the home agent have been established dynamically, and the mobile node has the capability to update its endpoint in the used key management protocol to the new care-of address every time it moves, the mobile node SHOULD set the Key Management Mobility Capability (K) bit in the Binding Update. Otherwise, the mobile node MUST clear the bit. o The value specified in the Lifetime field MUST be non-zero and SHOULD be less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding.
Mobile nodes that use dynamic home agent address discovery should be careful with long lifetimes. If the mobile node loses the knowledge of its binding with a specific home agent, registering a new binding with another home agent may be impossible as the previous home agent is still defending the existing binding. Therefore, to ensure that mobile nodes using home agent address discovery do not lose information about their binding, they SHOULD de-register before losing this information, or use small lifetimes. The Acknowledge (A) bit in the Binding Update requests the home agent to return a Binding Acknowledgement in response to this Binding Update. As described in Section 6.1.8, the mobile node SHOULD retransmit this Binding Update to its home agent until it receives a matching Binding Acknowledgement. Once reaching a retransmission timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart the process of delivering the Binding Update, but trying instead the next home agent returned during dynamic home agent address discovery (see Section 11.4.1). If there was only one home agent, the mobile node instead SHOULD continue to periodically retransmit the Binding Update at this rate until acknowledged (or until it begins attempting to register a different primary care-of address). See Section 11.8 for information about retransmitting Binding Updates. With the Binding Update, the mobile node requests the home agent to serve as the home agent for the given home address. Until the lifetime of this registration expires, the home agent considers itself the home agent for this home address. Each Binding Update MUST be authenticated as coming from the right mobile node, as defined in Section 5.1. The mobile node MUST use its home address -- either in the Home Address destination option or in the Source Address field of the IPv6 header -- in Binding Updates sent to the home agent. This is necessary in order to allow the IPsec policies to be matched with the correct home address. When sending a Binding Update to its home agent, the mobile node MUST also create or update the corresponding Binding Update List entry, as specified in Section 11.7.2. The last Sequence Number value sent to the home agent in a Binding Update is stored by the mobile node. If the sending mobile node has no knowledge of the correct Sequence Number value, it may start at any value. If the home agent rejects the value, it sends back a Binding Acknowledgement with a status code 135, and the last accepted sequence number in the Sequence Number field of the Binding Acknowledgement. The mobile node MUST store this information and use the next Sequence Number value for the next Binding Update it sends.
If the mobile node has additional home addresses, then the mobile node SHOULD send an additional packet containing a Binding Update to its home agent to register the care-of address for each such other home address. The home agent will only perform DAD for the mobile node's home address when the mobile node has supplied a valid binding between its home address and a care-of address. If some time elapses during which the mobile node has no binding at the home agent, it might be possible for another node to autoconfigure the mobile node's home address. Therefore, the mobile node MUST treat the creation of a new binding with the home agent using an existing home address, the same as creation of a new home address. In the unlikely event that the mobile node's home address is autoconfigured as the IPv6 address of another network node on the home network, the home agent will reply to the mobile node's subsequent Binding Update with a Binding Acknowledgement containing a Status of 134 (Duplicate Address Detection failed). In this case, the mobile node MUST NOT attempt to re-use the same home address. It SHOULD continue to register the care-of addresses for its other home addresses, if any. Mechanisms outlined in "Mobile IPv6 Bootstrapping in Split Scenario"  allow mobile nodes to acquire new home addresses to replace the one for which Status 134 was received. 11.7.2. Correspondent Registration When the mobile node is assured that its home address is valid, it can initiate a correspondent registration with the purpose of allowing the correspondent node to cache the mobile node's current care-of address. This procedure consists of the return routability procedure followed by a registration. This section defines when the correspondent registration is to be initiated and the rules to follow while it is being performed. After the mobile node has sent a Binding Update to its home agent, registering a new primary care-of address (as described in Section 11.7.1), the mobile node SHOULD initiate a correspondent registration for each node that already appears in the mobile node's Binding Update List. The initiated procedures can be used to either update or delete binding information in the correspondent node. For nodes that do not appear in the mobile node's Binding Update List, the mobile node MAY initiate a correspondent registration at any time after sending the Binding Update to its home agent. Considerations regarding when (and if) to initiate the procedure depend on the specific movement and traffic patterns of the mobile node and are outside the scope of this document.
In addition, the mobile node MAY initiate the correspondent registration in response to receiving a packet that meets all of the following tests: o The packet was tunneled using IPv6 encapsulation. o The Destination Address in the tunnel (outer) IPv6 header is equal to any of the mobile node's care-of addresses. o The Destination Address in the original (inner) IPv6 header is equal to one of the mobile node's home addresses. o The Source Address in the tunnel (outer) IPv6 header differs from the Source Address in the original (inner) IPv6 header. o The packet does not contain a Home Test, Home Test Init, Care-of Test, or Care-of Test Init message. If a mobile node has multiple home addresses, it becomes important to select the right home address to use in the correspondent registration. The used home address MUST be the Destination Address of the original (inner) packet. The peer address used in the procedure MUST be determined as follows: o If a Home Address destination option is present in the original (inner) packet, the address from this option is used. o Otherwise, the Source Address in the original (inner) IPv6 header of the packet is used. Note that the validity of the original packet is checked before attempting to initiate a correspondent registration. For instance, if a Home Address destination option appeared in the original packet, then rules in Section 9.3.1 are followed. A mobile node MAY also choose to keep its topological location private from certain correspondent nodes, and thus need not initiate the correspondent registration. Upon successfully completing the return routability procedure, and after receiving a successful Binding Acknowledgement from the home agent, a Binding Update MAY be sent to the correspondent node. In any Binding Update sent by a mobile node, the care-of address (either the Source Address in the packet's IPv6 header or the Care-of Address in the Alternate Care-of Address mobility option of the Binding Update) MUST be set to one of the care-of addresses currently
in use by the mobile node or to the mobile node's home address. A mobile node MAY set the care-of address differently for sending Binding Updates to different correspondent nodes. A mobile node MAY also send a Binding Update to such a correspondent node, instructing it to delete any existing binding for the mobile node from its Binding Cache, as described in Section 6.1.7. Even in this case a successful completion of the return routability procedure is required first. If the care-of address is not set to the mobile node's home address, the Binding Update requests that the correspondent node create or update an entry for the mobile node in the correspondent node's Binding Cache. This is done in order to record a care-of address for use in sending future packets to the mobile node. In this case, the value specified in the Lifetime field sent in the Binding Update SHOULD be less than or equal to the remaining lifetime of the home registration and the care-of address specified for the binding. The care-of address given in the Binding Update MAY differ from the mobile node's primary care-of address. If the Binding Update is sent to the correspondent node, requesting the deletion of any existing Binding Cache entry it has for the mobile node, the care-of address is set to the mobile node's home address and the Lifetime field set to zero. In this case, generation of the binding management key depends exclusively on the home keygen token (Section 5.2.5). The care-of nonce index SHOULD be set to zero in this case. In keeping with the Binding Update creation rules below, the care-of address MUST be set to the home address if the mobile node is at home, or to the current care-of address if it is away from home. If the mobile node wants to ensure that its new care-of address has been entered into a correspondent node's Binding Cache, the mobile node needs to request an acknowledgement by setting the Acknowledge (A) bit in the Binding Update. A Binding Update is created as follows: o The current care-of address of the mobile node MUST be sent either in the Source Address of the IPv6 header or in the Alternate Care-of Address mobility option. o The Destination Address of the IPv6 header MUST contain the address of the correspondent node.
o The Mobility Header is constructed according to rules in Sections 6.1.7 and 5.2.6, including the Binding Authorization Data (calculated as defined in Section 6.2.7) and possibly the Nonce Indices mobility options. o The home address of the mobile node MUST be added to the packet in a Home Address destination option, unless the Source Address is the home address. Each Binding Update MUST have a Sequence Number greater than the Sequence Number value sent in the previous Binding Update to the same destination address (if any). The sequence numbers are compared modulo 2**16, as described in Section 9.5.1. There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Binding Update sent or received, as long as the value stays within the window. The last Sequence Number value sent to a destination in a Binding Update is stored by the mobile node in its Binding Update List entry for that destination. If the sending mobile node has no Binding Update List entry, the Sequence Number SHOULD start at a random value. The mobile node MUST NOT use the same Sequence Number in two different Binding Updates to the same correspondent node, even if the Binding Updates provide different care-of addresses. The mobile node is responsible for the completion of the correspondent registration, as well as any retransmissions that may be needed (subject to the rate limitation defined in Section 11.8). 11.7.3. Receiving Binding Acknowledgements Upon receiving a packet carrying a Binding Acknowledgement, a mobile node MUST validate the packet according to the following tests: o The packet meets the authentication requirements for Binding Acknowledgements defined in Sections 6.1.8 and 5. That is, if the Binding Update was sent to the home agent, the underlying IPsec protection is used. If the Binding Update was sent to the correspondent node, the Binding Authorization Data mobility option MUST be present and have a valid value. o The Binding Authorization Data mobility option, if present, MUST be the last option and MUST NOT have trailing padding. o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update, and the Status field is not 135.
Any Binding Acknowledgement not satisfying all of these tests MUST be silently ignored. When a mobile node receives a packet carrying a valid Binding Acknowledgement, the mobile node MUST examine the Status field as follows: o If the Status field indicates that the Binding Update was accepted (the Status field is less than 128), then the mobile node MUST update the corresponding entry in its Binding Update List to indicate that the Binding Update has been acknowledged; the mobile node MUST then stop retransmitting the Binding Update. In addition, if the value specified in the Lifetime field in the Binding Acknowledgement is less than the Lifetime value sent in the Binding Update being acknowledged, the mobile node MUST subtract the difference between these two Lifetime values from the remaining lifetime for the binding as maintained in the corresponding Binding Update List entry (with a minimum value for the Binding Update List entry lifetime of 0). That is, if the Lifetime value sent in the Binding Update was L_update, the Lifetime value received in the Binding Acknowledgement was L_ack, and the current remaining lifetime of the Binding Update List entry is L_remain, then the new value for the remaining lifetime of the Binding Update List entry should be max((L_remain - (L_update - L_ack)), 0) where max(X, Y) is the maximum of X and Y. The effect of this step is to correctly manage the mobile node's view of the binding's remaining lifetime (as maintained in the corresponding Binding Update List entry) so that it correctly counts down from the Lifetime value given in the Binding Acknowledgement, but with the timer countdown beginning at the time that the Binding Update was sent. Mobile nodes SHOULD send a new Binding Update well before the expiration of this period in order to extend the lifetime. This helps to avoid disruptions in communications that might otherwise be caused by network delays or clock drift. o If the Binding Acknowledgement correctly passes authentication and the Status field value is 135 (Sequence Number out of window), then the mobile node MUST update its binding sequence number appropriately to match the sequence number given in the Binding Acknowledgement. Otherwise, if the Status field value is 135 but the Binding Acknowledgement does not pass authentication, the message MUST be silently ignored.
o If the Status field value is 1 (accepted but prefix discovery necessary), the mobile node SHOULD send a Mobile Prefix Solicitation message to update its information about the available prefixes. o If the Status field indicates that the Binding Update was rejected (the Status field is greater than or equal to 128), then the mobile node can take steps to correct the cause of the error and retransmit the Binding Update (with a new Sequence Number value), subject to the rate limiting restriction specified in Section 11.8. If this is not done or it fails, then the mobile node SHOULD record in its Binding Update List that future Binding Updates SHOULD NOT be sent to this destination. The treatment of a Binding Refresh Advice mobility option within the Binding Acknowledgement depends on where the acknowledgement came from. This option MUST be ignored if the acknowledgement came from a correspondent node. If it came from the home agent, the mobile node uses the Refresh Interval field in the option as a suggestion that it SHOULD attempt to refresh its home registration at the indicated shorter interval. If the acknowledgement came from the home agent, the mobile node examines the value of the Key Management Mobility Capability (K) bit. If this bit is not set, the mobile node SHOULD discard key management protocol connections, if any, to the home agent. The mobile node MAY also initiate a new key management connection. If this bit is set, the mobile node SHOULD move its own endpoint in the key management protocol connections to the home agent, if any. The mobile node's new endpoint should be the new care-of address. 11.7.4. Receiving Binding Refresh Requests When a mobile node receives a packet containing a Binding Refresh Request message, if the mobile node has a Binding Update List entry for the source of the Binding Refresh Request, and the mobile node wants to retain its Binding Cache entry at the correspondent node, then the mobile node should start a return routability procedure. If the mobile node wants to have its Binding Cache entry removed, it can either ignore the Binding Refresh Request and wait for the binding to time out, or at any time, it can delete its binding from a correspondent node with an explicit Binding Update with a zero lifetime and the care-of address set to the home address. If the mobile node does not know if it needs the Binding Cache entry, it can make the decision in an implementation-dependent manner, such as based on available resources.
Note that the mobile node should be careful not to respond to Binding Refresh Requests for addresses not in the Binding Update List to avoid being subjected to a denial of service attack. If the return routability procedure completes successfully, a Binding Update message SHOULD be sent, as described in Section 11.7.2. The Lifetime field in this Binding Update SHOULD be set to a new lifetime, extending any current lifetime remaining from a previous Binding Update sent to this node (as indicated in any existing Binding Update List entry for this node), and the lifetime SHOULD again be less than or equal to the remaining lifetime of the home registration and the care-of address specified for the binding. When sending this Binding Update, the mobile node MUST update its Binding Update List in the same way as for any other Binding Update sent by the mobile node. 11.8. Retransmissions and Rate Limiting The mobile node is responsible for retransmissions and rate limiting in the return routability procedure, in registrations, and in solicited prefix discovery. When the mobile node sends a Mobile Prefix Solicitation, Home Test Init, Care-of Test Init, or Binding Update for which it expects a response, the mobile node has to determine a value for the initial retransmission timer: o If the mobile node is sending a Mobile Prefix Solicitation, it SHOULD use an initial retransmission interval of INITIAL_SOLICIT_TIMER (see Section 12). o If the mobile node is sending a Binding Update and does not have an existing binding at the home agent, it SHOULD use InitialBindackTimeoutFirstReg (see Section 13) as a value for the initial retransmission timer. This long retransmission interval will allow the home agent to complete the Duplicate Address Detection procedure mandated in this case, as detailed in Section 11.7.1. o Otherwise, the mobile node should use the specified value of INITIAL_BINDACK_TIMEOUT for the initial retransmission timer. If the mobile node fails to receive a valid matching response within the selected initial retransmission interval, the mobile node SHOULD retransmit the message until a response is received.
The retransmissions by the mobile node MUST use an exponential back- off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile node MAY continue to send these messages at this slower rate indefinitely. The mobile node SHOULD start a separate back-off process for different message types, different home addresses, and different care-of addresses. However, in addition an overall rate limitation applies for messages sent to a particular correspondent node. This ensures that the correspondent node has a sufficient amount of time to respond when bindings for multiple home addresses are registered, for instance. The mobile node MUST NOT send Mobility Header messages of a particular type to a particular correspondent node more than MAX_UPDATE_RATE times within a second. Retransmitted Binding Updates MUST use a Sequence Number value greater than that used for the previous transmission of this Binding Update. Retransmitted Home Test Init and Care-of Test Init messages MUST use new cookie values. 12. Protocol Constants DHAAD_RETRIES 4 retransmissions INITIAL_BINDACK_TIMEOUT 1 second INITIAL_DHAAD_TIMEOUT 3 seconds INITIAL_SOLICIT_TIMER 3 seconds MAX_BINDACK_TIMEOUT 32 seconds MAX_DELETE_BCE_TIMEOUT 10 seconds MAX_NONCE_LIFETIME 240 seconds MAX_TOKEN_LIFETIME 210 seconds MAX_RO_FAILURE 3 retries MAX_RR_BINDING_LIFETIME 420 seconds MAX_UPDATE_RATE 3 times PREFIX_ADV_RETRIES 3 retransmissions PREFIX_ADV_TIMEOUT 3 seconds 13. Protocol Configuration Variables MaxMobPfxAdvInterval Default: 86,400 seconds MinDelayBetweenRAs Default: 3 seconds, Min: 0.03 seconds MinMobPfxAdvInterval Default: 600 seconds InitialBindackTimeoutFirstReg Default: 1.5 seconds
Home agents MUST allow the first three variables to be configured by system management, and mobile nodes MUST allow the last variable to be configured by system management. The default value for InitialBindackTimeoutFirstReg has been calculated as 1.5 times the default value of RetransTimer, as specified in Neighbor Discovery (RFC 4861 ) times the default value of DupAddrDetectTransmits, as specified in Stateless Address Autoconfiguration (RFC 4862 ). The value MinDelayBetweenRAs overrides the value of the protocol constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery (RFC 4861 ). This variable SHOULD be set to MinRtrAdvInterval, if MinRtrAdvInterval is less than 3 seconds. 14. IANA Considerations This document defines a new IPv6 protocol, the Mobility Header, described in Section 6.1. This protocol has been assigned protocol number 135. This document also creates a new name space "Mobility Header Type", for the MH Type field in the Mobility Header. The current message types are described starting from Section 6.1.2, and are the following: 0 Binding Refresh Request 1 Home Test Init 2 Care-of Test Init 3 Home Test 4 Care-of Test 5 Binding Update 6 Binding Acknowledgement 7 Binding Error Future values of the MH Type can be allocated using Standards Action or IESG Approval .
Furthermore, each mobility message may contain mobility options as described in Section 6.2. This document defines a new name space "Mobility Option" to identify these options. The current mobility options are defined starting from Section 6.2.2 and are the following: 0 Pad1 1 PadN 2 Binding Refresh Advice 3 Alternate Care-of Address 4 Nonce Indices 5 Authorization Data Future values of the Option Type can be allocated using Standards Action or IESG Approval . Finally, this document creates a third new name space "Status Code" for the Status field in the Binding Acknowledgement message. The current values are listed in Section 6.1.8 and are the following: 0 Binding Update accepted 1 Accepted but prefix discovery necessary 128 Reason unspecified 129 Administratively prohibited 130 Insufficient resources 131 Home registration not supported 132 Not home subnet 133 Not home agent for this mobile node 134 Duplicate Address Detection failed 135 Sequence number out of window 136 Expired home nonce index 137 Expired care-of nonce index
138 Expired nonces 139 Registration type change disallowed 174 Invalid Care-of Address Future values of the Status field can be allocated using Standards Action or IESG Approval . All fields labeled "Reserved" are only to be assigned through Standards Action or IESG Approval. This document also defines a new IPv6 destination option, the Home Address option, described in Section 6.3. This option has been assigned the Option Type value 0xC9. This document also defines a new IPv6 type 2 routing header, described in Section 6.4. The value 2 has been allocated by IANA. In addition, this document defines four ICMP message types, two used as part of the dynamic home agent address discovery mechanism, and two used in lieu of Router Solicitations and Advertisements when the mobile node is away from the home link. These messages have been assigned ICMPv6 type numbers from the informational message range: o The Home Agent Address Discovery Request message, described in Section 6.5; o The Home Agent Address Discovery Reply message, described in Section 6.6; o The Mobile Prefix Solicitation, described in Section 6.7; and o The Mobile Prefix Advertisement, described in Section 6.8. This document also defines two new Neighbor Discovery  options, which have been assigned Option Type values within the option numbering space for Neighbor Discovery messages: o The Advertisement Interval option, described in Section 7.3; and o The Home Agent Information option, described in Section 7.4.
15. Security Considerations 15.1. Threats Any mobility solution must protect itself against misuses of the mobility features and mechanisms. In Mobile IPv6, most of the potential threats are concerned with false bindings, usually resulting in denial-of-service attacks. Some of the threats also pose potential for man-in-the-middle, hijacking, confidentiality, and impersonation attacks. The main threats this protocol protects against are the following: o Threats involving Binding Updates sent to home agents and correspondent nodes. For instance, an attacker might claim that a certain mobile node is currently at a different location than it really is. If a home agent accepts such spoofed information sent to it, the mobile node might not get traffic destined to it. Similarly, a malicious (mobile) node might use the home address of a victim node in a forged Binding Update sent to a correspondent node. These pose threats against confidentiality, integrity, and availability. That is, an attacker might learn the contents of packets destined to another node by redirecting the traffic to itself. Furthermore, an attacker might use the redirected packets in an attempt to set itself as a man in the middle between a mobile and a correspondent node. This would allow the attacker to impersonate the mobile node, leading to integrity and availability problems. A malicious (mobile) node might also send Binding Updates in which the care-of address is set to the address of a victim node. If such Binding Updates were accepted, the malicious node could lure the correspondent node into sending potentially large amounts of data to the victim; the correspondent node's replies to messages sent by the malicious mobile node will be sent to the victim host or network. This could be used to cause a distributed denial-of- service attack. For example, the correspondent node might be a site that will send a high-bandwidth stream of video to anyone who asks for it. Note that the use of flow-control protocols such as TCP does not necessarily defend against this type of attack, because the attacker can fake the acknowledgements. Even keeping TCP initial sequence numbers secret does not help, because the attacker can receive the first few segments (including the ISN) at its own address, and only then redirect the stream to the victim's address. These types of attacks may also be directed to networks instead of nodes. Further variations of this threat are described elsewhere  .
An attacker might also attempt to disrupt a mobile node's communications by replaying a Binding Update that the node had sent earlier. If the old Binding Update was accepted, packets destined for the mobile node would be sent to its old location as opposed to its current location. A malicious mobile node associated to multiple home agents could create a routing loop amongst them. This can be achieved when a mobile node binds one home address located on a first home agent to another home address on a second home agent. This type of binding will force the home agents to route the same packet among each other without knowledge that a routing loop has been created. Such looping problem is limited to cases where a mobile node has multiple home agents and is permitted to be associated with the multiple home agents. For the single home agent case, a policy at the home agent would prevent the binding of one home address to another home address hosted by the same home agent. The potential problems caused by such routing loops in this scenario can be substantially reduced by use of the Tunnel-Limit Option specified in RFC 2473 . In conclusion, there are denial-of-service, man-in-the-middle, confidentiality, and impersonation threats against the parties involved in sending legitimate Binding Updates, the threat of routing loops when there are multiple home agents, and denial-of- service threats against any other party. o Threats associated with payload packets: Payload packets exchanged with mobile nodes are exposed to similar threats as that of regular IPv6 traffic. However, Mobile IPv6 introduces the Home Address destination option and a new routing header type (type 2), and uses tunneling headers in the payload packets. The protocol must protect against potential new threats involving the use of these mechanisms. Third parties become exposed to a reflection threat via the Home Address destination option, unless appropriate security precautions are followed. The Home Address destination option could be used to direct response traffic toward a node whose IP address appears in the option. In this case, ingress filtering would not catch the forged "return address"  . A similar threat exists with the tunnels between the mobile node and the home agent. An attacker might forge tunnel packets between the mobile node and the home agent, making it appear that the traffic is coming from the mobile node when it is not. Note that an attacker who is able to forge tunnel packets would
typically also be able to forge packets that appear to come directly from the mobile node. This is not a new threat as such. However, it may make it easier for attackers to escape detection by avoiding ingress filtering and packet tracing mechanisms. Furthermore, spoofed tunnel packets might be used to gain access to the home network. Finally, a routing header could also be used in reflection attacks, and in attacks designed to bypass firewalls. The generality of the regular routing header would allow circumvention of IP-address based rules in firewalls. It would also allow reflection of traffic to other nodes. These threats exist with routing headers in general, even if the usage that Mobile IPv6 requires is safe. o Threats associated with dynamic home agent and mobile prefix discovery. o Threats against the Mobile IPv6 security mechanisms themselves: An attacker might, for instance, lure the participants into executing expensive cryptographic operations or allocating memory for the purpose of keeping state. The victim node would have no resources left to handle other tasks. As a fundamental service in an IPv6 stack, Mobile IPv6 is expected to be deployed in most nodes of the IPv6 Internet. The above threats should therefore be considered as being applicable to the whole Internet. It should also be noted that some additional threats result from movements as such, even without the involvement of mobility protocols. Mobile nodes must be capable to defend themselves in the networks that they visit, as typical perimeter defenses applied in the home network no longer protect them. 15.2. Features This specification provides a series of features designed to mitigate the risk introduced by the threats listed above. The main security features are the following: o Reverse tunneling as a mandatory feature. o Protection of Binding Updates sent to home agents. o Protection of Binding Updates sent to correspondent nodes.
o Protection against reflection attacks that use the Home Address destination option. o Protection of tunnels between the mobile node and the home agent. o Closing routing header vulnerabilities. o Mitigating denial-of-service threats to the Mobile IPv6 security mechanisms themselves. The support for encrypted reverse tunneling (see Section 11.3.1) allows mobile nodes to defeat certain kinds of traffic analysis. Protecting those Binding Updates that are sent to home agents and those that are sent to arbitrary correspondent nodes requires very different security solutions due to the different situations. Mobile nodes and home agents are naturally expected to be subject to the network administration of the home domain. Thus, they can and are supposed to have a security association that can be used to reliably authenticate the exchanged messages. See Section 5.1 for the description of the protocol mechanisms, and Section 15.3 below for a discussion of the resulting level of security. It is expected that Mobile IPv6 route optimization will be used on a global basis between nodes belonging to different administrative domains. It would be a very demanding task to build an authentication infrastructure on this scale. Furthermore, a traditional authentication infrastructure cannot be easily used to authenticate IP addresses because IP addresses can change often. It is not sufficient to just authenticate the mobile nodes; authorization to claim the right to use an address is needed as well. Thus, an "infrastructureless" approach is necessary. The chosen infrastructureless method is described in Section 5.2, and Section 15.4 discusses the resulting security level and the design rationale of this approach. Specific rules guide the use of the Home Address destination option, the routing header, and the tunneling headers in the payload packets. These rules are necessary to remove the vulnerabilities associated with their unrestricted use. The effect of the rules is discussed in Sections 15.7, 15.8, and 15.9. Denial-of-service threats against Mobile IPv6 security mechanisms themselves concern mainly the Binding Update procedures with correspondent nodes. The protocol has been designed to limit the effects of such attacks, as will be described in Section 15.4.5.