Mailing List Archive

> On Aug 27, 2014, at 12:01 PM, Jeroen Massar <jeroen@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 (::ffff: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.

- Jared

On 2014-08-27 19:52, Jared Mauch wrote:
>
>> On Aug 27, 2014, at 12:01 PM, Jeroen Massar <jeroen@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 (::ffff: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

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

On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar <jeroen@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 (::ffff: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...

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 (::ffff: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
>

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 <jeroen@massar.ch
> <mailto:jeroen@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>
> (::ffff: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

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 :-(

-éric

PS: indeed, ask your vendors for features, customers have much more power than you guess :-)

From: Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Date: jeudi 28 août 2014 07:46
To: Jeroen Massar <jeroen@massar.ch<mailto:jeroen@massar.ch>>
Cc: IPv6 Ops list <ipv6-ops@lists.cluenet.de<mailto:ipv6-ops@lists.cluenet.de>>
Subject: Re: Something with filters

On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar <jeroen@massar.ch<mailto:jeroen@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> (::ffff: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...

Eric, guys,

On Thu, Aug 28, 2014 at 02:28:53PM +0000, 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 <lorenzo@google.com<mailto:lorenzo@google.com>>
> Date: jeudi 28 ao?t 2014 07:46
> To: Jeroen Massar <jeroen@massar.ch<mailto:jeroen@massar.ch>>
> Cc: IPv6 Ops list <ipv6-ops@lists.cluenet.de<mailto:ipv6-ops@lists.cluenet.de>>
> Subject: Re: Something with filters
>
> On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar <jeroen@massar.ch<mailto:jeroen@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> (::ffff: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
=======================================================

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

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" <erey@ernw.de> wrote:

>Eric, guys,
>
>On Thu, Aug 28, 2014 at 02:28:53PM +0000, 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 <lorenzo@google.com<mailto:lorenzo@google.com>>
>> Date: jeudi 28 ao?t 2014 07:46
>> To: Jeroen Massar <jeroen@massar.ch<mailto:jeroen@massar.ch>>
>> Cc: IPv6 Ops list
>><ipv6-ops@lists.cluenet.de<mailto:ipv6-ops@lists.cluenet.de>>
>> Subject: Re: Something with filters
>>
>> On Wed, Aug 27, 2014 at 9:01 AM, Jeroen Massar
>><jeroen@massar.ch<mailto:jeroen@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>
>>(::ffff: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
>=======================================================

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 AG Vorstand: 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

I'm happy to add my voice to the bug. Please let me know what vendor and bug id.

I can't open a bug against a 3rd party misbehaving box when I don't know what it is though. I assume you can get this info since you have the endpoint data somewhere.

Jared Mauch

> On Aug 27, 2014, at 3:58 PM, Jeroen Massar <jeroen@massar.ch> wrote:
>
>> On 2014-08-27 19:52, Jared Mauch wrote:
>>
>>> On Aug 27, 2014, at 12:01 PM, Jeroen Massar <jeroen@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 (::ffff: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

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