From owner-freebsd-net@FreeBSD.ORG  Wed Jul 21 11:44:56 2004
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6BE5616A4CE; Wed, 21 Jul 2004 11:44:56 +0000 (GMT)
Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com
	[65.124.16.9])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 4DB9C43D2F; Wed, 21 Jul 2004 11:44:56 +0000 (GMT)
	(envelope-from haesu@mx01.bos.ma.towardex.com)
Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid
	1001)	id AF0372F900; Wed, 21 Jul 2004 07:44:55 -0400 (EDT)
Date: Wed, 21 Jul 2004 07:44:55 -0400
From: James <james@towardex.com>
To: Andre Oppermann <andre@freebsd.org>
Message-ID: <20040721114455.GA47249@scylla.towardex.com>
References: <20040720021237.GA74977@scylla.towardex.com>
	<40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com>
	<40FE4367.AA7B0A7F@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40FE4367.AA7B0A7F@freebsd.org>
User-Agent: Mutt/1.4.1i
cc: freebsd-net@freebsd.org
cc: James <haesu@towardex.com>
Subject: Re: IPFW2 versrcreach update
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2004 11:44:56 -0000

Andre, 

> 
> James,
> 
> it just occured to me; but what is the purpose of versrcreach denying a
> packet that will be discarded a few cycles later anyway?  When I mark
> a route with -reject I want the ICMPs go out and still use the versrcreach
> functionality in ipfw.

The point is to have uRPF loose-check *drop* the packets sourced from IP's that
are null-routed. A null route would discard the packet destined *to* the null
route, but it would never drop a packet *sourced* with an IP within the null
route.

uRPF should not emit an ICMP when it drops a -reject route. Even with 
ip unreachables, Cisco won't emit ICMP when uRPF is killing a packet. The source
that triggered uRPF drop condition cannot be trusted as it may have spoofed the
packet.

-J

-- 
James Jun                                            TowardEX Technologies, Inc.
Technical Lead                        Network Design, Consulting, IT Outsourcing
james@towardex.com                  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net