Hi Fernando,
On Fri, 10 Jun 2011 18:51:12 -0300 Fernando Gont <ferna...@gont.com.ar> 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 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. For a switch interface facing a host, the switch would only accept 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. > > A more relaxed approach would be as follows: > * Extension headers are allowed with ND messages. > * If the packet is fragmented, the upper-layer header (ICMPv6 in this > case) must be present in the first fragment (i.e., hosts must not > generate packets that violate this requirement, and must discard them if > they receive them). > * Possibly have the RA-Guard box enforce a limit on the maximum number > of extension headers that it will process (e.g., if after jumping to > the, say 10th header the upper-layer header is not found, drop the packet) > * This approach is less aggressive than the one proposed in the > aforementioned I-Ds (i.e., more flexibility), but of course would also > mean that the RA-Guard implementation would need to follow the header > chain, thus leading to increased complexity, and possible performance > issues. > > Any comments/thoughts will be very much appreciated. > > 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 > > > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
