Oy, Le 10 mai 07 à 16:49, Pekka Savola a écrit :
> On Thu, 10 May 2007, Jeroen Massar wrote: >> As such, when you are a transit provider, and you have on the >> edges of >> your network some vulnerable hosts, those hosts can be used to apply >> this attack to your network. >> >> The documentation should thus specify that, where possible, RH0 >> should >> be filtered at customer borders. > > Well, IMHO that's a bit unnecessary. > > If you see packet ping-pong on the Internet, it's an indication that > ingress and egress filters haven't been adequately set up. Adding > those will stop your network's bandwidth being wasted. > > Maybe this RH0 vulnerability will turn out for the good after all if > it means better BCP38/84 deployment :-) I agree. To sum up : - ingress filtering will prevent the use of clients unpatched/non compliant clients nodes for bouncing RH0 traffic towards the internet. This will limit potential attacks to internal networks in the worst case scenario (if nothing is done by site administrators). This is efficiently implemented as this is done on the leaves. This does not impacts clients for regular traffic (including MIPv6). - on core routers, if RH0 are not processed as a result of deprecation/deactivation, this prevents their use for bouncing RH0 traffic: this also makes the Hop Limit an effective mean for limiting things too as the average distance between 2 possible waypoints (non compliant / unpatched) will be far higher than at the moment. In worst case scenario, an attacker could use 2 leaves in the network (i.e. in a single ISP network) and locally wastes some bandwidth. Basically, this will motivate the network operator to implement ingress filtering ;-) As deprecation also guarantees attackers won't be able to target service on compliant hosts, only unpatched/unfiltered ones will undergo attacks (in worst case scenario). Cheers, a+ -- Arnaud Ebalard EADS Innovation Works - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
