[nsp-sec] New IPV6 NDP issue (via cert)

Chris Morrow morrowc at ops-netman.net
Wed Oct 8 15:32:02 EDT 2008



On Tue, 7 Oct 2008, Jens Rosenboom wrote:

> On Fri, Oct 03, 2008 at 05:50:18PM +0000, Chris Morrow wrote:
>>
>> "IPv6 implementations insecurely update Forward Information Base"
>>
> Low threat for a local LAN maybe, but do you guys really trust all
> of the hosts on every IXP you are connected to? And in that case
> even things like uRPF aren't going to help you.

ok, so given this 'example':

12:18:33.072964  In IP6 (hlim 255, next-header: ICMPv6 (58), length: 32) 
2001:504:0:2::6939:1 > 2001:504:0:2:0:1:5169:1: [icmp6 sum ok] ICMP6, 
neighbor solicitation, length 32, who has 2001:504:0:2:0:1:5169:1
 	  source link-address option (1), length 8 (1): 00:0c:db:fb:23:00
12:18:33.073021 Out IP6 (hlim 255, next-header: ICMPv6 (58), length: 24) 
2001:504:0:2:0:1:5169:1 > 2001:504:0:2::6939:1: [icmp6 sum ok] ICMP6, 
neighbor advertisment, length 24, tgt is 2001:504:0:2:0:1:5169:1, Flags 
[router, solicited]


2001:504:0:2::6939:1 asks for the addr of: 2001:504:0:2:0:1:5169:1

who replies:
2001:504:0:2:0:1:5169:1 > 2001:504:0:2::6939:1: [icmp6 sum ok] ICMP6,
neighbor advertisment, length 24, tgt is 2001:504:0:2:0:1:5169:1,

so, is the FIB entry populated from the 'tgt is ...' or the src-addr of 
the icmpv6 packet? :) Cause if it's the src-addr we're all cool (can 
filter, might suck, but can filter) If it's from the 'tgt is ...' we're 
collectively screwed (until software/hardware upgrade happens), eh?

-Chris



More information about the nsp-security mailing list