Re: Sinkhole Architecture

["Christopher L. Morrow" <christopher.morrow () mci com>]

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?