peering requirements (Re: DDOS anecdotes)
... 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.
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@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.
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@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@gothik.org> // 408.859.4137 voice
On Sat, 23 Jun 2001, Eric Oosting wrote:
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?
Assymmetrical routing is a good one (see the reference Roland Dobbins posted for part of the story). Half the networks here are advertised out of different places from which the packets leave. This is mainly due to having one way satellite links. Sure the networks are advertised somewhere, but it's on the other side of the world (and to a bunch of different providers) from where we send the packets to you. Another one we have is a pop with a small link and larger link. To make some use out of the small link you might advertise only some networks at the pop. But at the same time outgoing traffic from any of the networks at that pop may go out that link. Sure you could prepend everything half a dozen times but some people ignore prepends for directly connected peers so this won't work (we tried it, we know). Another point, if people are going to have filters then they MUST have a quick and easy way for this filters to be changed and to propogate everywhere quickly. People who insist that you provide an exact list of what you want to advertise (with the exact prefixes) and then take a week to process any changes (or 12 hours for that matter) should have prices to match their discount level of service. -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon@darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
Which is where the IRR is supposed to come in. Simon Lyall wrote:
On Sat, 23 Jun 2001, Eric Oosting wrote:
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?
Assymmetrical routing is a good one (see the reference Roland Dobbins posted for part of the story).
Half the networks here are advertised out of different places from which the packets leave. This is mainly due to having one way satellite links.
Sure the networks are advertised somewhere, but it's on the other side of the world (and to a bunch of different providers) from where we send the packets to you.
Another one we have is a pop with a small link and larger link. To make some use out of the small link you might advertise only some networks at the pop. But at the same time outgoing traffic from any of the networks at that pop may go out that link. Sure you could prepend everything half a dozen times but some people ignore prepends for directly connected peers so this won't work (we tried it, we know).
Another point, if people are going to have filters then they MUST have a quick and easy way for this filters to be changed and to propogate everywhere quickly. People who insist that you provide an exact list of what you want to advertise (with the exact prefixes) and then take a week to process any changes (or 12 hours for that matter) should have prices to match their discount level of service.
-- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon@darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
-- ------------------------------------------------------------ Roland Dobbins <mordant@gothik.org> // 408.859.4137 voice
Hello Eric, Automagicness, you are asking for, is a beautiful thing, but in a reality, sometimes, assumption that Internet traffic is symmetrical, and a destination address of all your IP packets is 100% coherent with your BGP advertisements, can be false. Nearly all of our satellite connected POPs fall into this category. We are sending traffic up through the terrestial fiber links on which we don't (want to) BGP advertise it, and we expect to receive traffic from the sky, from our sattelite providers, so in such (over)simplyfied automagic algorithm for building "huger" ACL config lists we would be simply rejected. -- Besides -- The whole NANOG-mail-thread about "DDOS anecdotes", and grc.com, and DDoS somehow drifted into anti-spoofing disputes. But - unfortunately -- even in a perfect, "IP-unspoofable" ISP-land "(if that were a word" :-), somebody "0wning 1000 windoze boxen with customized IRC bots" will do the very same damage as some devil IP spoofer. Regardless of their (XP) IP stack vulnerability to IP spoofing or not. Those concerted DDoS attacks __don't require__ spoofing at all. The keyword there is "Distributed" -- they are dangerous and disturbing, but not because of lack of cooperation between ISPs in fight against IP spoofing, but because there are not known techniques and methods to fight against somebody stealth-ing his/her attack behind so many <really> distributed hosts that we don't know how to ACL them. You asked for thoughts -- here are my $.002 Przemek (IFXer always complainig about good (too)strict Netrail? BGP policies) -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Eric Oosting Sent: Saturday, June 23, 2001 9:41 PM To: Paul Vixie Cc: nanog@merit.edu Subject: Re: peering requirements (Re: DDOS anecdotes) 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@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.
participants (5)
-
Eric Oosting -
Paul Vixie -
Przemyslaw Karwasiecki -
Roland Dobbins -
Simon Lyall