North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: peering requirements (Re: DDOS anecdotes)
- From: Roland Dobbins
- Date: Sat Jun 23 22:08:17 2001
It's called unicast-rpf . . . there are special considerations when
you're multihomed, see
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.
> Eric Oosting firstname.lastname@example.org 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 <email@example.com> // 408.859.4137 voice