Re: Something with filters
On 2014-08-28 07:57, Tassos Chatzithomaoglou wrote: Jen had presented some similar stats a year ago. https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf These kind of issues have been demonstrated for as long as IPv6 has existed, and people have been complaining to their account managers and technical contacts too. Vendors just do not see what the problem is it seems... On 2014-08-28 07:46, Lorenzo Colitti wrote: On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar jer...@massar.ch mailto:jer...@massar.ch wrote: 9 2001:5a0:a00::2e (2001:5a0:a00::2e) 79.018 ms 79.910 ms 79.960 ms 10 :: (::) 101.893 ms 102.004 ms 103.574 ms 11 rar3.chicago-il.us.xo.net http://rar3.chicago-il.us.xo.net (:::65.106.1.155) 104.732 ms Yeah baby, we can use the unspecified address in ICMP replies! The mapped IPv4 address in there is pretty cool, too... Wow, I honestly had not even noticed that one; but indeed, another one that never should exist on the wire. At least for that one we can easily point at XO. Likely they are the problem for hop 10 too. Lets see if we can get them to resolve that mess... (even though I rather had proper source filtering installed worldwide...) Greets, Jeroen
Re: Something with filters
Eric, guys, On Thu, Aug 28, 2014 at 02:28:53PM +, Eric Vyncke (evyncke) wrote: The mapped IPv4 address is probably coming out of a 6PE (or 6VPE) MPLS router where the HopLimit field is copied into the MPLS header and when the poor P router in charge of sending the ICMPv6 has no IPv6 address at all? This is per RFC and perhaps an explanation why uRPF is not activated? No explanation about the :: address though? As a security person, I would love to have uRPF enabled where possible but I am afraid that even in IPv4 it is not deployed everywhere :-( to be honest, as another security person, I'm not really sure about the benefit of uRPF in the IPv6 world, in some scenarios. imagine a single infected smartphone on LTE, generating connections with potentially 2^64 different source addresses from its assigned /64. How would you counter that with uRPF? not to speak about a home device sitting behind a CPE (and mimicing connections from different /64s being part of the /56 the CPE got)... thoughts? best Enno -?ric PS: indeed, ask your vendors for features, customers have much more power than you guess :-) From: Lorenzo Colitti lore...@google.commailto:lore...@google.com Date: jeudi 28 ao?t 2014 07:46 To: Jeroen Massar jer...@massar.chmailto:jer...@massar.ch Cc: IPv6 Ops list ipv6-ops@lists.cluenet.demailto:ipv6-ops@lists.cluenet.de Subject: Re: Something with filters On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar jer...@massar.chmailto:jer...@massar.ch wrote: 9 2001:5a0:a00::2e (2001:5a0:a00::2e) 79.018 ms 79.910 ms 79.960 ms 10 :: (::) 101.893 ms 102.004 ms 103.574 ms 11 rar3.chicago-il.us.xo.nethttp://rar3.chicago-il.us.xo.net (:::65.106.1.155) 104.732 ms Yeah baby, we can use the unspecified address in ICMP replies! The mapped IPv4 address in there is pretty cool, too... -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: Something with filters
On Thu, Aug 28, 2014 at 04:31:22PM +0200, Enno Rey wrote: to be honest, as another security person, I'm not really sure about the benefit of uRPF in the IPv6 world, in some scenarios. imagine a single infected smartphone on LTE, generating connections with potentially 2^64 different source addresses from its assigned /64. How would you counter that with uRPF? With uRPF in place, you can just block off that /64. Without, the smartphone can fake addresses in the entire 2000::/3 unicast space. That's a pretty obvious win; uRPF didn't in itself prevent the attack, but it made it a lot easier to mitigate it. Also, uRPF makes a large class of traffic amplification attacks impossible, since you can't fake the source address anymore. /* Steinar */ -- Software Engineer, Google Switzerland
Re: Something with filters
Hi Enno, Regarding a 3GPP phone, AFAIK, it receives a /64 so it is scalable and easy to enforce uRPF at the very first layer-3 routers. Same for a home CPE (with a very minor impact, uRPF has same performance as plain forwarding == same lookup technique) and anyway the BNG/BRAS does DHCP-PD snooping and should do uRPF as well. Pretty much like in IPv4. But, we may indeed suspect that uRPF on a longer prefix such as /96 (??) could be as efficient as forwarding to a /96 which is rumored to be less efficient than forwarding to a prefix shorter than 64. Just a wild guess (and please do not assume some magical knowledge of mine based on my email address) -éric On 28/08/14 16:31, Enno Rey e...@ernw.de wrote: Eric, guys, On Thu, Aug 28, 2014 at 02:28:53PM +, Eric Vyncke (evyncke) wrote: The mapped IPv4 address is probably coming out of a 6PE (or 6VPE) MPLS router where the HopLimit field is copied into the MPLS header and when the poor P router in charge of sending the ICMPv6 has no IPv6 address at all? This is per RFC and perhaps an explanation why uRPF is not activated? No explanation about the :: address though? As a security person, I would love to have uRPF enabled where possible but I am afraid that even in IPv4 it is not deployed everywhere :-( to be honest, as another security person, I'm not really sure about the benefit of uRPF in the IPv6 world, in some scenarios. imagine a single infected smartphone on LTE, generating connections with potentially 2^64 different source addresses from its assigned /64. How would you counter that with uRPF? not to speak about a home device sitting behind a CPE (and mimicing connections from different /64s being part of the /56 the CPE got)... thoughts? best Enno -?ric PS: indeed, ask your vendors for features, customers have much more power than you guess :-) From: Lorenzo Colitti lore...@google.commailto:lore...@google.com Date: jeudi 28 ao?t 2014 07:46 To: Jeroen Massar jer...@massar.chmailto:jer...@massar.ch Cc: IPv6 Ops list ipv6-ops@lists.cluenet.demailto:ipv6-ops@lists.cluenet.de Subject: Re: Something with filters On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar jer...@massar.chmailto:jer...@massar.ch wrote: 9 2001:5a0:a00::2e (2001:5a0:a00::2e) 79.018 ms 79.910 ms 79.960 ms 10 :: (::) 101.893 ms 102.004 ms 103.574 ms 11 rar3.chicago-il.us.xo.nethttp://rar3.chicago-il.us.xo.net (:::65.106.1.155) 104.732 ms Yeah baby, we can use the unspecified address in ICMP replies! The mapped IPv4 address in there is pretty cool, too... -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: Something with filters
Hi, On Thu, Aug 28, 2014 at 04:31:22PM +0200, Enno Rey wrote: to be honest, as another security person, I'm not really sure about the benefit of uRPF in the IPv6 world, in some scenarios. imagine a single infected smartphone on LTE, generating connections with potentially 2^64 different source addresses from its assigned /64. How would you counter that with uRPF? The point is not to counter devices from spoofing random addresses - but from spoofing random addresses *not trackable to them*. not to speak about a home device sitting behind a CPE (and mimicing connections from different /64s being part of the /56 the CPE got)... thoughts? Same thing. I do not care which address customer A uses out of their /56, but if I get an abuse complaint, I do care very much that customer A is not sending packets with a source belonging to customer B... (And the whole bunch of reflective DoS attacks we're seeing these days would be stopped cold if uRPF/BCP38 would be deployed at the true sources of the spoofed packets) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Something with filters
On 8/28/14 10:56 AM, Eric Vyncke (evyncke) wrote: Hi Enno, Regarding a 3GPP phone, AFAIK, it receives a /64 so it is scalable and easy to enforce uRPF at the very first layer-3 routers. Same for a home CPE (with a very minor impact, uRPF has same performance as plain forwarding == same lookup technique) and anyway the BNG/BRAS does DHCP-PD snooping and should do uRPF as well. Pretty much like in IPv4. But, we may indeed suspect that uRPF on a longer prefix such as /96 (??) could be as efficient as forwarding to a /96 which is rumored to be less efficient than forwarding to a prefix shorter than 64. Just a wild guess (and please do not assume some magical knowledge of mine based on my email address) We have been told by Cisco that things like uRPF aren't likely to be tested/optimized. Folks forget it in the hardware design phase and then it's too late. There is no cultural habit to think about security first. CSCuq42336 is a clear example of security not even being thought of. - Jared
Something with filters
I was doing some traceroutes to determine some weird claim of a transit (not shown in the below trace) being tier1 while another transit actually popped up in their network and then noticed this beauty: 9 2001:5a0:a00::2e (2001:5a0:a00::2e) 79.018 ms 79.910 ms 79.960 ms 10 :: (::) 101.893 ms 102.004 ms 103.574 ms 11 rar3.chicago-il.us.xo.net (:::65.106.1.155) 104.732 ms Yeah baby, we can use the unspecified address in ICMP replies! Why oh why is that packet even allowed to come back to me, let alone travel all those hops... Oh, yeah, something with uRPF and other such awesome standards. Greets, Jeroen
Re: Something with filters
On 2014-08-27 19:52, Jared Mauch wrote: On Aug 27, 2014, at 12:01 PM, Jeroen Massar jer...@massar.ch wrote: I was doing some traceroutes to determine some weird claim of a transit (not shown in the below trace) being tier1 while another transit actually popped up in their network and then noticed this beauty: 9 2001:5a0:a00::2e (2001:5a0:a00::2e) 79.018 ms 79.910 ms 79.960 ms 10 :: (::) 101.893 ms 102.004 ms 103.574 ms 11 rar3.chicago-il.us.xo.net (:::65.106.1.155) 104.732 ms Yeah baby, we can use the unspecified address in ICMP replies! Why oh why is that packet even allowed to come back to me, let alone travel all those hops... Oh, yeah, something with uRPF and other such awesome standards. uRPF is an expensive feature in hardware that most people don’t ask their vendors for. uRPF for IPv6 is even harder because of things like hop #11 seen above. We keep asking the vendors but apparently we are in the minority. I know that the majority of the list here wants it; but the vendors don't it seems... one has to wonder why... Especially a check for a zero'd address is really not that hard; it is just crazyness that that is not checked for. If possible, please file this problem with your relevant technical contacts and account managers, as it is just nonsense that that packet is allowed to travel over the Internet. Greets, Jeroen
Re: Something with filters
Hi, Especially a check for a zero'd address is really not that hard; it is just crazyness that that is not checked for. If possible, please file this problem with your relevant technical contacts and account managers, as it is just nonsense that that packet is allowed to travel over the Internet. Reminds me of someone showing me a packet with link-local source address and global destination address traveling several hops... :) Cheers, Sander
Re: Something with filters
On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar jer...@massar.ch wrote: 9 2001:5a0:a00::2e (2001:5a0:a00::2e) 79.018 ms 79.910 ms 79.960 ms 10 :: (::) 101.893 ms 102.004 ms 103.574 ms 11 rar3.chicago-il.us.xo.net (:::65.106.1.155) 104.732 ms Yeah baby, we can use the unspecified address in ICMP replies! The mapped IPv4 address in there is pretty cool, too...
Re: Something with filters
Jen had presented some similar stats a year ago. https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf -- Tassos Jeroen Massar wrote on 27/8/2014 19:01: I was doing some traceroutes to determine some weird claim of a transit (not shown in the below trace) being tier1 while another transit actually popped up in their network and then noticed this beauty: 9 2001:5a0:a00::2e (2001:5a0:a00::2e) 79.018 ms 79.910 ms 79.960 ms 10 :: (::) 101.893 ms 102.004 ms 103.574 ms 11 rar3.chicago-il.us.xo.net (:::65.106.1.155) 104.732 ms Yeah baby, we can use the unspecified address in ICMP replies! Why oh why is that packet even allowed to come back to me, let alone travel all those hops... Oh, yeah, something with uRPF and other such awesome standards. Greets, Jeroen
