Home » Mailing list archives » linux-netdev » 2007 » October » 1

Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address

Previous thread: Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING by Cedric Le Goater on Friday, September 28, 2007 - 8:42 am. (9 messages)

Next thread: /proc/net/ bad hard links count [Was: 2.6.23-rc8-mm2] by Jiri Slaby on Friday, September 28, 2007 - 9:30 am. (2 messages)
[view original message]
From: Brian Haley
Subject: [IPV6] Fix ICMPv6 redirect handling with target multicast address
Date: Friday, September 28, 2007 - 9:26 am

When the ICMPv6 Target address is multicast, Linux processes the 
redirect instead of dropping it.  The problem is in this code in 
ndisc_redirect_rcv():

         if (ipv6_addr_equal(dest, target)) {
                 on_link = 1;
         } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
                 ND_PRINTK2(KERN_WARNING
                            "ICMPv6 Redirect: target address is not 
link-local.\n");
                 return;
         }

This second check will succeed if the Target address is, for example, 
FF02::1 because it has link-local scope.  Instead, it should be checking 
if it's a unicast link-local address, as stated in RFC 2461/4861 Section 
8.1:

       - The ICMP Target Address is either a link-local address (when
         redirected to a router) or the same as the ICMP Destination
         Address (when redirected to the on-link destination).

I know this doesn't explicitly say unicast link-local address, but it's 
implied.

This bug is preventing Linux kernels from achieving IPv6 Logo Phase II 
certification because of a recent error that was found in the TAHI test 
suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the 
multicast address in the Destination field instead of Target field, so 
we were passing the test.  This won't be the case anymore.

The patch below fixes this problem, and also fixes ndisc_send_redirect() 
to not send an invalid redirect with a multicast address in the Target 
field.  I re-ran the TAHI Neighbor Discovery section to make sure Linux 
passes all 245 tests now.

-Brian


Signed-off-by: Brian Haley <brian.haley@hp.com>


[ message continues ]
[view original message]
From: David Stevens
Subject: Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address
Date: Friday, September 28, 2007 - 5:50 pm

Brian,
        A multicast address should never be the target of a neighbor
discovery request; the sender should use the mapping function for all
multicasts. So, I'm not sure that your example can ever happen, and it
certainly is ok to send ICMPv6 errors to multicast addresses in general.
But I don't see that it hurts anything. either (since it should never 
happen :-)),
so I don't particularly object, either.
        I think it'd also be better if you add the check to be:

        if (ipv6_addr_type(target) & 
(IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST))

or something along those lines, rather than reproducing ipv6_addr_type() 
code
separately in a new ipv6_addr_linklocal() function.

                                                +-DLS


-


[ message continues ]
[view original message]
From: YOSHIFUJI Hideaki /
Subject: Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address
Date: Friday, September 28, 2007 - 6:04 pm

Dave, Brian,

Let me double check this patch.

Regards,

--yoshfuji

-


[ message continues ]
[view original message]
From: Brian Haley
Subject: Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address
Date: Sunday, September 30, 2007 - 8:27 pm

Hi Yoshifuji,


TAHI generates a lot of packets that shouldn't happen :) see below for 
the problem.  The patch in ndisc_send_redirect() is probably 

I did have it:

if (ipv6_addr_type(target) &
     (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST) ==
     (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST))

but changed it since I had proposed ipv6_addr_linklocal() in a previous 
patch because there are other possible users of that.

This is the actual packet trace that was sent to me, edited to remove 
non-relevant data, but I've actually been unable to reproduce Packet 12 
below (note the Destination MAC).  My knee-jerk reaction was the 
proposed patch.  It could just be timing-related, I'll do more testing 
Monday.  Strangely, the TAHI test passes anyway, but it shouldn't.

Packet 10 : Icmpv6 : Redirect
Ethernet
Destination MAC.........................00:1A:4B:EB:FC:E6
Source MAC..............................00:00:10:10:10:60
Ipv6
Version.................................6
Next Header.............................58
Hop Limit...............................255
Source IP.....................FE80:0000:0000:0000:0200:10FF:FE10:1060
Destination IP................3000:0000:0000:0000:021A:4BFF:FEEB:FCE6
Icmpv6
Type....................................0x89
Code....................................0x00
Reserved................................0x00000000
Target Address................FF02:0000:0000:0000:0000:0000:0000:0001
Destination Address...........3001:0000:0000:0000:0200:10FF:FE10:1180
Options
LLAddressOption
   Option Type.............................2
   Option Length...........................1
   Link-Layer Address......................0x000010101061

Packet 11 : Icmpv6 : Echo Request
Ethernet
Destination MAC.........................00:1A:4B:EB:FC:E6
Source MAC..............................00:00:10:10:10:60
Ipv6
Version.................................6
Next Header.............................58
Hop Limit...............................255
Source ...
[ message continues ]
[view original message]
From: YOSHIFUJI Hideaki /
Subject: Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address
Date: Monday, October 1, 2007 - 4:49 am

Hello.


I'm fine with the idea of the fix itself.

Please use ipv6_addr_type() so far and convert other users as well
to ipv6_addr_linklocal() in another patch.

Regards,

--yoshfuji

-


[ message continues ]
[view original message]
From: Brian Haley
Subject: Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address
Date: Monday, October 1, 2007 - 10:36 am

Hi,



I'll re-do the patch.

-Brian
-


[ message continues ]
[view original message]
From: Brian Haley
Subject: [IPv6] Fix ICMPv6 redirect handling with target multicast address
Date: Tuesday, October 2, 2007 - 12:18 pm

When the ICMPv6 Target address is multicast, Linux processes the 
redirect instead of dropping it.  The problem is in this code in 
ndisc_redirect_rcv():

         if (ipv6_addr_equal(dest, target)) {
                 on_link = 1;
         } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
                 ND_PRINTK2(KERN_WARNING
                            "ICMPv6 Redirect: target address is not 
link-local.\n");
                 return;
         }

This second check will succeed if the Target address is, for example, 
FF02::1 because it has link-local scope.  Instead, it should be checking 
if it's a unicast link-local address, as stated in RFC 2461/4861 Section 
8.1:

       - The ICMP Target Address is either a link-local address (when
         redirected to a router) or the same as the ICMP Destination
         Address (when redirected to the on-link destination).

I know this doesn't explicitly say unicast link-local address, but it's 
implied.

This bug is preventing Linux kernels from achieving IPv6 Logo Phase II 
certification because of a recent error that was found in the TAHI test 
suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the 
multicast address in the Destination field instead of Target field, so 
we were passing the test.  This won't be the case anymore.

The patch below fixes this problem, and also fixes ndisc_send_redirect() 
to not send an invalid redirect with a multicast address in the Target 
field.  I re-ran the TAHI Neighbor Discovery section to make sure Linux 
passes all 245 tests now.

-Brian


Signed-off-by: Brian Haley <brian.haley@hp.com>


[ message continues ]
[view original message]
From: David Stevens
Subject: Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address
Date: Tuesday, October 2, 2007 - 1:39 pm

Brian,
        ipv6_addr_type() returns a mask, so checking for equality will 
fail to
match if  any other (irrelevant) attributes are set. How about using 
bitwise
operators for that? Also, the error message is no longer descriptive of 
the
failure if it's a link-local multicast, but you could make it "target 
address is not
link-local unicast.\n" (in both places).

                                                +-DLS

-


[ message continues ]
[view original message]
From: Brian Haley
Subject: Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address
Date: Tuesday, October 2, 2007 - 2:06 pm

Hi David,


ipv6_addr_type() does return a mask, but there's a lot of code that just 
checks for equality since some things are mutually-exclusive - this code 
is actually identical to what ip6_route_add() does.  I don't 
particularly like this duality, but it's there - I'd gladly volunteer to 
clean this up everywhere if I didn't think there might be some 

I can do that, thanks.

-Brian
-


[ message continues ]
[view original message]
From: David Stevens
Subject: Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address
Date: Tuesday, October 2, 2007 - 3:41 pm

Brian,
        I don't think a few instructions is a performance issue in the 
redirect
paths (it'd be pretty broken if you're getting or generating lots of 
them), but I
know there are lots of other checks similar to that that will break with 
new
attributes, so doing that as a general clean-up separately is ok with me, 
too.

With the error message changes, you can add:

Acked-by: David L Stevens <dlstevens@us.ibm.com>

FWIW. :-)

                                                +-DLS


-


[ message continues ]
[view original message]
From: Brian Haley
Subject: [IPv6] Fix ICMPv6 redirect handling with target multicast address, try 3
Date: Wednesday, October 3, 2007 - 7:44 am

When the ICMPv6 Target address is multicast, Linux processes the 
redirect instead of dropping it.  The problem is in this code in 
ndisc_redirect_rcv():

         if (ipv6_addr_equal(dest, target)) {
                 on_link = 1;
         } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
                 ND_PRINTK2(KERN_WARNING
                            "ICMPv6 Redirect: target address is not 
link-local.\n");
                 return;
         }

This second check will succeed if the Target address is, for example, 
FF02::1 because it has link-local scope.  Instead, it should be checking 
if it's a unicast link-local address, as stated in RFC 2461/4861 Section 
8.1:

       - The ICMP Target Address is either a link-local address (when
         redirected to a router) or the same as the ICMP Destination
         Address (when redirected to the on-link destination).

I know this doesn't explicitly say unicast link-local address, but it's 
implied.

This bug is preventing Linux kernels from achieving IPv6 Logo Phase II 
certification because of a recent error that was found in the TAHI test 
suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the 
multicast address in the Destination field instead of Target field, so 
we were passing the test.  This won't be the case anymore.

The patch below fixes this problem, and also fixes ndisc_send_redirect() 
to not send an invalid redirect with a multicast address in the Target 
field.  I re-ran the TAHI Neighbor Discovery section to make sure Linux 
passes all 245 tests now.

-Brian


Signed-off-by: Brian Haley <brian.haley@hp.com>
Acked-by: David L Stevens <dlstevens@us.ibm.com>

[ message continues ]
[view original message]
From: David Miller
Subject: Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address, try 3
Date: Monday, October 8, 2007 - 12:12 am

From: Brian Haley <brian.haley@hp.com>

I believe everyone's concerns have been addressed in this
version of the patch, so I have applied it to net-2.6

Thanks everyone!
-


[ message continues ]
Previous thread: Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING by Cedric Le Goater on Friday, September 28, 2007 - 8:42 am. (9 messages)

Next thread: /proc/net/ bad hard links count [Was: 2.6.23-rc8-mm2] by Jiri Slaby on Friday, September 28, 2007 - 9:30 am. (2 messages)