From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 08:04:42 2004 Return-Path: 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 D71F116A4CE for ; Tue, 20 Jul 2004 08:04:42 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11E3F43D45 for ; Tue, 20 Jul 2004 08:04:42 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 23589 invoked from network); 20 Jul 2004 08:02:38 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 Jul 2004 08:02:38 -0000 Message-ID: <40FCD21B.40CB83ED@freebsd.org> Date: Tue, 20 Jul 2004 10:04:43 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James References: <20040720021237.GA74977@scylla.towardex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2004 08:04:43 -0000 James wrote: > > Andre, et al: > > Previously, in "My planned work on networking stack" thread, Andre made a patch > which allows loose-check uRPF verification using ipfw2. The command syntax is > versrcreach as opposed to verrevpath. The versrcreach simply checks if the > source address has a route other than default. In other words, pass the packet > if the source address is reachable via any interface available where there is a > route for. This is useful in multihomed BGP environment (mostly for service > providers using FreeBSD as routing platform). The message in which Andre posted > patch is below this email, quoted. > > Anyhow, getting straight to business: > The uRPF loose-check implementation by the industry vendors, at least on Cisco > and possibly Juniper, will fail the check if the route of the source address > is pointed to Null0 (on Juniper, discard or reject route). What this means is, > even if uRPF Loose-check finds the route, if the route is pointed to blackhole, > uRPF loose-check must fail. This allows people to utilize uRPF loose-check mode > as a pseudo-packet-firewall without using any manual filtering configuration -- > one can simply inject a IGP or BGP prefix with next-hop set to a static route > that directs to null/discard facility. This results in uRPF Loose-check failing > on all packets with source addresses that are within the range of the nullroute. > > Under verify_path() in ip_fw2.c patch Andre provided, I'd like to propose > possibly including the following line of change I'm thinking about in my head > right now. > > /* if no ifp provided, check if rtentry is not default route */ > if (ifp == NULL && > satosin(rt_key(ro.ro_rt))->sin_addr.s_addr == INADDR_ANY) { > RTFREE(ro.ro_rt); > return 0; > } > > + /* by this point a route is found. check if this is pointed > + * to blackhole/reject */ > + if (ifp == NULL && ro.ro_rt->rt_flags & (RTF_REJECT|RTF_BLACKHOLE) ) { > + RTFREE(ro.ro_rt); > + return 0; > + } > > Haven't tested this yet, but will do tomorrow after I finish some other stuff > I need done before rebooting w/ a test kernel. Tell me what the test results are. > Anyway the idea is to fail the check if the route has RTF_REJECT or > RTF_BLACKHOLE flag, under loose-check (ifp set to NULL) operation, which is > an easy straight forward change. How do you set the RTF_REJECT or RTF_BLACKHOLE flags on a route with Zebra/ Quagga and friends? -- Andre > Thanks, > -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 > > > > > Here you go: > > > > http://www.nrg4u.com/freebsd/ipfw_versrcreach.diff > > > > This one implements the standard functionality, the definition of an > > interface through which it has to be reachable is not (yet) supported. > > > > Using this option only makes sense when you don't have a default route > > which naturally always matches. So this is useful for machines acting > > as routers with a default-free view of the entire Internet as common > > when running a BGP daemon (Zebra/Quagga or OpenBSD bgpd). > > > > One useful way of enabling it globally on a router looks like this: > > > > ipfw add xxxx deny ip from any to any not versrcreach > > > > or for an individual interface only: > > > > ipfw add xxxx deny ip from any to any not versrcreach recv fxp0 > > > > I'd like to get some feedback (and a man page draft) before I commit it > > to -CURRENT. > > > > -- > > Andre