[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: Different view on RH0: it is good to take out unmaintained
From:       Tim Enos <timbeck04 () verizon ! net>
Date:       2007-05-14 14:37:49
Message-ID: 27683277.8348601179153469759.JavaMail.root () vms226 ! mailsrvcs ! net
[Download RAW message or body]

Hi Jeroen/all,

> Hi,
> 
> A little mail for a nice Monday morning discussion/flamebait:
> 
> I became to realize that RH0 filtering is at all not really necessary.
> 
> 
> Networks who have uRPF enabled, they check the source of the packet and
> as such the packet pingpong doesn't work, yes the packet arrives, but
> when the packet has to be sent out onto the network again, it gets
> caught by the uRPF filter.
> 
> Networks who do not have uRPF enabled and thus are not properly checking
> where a packet is actually being sourced from are open to the RH0 attack.
> 
> As such, any network which does not have uRPF enabled is vulnerable to
> some nice RH0 packet ping ponging.
> 
> Now, what we should hope is that people actually do NOT filter out RH0
> and then send out a lot of packets with RH0 headers ping ponging
> throughout the Internet. This will take care that the networks who are
> not properly applying uRPF will in effect nicely melt down.
> 
> Maybe that brings to their attention that doing uRPF is actually a good
> thing as is being specified in BCP38 (BCP stands for Best Common
> Practices, but clearly a lot of networks don't take it in common).

Sort of a re-hash of my 11May07 posting:

The authors of BCP 38 clearly decided against also doing strict RPF because of the \
number of asymmetric routes in the Internet. If any kind of RPF is to be done in \
conjunction with ingress filtering (on the edge), it would not be the strict kind.

It was pointed out (correctly I believe) that with the implementation of BCP 38 (aka \
RFC 2827) on the edges, potential for ping-ponging RH0 traffic would be limited (at \
worst) to internal networks.

Should site administrators implement (loose) RPF in the cores of their respective \
networks, internal attacks would be mitigated (if the source address being spoofed is \
not in the routing table of the core router that receives the packet).

In intended validation of earlier e-mail, support from major router vendors for these \
features lags behind specification/recommendation for their use. Strict RPF clearly \
will not work well on peering and transit interfaces.

> 
> Greets,
> Jeroen

Best Regards,

Tim Enos
Rom 8:28

> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]