From owner-freebsd-security  Sat Jan 22  3:22:48 2000
Delivered-To: freebsd-security@freebsd.org
Received: from gate.az.com (gate.az.com [216.145.8.252])
	by hub.freebsd.org (Postfix) with ESMTP id 41FF9154D1
	for <security@FreeBSD.ORG>; Sat, 22 Jan 2000 03:22:46 -0800 (PST)
	(envelope-from yankee@gate.az.com)
Received: (from yankee@localhost)
	by gate.az.com (8.8.5/8.8.5) id DAA16378;
	Sat, 22 Jan 2000 03:22:32 -0800 (PST)
Date: Sat, 22 Jan 2000 03:22:31 -0800 (PST)
From: "Dan Seafeldt, AZ.COM System Administrator" <yankee@az.com>
To: sthaug@nethelp.no
Cc: gdonl@tsc.tdk.com, security@FreeBSD.ORG
Subject: MAPS effort / CISCO 12.0
In-Reply-To: <58522.948538783@verdi.nethelp.no>
Message-ID: <Pine.BSF.3.91.1000122031405.13757C-100000@gate.az.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


I have a CISCO router upgraded to pre-release 12.0 and will look at that. 
And regarding the mention of MAPS effort, I thought about that but I was
worried about all the ISP's out there who may use one
gateway/router to connect 2 separate upstream netblocks without any use of
BGP. In this case, it is possible that outbound packets will always go
through one upstream ISP even though the returns end up going through 2
different ISP's For example, a CISCO 2600 series with one Frame Relay
connection and 2 PVCS to two different upsteams, and the gateway set to one
of these PVC's with a different class C coming down each PVC's

I could see where an egress block enabled by the upstream provider who is
not the gateway would shut down access to that class C. Not all ISP's can
afford to or understand how to implement BGP but want some amount of
redudancy or additional bandwidth via 2 different upstreams. 


On Sat, 22 Jan 2000 sthaug@nethelp.no wrote:

> > At some point in the chain of routers during a reverse route trace back,
> > the key router that was originally spoofed would figure out where the
> > packet REALLY came from and realize it was different than the originally
> > documented source address in its history/route table. Sort of like, Hey -
> > I don't have a destination to you and I'm getting complaints about you 
> 
> This exists in Cisco IOS 12.0, and also 11.1CC. It's a per-interface
> setting called "ip verify unicast reverse-path", and will indeed check
> the source address against the routing tables. A couple of caveats:
> 
> - Not really all that usable for core routers, since it doesn't work
> reliably for asymmetric routing paths. You need to do this at the edge
> routers. It's still much better than having to make an access list per
> interface, though.
> 
> - Requires you to run CEF.
> 
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message