North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Sinkhole Architecture

  • From: Christopher L. Morrow
  • Date: Fri Apr 29 11:43:27 2005

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?