[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