[Mip6] comments on draft-vogt-mip6-early-binding-updates-00

[Jari Arkko <[e-mail]>]

I already sent some comments earlier, but I reread this draft
prior to the meeting. Here are some additional comments. Overall
I find your draft quite promising. There's probably a need to
change the approach to byte counts rather than fixed time
limits, as dicussed earlier.

> We propose a modified binding-update procedure that
> evades the latency of both address tests.

If this draft goes further, it might make sense to separate
the home address and care-of address optimizations. That is,
you could have one draft that explains how the home address
tests can be initiated before handover takes place. Or would
this be considered too simple for a draft?... I don't know.
Maybe with some simulation data should be included, and rules
to tell when it makes sense: delay at movement vs. potentially
unnecessary messaging if we didn't move after all. Anyway,
this part of the optimization would work well with any other
optimization scheme as well, not just the care-of-test-less
early binding updates. Or without any other optimization.

>    before changing its point of network attachment. At home, the mobile
>    node does not use Mobile IPv6. It hence does not run a home-address
>    test, and it does not acquire a Home Keygen Token, before it moves to
>    a foreign link. Also, when the mobile node powers on at a foreign

I don't see a reason why the predictive home test strategy
wouldn't work even in this case. In either case, you have to have
some ability to "guess" that you will be moving soon, or otherwise
you'll just be doing some extra signaling.

>    One may consider letting the mobile node perform a home-address test
>    even while being at home. This could accelerate handovers from the
>    home link to a foreign link. The Home Test Init and Home Test
>    messages would continue to obey to the rules defined in sections 9.4
>    and 11.6 of [1], except that they would not have to be tunneled
>    between the mobile node and its home agent.

This is true. But if you are going to adopt predictive home tests,
I would apply them even to the home case.

Perhaps the separate draft that I suggested makes sense, because
you would also have to describe the exception that you talk about
in the above.

>    These observations lead to the following exception: When a mobile
>    node wants to register a new care-of address with a correspondent
>    node, and the mobile node does not yet know a valid Home Keygen
>    Token, the mobile node runs a standard binding update instead of an
>    Early Binding Update. When the standard binding update is complete,
>    the mobile node can communicate through its new care-of address. The

Presumably you could do an EBU as soon as you receive the Home Test
message. I think this would simplify your state machine.

>    test. We claim that testing the mobile node's reachability at its new
>    care-of address may also be done at (3). Data transmission to and
>    from the new care-of address may wait or, as with Early Binding
>    Updates, start with appropriate restrictions until the mobile node
>    has provided proof to the correspondent node that it is reachable at
>    its new care-of address.

This is the issue we discussed earlier. As has been stated by Francis
and others, in the Internet we already (unfortunately, since ingress
filtering is not ubiquitous) have the possibility to spoof source
addresses, leading to 1-1 reflection attacks on e.g. TCP SYN packets.
So 1-1 reflection is not necessarily something we need to prevent
in Mobile IPv6. Base RR attempts, however, to prevent 1-N reflection
attacks where you send one (or some) packets and get many more packets
to the victim's network. The basic scenario is tricking someone into
opening a stream, and moving the stream towards the victim and letting
the "someone" pump data towards the victim for a while.

Your -00 draft with the 3 second time limit still has this issue,
as a CN which supports EBUs could pump 3 seconds of data stream
to the victim. How serious is this? It depends on the interface speed
and effort needed to open the particular stream. Lets say 10 packets
to open the stream and get over the slow start (maybe someone can
help me with the actual numbers...). If the CN is a mobile on a
congested GPRS link, there may not be many packets sent during the
3 seconds. But if the CN is an idle web server on an OC-3 link
there could be a lot of packets, particularly since the attacker
can send some spoofed TCP ACKs, having learned the sequence numbers
while opening the stream.

However, if as suggested you would change the approach to specifically
take this into account, this would no longer be a problem. Basically,
a CN would agree to send out at most X bytes of traffic while in
the tentative state, where X is, say, 10 % of the bytes sent by the
MN during the last few minutes. This would result in the attacker
(mobile node) having to send at least 100 bytes to get just 10 bytes
to the attacker, clearly less than the 1-1 reflection simply using
TCP SYNs. Still, the 10% is more than enough to transfer the data
needed until the care-of test answer arrives: if you have a constant
data rate, 10% of data sent during three minutes gives you 18 s to
complete the care-of address test.

If you exceed X, you move the stream back to the home address.

The drawback of this scheme is that on the first binding you may
be unable to do this, even if you had ongoing data transfer with
the mobile while it was at home. This is because the IP stack would
not be counting the received bytes.
The Home Keygen Token and

>    the Care-of Keygen Token are likely to arrive at the mobile node via
>    disjoint paths: The former passes through the mobile node's home
>    agent, the latter does not. An attacker will thus have a hard time to
>    capture both tokens.

Strictly speaking, this is not the main worry. As documented in [1],
the attacker is free to choose the care-of path. So I would worry
more about attackers posing as mobile nodes and doing the RR test
than attackers being able to eavesdrop on an RR test performed
by a legitimate node. In order to pose as a mobile node, you need
to be on the path to the home agent, and your draft does not change
that so I think you are ok. (Also, if you are on the path to the home
agent you can do all sorts of other nasty stuff.)

(You say all this later in the text, but I just wanted to say
that two paths are not a protection in RR, your method, or other
methods.)

>    Another way to mitigate the threat of flooding attacks is to grant
>    Early Binding Updates to trusted nodes only. Recall that the

I wouldn't put too much emphasis on this. However, if we had some
stronger home test mechanisms (e.g. CGA), you could combine EBUs
with them, getting more security.

--Jari

[1] http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt


_______________________________________________
Mip6 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mip6