peering requirements (Re: DDOS anecdotes)

Sun Jun 24 01:41:20 UTC 2001

Has there been any work done, or is it even a good idea to implement
something kinda like the RPF check in Multicast, but for unicast, that
could be used on interfaces at AS boundaries.

As each packet is accepted on an interface, the source address of the
packet could be checked as being in a prefix that is advertised by the bgp
peer that sent you the packet. This could be done by the router, with only
a config statement on the interface to turn it on. The idea being that if
another AS sends you a packet with a particular source address, they
better have a way back to the source. Packets that did not meet this
criteria could either be denied or logged. (If dumping them is too harsh,
atleast logging them could help track attacks)

This could be useful at peering boundaries for both parties, where full
views are not exchanged. This could also be used by ISPs on customer
interfaces, as long as all potential source addresses are advertised over
the bgp session, which is not necessarily the case with customer sessions.
(Note: Most peering agreements require the same routes advertised at all
points ... not the case with customers)

I know that this could be automated by creating access lists from bgp
advertisements using auto-magic scripts, but it wouldn't be in real time,
making it useless IMHO. It would also make the configs huge. (well, huger,
if that were a word.)

There are the obvious hardware considerations... Can todays hardware
support access lists of this size at line rate? Will they for be able to
for long?

Under what circumstances would the assumption (that an AS should always
advertise a route to the source address of packets it transmits) not be a
good one?

Of course this could be turned around and the capability made to deny or
log packets with a source address that you are not advertising a route to.

Thoughts?

Eric

Eric Oosting               eric at netrail.net        office:404.739.4385
Sr. Network Engineer   Network Eng and Operations         NetRail, Inc

On 23 Jun 2001, Paul Vixie wrote:

> 
> > ... but I do not blame their IP stack for this like Mr Gibson does though.
> 
> Same here.
> 
> > ... From spoofed sources because ISPs do not source address filter?
> > Gah. Basically untraceable.
> 
> This is the problem.
> 
> > What should we do?
> 
> Recommendation: upgrade your peering requirements to include language like:
> 
> 	Each peer agrees to emit only IP packets with accurate
> 	source addresses, to require their customers to do likewise,
> 	and to extend this requirement to all other peers by $DATE.
> 
> Where DATE = (now() + '6 months') or some other negotiated value.
> 
> I've been saying this since 1993.  Is anybody ready to believe me yet?  We
> solve this, or our industry stops growing because we're spending too much
> time dealing with this problem and new customers see diminished returns.
> 