On Sat, 11 Jun 2011 10:45:37 +0930 Mark Smith <[email protected]> wrote:
> Hi Fernando, > > > On Fri, 10 Jun 2011 18:51:12 -0300 > Fernando Gont <[email protected]> wrote: > > > Hi, > > > > Some folks have expressed (both on-list and off-list) that they would > > prefer a less agressive solution for the RA-Guard evasion vulnerability. > > So I'd like to hear comments about the possible alternatives.. > > > > The current I-Ds (draft-gont-6man-nd-extension-headers and > > draft-gont-v6ops-ra-guard-evasion) basically take this approach: > > > > * Prohibit use of extension headers in ND messages. A host > > implementation must not produce these packets, and must discard them if > > it receives them > > * This results in a RA-Guard implementation that is as simple as > > possible (it only has to look at the header following the fixed IPv6 > > header). > > > > 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. > > fe80::/16 - hosts and "legacy untyped" link local address use > fe81::/16 - neighbor discovery address resolution > fe82::/16 - router functions e.g. RAs, ICMPv6 redirects > fe83::/16 - dhcpv6 server functions > fe84::/16 - RIP messages and next-hops > fe85::/16 - OSPF messages and next-hops > fe86::/16 - IS-IS next hop > fe87::/16 - BGP messages and next-hops > etc. > > (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. > corresponding function as a source address e.g. > > fe80::1 - normal link-local unicast communications > fe81::1 - neighbor discovery address resolution functions > fe82::1 - router related functions (RAs, ND redirects) > fe83::1 - dhcpv6 server related functions > > I'd think "RA guard" type filtering would then be pretty easy in layer > 2 devices, as these bits have a fixed location in the IPv6 header, and > the filtering would be a binary match on a 16 bit value. For a > switch interface facing a router, the switch would only accept > fe80::16, fe81::/16 and fe82::/16 link local source addresses. should have been fe80::/16, fe81::/16, fe82::/16 and fe83::/16 > For a > switch interface facing a host, the switch would only accept fe80::16 fe80::/16 > 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 > 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. > > 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. > > 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. I don't have access to much of a test environment > at the moment as I'm between jobs, so I'm limited to what I can test > with a few Linux boxes. > > Encoding a device type or function in network layer addresses isn't a > new idea, IIRC in appletalk they had clients use the lower 0 - 127 node > addresses and servers use the higher 128 - 255 addresses on a cable > number. > > > Regards, > Mark. > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
