On Fri, 29 Apr 2005, Howard C. Berkowitz wrote:
At 1:34 PM +0000 4/29/05, Christopher L. Morrow wrote:
On Fri, 29 Apr 2005, Howard C. Berkowitz wrote:
I've seen some Cisco security presentations that include sinkholes composed of an ingress and egress router, interconnected with a switch. The switch provides access for tools such as packet analyzers, IDS, routing analyzers, etc. The multiple routers also provide more horsepower for inspection, filtering, and overhead-imposing measurements such as NetFlow.
the multiple routers could just be a way to get a MAC to the ingress router for delivery over the ethernet... a sun/linux/bsd/*unix box might provide the same function. (please logging, analysis, ids, flow collection)
The architecture described doesn't have the two routers treating the Ethernet as a destination:
SinkholeIn--->Switch------>SinkholeOut | | analyzers
hrm, 'sinkhole' to me always means 'hole' not 'sinkpassthrough'. normally if we do this we just drop the traffic in a hole we can look at, then release the route later after analysis. With the 'in/out' concept you have to provide a manner to tunnel away from the hole, else you end up looping back through it indefinitely (or so it would seem).
I am unclear about the BGP relationship between the two routers, which are meant to be treated as one subsystem. The ingress router (with respect to the outside) clearly has to have its BGP isolated from the rest of the AS, so it can't be part of the iBGP mesh.
why can't it be part of the ibgp mesh? I'm not sure I see why that would be BAD, aside from it bouncing under load and affecting all ibgp neighbors... so, aside from route-churn and neighbor setup/teardown churn what other reasons?
The most basic is whether I am diverting a maliciously inserted route to it from the edge router.
uhm, so you put a /32 into the sinkhole all traffic to that destination in your network heads there. What 'maliciously inserted route' are you talking about? something a customer of yours sends you?