Re: Reporting DDOS reflection attacks
Out of curiosity, have any of you had luck reporting the sources of attacks to the admins of the origin ASNs? Any failure or success stories you can share? Macca On Sat, Nov 8, 2014 at 6:20 PM, Paul Bennett paul.w.benn...@gmail.com wrote: On Sat, Nov 8, 2014 at 2:00 AM, Roland Dobbins rdobb...@arbor.net wrote: On 8 Nov 2014, at 1:56, srn.na...@prgmr.com wrote: But right now how should we be doing it? http://www.team-cymru.org/Services/ip-to-asn.html Once you get the ASN or at least the domain name of the ISP providing service to the reflecting host, several major reputable ISPs (including my employer, who I can't name because I'm not an official spokesperson) will welcome RFC 5070 IODEF reports for general network abuse and RFC 5965 MARF format for email abuse, directed to abuse@ the main domain for that ISP. http://www.ietf.org/rfc/rfc5070.txt http://www.ietf.org/rfc/rfc5965.txt -- Paul W Bennett
Re: Reporting DDOS reflection attacks
On 8 Nov 2014, at 17:09, McDonald Richards wrote: Any failure or success stories you can share? In my experience, it's the generally broadband access operators who will sometimes respond, when contacted about reflection/amplification attacks leveraging misconfigured, abusable CPE. Generally speaking, networks running misconfigured, abusable devices by definition aren't very actively managed - and so those operators don't often respond, unless one has personal contacts within the relevant group(s). YMMV, of course. --- Roland Dobbins rdobb...@arbor.net
Re: Reporting DDOS reflection attacks
Hey, We've been hit on/off with large scale amplification attacks over the last few years. We found looking up src ASN of the attack and reporting is not super helpful, as many blocks come from sub allocations and you'll just get redirected to someone else. This will just cause more overhead and legwork for you in the long run. Whois data *seems* to be a little more reliable, and there's an abuseEmail script out there that helps automate the abuse contact lookup ( http://abuseemail.sourceforge.net/ ). We've added a bit of logic in front of this to aggregate the flows per destination abuse email, then send a report with all listed flows + timestamp. Feel free to ping me offlist if you want some more info on this. /Ruairi On 7 November 2014 18:56, srn.na...@prgmr.com wrote: Like most small providers, we occasionally get hit by DoS attacks. We got hammered by an SSDP reflection attack (udp port 1900) last week. We took a 27 second log and from there extracted about 160k unique IPs. It is really difficult to find abuse emails for 160k IPs. We know about abuse.net but abuse.net requires hostnames, not IPs for lookups and not all IP addresses have valid DNS entries. The only other way we know of to report problems is to grab the abuse email addresses is whois. However, whois is not structured and is not set up to deal with this number of requests - even caching whois data based on subnets will result in many thousands of lookups. Long term it seems like structured data and some kind of authentication would be ideal for reporting attacks. But right now how should we be doing it?
Re: Reporting DDOS reflection attacks
I can offer an indirect story, and not quite a reflection attack, but a DDoS one. We happen to have a host that had an IPMI board exposed to the net, that got compromised, and became a vector for a DDoS attack. The target reported the attack to at least some of the sources, including Windstream/Hosted Solutions, where this particular server is located. They contacted me, and I dealt with things with about a 1-hour turn-around from when a trouble ticket hit my inbox (well, still dealing with things - that IPMI card is offline until I get around to securing it, and it's the occasional reboot-by-phone-call until then). So at least one small success. Miles Fidelman McDonald Richards wrote: Out of curiosity, have any of you had luck reporting the sources of attacks to the admins of the origin ASNs? Any failure or success stories you can share? Macca On Sat, Nov 8, 2014 at 6:20 PM, Paul Bennett paul.w.benn...@gmail.com wrote: On Sat, Nov 8, 2014 at 2:00 AM, Roland Dobbins rdobb...@arbor.net wrote: On 8 Nov 2014, at 1:56, srn.na...@prgmr.com wrote: But right now how should we be doing it? http://www.team-cymru.org/Services/ip-to-asn.html Once you get the ASN or at least the domain name of the ISP providing service to the reflecting host, several major reputable ISPs (including my employer, who I can't name because I'm not an official spokesperson) will welcome RFC 5070 IODEF reports for general network abuse and RFC 5965 MARF format for email abuse, directed to abuse@ the main domain for that ISP. http://www.ietf.org/rfc/rfc5070.txt http://www.ietf.org/rfc/rfc5965.txt -- Paul W Bennett -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: Reporting DDOS reflection attacks
On 11/07/2014 11:20 PM, Paul Bennett wrote: On Sat, Nov 8, 2014 at 2:00 AM, Roland Dobbins rdobb...@arbor.net wrote: On 8 Nov 2014, at 1:56, srn.na...@prgmr.com wrote: But right now how should we be doing it? http://www.team-cymru.org/Services/ip-to-asn.html Once you get the ASN or at least the domain name of the ISP providing service to the reflecting host, several major reputable ISPs (including my employer, who I can't name because I'm not an official spokesperson) will welcome RFC 5070 IODEF reports for general network abuse and RFC 5965 MARF format for email abuse, directed to abuse@ the main domain for that ISP. http://www.ietf.org/rfc/rfc5070.txt http://www.ietf.org/rfc/rfc5965.txt Thanks, the IP-subnet/ASN lookup and rfc5070 look like exactly what we need to start with. I'm fairly certain it would have gotten us the same contact for all the IPs we reported last week. Since IODEF is so flexible, are there any exact guidelines or examples on how to use it to report a DDOS? For example, should there be a separate XML document for each prefix or one for the entire list? What I found was https://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-03#page-21 but it could use some more explanation.
Re: Clueful Jive Communications Contact?
Thanks to all replies off-list. Contact has been made with all the right people in the right places. It really is amazing to see how active the nanog community is and all the great players involved. Chris On Fri, Nov 7, 2014 at 6:24 PM, chris tknch...@gmail.com wrote: Sorry for the noise but If anyone from Jive Communications is on the list or if anyone has any clueful technical contacts please contact me offlist. I have a very frustrated mutual customer we provide network services to who utilizes Jive for their voice and we can see that there is intermittent reachability problems and all attempts to go through normal support with the information we have provided are going nowhere. Thanks chris
Re: Reporting DDOS reflection attacks
On 11/08/2014 03:30 AM, Ruairi Carroll wrote: Whois data *seems* to be a little more reliable, and there's an abuseEmail script out there that helps automate the abuse contact lookup ( http://abuseemail.sourceforge.net/ ). I believe this script is out of date and I would not use this script without doing a thorough review/update. For example, 100.43.102.0/24 is reported to be reserved but whois clearly shows that it is allocated to Xplornet Communications Inc. Then when I remove the reserved allocation from the script, the abuse email returned is arin.net rather than xplornet.com. Using dig +short 102.43.100.origin.asn.cymru.com TXT and then whois as22995 would have gotten me the same abuse email address as what I originally found.
v6 cdn problems
Prefix this - I'm on fios in the Baltimore area, using a HE tunnel terminating in ashburn. (*still* no native v6 on fios :-( Speedtest shows little or no congestion, and didn't change significantly when I reduced mtu by 8. (interestingly, speedtest.net usually reads faster than verizon's internal speedtest, and rarely averages less than my billed speed.) I've recently had problems (started a few weeks ago with www.att.com, 4-5 days ago with *.google.com) which unfortunately happy eyeballs doesn't help. att.com uses akamai, google uses their own cdn (per dns; I don't know if there are any connections behind the scenes.) This occurs on several google sites, all of which resolve to the same netblocks from here (maps.google.com, www.google.com, maps.gstatic.com, and at least one of the ad servers). Symptom with akamai is that it connects immediately then data transfer times out. With google, symptom involves both slow connection, and data transfer timing out. I don't know if chrome's happy eyeballs is working since if it was, and absent address caching, I shouldn't see the slow connection. v6 connections to my hosts in Los Angeles (not on HE address space, but we do peer with them on any2) work fine transferring graphics and large database files both ways, so I'm pretty sure I don't have an mtu problem nor some other fios or HE problem. Just to be sure, I dropped the 1500 to 1492 on the fios link and did the same adjustment to the mtu on my tunnel (becomes 1472). No change on my hosts. att.com appears a little better, though still very slow. Google shows no change at all. I saw some of the same problem yesterday from Frederick on comcast (only to google, didn't look at att), but couldn't take the time to do traceroutes. If desired, I'm likely to go out there tomorrow and can do that too. (we use a freebsd+pf router there). Is this a provisioning problem where v6 eyeballs are outstripping cdn provisioning (since win7 and 8 both default to v6)? Or is something else going on. Since this seems to affect more than one cdn, it seems odd. I run my own resolver locally instead of using verizon's. (and my own (vyatta) router instead of theirs. Actually I'm still using theirs as a bridge to talk to the set-top box (I don't know if Motorola still makes the coax terminal that would bridge it directly...) Resolve and traceroutes of relevant sites: [pete@port5 ~]$ host www.att.com www.att.com is an alias for prod-www.zr-att.com.akadns.net. prod-www.zr-att.com.akadns.net is an alias for www.att.com.edgekey.net. www.att.com.edgekey.net is an alias for e2318.dscb.akamaiedge.net. e2318.dscb.akamaiedge.net has address 23.76.217.145 e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:9200::90e e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:8600::90e Traceroute (v4) to this shows it is in Newark or environs: [pete@port5 ~]$ traceroute e2318.dscb.akamaiedge.net traceroute to e2318.dscb.akamaiedge.net (23.76.217.145), 30 hops max, 60 byte packets 1 rtr.east.altadena.net (192.168.170.1) 2.008 ms 2.450 ms 3.091 ms 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 9.021 ms 9.054 ms 9.045 ms 3 G0-7-4-5.BLTMMD-LCR-21.verizon-gni.net (100.41.195.94) 10.670 ms 10.683 ms 10.677 ms 4 ae4-0.RES-BB-RTR2.verizon-gni.net (130.81.209.230) 9.002 ms ae20-0.RES-BB-RTR1.verizon-gni.net (130.81.151.112) 8.995 ms so-1-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.199.2) 8.953 ms 5 * * * 6 * * * 7 0.xe-5-0-4.XL3.EWR6.ALTER.NET (140.222.225.73) 51.202 ms 41.102 ms 40.345 ms 8 0.ae1.XL4.EWR6.ALTER.NET (140.222.228.41) 33.065 ms TenGigE0-6-0-3.GW8.EWR6.ALTER.NET (152.63.19.158) 11.550 ms TenGigE0-6-0-6.GW8.EWR6.ALTER.NET (152.63.25.10) 11.659 ms 9 TenGigE0-7-0-1.GW8.EWR6.ALTER.NET (152.63.19.166) 19.854 ms akamai-gw.customer.alter.net (152.179.185.126) 1766.402 ms TenGigE0-7-0-7.GW8.EWR6.ALTER.NET (152.63.25.30) 18.227 ms 10 akamai-gw.customer.alter.net (152.179.185.126) 1747.269 ms a23-76-217-145.deploy.static.akamaitechnologies.com (23.76.217.145) 10.672 ms 11.263 ms Traceroute6 to it appears to be local (but is hard to tell. Next-to-last hop looks like either a router or load-balancer is overloaded. Same for the v4 traceroute... [pete@port5 ~]$ traceroute6 www.att.com traceroute to www.att.com (2600:807:320:202:9200::90e), 30 hops max, 80 byte packets 1 rtr.east.altadena.net (2001:470:e160:1::1) 5.182 ms 5.274 ms 5.254 ms 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.452 ms 15.040 ms 18.592 ms 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 20.273 ms 20.574 ms 20.567 ms 4 eqx.br6.iad8.verizonbusiness.com (2001:504:0:2::701:1) 20.522 ms 20.232 ms 20.475 ms 5 * * * 6 2600:802:44f::2 (2600:802:44f::2) 1283.113 ms 1296.115 ms 1296.181 ms 7 2600:807:320:200::1743:f397 (2600:807:320:200::1743:f397) 20.181 ms 16.169 ms 14.073 ms [pete@port5 ~]$ host www.google.com www.google.com has address
Re: v6 cdn problems
Possibly https://puck.nether.net/pipermail/outages/2014-November/007421.html ? -- Hugo Slabbert Network Specialist Phone: 604.606.4448tel:604.606.4448 Email: hslabb...@stargate.camailto:hslabb...@stargate.ca Stargate Connections Inc. http://www.stargate.cahttp://www.stargate.ca/ On Nov 8, 2014, at 14:56, Pete Carah p...@altadena.netmailto:p...@altadena.net wrote: Prefix this - I'm on fios in the Baltimore area, using a HE tunnel terminating in ashburn. (*still* no native v6 on fios :-( Speedtest shows little or no congestion, and didn't change significantly when I reduced mtu by 8. (interestingly, speedtest.nethttp://speedtest.net usually reads faster than verizon's internal speedtest, and rarely averages less than my billed speed.) I've recently had problems (started a few weeks ago with www.att.comhttp://www.att.com, 4-5 days ago with *.google.comhttp://google.com) which unfortunately happy eyeballs doesn't help. att.comhttp://att.com uses akamai, google uses their own cdn (per dns; I don't know if there are any connections behind the scenes.) This occurs on several google sites, all of which resolve to the same netblocks from here (maps.google.comhttp://maps.google.com, www.google.comhttp://www.google.com, maps.gstatic.comhttp://maps.gstatic.com, and at least one of the ad servers). Symptom with akamai is that it connects immediately then data transfer times out. With google, symptom involves both slow connection, and data transfer timing out. I don't know if chrome's happy eyeballs is working since if it was, and absent address caching, I shouldn't see the slow connection. v6 connections to my hosts in Los Angeles (not on HE address space, but we do peer with them on any2) work fine transferring graphics and large database files both ways, so I'm pretty sure I don't have an mtu problem nor some other fios or HE problem. Just to be sure, I dropped the 1500 to 1492 on the fios link and did the same adjustment to the mtu on my tunnel (becomes 1472). No change on my hosts. att.comhttp://att.com appears a little better, though still very slow. Google shows no change at all. I saw some of the same problem yesterday from Frederick on comcast (only to google, didn't look at att), but couldn't take the time to do traceroutes. If desired, I'm likely to go out there tomorrow and can do that too. (we use a freebsd+pf router there). Is this a provisioning problem where v6 eyeballs are outstripping cdn provisioning (since win7 and 8 both default to v6)? Or is something else going on. Since this seems to affect more than one cdn, it seems odd. I run my own resolver locally instead of using verizon's. (and my own (vyatta) router instead of theirs. Actually I'm still using theirs as a bridge to talk to the set-top box (I don't know if Motorola still makes the coax terminal that would bridge it directly...) Resolve and traceroutes of relevant sites: [pete@port5 ~]$ host www.att.comhttp://www.att.com www.att.comhttp://www.att.com is an alias for prod-www.zr-att.com.akadns.nethttp://www.zr-att.com.akadns.net. prod-www.zr-att.com.akadns.nethttp://www.zr-att.com.akadns.net is an alias for www.att.com.edgekey.nethttp://www.att.com.edgekey.net. www.att.com.edgekey.nethttp://www.att.com.edgekey.net is an alias for e2318.dscb.akamaiedge.nethttp://e2318.dscb.akamaiedge.net. e2318.dscb.akamaiedge.nethttp://e2318.dscb.akamaiedge.net has address 23.76.217.145 e2318.dscb.akamaiedge.nethttp://e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:9200::90e e2318.dscb.akamaiedge.nethttp://e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:8600::90e Traceroute (v4) to this shows it is in Newark or environs: [pete@port5 ~]$ traceroute e2318.dscb.akamaiedge.nethttp://e2318.dscb.akamaiedge.net traceroute to e2318.dscb.akamaiedge.nethttp://e2318.dscb.akamaiedge.net (23.76.217.145), 30 hops max, 60 byte packets 1 rtr.east.altadena.nethttp://rtr.east.altadena.net (192.168.170.1) 2.008 ms 2.450 ms 3.091 ms 2 L300.BLTMMD-VFTTP-64.verizon-gni.nethttp://L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 9.021 ms 9.054 ms 9.045 ms 3 G0-7-4-5.BLTMMD-LCR-21.verizon-gni.nethttp://G0-7-4-5.BLTMMD-LCR-21.verizon-gni.net (100.41.195.94) 10.670 ms 10.683 ms 10.677 ms 4 ae4-0.RES-BB-RTR2.verizon-gni.nethttp://ae4-0.RES-BB-RTR2.verizon-gni.net (130.81.209.230) 9.002 ms ae20-0.RES-BB-RTR1.verizon-gni.nethttp://ae20-0.RES-BB-RTR1.verizon-gni.net (130.81.151.112) 8.995 ms so-1-1-0-0.RES-BB-RTR1.verizon-gni.nethttp://so-1-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.199.2) 8.953 ms 5 * * * 6 * * * 7 0.xe-5-0-4.XL3.EWR6.ALTER.NEThttp://XL3.EWR6.ALTER.NET (140.222.225.73) 51.202 ms 41.102 ms 40.345 ms 8 0.ae1.XL4.EWR6.ALTER.NEThttp://XL4.EWR6.ALTER.NET (140.222.228.41) 33.065 ms TenGigE0-6-0-3.GW8.EWR6.ALTER.NEThttp://GW8.EWR6.ALTER.NET (152.63.19.158) 11.550 ms TenGigE0-6-0-6.GW8.EWR6.ALTER.NEThttp://GW8.EWR6.ALTER.NET (152.63.25.10) 11.659 ms 9
RE: v6 cdn problems
The Google angle is also being discussed on outages. Initial suspicions are PTB packets not flowing through tunneled connections. Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Pete Carah Sent: Saturday, November 08, 2014 4:56 PM To: nanog@nanog.org Subject: v6 cdn problems Prefix this - I'm on fios in the Baltimore area, using a HE tunnel terminating in ashburn. (*still* no native v6 on fios :-( Speedtest shows little or no congestion, and didn't change significantly when I reduced mtu by 8. (interestingly, speedtest.net usually reads faster than verizon's internal speedtest, and rarely averages less than my billed speed.) I've recently had problems (started a few weeks ago with www.att.com, 4-5 days ago with *.google.com) which unfortunately happy eyeballs doesn't help. att.com uses akamai, google uses their own cdn (per dns; I don't know if there are any connections behind the scenes.) This occurs on several google sites, all of which resolve to the same netblocks from here (maps.google.com, www.google.com, maps.gstatic.com, and at least one of the ad servers). Symptom with akamai is that it connects immediately then data transfer times out. With google, symptom involves both slow connection, and data transfer timing out. I don't know if chrome's happy eyeballs is working since if it was, and absent address caching, I shouldn't see the slow connection. v6 connections to my hosts in Los Angeles (not on HE address space, but we do peer with them on any2) work fine transferring graphics and large database files both ways, so I'm pretty sure I don't have an mtu problem nor some other fios or HE problem. Just to be sure, I dropped the 1500 to 1492 on the fios link and did the same adjustment to the mtu on my tunnel (becomes 1472). No change on my hosts. att.com appears a little better, though still very slow. Google shows no change at all. I saw some of the same problem yesterday from Frederick on comcast (only to google, didn't look at att), but couldn't take the time to do traceroutes. If desired, I'm likely to go out there tomorrow and can do that too. (we use a freebsd+pf router there). Is this a provisioning problem where v6 eyeballs are outstripping cdn provisioning (since win7 and 8 both default to v6)? Or is something else going on. Since this seems to affect more than one cdn, it seems odd. I run my own resolver locally instead of using verizon's. (and my own (vyatta) router instead of theirs. Actually I'm still using theirs as a bridge to talk to the set-top box (I don't know if Motorola still makes the coax terminal that would bridge it directly...) Resolve and traceroutes of relevant sites: [pete@port5 ~]$ host www.att.com www.att.com is an alias for prod-www.zr-att.com.akadns.net. prod-www.zr-att.com.akadns.net is an alias for www.att.com.edgekey.net. www.att.com.edgekey.net is an alias for e2318.dscb.akamaiedge.net. e2318.dscb.akamaiedge.net has address 23.76.217.145 e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:9200::90e e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:8600::90e Traceroute (v4) to this shows it is in Newark or environs: [pete@port5 ~]$ traceroute e2318.dscb.akamaiedge.net traceroute to e2318.dscb.akamaiedge.net (23.76.217.145), 30 hops max, 60 byte packets 1 rtr.east.altadena.net (192.168.170.1) 2.008 ms 2.450 ms 3.091 ms 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 9.021 ms 9.054 ms 9.045 ms 3 G0-7-4-5.BLTMMD-LCR-21.verizon-gni.net (100.41.195.94) 10.670 ms 10.683 ms 10.677 ms 4 ae4-0.RES-BB-RTR2.verizon-gni.net (130.81.209.230) 9.002 ms ae20-0.RES-BB-RTR1.verizon-gni.net (130.81.151.112) 8.995 ms so-1-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.199.2) 8.953 ms 5 * * * 6 * * * 7 0.xe-5-0-4.XL3.EWR6.ALTER.NET (140.222.225.73) 51.202 ms 41.102 ms 40.345 ms 8 0.ae1.XL4.EWR6.ALTER.NET (140.222.228.41) 33.065 ms TenGigE0-6-0-3.GW8.EWR6.ALTER.NET (152.63.19.158) 11.550 ms TenGigE0-6-0-6.GW8.EWR6.ALTER.NET (152.63.25.10) 11.659 ms 9 TenGigE0-7-0-1.GW8.EWR6.ALTER.NET (152.63.19.166) 19.854 ms akamai-gw.customer.alter.net (152.179.185.126) 1766.402 ms TenGigE0-7-0-7.GW8.EWR6.ALTER.NET (152.63.25.30) 18.227 ms 10 akamai-gw.customer.alter.net (152.179.185.126) 1747.269 ms a23-76-217-145.deploy.static.akamaitechnologies.com (23.76.217.145) 10.672 ms 11.263 ms Traceroute6 to it appears to be local (but is hard to tell. Next-to-last hop looks like either a router or load-balancer is overloaded. Same for the v4 traceroute... [pete@port5 ~]$ traceroute6 www.att.com traceroute to www.att.com (2600:807:320:202:9200::90e), 30 hops max, 80 byte packets 1 rtr.east.altadena.net (2001:470:e160:1::1) 5.182 ms 5.274 ms 5.254 ms 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.452 ms 15.040 ms 18.592 ms 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 20.273 ms 20.574 ms 20.567 ms 4
Re: v6 cdn problems
On 2014-11-08 23:55, Pete Carah wrote: [..] Symptom with akamai is that it connects immediately then data transfer times out. With google, symptom involves both slow connection, and data transfer timing out. See amongst others: https://forums.he.net/index.php?topic=3281.0 https://www.sixxs.net/forum/?msg=general-12378937 https://www.sixxs.net/forum/?msg=general-12626989 and already reported in various places, eg ipv6-ops@ etc. Akamai is working on it as they have noted in various places already, (thanks to Marty etc). Google does not seem to be home. They used to have a handy i...@google.com address, but alas, that does not exist anymore. And it does not look their own employees actually use IPv6 otherwise they would have noticed it themselves, or like you know their monitoring systems showing that lots of connections are hanging and never actually properly finishing. I don't know if chrome's happy eyeballs is working since if it was, and absent address caching, I shouldn't see the slow connection. Chrome's Happy Eyeballs does not work when the TCP session has been made. (At least that is what it looks like on OSX). Hence, when the session gets stuck it is waiting for the TCP timeout to happen before it retries. It then does seem to remember that that connections is broken. [..] Is this a provisioning problem where v6 eyeballs are outstripping cdn provisioning (since win7 and 8 both default to v6)? Or is something else going on. Since this seems to affect more than one cdn, it seems odd. Coincidence it seems. [..] When I disable the HE tunnel, (and restart the browser - apparently happy-eyeballs caches), everything works just fine, so the problem does appear to relate to v6. *TEMPORARY* null routing the relevant prefixes on your *CPE* resolves the problems you are seeing as then your local router reports !N and your browser falls back to IPv4, which then works again. Greets, Jeroen
RE: Reporting DDOS reflection attacks
Do you know if third-parties such as SANS ISC or ShadowServer take lists of IPs? Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of srn.na...@prgmr.com Sent: Friday, November 07, 2014 12:57 PM To: nanog@nanog.org Subject: Reporting DDOS reflection attacks Like most small providers, we occasionally get hit by DoS attacks. We got hammered by an SSDP reflection attack (udp port 1900) last week. We took a 27 second log and from there extracted about 160k unique IPs. It is really difficult to find abuse emails for 160k IPs. We know about abuse.net but abuse.net requires hostnames, not IPs for lookups and not all IP addresses have valid DNS entries. The only other way we know of to report problems is to grab the abuse email addresses is whois. However, whois is not structured and is not set up to deal with this number of requests - even caching whois data based on subnets will result in many thousands of lookups. Long term it seems like structured data and some kind of authentication would be ideal for reporting attacks. But right now how should we be doing it?
Re: Reporting DDOS reflection attacks
Another DDoS/DoS email thread in progress, ah?... these seem to occur often lately... SoPerfect timing to remind all in the list that there is a NANOG BCOP in the works on this topic. Some of us have been working on documenting our collective knowledge about real practices that can help our community deal with this annoying networking decease...in a vendor agnostic manner... Our DDoS/DoS attack Best Common Ops Practices doc seeks to provide community-wide guidelines on what to do before, during and after a DDoS/DoS attack. If any of you want to contribute and join us to help the community on what we have documented so far, please check out the document below and/or drop me a note... http://bcop.nanog.org/index.php/BCOP_Drafts Yardiel Fuentes yard...@gmail.com twitter: #techguane On Nov 8, 2014, at 6:19 PM, Frank Bulk wrote: Do you know if third-parties such as SANS ISC or ShadowServer take lists of IPs? Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of srn.na...@prgmr.com Sent: Friday, November 07, 2014 12:57 PM To: nanog@nanog.org Subject: Reporting DDOS reflection attacks Like most small providers, we occasionally get hit by DoS attacks. We got hammered by an SSDP reflection attack (udp port 1900) last week. We took a 27 second log and from there extracted about 160k unique IPs. It is really difficult to find abuse emails for 160k IPs. We know about abuse.net but abuse.net requires hostnames, not IPs for lookups and not all IP addresses have valid DNS entries. The only other way we know of to report problems is to grab the abuse email addresses is whois. However, whois is not structured and is not set up to deal with this number of requests - even caching whois data based on subnets will result in many thousands of lookups. Long term it seems like structured data and some kind of authentication would be ideal for reporting attacks. But right now how should we be doing it?
DDOS, IDS, RTBH, and Rate limiting
Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. Does anyone have any suggestions for mitigating these type of attacks? A couple of things that we've done already... We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive 100Mbps of traffic. A few searches are initially coming up dry... Eric Miller, CCNP Network Engineering Consultant (407) 257-5115
Re: v6 cdn problems
On 11/08/2014 06:10 PM, Jeroen Massar wrote: On 2014-11-08 23:55, Pete Carah wrote: [..] Symptom with akamai is that it connects immediately then data transfer times out. With google, symptom involves both slow connection, and data transfer timing out. See amongst others: https://forums.he.net/index.php?topic=3281.0 https://www.sixxs.net/forum/?msg=general-12378937 https://www.sixxs.net/forum/?msg=general-12626989 and already reported in various places, eg ipv6-ops@ etc. Another list to subscribe... *TEMPORARY* null routing the relevant prefixes on your *CPE* resolves the problems you are seeing as then your local router reports !N and your browser falls back to IPv4, which then works again. DIsgusting but necessary. At least I don't have to do this on verizon's actiontec :-) -- Pete Greets, Jeroen
Re: v6 cdn problems
On 11/08/2014 06:10 PM, Jeroen Massar wrote: On 2014-11-08 23:55, Pete Carah wrote: [..] Symptom with akamai is that it connects immediately then data transfer times out. With google, symptom involves both slow connection, and data transfer timing out. See amongst others: https://forums.he.net/index.php?topic=3281.0 https://www.sixxs.net/forum/?msg=general-12378937 https://www.sixxs.net/forum/?msg=general-12626989 ... *TEMPORARY* null routing the relevant prefixes on your *CPE* resolves the problems you are seeing as then your local router reports !N and your browser falls back to IPv4, which then works again. So, I can do this fine. How do we get my proverbial grandmother to do it? (or even my daughter, who at least knows what a router is, but only that it contains suitable magic). -- Pete
Re: DDOS, IDS, RTBH, and Rate limiting
Eric C. Miller wrote: Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. Does anyone have any suggestions for mitigating these type of attacks? The phrase automated offensive cyber counter-attack has been coming to mind rather frequently, of late. I wonder if DARPA might fund some work in this area. :-) -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DDOS, IDS, RTBH, and Rate limiting
Check out Arbour Networks, they produce a range of DDoS scrubbing appliances that do pretty much what you want. Regards, Tim Raphael On 9 Nov 2014, at 9:10 am, Eric C. Miller e...@ericheather.com wrote: Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. Does anyone have any suggestions for mitigating these type of attacks? A couple of things that we've done already... We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive 100Mbps of traffic. A few searches are initially coming up dry... Eric Miller, CCNP Network Engineering Consultant (407) 257-5115
RE: DDOS, IDS, RTBH, and Rate limiting
Here's a thought-provoking video on what Brocade has done with its SDN software load on the MLX: http://vimeo.com/87476840 (demo at ~15 minute mark) I've written it before: if there was a software feature in routers where I could specify the maximum rate any prefix size (up to /32) could receive, that would be very helpful. If my fastest speed (residential) customer was 100 Mbps and I specified that 200 Mbps was the highest, I would never see high-rate attacks enter our network. Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Eric C. Miller Sent: Saturday, November 08, 2014 7:10 PM To: NANOG (nanog@nanog.org) Subject: DDOS, IDS, RTBH, and Rate limiting Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. Does anyone have any suggestions for mitigating these type of attacks? A couple of things that we've done already... We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive 100Mbps of traffic. A few searches are initially coming up dry... Eric Miller, CCNP Network Engineering Consultant (407) 257-5115
Re: DDOS, IDS, RTBH, and Rate limiting
On 9 Nov 2014, at 8:10, Eric C. Miller wrote: Does anyone have any suggestions for mitigating these type of attacks? You can start with S/RTBH (or flowspec, if your platform supports it): http://tools.ietf.org/html/rfc5635 http://tools.ietf.org/html/rfc5575 https://app.box.com/s/xznjloitly2apixr5xge Here's a preso which discusses reflection/amplification attacks, including chargen reflection/amplification attacks such as the one you describe: https://app.box.com/s/r7an1moswtc7ce58f8gg --- Roland Dobbins rdobb...@arbor.net
Re: DDOS, IDS, RTBH, and Rate limiting
On 9 Nov 2014, at 8:59, Frank Bulk wrote: I've written it before: if there was a software feature in routers where I could specify the maximum rate any prefix size (up to /32) could receive, that would be very helpful. QoS generally isn't a suitable mechanism for DDoS mitigation, as the programmatically-generated attack traffic ends up 'crowding out' legitimate traffic. S/RTBH, flowspec, and other methods tend to produce better results. --- Roland Dobbins rdobb...@arbor.net
Re: Reporting DDOS reflection attacks
On 9 Nov 2014, at 6:46, Yardiel D. Fuentes wrote: http://bcop.nanog.org/index.php/BCOP_Drafts There are some good general recommendations in this document (Word format? Really?), but this is incorrect and harmful, and should be removed: iii. Consider dropping any DNS reply packets which are larger than 512 Bytes – these are commonly found in DNS DoS Amplification attacks. This *breaks the Internet*. Don't do it. --- Roland Dobbins rdobb...@arbor.net
RE: DDOS, IDS, RTBH, and Rate limiting
There's no doubt, rate-limiting is a poor-man's way of getting the job done, but for small operators who aren't as well instrumented (whether that due to staff or resources), a simple rule such as: access-list 100 ip host 0.0.0.0 0.0.0.0 rate-limit 20 access-list 100 ip host 0.0.0.0 0.0.0.255 rate-limit 500 int vlan 10 description Internet uplink ip access-group 100 in ! would be great. Yes, the /32 under attack would essentially be out of service, but at least the downstream network doesn't get congested and more customers affected. Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roland Dobbins Sent: Saturday, November 08, 2014 8:28 PM To: NANOG Subject: Re: DDOS, IDS, RTBH, and Rate limiting On 9 Nov 2014, at 8:59, Frank Bulk wrote: I've written it before: if there was a software feature in routers where I could specify the maximum rate any prefix size (up to /32) could receive, that would be very helpful. QoS generally isn't a suitable mechanism for DDoS mitigation, as the programmatically-generated attack traffic ends up 'crowding out' legitimate traffic. S/RTBH, flowspec, and other methods tend to produce better results. --- Roland Dobbins rdobb...@arbor.net
Re: DDOS, IDS, RTBH, and Rate limiting
On 9 Nov 2014, at 9:42, Frank Bulk wrote: There's no doubt, rate-limiting is a poor-man's way of getting the job done, but for small operators who aren't as well instrumented (whether that due to staff or resources) You might as well just D/RTBH the victim and have done with it, heh. This is applicable: http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html --- Roland Dobbins rdobb...@arbor.net
Re: DDOS, IDS, RTBH, and Rate limiting
http://www.andrisoft.com/software/wanguard/ddos-mitigation-protection https://bitbucket.org/tortoiselabs/ddosmon https://github.com/FastVPSEestiOu/fastnetmon I have no idea if any of them actually work. On 11/08/2014 05:10 PM, Eric C. Miller wrote: Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. Does anyone have any suggestions for mitigating these type of attacks? A couple of things that we've done already... We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive 100Mbps of traffic. A few searches are initially coming up dry... Eric Miller, CCNP Network Engineering Consultant (407) 257-5115
Re: DDOS, IDS, RTBH, and Rate limiting
On Sat, 8 Nov 2014, Miles Fidelman wrote: Does anyone have any suggestions for mitigating these type of attacks? The phrase automated offensive cyber counter-attack has been coming to mind rather frequently, of late. I wonder if DARPA might fund some work in this area. :-) When you're being hit with one of the UDP reflection DDoS's, attacking the world in response isn't likely to work too well. In theory, you could write something that takes flow data from your transit routers, and in either near or real time, looks at that data and triggers an RTBH route for any IP that is responsible for more than a certain defined threshold of inbound traffic. In practice, it gets a little more complicated than that, as you'll likely want to whitelist some IPs and/or maybe be able to set different thresholds for different IPs. But it's not that complicated a problem to solve. Have a default threshold, and a table of networks and thresholds. Once a minute, look at the top X local destinations over the past minute. For each one, check to see if it has a custom threshold. If it doesn't, it gets the default. Then see if it's over its threshold. If it is, generate an RTBH route and email your NOC. The tricky part is when to remove the route...since you can't tell if the attack has ended while the target is black holed by your upstreams. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: DDOS, IDS, RTBH, and Rate limiting
On 9 Nov 2014, at 10:12, Jon Lewis wrote: The tricky part is when to remove the route...since you can't tell if the attack has ended while the target is black holed by your upstreams. You can with NetFlow, if you've D/RTBHed the IP in question on your own infrastructure. NetFlow reports statistics on dropped traffic (except on a few platforms with implementation deficiencies). But this kind of thing punishes the victim. It's far better to do everything possible to *protect* the target(s) of an attack, and only use D/RTBH as a last resort. --- Roland Dobbins rdobb...@arbor.net
Re: DDOS, IDS, RTBH, and Rate limiting
A quick and dirty win is to get your upstream(s) to kill anything UDP 19 to your prefixes at their ingress points if it becomes a common thing. You lose visibility as to when you're getting targeted by that type of attack again though, which could matter depending on your network. On Saturday, November 8, 2014, Jon Lewis jle...@lewis.org wrote: On Sat, 8 Nov 2014, Miles Fidelman wrote: Does anyone have any suggestions for mitigating these type of attacks? The phrase automated offensive cyber counter-attack has been coming to mind rather frequently, of late. I wonder if DARPA might fund some work in this area. :-) When you're being hit with one of the UDP reflection DDoS's, attacking the world in response isn't likely to work too well. In theory, you could write something that takes flow data from your transit routers, and in either near or real time, looks at that data and triggers an RTBH route for any IP that is responsible for more than a certain defined threshold of inbound traffic. In practice, it gets a little more complicated than that, as you'll likely want to whitelist some IPs and/or maybe be able to set different thresholds for different IPs. But it's not that complicated a problem to solve. Have a default threshold, and a table of networks and thresholds. Once a minute, look at the top X local destinations over the past minute. For each one, check to see if it has a custom threshold. If it doesn't, it gets the default. Then see if it's over its threshold. If it is, generate an RTBH route and email your NOC. The tricky part is when to remove the route...since you can't tell if the attack has ended while the target is black holed by your upstreams. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: DDOS, IDS, RTBH, and Rate limiting
How many holes are you going to stick fingers in to stop the flows? Good luck getting your provider to put in such a filter and make it anything more than temporary...and then there's still DNS, NTP, SNMP, and other protocols an attacker can easily utilize when they find that chargen isn't getting the job done. On Sat, 8 Nov 2014, Trent Farrell wrote: A quick and dirty win is to get your upstream(s) to kill anything UDP 19 to your prefixes at their ingress points if it becomes a common thing. You lose visibility as to when you're getting targeted by that type of attack again though, which could matter depending on your network. On Saturday, November 8, 2014, Jon Lewis jle...@lewis.org wrote: On Sat, 8 Nov 2014, Miles Fidelman wrote: Does anyone have any suggestions for mitigating these type of attacks? The phrase automated offensive cyber counter-attack has been coming to mind rather frequently, of late. I wonder if DARPA might fund some work in this area. :-) When you're being hit with one of the UDP reflection DDoS's, attacking the world in response isn't likely to work too well. In theory, you could write something that takes flow data from your transit routers, and in either near or real time, looks at that data and triggers an RTBH route for any IP that is responsible for more than a certain defined threshold of inbound traffic. In practice, it gets a little more complicated than that, as you'll likely want to whitelist some IPs and/or maybe be able to set different thresholds for different IPs. But it's not that complicated a problem to solve. Have a default threshold, and a table of networks and thresholds. Once a minute, look at the top X local destinations over the past minute. For each one, check to see if it has a custom threshold. If it doesn't, it gets the default. Then see if it's over its threshold. If it is, generate an RTBH route and email your NOC. The tricky part is when to remove the route...since you can't tell if the attack has ended while the target is black holed by your upstreams. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: DDOS, IDS, RTBH, and Rate limiting
On 9 Nov 2014, at 10:37, Jon Lewis wrote: I'm sure it's not always the case, but in my experience as a SP, the victim virtually always did something to instigate the attack, and is usually someone you don't want as a customer. This may be a reflection of your experience and customer base, but it isn't a valid generalization. Legitimate customers are attacked all the time, for various reasons - including unknowingly having their servers compromised and used as CCs by miscreants, who're then attacked by other miscreants. But to say that attacks are 'virtually always' provoked by customers themselves simply isn't true. DDoS extortion, ideologically-motivated DDoS attacks, maskirovkas intended as a distraction away from other activities, simple nihilism, et. al. are, unfortunately, quite common. When I worked for a cloud hosting provider, the DDoS victims tended to be fraudulent signups who were doing malicious or anti-social things on the net and were not paying customers anyway. Many DDoS attacks are miscreant-vs.-miscreant, that's certainly true. Compromised machines are 'attractive nuisances', which is yet another reason it's important to have visibility into your network traffic (it's easy to get started with NetFlow and open-source tools). --- Roland Dobbins rdobb...@arbor.net
Re: DDOS, IDS, RTBH, and Rate limiting
I wouldn't have suggested it if I hadn't successfully made these requests myself. Most attacks don't last long enough to put a dent on billing so it's in everyone best interest to cull it quickly. Providing the upstream network is big enough and your attacks aren't huge pipefills, they will usually place the acl on your customer port first, which in those cases should be enough. For smaller attacks you can try to drop at your router/absorb it/ scrub it inside your border if you have the kit - but anything significant like the NTP reflection attacks earlier in the year, you come up against the bandwidth arms race problem. There are services out there like Prolexic/Black Lotus offer where they can scrub traffic for you, but I've never used one first hand so can't comment. On Saturday, November 8, 2014, Jon Lewis jle...@lewis.org wrote: How many holes are you going to stick fingers in to stop the flows? Good luck getting your provider to put in such a filter and make it anything more than temporary...and then there's still DNS, NTP, SNMP, and other protocols an attacker can easily utilize when they find that chargen isn't getting the job done. On Sat, 8 Nov 2014, Trent Farrell wrote: A quick and dirty win is to get your upstream(s) to kill anything UDP 19 to your prefixes at their ingress points if it becomes a common thing. You lose visibility as to when you're getting targeted by that type of attack again though, which could matter depending on your network. On Saturday, November 8, 2014, Jon Lewis jle...@lewis.org wrote: On Sat, 8 Nov 2014, Miles Fidelman wrote: Does anyone have any suggestions for mitigating these type of attacks? The phrase automated offensive cyber counter-attack has been coming to mind rather frequently, of late. I wonder if DARPA might fund some work in this area. :-) When you're being hit with one of the UDP reflection DDoS's, attacking the world in response isn't likely to work too well. In theory, you could write something that takes flow data from your transit routers, and in either near or real time, looks at that data and triggers an RTBH route for any IP that is responsible for more than a certain defined threshold of inbound traffic. In practice, it gets a little more complicated than that, as you'll likely want to whitelist some IPs and/or maybe be able to set different thresholds for different IPs. But it's not that complicated a problem to solve. Have a default threshold, and a table of networks and thresholds. Once a minute, look at the top X local destinations over the past minute. For each one, check to see if it has a custom threshold. If it doesn't, it gets the default. Then see if it's over its threshold. If it is, generate an RTBH route and email your NOC. The tricky part is when to remove the route...since you can't tell if the attack has ended while the target is black holed by your upstreams. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: DDOS, IDS, RTBH, and Rate limiting
On Sat, Nov 08, 2014 at 10:37:45PM -0500, Jon Lewis wrote: On Sun, 9 Nov 2014, Roland Dobbins wrote: But this kind of thing punishes the victim. It's far better to do everything possible to *protect* the target(s) of an attack, and only use D/RTBH as a last resort. I'm sure it's not always the case, but in my experience as a SP, the victim virtually always did something to instigate the attack Like have the temerity to have a successful online store. Or be featured in the mainstream media for providing information during a natural disaster. The bastards. I've dealt with far more DDoS attacks that were for the purposes of extortion or lulz than were due to the recipient instigating the attack. Perhaps that's a function of not attempting to cater to the lowest common denominator. - Matt
Re: DDOS, IDS, RTBH, and Rate limiting
On 11/8/14 6:28 PM, Roland Dobbins wrote: On 9 Nov 2014, at 8:59, Frank Bulk wrote: I've written it before: if there was a software feature in routers where I could specify the maximum rate any prefix size (up to /32) could receive, that would be very helpful. QoS generally isn't a suitable mechanism for DDoS mitigation, as the programmatically-generated attack traffic ends up 'crowding out' legitimate traffic. if you can identify attack traffic well enough to police it reliably then you can also drop it on the floor. S/RTBH, flowspec, and other methods tend to produce better results. yup. --- Roland Dobbins rdobb...@arbor.net signature.asc Description: OpenPGP digital signature
RE: DDOS, IDS, RTBH, and Rate limiting
But that's my point: many small operators don't have tools and/or staff to identify flows in order to police and/or drop the traffic, and definitely not a NOC that can intervene in under 5 minutes. How much simpler if there was a generic rule that said no one IP can receive more than 200 Mbps, log on that, and then if it takes 30 or 90 minutes for someone to react, that's fine, but in the meantime other customers weren't affected. Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of joel jaeggli Sent: Saturday, November 08, 2014 11:22 PM To: Roland Dobbins; NANOG Subject: Re: DDOS, IDS, RTBH, and Rate limiting On 11/8/14 6:28 PM, Roland Dobbins wrote: On 9 Nov 2014, at 8:59, Frank Bulk wrote: I've written it before: if there was a software feature in routers where I could specify the maximum rate any prefix size (up to /32) could receive, that would be very helpful. QoS generally isn't a suitable mechanism for DDoS mitigation, as the programmatically-generated attack traffic ends up 'crowding out' legitimate traffic. if you can identify attack traffic well enough to police it reliably then you can also drop it on the floor. S/RTBH, flowspec, and other methods tend to produce better results. yup. --- Roland Dobbins rdobb...@arbor.net
FW: M-Lab-Related PCAPs
FYI to this list since I suspect few of you are on the M-Lab Discuss list. Srikanth from ICSI has kindly taken on consolidating some PCAPs. If anyone wishes to send any to him, he is at srknt...@gmail.commailto:srknt...@gmail.com. JL On 11/6/14, 7:24 PM, Srikanth S srknt...@gmail.commailto:srknt...@gmail.com wrote: So it looks as though marking is not done for all MLab traffic. Also, some web traffic (to CNN) is marked at a lower priority than streaming (Netflix), which is strange as web traffic is likely more sensitive to degradation than streaming (?). Here are the traces: http://www1.icsi.berkeley.edu/~srikanth/pcaps/google.pcap http://www1.icsi.berkeley.edu/~srikanth/pcaps/youtube-image.pcap http://www1.icsi.berkeley.edu/~srikanth/pcaps/cnn.pcap http://www1.icsi.berkeley.edu/~srikanth/pcaps/netflix-streaming.pcap On Tuesday, November 4, 2014 1:29:16 PM UTC-8, Jason Livingood wrote: Another follow-up. Someone emailed me a PCAP off-list from an enterprise type of customer. Their PCAP was somewhat incomplete (so I still need more) but they noticed that some traffic at the next priority down from 0x48 at 0x28 (priority). And some other traffic was marked with the next priority down again at 0x00 (routine). So it appears there are three DSCP / ToS markings in use rather than just two (0x00, 0x28, 0x48). So safe to say more research is needed here – anyone collecting PCAPs should IMHO continue. :-) Jason
