[e2e] Redirection-Based Flooding Attacks (was Re: DDoS attack vs. Spoofing of Source Address)

[Christian Vogt]

Everybody,

a typical issue with mobility protocols such as Mobile IPv6 [1] or the
Host Identity Protocol's mobility extensions [2] is that they
potentially introduce a new form of flooding attack:  redirection-based
flooding attacks.

In waging a redirection-based flooding attack, the perpetrator uses its
own IP address to request the download of a large file, e.g., through a
TCP handshake.    Once the server begins transmitting this file, the
attacker redirects the flow to the IP address of its victim, pretending
to be mobile and to now be reachable via the victim's IP address.

Depending on the mobility protocol, ingress filtering may keep the
redirector from sending the redirection request (in particular, if the
new IP address appears the IPv6 header's Source Address field).  In any
case, ingress filtering cannot stop the redirected packets, however,
because their source addresses are correct.

Also depending on the mobility protocol, the victim may or may not be
able to identify the redirector based on information in the packets that
it is impelled to receive.  E.g., in Mobile IPv6, a verified, stable IP
address of the redirector---the so-called "home address"---is present in
all redirected packets, whereas the Host Identity Protocol does not have
a feature like this.  However, the hint on the redirector is usually of
little benefit anyway, as it may only identify a zombie, not the actual
attacker.

The issue with redirection-based flooding attacks is solved by
reachability checks, or "return-routability checks", as they have been
named within the IETF:  When a mobile node requests a packet flow to be
redirected to a new IP address, its peer verifies whether there is
indeed someone willing to receive the packets at that new IP address.
The verification is quite simple:  The peer sends an unguessable number
to the new IP address and waits for this number to be echoed by the
mobile node.  Only then will the peer start to send packets to the new
IP address.

Of course, reachability tests take their time and have an impact on
handoff performance.  They thus compromise the quality of
delay-sensitive real-time applications such as VoIP.  But there are ways
to make reachability verification concurrent in order to hide its
latency.  One can thus check a new IP address while this IP address is
already being used---without loosing any of the security that
(non-concurrent, blocking) reachability verification provides [2][3].

Best,
- Christian

[1] RFC 3775
[2] draft-ietf-hip-mm-02.txt
[3] draft-vogt-mobopts-credit-based-authorization-00.txt

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



John Kristoff wrote:
> On Wed, 18 Jan 2006 15:09:14 +0000
> "rishi jethwa" <rishi_jethwa at hotmail.com> wrote:
> 
> 
>>This spoofing and  DoS problem would be completely solved
>>if all the routers in the internet  would employ ingress filtering.
> 
> 
> This is simply not true.  A great number of DoS attacks currently do
> not spoof their source address and even those that do often only spoof
> within the local /24 netblock.
> 
> 
>>But as of now there is no general consensus  on employing ingress
>>filtering. All they want is to concentrate on effciency  of moving
>>packets.
> 
> 
> Actually I think there is consensus that anti-spoof filtering is
> generally a good idea, but the reason it isn't ubiquitous is usually
> because of practical limitations (e.g. equipment support and complex
> network configurations).
> 
> 
>>A) If all the routers in the internet would employ ingress filtering,
>>DoS  attacks can be mitigated. Also the router can now easily identify
>>the source  of the attack and stop it from doing that. I have no idea
>>what uRPF is.
> 
> 
> With all due respect, for someone who did their thesis on DoS attacks,
> I am disappointed by your answers thus far.
> 
> uRPF stands for unicast reverse path check.  In a nutshell, when a
> packet arrives on an interface, if uRPF is enabled, the router can
> perform a check to verify whether the best (or in some configurations
> a feasible) path back to the source is back out that ingress interface.
> If it is, then the packet is allowed to be forwarded, otherwise it is
> filtered.
> 
> 
>>Yes, spoofing is the main reason for the presense of DoS  attack.
> 
> 
> Again, not true.  In, spoofing appears to have waned considerably
> over the past few years.  Here is just one confirmation of that (see
> slide number 3):
> 
>   <http://www.nanog.org/mtg-0501/deitrich.html>
> 
>>My Thesis topic was "Sabotashing a Trusted Relationship: A Novel DoS 
>>attack". I have also proposed a reliable solution to defeat such
>>attacks.
> 
> 
> Hmmm...
> 
> John