JUNOS forwards IPv6 link-local packets
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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 4/27/2012 8:56 AM, Chris Adams wrote:
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.
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. :( Jack
Once upon a time, Jack Bates <jbates@brightok.net> said:
On 4/27/2012 8:56 AM, Chris Adams wrote:
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.
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. :(
I don't think that will work, because there's an automatic direct route for fe80::/64 to all interfaces with family inet6 configured. The only way I see around it is to apply a firewall filter to all IPv6 interfaces that blocks anything with a source in fe80::/64 and destination _not_ in fe80::/64. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 4/27/2012 9:26 AM, Chris Adams wrote:
I don't think that will work, because there's an automatic direct route for fe80::/64 to all interfaces with family inet6 configured. The only way I see around it is to apply a firewall filter to all IPv6 interfaces that blocks anything with a source in fe80::/64 and destination _not_ in fe80::/64.
fe80::/65 discard fe80:0:0:0:8000::/65 discard More specifics rule out over connected any day. Jack
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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 4/27/2012 11:20 AM, Chris Adams wrote:
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.
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
you know what I love? address selection rules, or rather the fact that we have to have them in this new ip protocol :( bugs and code problems and operational headaches and filters and ... :( On Fri, Apr 27, 2012 at 12:31 PM, Jack Bates <jbates@brightok.net> wrote:
On 4/27/2012 11:20 AM, Chris Adams wrote:
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.
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
We kind of needed them in IPv4, though not universally. At least in IPv6, we have them. Owen On Apr 27, 2012, at 12:16 PM, Christopher Morrow wrote:
you know what I love? address selection rules, or rather the fact that we have to have them in this new ip protocol :(
bugs and code problems and operational headaches and filters and ... :(
On Fri, Apr 27, 2012 at 12:31 PM, Jack Bates <jbates@brightok.net> wrote:
On 4/27/2012 11:20 AM, Chris Adams wrote:
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.
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
On Fri, 27 Apr 2012, Chris Adams wrote:
I don't think that will work, because there's an automatic direct route for fe80::/64 to all interfaces with family inet6 configured. The only way I see around it is to apply a firewall filter to all IPv6 interfaces that blocks anything with a source in fe80::/64 and destination _not_ in fe80::/64.
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
On 4/30/12 2:36 PM, "Justin M. Streiner" <streiner@cluebyfour.org> wrote:
On Fri, 27 Apr 2012, Chris Adams wrote:
I don't think that will work, because there's an automatic direct route for fe80::/64 to all interfaces with family inet6 configured. The only way I see around it is to apply a firewall filter to all IPv6 interfaces that blocks anything with a source in fe80::/64 and destination _not_ in fe80::/64.
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
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
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 On 4/27/12 9:56 AM, "Chris Adams" <cmadams@hiwaay.net> wrote:
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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
participants (6)
-
Chris Adams -
Christopher Morrow -
Jack Bates -
Justin M. Streiner -
Owen DeLong -
Phil Bedard