peering requirements (Re: DDOS anecdotes)

Sun Jun 24 02:14:16 UTC 2001

It's called unicast-rpf . . . there are special considerations when
you're multihomed, see
http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf.

Eric Oosting wrote:
> 
> 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.
> >

-- 
------------------------------------------------------------
Roland Dobbins <mordant at gothik.org> // 408.859.4137 voice