Hi *,

Le 26 avr. 07 à 02:39, Bob Hinden a écrit :

> [trimming this to just the IPv6 w.g.]
>
> We think the question for the IPv6 working group on this topic is
> does the working group want to do anything to address the issues
> raised about the Type 0 routing header.  Possible actions include:
>
>   1) Deprecate all usage of RH0
>   2) Recommend that RH0 support be off by default in hosts and routers
>   3) Recommend that RH0 support be off by default in hosts
>   4) Limit it's usage to one RH0 per IPv6 packet and limit the number
> of addresses in one RH0.
>
> These examples are not all mutually exclusive.
>
> Please respond to the list with your preference and justifications.

After the time spent playing with the mechanism, my conclusion is  
that RH0 is clearly too powerful and impacting to still allow core  
routers and even simple routers to process it by default. For host  
case, forwarding of packets with RH0 is an error (quite obviously)  
and even processing is questionable.

Regarding the needs, 99.999...% of worldwide IPv6 traffic does not  
use the mechanism and still perfectly flows. The remaining part is  
from researchers or attackers that want to DoS infrastructure  
elements or bypass filtering devices. Just as Paul Vixie asked, I  
would also be interested to hear from people that use it in a day to  
day basis and for valid reasons.

Where some will argue that you can still filter incoming traffic that  
includes Type 0 Routing Header in destination sites, this is clearly  
not a solution, but only a bad workaround as it may still be too late  
at that point.

If 4) is selected and even if a low number of addresses are allowed,  
anycast will still be defeated. Among others, maintainers of  
infrastructures that uses this routing scheme should be asked before  
selecting that action.

If 3) is selected and hosts simply drop all packets that include RH0  
(_even_ those with a null SegLeft value), this will clearly limit the  
interest of the mechanism for attackers, as none of their packets  
will be processed on an ultimate destination (I mean upper layer  
processing in default configuration). This action will not prevent  
amplification issues.

If 2) is selected, this will also prevent attackers from using the  
mechanism on routers (on networks that are not specifically  
configured to accept it) to perform all the nasty things Philippe and  
I presented. This idea has already been ported to the attention of  
vendors (Cisco and Juniper) as the default configuration of their  
routers at the moment is to support RH0 by default (as expected from  
the specification). From my perspective, this action should be  
selected if 1) has too many side effects.

If 1) is selected, this would simplify the specification (more than  
15% deals with RH), simplify stacks and would also put a final  
conclusion to the blind source routing issues that bother everyone  
for years. My preference goes to this one. IMHO, the main concern  
associated with that removal is MIPv6: the side effects on RH2 should  
be carefully considered, if any.

hope this helps,

Regards,

a+

-- Arnaud Ebalard
EADS Innovation Works - IT Sec Research Engineer
PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to