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

[Christian Vogt <[e-mail]>]

Hi Jari!

> 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.

You are referring to the following question: How can a correspondent
node (CN) know how much data it may sent to a "good" mobile node's
(MN's) new care-of address (CoA), while that CoA is being verified
by a concurrent CoA test, without allowing a malicious node to misuse
the concurrent CoA test for a flooding attack. And yes, the 3-seconds
time limit on the concurrent CoA test, which we proposed in version
-00 of the [2], does not solve the problem for two reasons.

The first reason is the one you mentioned in an earlier email: The
amount of data a CN may send within three seconds can be arbitrarily
high. It is only limited by the pipe between the CN and the target IP
address. A second reason is that a 3-seconds time limit alone does not
prevent a malicious node from continually refreshing a tentative
CoA registration.

It might seem to be an obvious approach to replace the 3-seconds time
limit by a constant byte (or packet) limit. A constant byte limit would
bound the data volume that a CN may send to a yet-to-be-verified
CoA. But a constant byte limit has a similar shortfall than the
constant time time limit proposed in [2], namely: Whatever limit is
chosen, it might still allow for a flooding attack against a node at a
narrow link.

This observation led us to the idea of balancing the data volume that a
CN can send to an "unconfirmed" CoA of a MN with the data volume
that the CN has earlier sent to a "confirmed" CoA of the same MN. With
"unconfirmed" CoA I mean a CoA for which a concurrent CoA test is still
ongoing. With "confirmed" CoA I mean a CoA for which the CN has
obtained assurance, through a CoA test, that the MN is indeed reachable
at that CoA. We called this approach "Credit-Based Authorization",
meaning that a MN must collect some "credit" (in terms of data volume)
before it can do a concurrent CoA test.

In an email, you suggest using the data volume originated *by the MN*,
and sent to the CN, as the counter-balance to what the CN may sent to a
yet-to-be-verified CoA of the MN. Yes, this is a good idea. As
discussed during our conversation after yesterday's MIP6 session,
one should probably use both types of traffic, which would also allow
for applications with asymmetric data flows. 

> 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.

We are currently working on version -01 of [2] in which we specify
Credit-Based Authorization, but we did not finish the new version
in time for this IETF meeting. I do have a slide on Credit-Based
Authorization, which I will show during my presentation of Early
Binding Updates at the MOBOPTS session on Wednesday afternoon, 
provided there is sufficient time. (It is only a 10-minutes
presentation.)

> 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.

One argument that might be against separating Early Binding Update I-D
is that, in Mobile IPv6, a MN may already do a home-address (HoA) test
whenever it whishes. Though the MIPv6 specification suggest to do the
HoA test after a handover, a MN may also do it before the handover
without violating the protocol specification. In fact, a HoA test can
be done at any time as long as the Home Keygen Token retrieved from it
is not expired when eventually used for Binding Update message
authentication. Nonetheless, I think that splitting the I-D is an
excellent idea, because both the early HoA test as well as the
concurrent CoA test require additional commentary. As far as the HoA
test goes, I may just cite your previous email:

> 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 [...]

...namely having the MN do a HoA test even when it is at home. As far
as the CoA test goes, there is this credit-based authorization method
which will be specified in version -01 of [2]. Certainly, splitting
the I-D into two separate I-Ds would make both of them easier to read.

> Maybe the byte count scheme could be called the "Adaptive
> Amplification Attack Prevention" (AAAP) or "Attack Cost
> War for Amplification" (ACWA).

We called it "Credit-Based Authorization" for now. It does not sound
too spectacular, I admit. "Counter-Balance-Based Egress Monitoring
could be another alternative.

> Hmm... I wonder if this has been described anywhere else.
> Seems like a rather general scheme. But maybe not, as it
> only makes sense in movements. Write a paper somewhere on this,
> interested?

Credit-Based Authorization is definitely an important topic per se
and needs dedicated consideration. And yes, we intend to elaborate
further on this topic. Writing a paper is an excellent idea!

The following comments are not related to Credit-Based Authorization.

> 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.

You are right. Simulation analyses are still on our to-do list.

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

I agree. This is true. When writing this I-D, we thought from an
implementor's perspective: An Early-Binding-Update-enabled MN would
probably implement standard binding updates as well, and that code
could just be re-used here. But, you are right: The state machine gets
simpler if Early Binding Updates are used in all situations.

Jari, I appreciate your detailed comments on Early Binding Updates.

Best regards,


- Christian


[1]
http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt
[2]
http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt


|
| Christian Vogt
| Institute of Telematics, University of Karlsruhe
| www.tm.uka.de/~chvogt/
|


Quoting 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 trans-
> > mission 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





-------------------------------------------------------------
This message was sent through ATIS: http://atiswww.ira.uka.de 

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