Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt

["Ebalard, Arnaud" <[e-mail]>]

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
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------