Tracking stealth portscan/pepsi attacks

> Last month I described the idea of an special prefix access
> list on de.comm.internet.routing that basically solves that
> problem.
>
> The syntax would look something like this:
>
>  'access-list 1000 permit bgp-neighbor 1.2.3.4 received-networks'
>  'access-list 1100 permit bgp-neighbor 1.2.3.4 announced-networks'
>
> It simply conscructs an automatic ip prefix access-list based
> on the prefixes received/announced to/from the BGP peer. This
> has the cute side effect that all ip filters can be done in one
> place; the bgp configuration.

Umm, how is this significantly different from doing RPF (Reverse
Path Forwarding) checks for unicast packets, as I described
earlier, and as already implemented by Cisco?

If I understand what you're trying to do correctly, doing the
"received-networks" would be to just turn on RPF checking on the
incoming interface from the neighbor, while doing "announced-
networks" will mean that you either have to make sure you have
RPF checking on all your edges or that all interfaces on this
particular customer access router has RPF checking turned on.

> The 'permit received-networks' part looks pretty promising for
> an easy implementation because the router has to perform an bgp
> table lookup anyway for each incoming ip packet.

Um, that's not quite correct.  The router does a forwarding table
lookup for the destination address in each packet when doing
packet forwarding; the forwarding table is being built from
(among other sources) the BGP routing database.

Doing the RPF check for unicast packets adds a second forwarding
table lookup for each packet (look up the source and see if the
packet entered on an interface where we have a route pointing
back out), so it does have a cost, but demanding CEF (as Cisco
does) reduces that cost over the other potential alternatives.


Regards,

- Håvard