JUNOS forwards IPv6 link-local packets

Mailman List Mirror (Read Only)
1

I found out by accident yesterday that JUNOS routers will forward IPv6
packets with a link-local source address, in direct opposition of RFC
4291. To me, this seems to be a security hole that would be useful for
DDoS attackers, giving them a way to send traffic that is difficult to
trace back to the source. I try to be a good "net neighbor", using uRPF
wherever possible (and other filters elsewhere) to make sure all packets
coming from my network at least look valid, but this goes right by that.

I posted over on juniper-nsp about this (more to see if I was just
missing something) and got a response that it is a known thing. There's
a closed Juniper PR, 556860, that says this affects all JUNOS devices
except SRX (Trio platforms will get a fix starting with JUNOS 12.3). It
doesn't sound like Juniper is going to fix this for the rest of us.

I guess I'm mainly curious to see what others think about this.

2

Theoretically you can do a discard route and then uRPF should work with it. I'm not sure if it will kill the RE traffic, though. If it does, you'll have to have fail filters to allow it. :frowning:

Jack

3

Once upon a time, Jack Bates <jbates@brightok.net> said:

4

fe80::/65 discard
fe80:0:0:0:8000::/65 discard

More specifics rule out over connected any day.

Jack

5

Just since I had everything hooked up I did a quick test on IOS-XR 4.2.0
on an ASR9000 and found it also forwards v6 traffic with a link-local
source address and a global destination address. The destination was a
Juniper box which I tried to DoS using ICMPv6 echo requests. The
200:11ff:fe00:0 is an Ixia tester a couple IOS-XR hops away...

11:21:38.051256 In IP6 fe80::200:11ff:fe00:0 > 2001:578:101::2: ICMP6,
echo request, seq 0, length 28
11:21:38.250659 In IP6 fe80::200:11ff:fe00:0 > 2001:578:101::2: ICMP6,
echo request, seq 0, length 28
11:21:38.451093 In IP6 fe80::200:11ff:fe00:0 > 2001:578:101::2: ICMP6,
echo request, seq 0, length 28

Which kicked in the junos ddos protection...

Apr 27 11:29:12.527 2012 jddosd[1516]: DDOS_PROTOCOL_VIOLATION_SET:
Protocol ICMPv6:aggregate is violated at fpc 7 for 1 times, started at
2012-04-27 11:29:07 EDT, last seen at 2012-04-27 11:29:07 EDT

-Phil

6

Once upon a time, Jack Bates <jbates@brightok.net> said:

fe80::/65 discard
fe80:0:0:0:8000::/65 discard

More specifics rule out over connected any day.

That would also kill any legitimate link-local traffic though.

7

Perhaps. I'm actually curious on that, as the rules for routing to link-local are very specialized. It might flag on uRPF for local traffic, but that can be overcome with a fail filter. Sending out from the RE could likely ignore the route, as it has to send to specific interfaces. Receiving on interfaces that don't have uRPF should still work as well.

It's a theory and would have to be tested.

Jack

8

you know what I love? address selection rules, or rather the fact that
we have to have them in this new ip protocol :frowning:

bugs and code problems and operational headaches and filters and ... :frowning:

9

We kind of needed them in IPv4, though not universally.

At least in IPv6, we have them.

Owen

10

I've verified this between two M7is in my lab, running Junos 10.3. I tried to verify similar behavior between a 6509 running 12.2(33)SXJ2 and my target M7i, but either the Cisco box doesn't appear to allow the traffic, or the command parser in that version of IOS is smart enough not to allow a ping sourced from a link-local address, but destined to a non-link-local address.

jms

11

When I tried this on IOS-XR I first tried a local ping and it did not
allow a ping sourced from a link-local address to ping any global address
except for one assigned to the same interface. However that didn't stop
it from forwarding frames coming into an interface from another device.

Phil