lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 30 Sep 2007 23:27:35 -0400 From: Brian Haley <brian.haley@...com> To: YOSHIFUJI Hideaki / ???? <yoshfuji@...ux-ipv6.org> Cc: dlstevens@...ibm.com, davem@...emloft.net, netdev@...r.kernel.org Subject: Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address Hi Yoshifuji, YOSHIFUJI Hideaki / ???? wrote: > Dave, Brian, > > Let me double check this patch. > > Regards, > > --yoshfuji > > In article <OF5FC97D70.5FD0A80A-ON88257365.00025E58-88257365.00048D1E@...ibm.com> (at Fri, 28 Sep 2007 17:50:38 -0700), David Stevens <dlstevens@...ibm.com> says: > >> 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 :-)), TAHI generates a lot of packets that shouldn't happen :) see below for the problem. The patch in ndisc_send_redirect() is probably unnecessary, but since the code was identical I figured it wouldn't hurt. >> 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)) 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 IP.....................3001:0000:0000:0000:0200:10FF:FE10:1180 Destination IP................3000:0000:0000:0000:021A:4BFF:FEEB:FCE6 Icmpv6 Type....................................0x80 Code....................................0x00 Identifier..............................0x0000 Sequence Number.........................0x0000 Data....................................0x00 Packet 12 : Icmpv6 : Echo Reply Ethernet Destination MAC.........................33:33:00:00:00:01 Source MAC..............................00:1A:4B:EB:FC:E6 Ipv6 Version.................................6 Next Header.............................58 Hop Limit...............................64 Source IP.....................3000:0000:0000:0000:021A:4BFF:FEEB:FCE6 Destination IP................3001:0000:0000:0000:0200:10FF:FE10:1180 Icmpv6 Type....................................0x81 Code....................................0x00 Identifier..............................0x0000 Sequence Number.........................0x0000 Data....................................0x00 This should have been sent to 00:00:10:10:10:60 -Brian - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists