From: Brent Cook <bcook@breakingpoint.com>
To: <netdev@vger.kernel.org>
Subject: Re: Possible DoS with 6RD border relay
Date: Wed, 4 Jan 2012 11:02:31 -0600 [thread overview]
Message-ID: <201201041102.31205.bcook@breakingpoint.com> (raw)
In-Reply-To: <201201041048.44509.bcook@breakingpoint.com>
On Wednesday, January 04, 2012 10:48:44 AM Brent Cook wrote:
> Hi All,
>
> I have been doing some testing of Linux serving as a 6RD border relay. It
> seems that if a client sends 6RD-encapsulated packets and varies the lower
> 64- bits of the 6RD address over the range of the neighbor table size (the
> bits below the delegated prefix), it causes the neighbor table to quickly
> overflow. However, viewing the neighbor table never shows more than a
> handful of entries. When the neighbor table overflows, packet routing on
> my test system slows from 1Gbps to a couple of Mbps at most.
I forgot to mention, I'm testing 3.2 rc7:
Linux target1 3.2.0-7-generic #13-Ubuntu SMP Sat Dec 24 18:06:57 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
but the same behavior occurs with 2.6.35
> [28765.764079] net_ratelimit: 32003 callbacks suppressed
> [28765.764084] ipv6: Neighbour table overflow.
> [28765.764171] ipv6: Neighbour table overflow.
>
> root@target1:~# ip neigh
> fe80::1a:c5ff:fe02:2 dev test2 router FAILED
> 2001:1234::3 dev test2 lladdr 02:1a:c5:02:00:02 REACHABLE
> 192.168.2.1 dev mgmt0 lladdr 04:7d:7b:06:8d:2d REACHABLE
> 1.0.0.1 dev test0 lladdr 02:1a:c5:01:00:00 REACHABLE
>
> If I send packets much more slowly, the system works as expected. If the
> 6RD client sends from a constant address rather than varying the lower
> bits, it also works fine. I tested the two neighbor table checks in sit.c
> and
continuing thought: ipip6_tunnel_xmit does not appear to be hitting the ISATAP
or !dst sections that might invoke a call to dst_get_neighbour().
> The network topology looks something like this:
>
> 6RD client -> Router -> Linux (6RD BR) -> IPv6 host
>
> The 6RD client is at 1.1.1.1/24
> The Linux BR is at 1.0.0.2/24, the IPv4 router is at 1.0.0.1/24 and the
> IPv6 host is directly attached on a second physical interface at address
> 2001:1234::3
>
> A configuration script for configuring the BR follows:
>
> #!/bin/bash
> PREFIX1="2001:0db8" # 6rd ipv6 prefix
> intf1=test0
> intf2=test2
>
> modprobe sit
>
> ## Setup the tunnel, it will create an interface named '6rd'
> ip addr add 1.0.0.2/24 dev $intf1
> ip link set $intf1 up
> sudo ip route add 1.1.1.0/24 via 1.0.0.1
> ip addr add 2001:1234::1/64 dev $intf2
> ip link set $intf2 up
> ip tunnel add 6rd mode sit local 1.0.0.2 dev $intf1 ttl 64
> ip tunnel 6rd dev 6rd 6rd-prefix ${PREFIX1}::/32
> ip addr add ${PREFIX1}::1/32 dev 6rd
> ip link set 6rd up
>
> sysctl -w net.ipv6.conf.all.forwarding=1
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-01-04 17:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 16:48 Possible DoS with 6RD border relay Brent Cook
2012-01-04 17:02 ` Brent Cook [this message]
2012-01-04 17:25 ` Eric Dumazet
2012-01-04 17:35 ` Brent Cook
2012-01-04 17:53 ` Eric Dumazet
2012-01-04 19:26 ` Brent Cook
2012-01-05 4:22 ` Brent Cook
2012-01-05 19:20 ` David Miller
2012-01-04 17:02 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201201041102.31205.bcook@breakingpoint.com \
--to=bcook@breakingpoint.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.