North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: peering requirements (Re: DDOS anecdotes)
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 [email protected] 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 protected]> // 408.859.4137 voice
|