Subject: [Mip6] New I-D: Early Binding Updates for Mobile IPv6

From: "Christian Vogt" <[email-masked]>
Date: Sun, 8 Feb 2004 19:45:03 +0100

Hi,

we submitted a new Internet-Draft, draft-vogt-mip6-early-binding-updates-00.txt,
that proposes Early Binding Updates for Mobile IPv6 (please see the abstract below).
The proposal is an optional extension to Mobile IPv6's Route Optimization mode.

We recognize that Early Binding Updates for Mobile IPv6 may fit into either the
mip6 WG's or the mipshop WG's charter. We would therefore appreciate feedback from
this WG on whether the proposal is appropriate to be adopted as a WG item later.

Title....: Early Binding Updates for Mobile IPv6
Author(s): C. Vogt, R. Bless, M. Doll, T. Kuefner
Filename.: draft-vogt-mip6-early-binding-updates-00.txt
Pages....: 28
Date.....: 2004-02-04

Abstract:
   The long latency associated with Mobile IPv6's home-address and
   care-of-address tests can significantly impact delay-sensitive
   applications. We propose a modified binding-update procedure that
   evades the latency of both address tests. The modified binding update
   runs in half, or less, of the time that a standard binding update
   takes. Moreover, the modified binding update is nearly equivalent to
   the standard procedure with respect to security, and it increases the
   resources required at the correspondent node only marginally. The
   modification is realized as an optional, and fully
   backward-compatible, extension to Mobile IPv6.

The Internet-Draft is available from the on-line Internet-Drafts directories. The URL is:
http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt

Best regards,

- Christian Vogt

PS: A feasible, yet non-trivial variation of "Early Binding Updates for Mobile IPv6" is
to have the mobile node tentatively register a new care-of address *before* it changes
its point of network attachment. We are currently working on a solution for this
variation. We intend to publish our work in a separate Internet-Draft in the near future.

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

Šž¦j)bž	b²Ó"§¨žµú+‚m¦ÏÿÃ"z×è®æj)fjåŠËbú?š*z

---

From: Brian Haley <[email-masked]>
Date: Mon, 09 Feb 2004 12:44:35 -0500

Hi Christian,

I believe there is a need for faster handovers in Mipv6 (Fmip and Hmip 
are addressing some of this), but I'm not sure I agree with Section 6.2 
in the security considerations part of this draft.

 >  Concerning security against flooding attacks, Early Binding Updates
 >  are at a minor disadvantage with standard binding updates, because a
 >  malicious node may exploit the time window during which a
 >  correspondent node sends data to a yet-unverified care-of address.
 >  We propose two ways to mitigate this threat.
 >
 >  One way is to properly configure the lifetime of a tentative
 >  binding-cache entry. We propose the value,
 >  TENTATIVE_BINDING_LIFETIME, given in Section 8. In scenarios where
 >  flooding attacks cannot be ruled out, one should appropriately reduce
 >  TENTATIVE_BINDING_LIFETIME.

We're talking about this attack:

1. I take control of, or have, a system with Mipv6 MN functionality
2. I have it do HoTI/HoT with 10,000 random systems that have CN
	functionality with this new "early" support
3. I send an Early Binding Update to them all
4. Immediately followed by a TCP SYN, ping, etc.
5. Someone just got flooded

Even having just 1 second (the draft gives 3) gives someone a lot of 
time since they can just keep choosing new systems to flood from, until 
their MN is caught.  Then they move to another MN or network...  This 
particular attack is not possible with regular Binding Updates.

-Brian

Christian Vogt wrote:

> 2*z™¨¥Šx%ŠËLŠž¢z×è®m¶›?ÿ0‰ë_¢¸?™¨¥™©ÿ–+-Šwèþh©6===

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 09 Feb 2004 19:34:38 +0100

In your previous mail you wrote:

=> as there is currently some FUD about reflection attacks with
mobile IPv6 optimizations, IMHO we have to be accurate about
this issue. This is why I submitted this afternoon (in Europe)
a draft about this.

    >  correspondent node sends data to a yet-unverified care-of address.

=> in fact even if to verify new care-of addresses is not bad this does
not improve the security because:
 - the HA does not verify them (i.e., why to close the window when
   the door remains open?)
 - using mobile IPv6 does not add goodies to the standard reflection
   attack
 - this is true for carefully designed optimized schemes, which of course
   should not verify new care-of addresses if they'd really like to
   be optimized (:-).

   
=> I propose something easier:
  1. I take control of, or have, a system with IPv6 functionality
  2. I send an HTTP request or ping or etc. to 10,000 random web
       servers that have IPv6 support
  3. Someone just got flooded

   Even having just 1 second (the draft gives 3) gives someone a lot of 
   time since they can just keep choosing new systems to flood from, until 
   their MN is caught.  Then they move to another MN or network...

=> so either the reflection attack is accepted or the optimization
is not optimizing.

   This particular attack is not possible with regular Binding Updates.

=> to be accurate it is hard with return routability check on the care-of
address.
   
Regards

[email-masked]

PS: in fact there is an important detail which is wrong in the early
binding draft: the CN MUST NOT accept an early binding update carrying
an alternate care-of address option with a different address than
the source address in the IPv6 header (the place where the care-of
address is usually found). With this precaution the reflection attack
using an "early CN" is not better (from the bad guy's point of view)
than the standard one.
PPS: please wait the publication of my draft in some days, its name is
draft-dupont-mipv6-3bombing-00.txt .

---

From: "Christian Vogt" <[email-masked]>
Date: Tue, 10 Feb 2004 16:10:55 +0100

Hi Brian,

> 5. Someone just got flooded

First of all: Yes, you are right. As stated in the Internet-Draft, the attack would persist for a time limited by the CN's TENTATIVE_BINDING_LIFETIME protocol-configuration variable. The Internet-Draft claims that this time is too small for a worthwhile attack. You argue that the time is long enough, because the attacker could successively exploit multiple CNs in order to keep the attack going. Let's look closer at how an attacker would have to operate...

Right now, I see two styles of flooding attacks which are related to our discussion: simple redirection of data and the combination of data redirection and amplification.

(1) Simple redirection attacks: An attacker sends a packet to a CN. The packet's IP Source Address is spoofed: It contains the IP address of an attacked node, say, the victim. The packet is such that the CN responds to the victim with a packet of (approximately) the same size. This kind of flooding attack could be the well-known TCP-SYN-flooding attack. It could also be an ICMP-Echo-Request (Ping) flooding attack. Either way, this kind of attack is possible with normal IPv6, i.e., even without Mobile IPv6!

(2) Combining redirection with amplification: The attacker sets up a higher-level data stream. This could be a TCP- or UDP-based download, which typically require a more or less complicated a-priori handshake. (The need for a handshake is clear in the case of a TCP-based download. However, most UDP-based protocols also require some kind of handshake before data gets flowing.) Note that the attacker must maintain state in order to successfully do the handshake. 

Now, Early Binding Updates come into play. Having shaken hands with the CN, the attacker redirects the data flow towards the victim with the help of an Early Binding Update message. This data stream will hold for at most TENTATIVE_BINDING_LIFETIME seconds. (TENTATIVE_BINDING_LIFETIME defaults to 3 seconds; one may - and probably should - reduce this time.)

Having done the Early Binding Update, the attacker may delete (part of) the state it has created for the initial handshake. However, the attacker must continue to blindly send spoofed acknowledgements in periodic intervals in order to keep the download up and running. (With "spoofed acknowledgements", I mean acknowledgements with the IP Source Address field pretending that the packets come from the victim.) Most probably, the attacker needs to keep a bit of state in order to synchronize its acknowledgements with the CN.

Again, with Early Binding Updates, the attacker's yield is a data stream towards the victim of TENTATIVE_BINDING_LIFETIME seconds' length. Isn't this yield too little to make the flooding attack a "success" (from the attacker's point of view)? 

I think what is most important is the relation between the attacker's yield and the attacker's "investments" in terms of state and handshaking overhead.

Brian, you mention that the attacker could exploit thousands of CNs for its attack. Yet, the more CNs are being exploited, the more state the attacker will have to maintain. 

Please, tell me if I am missing something.

Best regards,

- Christian

|
| Christian Vogt
| Institute of Telematics, University of Karlsruhe (TH)
| www.tm.uni-karlsruhe.de/~chvogt/
|

----- Original Message ----- 
From: "Brian Haley" <[email-masked]>
To: "Christian Vogt" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 09, 2004 6:44 PM
Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6

Hi Christian,

-Brian

> | Institute of Telematics, University of Karlsruhe (TH)
"§©šŠX§‚X¬´È©ê'~Šà†Ûi³ÿðÃžµú+ƒùšŠYšŸùb²Ø§~æŠž

---

From: "Christian Vogt" <[email-masked]>
Date: Tue, 10 Feb 2004 16:15:53 +0100

> [...] in fact there is an important detail which is wrong in the early
> than the standard one. [...]

Hi Francis,

you are totally right. Designing Early Binding Updates, we implicitly assumed not to use the Alternate CoA Option. The Internet-Draft fails to mention this, and we should add an explicit passage in the next version. Thanks for pointing to this.

Best regards,

- Christian Vogt

|
| Christian Vogt

---

From: Brian Haley <[email-masked]>
Date: Wed, 11 Feb 2004 11:33:44 -0500

Hi Christian,

> Now, Early Binding Updates come into play. Having shaken hands with the CN, the attacker redirects the data flow towards the victim with the help of an Early Binding Update message. This data strea…

Yes, I understand that there are attacks that can be made with "regular" 
IPv6 and Mobile IPv6, but you are creating another possibile scenario, 
which I wanted to make clear.  The WG would have to decide if it's worth 
the risk.

> Again, with Early Binding Updates, the attacker's yield is a data stream towards the victim of TENTATIVE_BINDING_LIFETIME seconds' length. Isn't this yield too little to make the flooding attack a…

But I can continue to extend this lifetime by just sending more EBUs.

> Brian, you mention that the attacker could exploit thousands of CNs for its attack. Yet, the more CNs are being exploited, the more state the attacker will have to maintain. 

If I use ICMP Echo Request I don't need to store any state.

I will have to read Francis' drafts when they come out to see how they 
relate to yours.

Regards,

-Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Feb 2004 19:00:25 +0100

Yes, I understand that there are attacks that can be made with "regular" 
   IPv6 and Mobile IPv6, but you are creating another possibile scenario, 
   which I wanted to make clear.

=> this is a new scenario but without any advantages for attackers.

=> draft-dupont-mipv6-3bombing-00.txt was announced and should be
in all repositories.

Regards

---

From: Brian Haley <[email-masked]>
Date: Wed, 11 Feb 2004 14:00:11 -0500

> => this is a new scenario but without any advantages for attackers.

Can you please explain why you think there are no advantages?

-Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Feb 2004 20:10:52 +0100

=> what a bad guy can do or from the opposite point of view what are
the possible defenses are the same with IPv6 and Mobile IPv6+Early BUs
(or other optimized Mobile IPv6 schemes).
The only useful things we can do are to fix optimized schemes which
still accept alternate care-of addresses and, more important, to bash
the router vendors who sell routers without ingress filtering support or
where ingress filtering kills performance (I can give names in private).
Unfortunately the second is true for IPv4 too...

Regards

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2004 04:02:12 +0200

After a quick read, this draft looks interesting. Quite
promising, actually.

A couple of comments:

- THe base draft already allows caching and re-use of home
   keygen tokens. (Or maybe I just thought it does? Anyway,
   it does not matter either way, its good that you draft
   explains how to do it just before movement.)

- Your argument that the attacker has to keep a lot of
   state if multiple CNs are used. Hmm.... I memory is
   cheap these days. I think it is more interesting to
   track the bandwidth that the attacker vs. victims have
   to use.

- Speaking of bandwidth, why not adopt a packet count
   lifetime instead of a time based lifetime? Three
   seconds can be very little on a GPRS link and quite a
   lot on a fiber...

- Did you specify somewhere what happens if the
   CN does not support your scheme? Does the MN have
   to resend the optimistically delivered packets?
   Do you have simulation results on what that means
   for performance?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 29 Feb 2004 17:38:24 +0200

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