Hi, Mark, On 06/10/2011 10:51 PM, Mark Smith wrote: >> If changing host implementations is an option, then a simpler idea >> might be to have RAs come from a source address from within a well-known >> range of link-local addresses. The 11th to 16th bits (or more) after >> the fe80 in the link local address could be used to indicate the type >> of address e.g.
This might help with attack vectors based on forged RAs, but not with other vectors (e.g., forged Neighbor Advertisements). Also, your proposal modifies the addressing architecture -- while this is not "per se" a bad thing this is a more radical change than the one proposed in my I-D (which, as far as legitimate traffic is concerned, is a no-op, since extension headers with ND are not used for any legitimate purpose). >> (I'm not sure if the routing protocol ones would be useful) >> >> so a device acting as a router, a dhcpv6-server and an host would >> have 3 link local addresses, using each different one for the > ^ > should be 4, realised that there probably would be value in having a > separate category for neighbor discovery address resolution while > writing the email, a few similar related errors below. If you don't prevent the use of extension headers for ND (in particular, of the Fragment Header) it's still very painful to perform any kind of monitoring on the Neighbor Discovery traffic (e.g., with NDPMon and the like). >> and fe81::/16. Some IPv6 switches today are able to implement basic >> ACLs including source IPv6 addresses, so once the devices providing >> these functions are using these typed source addresses, there would be Note that this would also require an update to routers (which might not be possible), and would also imply a rather radical change for the ops people (which, imo, at this point in time would be a bad thing). But there seems to be an even more substantial problem: this seems to require a flag day. i.e., how do hosts tell if they are receiving "traditional" RAs because they are under attack, or because the network has not yet been upgraded to implement your proposal? >> an option of implementing this sort of checking today for a number of >> people. I think the key advantage to this idea is that very little >> intensive packet checking has to occur before a forward/drop decision >> can be made. If extension headers are prohibited, you only need to look at fixed locations in the packet (IPv6 "Next Header", and then ICMP type). >> Hosts would have to implement these checks too. Until they're >> implemented in the IPv6 stack, an interim option would be to use the >> host's IPv6 firewall to perform these source address type checks. E.g., >> to only accept RAs from an allowed router, check the RA came from a >> link-local address with fe82::/16 in it's source address. But the RA-Guard box would still need to deal with the "traditional" RAs, since there might be legacy hosts that would react to them. >> I think the only outstanding issue might be is whether existing IPv6 >> implementations will allow or accept non-fe80::/16 link local >> source and destination addresses addresses until their IPv6 stacks are >> updated. I think it is possible that they would, as long as they aren't >> checking the values of the 54 zero bits between /10 and /64 in today's >> link local addresses. Oh, yes, they do. :-) KAME discards such packets. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
