RFC 6275
Mobility Support in IPv6
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 [21], 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" [22] 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 seconds13. 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 [18]) times the default value of DupAddrDetectTransmits, as specified in Stateless Address Autoconfiguration (RFC 4862 [19]). The value MinDelayBetweenRAs overrides the value of the protocol constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery (RFC 4861 [18]). 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 [23].
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 [23]. 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 [23]. 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 [18] 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 [28] [35].
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 [7].
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" [38] [43].
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.
(next page on part 8)
