[LAC-TF] Quiz: Weird IPv6 Traffic on the Local Network

[Fernando Gont]

On 02/17/2016 11:11 AM, Alejandro Acosta wrote:
> Hola Fer,
>   Reconozco que busqué en Internet.
>   Entre lineas:
> 
> El 2/16/2016 a las 6:25 PM, Fernando Gont escribió:
>> Estimados,
>>
>> Para entretenerse:
>> <http://blog.si6networks.com/2016/02/quiz-weird-ipv6-traffic-on-local-network.html>
>>
>>
>> Version fea sin colores (en el blog se ve mas facil):
>> ---- cut here ----
>> Quiz: Weird IPv6 Traffic on the Local Network
>>
>> One thing that I enjoy a lot is capturing network traffic to
>> subsequently try to figure out whether the captured traffic makes any
>> sense -- you learn a lot that way.
>>
>> The following packet was shared with me by Timo Hilbrink during the 10th
>> Slovenian IPv6 Summit.
>>
>> The quiz consists in explaining the packet trace bellow.
>>
>> Actors:
>>
>> * Apple iOS 8.3
>> * Fritz!Box CPE
>>
>>
>> The "Crime Scene" (tcpdump packet trace):
>>
>> Two packets:
> 
> Veo más de dos.., pero esta bien.

Donde? :-)

Es un paquete malformado, y un RA...



>> 19:00:02.246726 IP6 truncated-ip6 - 16011 bytes missing!(class 0x50,
>> flowlabel 0x00040,
>> hlim 0, next-header unknown (64) payload length: 16035)
>> 4006:a0bd:c0a8:b229:40e9:a79c:f129:50 > f141:8159::b002:ffff:32fc:0:
>> ip-proto-64
>> 16035
>> 19:00:02.252529 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 256)
>> fe80::be05:43ff:feea:be92 > ip6-allnodes: [icmp6 sum ok] ICMP6, router
>> advertisement, length 256
>> hop limit 255, Flags [other stateful], pref high, router lifetime 1800s,
>> reachable time
>> 0s, retrans time 0s
>> prefix info option (3), length 32 (4): 4006:a0bd:c0a8:b229::/64, Flags
>> [onlink, auto],
>> valid time 7200s, pref. time 0s
> 
> Aqui es donde ocurre lo bueno o lo malo.
> Ya para este momento basicamanete aqui es donde la caja Fritz sabe que
> el prefijo (4006:a0bd:c0a8:b229::/64) no es válido en la red. Por ello
> anuncia el pref. time en 0s (Preferred Time). La intención de esto es
> invalidar el uso del prefijo en la LAN.

Esto es correcto.


>> prefix info option (3), length 32 (4): 4006:11b:c0a8:b229::/64, Flags
>> [onlink, auto],
>> valid time 6973s, pref. time 0s
> 
> idem
> 
>> prefix info option (3), length 32 (4): 4006:3e38:c0a8:b229::/64, Flags
>> [onlink, auto],
>> valid time 6972s, pref. time 0s
> 
> idem
> 
>> prefix info option (3), length 32 (4): 2001:980:376d:1::/64, Flags
>> [onlink, auto], valid
>> time 6603s, pref. time 3600s
> 
> Este debe ser el prefijo correcto en la red que los clientes deberían
> utilizar.

Correcto.


> 
>> rdnss option (25), length 24 (3): lifetime 1200s, addr:
>> fd00::be05:43ff:feea:be92
>> mtu option (5), length 8 (1): 1500
>> unknown option (24), length 8 (1):
>> 0x0000: 0008 0000 0708
>>
>>
>> So... can you explain what this packet trace is all about?
> 
> Cuando arriba indicaba que es malo lo digo porque sería interante ver
> este comportamiento en una red donde exista más de un prefijo válido
> anunciado por dos diferentes routers.

Exacto.


> Volviendo a lo de arriba.., podemos asumir que esto también puede ser un
> tipo de ataque en IPv6?. Colocar el preferred time en 0 dentro de loa RA
> y así invalidar el prefijo en la red?.

Esto se puede realizar como ataque. -- aunque no es el caso.

Sobre esto, una anecdota:

Mayo 2011, Presente evasion de RA-Guard en el evento de LACNIC, y Jordi
argumento que no funcionaria. El dia del evento paralelo (?) hice una
prueba desde una sala de al lado, anuncioando un par de prefijos
invalidos. El ataque funciono (LTA). La red IPv6 del evento dejo de
funcionar. Nos contactaron respecto de la situacion (*), e intente
reparar el problema enviando RAs de este tipo -- pero por motivos que no
recuerdo, no funciono.

(*) s/Nos contactaron respecto de la situacion/empezaron a llegar las
puteadas, con sugerencias de que la situacion mejore/ :-)


Abrazo,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492