Re: Different view on RH0: it is good to take out unmaintained networks

[Tim Enos <timbeck04 at verizon.net>]

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 worFrom ipv6-bounces at ietf.org Mon May 14 10:37:48 2007
Return-path: <ipv6-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HnbgG-000731-MS; Mon, 14 May 2007 10:37:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbgF-00072q-0Z
	for ipv6 at ietf.org; Mon, 14 May 2007 10:37:43 -0400
Received: from vms044pub.verizon.net ([206.46.252.44])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbgE-0000uh-Ng
	for ipv6 at ietf.org; Mon, 14 May 2007 10:37:42 -0400
Received: from vms226.mailsrvcs.net ([192.168.1.2])
	by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01
	(built Apr
	3 2006)) with ESMTPA id <0JI10013HCMSER10 at vms044.mailsrvcs.net> for
	ipv6 at ietf.org; Mon, 14 May 2007 09:37:40 -0500 (CDT)
Received: from 129.55.200.20 ([129.55.200.20])
	by vms226.mailsrvcs.net (Verizon Webmail) with HTTP; Mon,
	14 May 2007 09:37:40 -0500 (CDT)
Date: Mon, 14 May 2007 09:37:40 -0500 (CDT)
From: Tim Enos <timbeck04 at verizon.net>
X-Originating-IP: [129.55.200.20]
To: IETF IPv6 Mailing List <ipv6 at ietf.org>,
	IPv6 Ops list <ipv6-ops at lists.cluenet.de>, Jeroen Massar <jeroen at unfix.org>
Message-id: <27659123.8348471179153460329.JavaMail.root at vms226.mailsrvcs.net>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: 
Subject: Re: Different view on RH0: it is good to take out unmaintained
	networks
X-BeenThere: ipv6 at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6 at ietf.org>
List-Help: <mailto:ipv6-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=subscribe>
Errors-To: ipv6-bounces at ietf.org

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


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