Re: Netblock reassigned from Chile to US ISP...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 12, 2008 at 11:36 PM, Randy Bush wrote: >> So having said all that, what exactly was your point? :-) > > bluff calling. > > that you can not tell us if that specific host is a proxy means that this > is pretty much bs. > > that you and your no-girls-allowed club have some list of things you > think are proxies (sure would be nice to have a definition thereof), > doeth not make a rigorous, testable, and scalable system. Gee, I seem to have said that before regarding nsp-sec. D-oh! Look it, whatever you may think, there's certainly no "old boys club" factor at work here, but I'm certainly not going to put up a portal where anyone and their grandmother can check for known open proxies -- there is already enough of that -- and that actually is not the point. That chip on your shoulder must be getting pretty heavy... so forget it. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJQ2eRq1pz9mNUZTMRAsWNAKDU1/u/PH3xTNQAfGJqZIpT6H6jpQCg+cbM nxKsQOt+2vwa92pA3oWqI5w= =vmia -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Netblock reassigned from Chile to US ISP...
So having said all that, what exactly was your point? :-) bluff calling. that you can not tell us if that specific host is a proxy means that this is pretty much bs. that you and your no-girls-allowed club have some list of things you think are proxies (sure would be nice to have a definition thereof), doeth not make a rigorous, testable, and scalable system. though i guess some list of things you don't like has some utility. but it sure ain't automatible ops let alone computer science. randy
Re: Netblock reassigned from Chile to US ISP...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 12, 2008 at 11:24 PM, Randy Bush wrote: >> Give me an IP address (privately, of course). I can tell you if it is, >> with >> consult from other colleagues in the security community. > > 147.28.0.36 > > and "consult with colleagues" is not something very operationally > scalable. > Of course, chasing ghosts in RGnet/PSGnet is clever, but not a worthwhile exercise. The point here is that there are many folks monitoring open proxies for illegal activities, etc., and not all of the mind-share reside in one single database. A collaborate effort to share information on abuse activity is required, of course -- and indeed already exists. So having said all that, what exactly was your point? :-) - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJQ2R7q1pz9mNUZTMRArY+AJ0VRvOLF/xEBzAKHysNKRo668ucQwCgmhL9 ZoPn/XhkTcABuVQwFBKa2qk= =sdw8 -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Netblock reassigned from Chile to US ISP...
Give me an IP address (privately, of course). I can tell you if it is, with consult from other colleagues in the security community. 147.28.0.36 and "consult with colleagues" is not something very operationally scalable. randy
Re: Netblock reassigned from Chile to US ISP...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 12, 2008 at 11:12 PM, Randy Bush wrote: > On 08.12.13 09:33, Tomas L. Byrnes wrote: >> >> anyone with half a brain blocks proxies from their e-commerce site. > > can you know at a reasonable confidence level that it's a proxy? > Give me an IP address (privately, of course). I can tell you if it is, with consult from other colleagues in the security community. That's almost a no-brainer. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJQ2Kqq1pz9mNUZTMRArkZAJ42wBsiviQOeX/Ei6gPCY+Rk8zRjQCdHDfg djeldwF25CYOUsDoGQQzKPs= =jkIf -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Netblock reassigned from Chile to US ISP...
On 08.12.13 09:33, Tomas L. Byrnes wrote: anyone with half a brain blocks proxies from their e-commerce site. can you know at a reasonable confidence level that it's a proxy? randy
Re: Netblock reassigned from Chile to US ISP...
On Fri, Dec 12, 2008 at 7:33 PM, Tomas L. Byrnes wrote: > Because anyone with half a brain blocks proxies from their e-commerce > site. > I doubt it. -M<
RE: Netblock reassigned from Chile to US ISP...
Because anyone with half a brain blocks proxies from their e-commerce site. >-Original Message- >From: Owen DeLong [mailto:o...@delong.com] >Sent: Friday, December 12, 2008 3:49 PM >To: Nathan Stratton >Cc: nanog@nanog.org >Subject: Re: Netblock reassigned from Chile to US ISP... > > >On Dec 12, 2008, at 3:14 PM, Nathan Stratton wrote: > >> On Fri, 12 Dec 2008, Joe Abley wrote: >> >>> On 2008-12-12, at 15:02, Martin List-Petersen wrote: >>> It's a misconception of some muppets, especially in IT related products, that forget, that a lot or IT professionals do travel all over the world and usually have a credit card in their home country. Pure and utter nonsense. >>> >>> Or perhaps the hassle of dealing with stolen US credit card numbers >>> from clients outside the US costs far more money than you could >>> hope to make back with the purchases of US nationals travelling >>> overseas? >>> >>> Could well be muppets, but surely there are other possibilities. >> >> Sad but true, we have had to turn off signups outside the US because >> of that very problem. Yes, I am sure we lose some sales, but in >> general it is not worth the fraud costs. > >Why don't the fraudsters just use Open US Proxies? > >Owen >
RE: Netblock reassigned from Chile to US ISP...
We probably should move this to funsec, but I'll bite. The basic problem is the lack of security and non-repudiation in credit cards in general, and the US in particular. Non-clonable, card-present, technologies have existed for a long time, and card readers are cheap. AMEX tried to make this free with Blue, but it wasn't adopted. So, the US banks, and AMEX, seem willing to exchange some amount of fraud, and inconvenience for a minority; in exchange for convenience and higher transaction volume for the majority. They've been enabled by the fact that HNC's software works very well. As long as those who make the profit bear the bulk of the risk, as they do with credit cards, I guess there's no issue. Given the "debit card" lack of limit of liability for the consumer, this may change. >-Original Message- >From: Joe Abley [mailto:jab...@hopcount.ca] >Sent: Friday, December 12, 2008 3:07 PM >To: Martin List-Petersen >Cc: nanog@nanog.org >Subject: Re: Netblock reassigned from Chile to US ISP... > > >On 2008-12-12, at 15:02, Martin List-Petersen wrote: > >> It's a misconception of some muppets, especially in IT related >> products, that forget, that a lot or IT professionals do travel all >> over the world and usually have a credit card in their home country. >> >> Pure and utter nonsense. > >Or perhaps the hassle of dealing with stolen US credit card numbers >from clients outside the US costs far more money than you could hope >to make back with the purchases of US nationals travelling overseas? > >Could well be muppets, but surely there are other possibilities. > > >Joe >
Re: Netblock reassigned from Chile to US ISP...
Owen DeLong wrote: > > On Dec 12, 2008, at 3:14 PM, Nathan Stratton wrote: > >> On Fri, 12 Dec 2008, Joe Abley wrote: >> >>> On 2008-12-12, at 15:02, Martin List-Petersen wrote: >>> It's a misconception of some muppets, especially in IT related products, that forget, that a lot or IT professionals do travel all over the world and usually have a credit card in their home country. Pure and utter nonsense. >>> >>> Or perhaps the hassle of dealing with stolen US credit card numbers >>> from clients outside the US costs far more money than you could hope >>> to make back with the purchases of US nationals travelling overseas? >>> >>> Could well be muppets, but surely there are other possibilities. >> >> Sad but true, we have had to turn off signups outside the US because >> of that very problem. Yes, I am sure we lose some sales, but in >> general it is not worth the fraud costs. > > Why don't the fraudsters just use Open US Proxies? > You can be sure, that the people wanting to defraud merchants know all these tricks and use them. The verified by visa password option is a far better solution, but I've not seen many US merchants supporting that yet. Instead they're relying on outdated geoip data or ask people to fax a copy of their credit card. /Martin -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968
Re: Netblock reassigned from Chile to US ISP...
Joe Abley wrote: > > On 2008-12-12, at 15:02, Martin List-Petersen wrote: > >> It's a misconception of some muppets, especially in IT related >> products, that forget, that a lot or IT professionals do travel all >> over the world and usually have a credit card in their home country. >> >> Pure and utter nonsense. > > Or perhaps the hassle of dealing with stolen US credit card numbers from > clients outside the US costs far more money than you could hope to make > back with the purchases of US nationals travelling overseas? > > Could well be muppets, but surely there are other possibilities. > I can understand merchants wanting the extra security, but the issue is, that they then don't want to fork out for a MaxMind subscription or the likes. One of the bigger colo providers in the states is selling SSL certificates, but their geoip data is ancient. I even bothered to raise a ticket with them and the answer was just "we're working with our development team on that". When I revisited 6 months later, nothing had changed. It's not the only case, that I've ran into this issue and the US is not the only place that credit cards are issued or used. Nor is credit card/credit card theft a outside US only thing. It happens anywhere, inside or outside the US. That's exactly, why the banks starting adding the personalized password option etc. Using outdated geoip data for merchant-services is as unprofessional as asking people to fax a copy of their credit card to some fax number. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968
Re: Netblock reassigned from Chile to US ISP...
On Dec 12, 2008, at 3:14 PM, Nathan Stratton wrote: On Fri, 12 Dec 2008, Joe Abley wrote: On 2008-12-12, at 15:02, Martin List-Petersen wrote: It's a misconception of some muppets, especially in IT related products, that forget, that a lot or IT professionals do travel all over the world and usually have a credit card in their home country. Pure and utter nonsense. Or perhaps the hassle of dealing with stolen US credit card numbers from clients outside the US costs far more money than you could hope to make back with the purchases of US nationals travelling overseas? Could well be muppets, but surely there are other possibilities. Sad but true, we have had to turn off signups outside the US because of that very problem. Yes, I am sure we lose some sales, but in general it is not worth the fraud costs. Why don't the fraudsters just use Open US Proxies? Owen
Re: Netblock reassigned from Chile to US ISP...
On Fri, 12 Dec 2008, Joe Abley wrote: On 2008-12-12, at 15:02, Martin List-Petersen wrote: It's a misconception of some muppets, especially in IT related products, that forget, that a lot or IT professionals do travel all over the world and usually have a credit card in their home country. Pure and utter nonsense. Or perhaps the hassle of dealing with stolen US credit card numbers from clients outside the US costs far more money than you could hope to make back with the purchases of US nationals travelling overseas? Could well be muppets, but surely there are other possibilities. Sad but true, we have had to turn off signups outside the US because of that very problem. Yes, I am sure we lose some sales, but in general it is not worth the fraud costs. <> Nathan StrattonCTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.nethttp://www.blinkmind.com
Re: Netblock reassigned from Chile to US ISP...
On 2008-12-12, at 15:02, Martin List-Petersen wrote: It's a misconception of some muppets, especially in IT related products, that forget, that a lot or IT professionals do travel all over the world and usually have a credit card in their home country. Pure and utter nonsense. Or perhaps the hassle of dealing with stolen US credit card numbers from clients outside the US costs far more money than you could hope to make back with the purchases of US nationals travelling overseas? Could well be muppets, but surely there are other possibilities. Joe
Re: e300 vs mx240 for border router ?
Leslie, Can you summarize any other info you may have learned in the private responses for the benefit of those that are interested ? I am not at all familiar with the Force10s, am buying new border routers now. Thanks, Mike On Fri, 2008-12-12 at 14:27 -0800, Leslie wrote: > Thanks to everyone who wrote back privately -- > > I also didn't know that force10 now has dual-cam linecards which raises > the amount of routes it can handle > > Leslie wrote: > > Hey nanog-izens > > > > So for routers that are touching our transit and (hopefully soon) future > > peering, we're looking at both the force10 e300's and juniper mx240's. > > The e300's are cheap but I have heard some rumors/talk of falling over > > when it has to deal with large numbers of prefixes and routes? The > > mx240's are nice but the cost difference is enormous. Does anyone have > > experience with e300's running into issues with large routing tables? > > Are there any tricks/tips that work around any issues (if they exist?) > > > > Thanks in advance > > > > Leslie > -- Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more
Re: e300 vs mx240 for border router ?
Thanks to everyone who wrote back privately -- I also didn't know that force10 now has dual-cam linecards which raises the amount of routes it can handle Leslie wrote: Hey nanog-izens So for routers that are touching our transit and (hopefully soon) future peering, we're looking at both the force10 e300's and juniper mx240's. The e300's are cheap but I have heard some rumors/talk of falling over when it has to deal with large numbers of prefixes and routes? The mx240's are nice but the cost difference is enormous. Does anyone have experience with e300's running into issues with large routing tables? Are there any tricks/tips that work around any issues (if they exist?) Thanks in advance Leslie
RE: e300 vs mx240 for border router ?
How many BGP sessions will you run on these routers? Sincerely, David Kotlerewsky, Sr. Network Engineer - OVERSEE.NET 515 S. Flower Street, Suite 4400 Los Angeles, CA 90071 ph 213.408.0080 x1458 cell 310.350.0399 www.oversee.net dkotlerew...@oversee.net Confidentiality Warning: this email contains information intended for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in it, or transmitted with this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. -Original Message- From: Leslie [mailto:les...@craigslist.org] Sent: Friday, December 12, 2008 1:38 PM To: nanog@nanog.org Subject: e300 vs mx240 for border router ? Hey nanog-izens So for routers that are touching our transit and (hopefully soon) future peering, we're looking at both the force10 e300's and juniper mx240's. The e300's are cheap but I have heard some rumors/talk of falling over when it has to deal with large numbers of prefixes and routes? The mx240's are nice but the cost difference is enormous. Does anyone have experience with e300's running into issues with large routing tables? Are there any tricks/tips that work around any issues (if they exist?) Thanks in advance Leslie
e300 vs mx240 for border router ?
Hey nanog-izens So for routers that are touching our transit and (hopefully soon) future peering, we're looking at both the force10 e300's and juniper mx240's. The e300's are cheap but I have heard some rumors/talk of falling over when it has to deal with large numbers of prefixes and routes? The mx240's are nice but the cost difference is enormous. Does anyone have experience with e300's running into issues with large routing tables? Are there any tricks/tips that work around any issues (if they exist?) Thanks in advance Leslie
Re: UDP DoS mitigation?
Replying to my own since there are currently about a dozen responses.
- Hardware/ASIC routers are a consistent response. We are currently
evaluating Juniper for other reasons, but I'll add DoS mitigation to
mix.
- Upstream involvement: We get transit from 701, 1239, etc. I've had
mixed results getting timely responses from our upstreams. It's useful
for long-term issues, but I need as much local and timely control as I
can get.
- I'm not having a problem with pipe bandwidth, but high pps.
- uRPF and RTBH helped internally, but anything passing through that
upstream connection was impacted.
- This instance was a DoS, not DDoS. Single source and destination, but
the source (assuming no spoofing) was in Italy. Turning off netflow
seemed to help, but the attack itself stopped at about the same time.
Also, thanks for the offers of individual help in mitigation, although I'd
be concerned that "Hey, can somebody block traffic {from} or {to}?" would
be an interesting experiment in a socially-engineered DoS.
Finally, there were some suggestions "S/RTBH". RTBH I get, but my
Google-fu is weak on S/RTBH. Details?
Thanks,
Rick
On Fri, December 12, 2008 10:15, Rick Ernst wrote:
>
> We've had an increasing rate of DoS attacks that spew tens-of-thousands of
> small UDP packets to a destination on our network. We are getting roughly
> 2x our entire normal pps across all providers through one interface, or
> about 4x normal through the individual interface. The Cisco
> 7206VXR/NPE-G1 CPU melts (>95% load vs 15% average, 20% normal peak) when
> this hits.
>
> I'm using CEF and ip-route-cache flow on the outside interface. Unicast
> RPF is also enabled on the interface. Unicast RPF in conjunction with a
> BGP black-hole generator handles TCP attacks fairly well.
>
> Two questions:
> - Are there any knobs I should be turning in the Cisco config to help with
> mitigate this?
> - Are there any platforms that deal with high PPS/small packet more
> gracefully?
>
> We are looking at a network refresh and aren't locked into Cisco as a
> vendor (although our current IP network consists entirely of Cisco gear).
> Our current aggregate (all providers, in- plus out-bound) bandwidth is
> ~500Mbs, but projected growth is 1Gbs within the year.
>
> Thanks,
> Rick
>
>
>
RE: UDP DoS mitigation?
Although the problem we had wasn't DoS, but rather high packet rates for market data, we saw a huge improvement by moving from a 7204VRX to a 7600 platform. Going from a software switched environment to a hardware one help deal with large number of packet drops during peaks of burst activity. We looked at the ASR1000, but found the price too high. Although cisco doesn't promote it, the 7604 with the Sup32 engine (WS-SUP32-GE-3B) with 8 x GE interfaces is a very cost effective hardware router. -Original Message- From: Rick Ernst [mailto:er...@easystreet.com] Sent: Friday, December 12, 2008 1:15 PM To: nanog@nanog.org Subject: UDP DoS mitigation? We've had an increasing rate of DoS attacks that spew tens-of-thousands of small UDP packets to a destination on our network. We are getting roughly 2x our entire normal pps across all providers through one interface, or about 4x normal through the individual interface. The Cisco 7206VXR/NPE-G1 CPU melts (>95% load vs 15% average, 20% normal peak) when this hits. I'm using CEF and ip-route-cache flow on the outside interface. Unicast RPF is also enabled on the interface. Unicast RPF in conjunction with a BGP black-hole generator handles TCP attacks fairly well. Two questions: - Are there any knobs I should be turning in the Cisco config to help with mitigate this? - Are there any platforms that deal with high PPS/small packet more gracefully? We are looking at a network refresh and aren't locked into Cisco as a vendor (although our current IP network consists entirely of Cisco gear). Our current aggregate (all providers, in- plus out-bound) bandwidth is ~500Mbs, but projected growth is 1Gbs within the year. Thanks, Rick
Re: Netblock reassigned from Chile to US ISP...
Nicolas Antoniello wrote: Sorry for my ignorance... but may some one explain how this fraud-prevention service works? How about US tourists in Chile trying to buy something with it's US based credit card? :) It's a misconception of some muppets, especially in IT related products, that forget, that a lot or IT professionals do travel all over the world and usually have a credit card in their home country. Pure and utter nonsense. /M Thx, Nic. Frank Bulk wrote: Is there an easy way to get past history on an IP block? Most sites will show you aspects of that *now* Frank -Original Message- From: Robert Tarrall [mailto:tarr...@ecentral.com] Sent: Thursday, December 11, 2008 9:45 PM To: nanog@nanog.org Subject: Re: Netblock reassigned from Chile to US ISP... Martin List-Petersen wrote: -> Contact Google. Somebody from Google replied off-list. Sounds like Google maybe had this updated even before he looked at it. -> Again. Akamai is helpful. Contact them. Somebody from Akamai replied off-list and they're looking into it. -> 3) End-user unable to complete an online e-commerce transaction -> due to a fraud-prevention service thinking he was a Chilean user -> trying to buy something with a US-based credit card. -> -> There's no fast fix for this, but have you talked to MaxMind about -> chaning the Geo location ? They'll implent it fast and it's in their -> DB within a week, max 2, but it'll take 2 months at least, before it MaxMind was the first place I checked; they already had the correct info when I looked. IP2Location don't have the right info, but they think it's a Speakeasy.net IP in Washington DC which probably won't be a problem. No idea about Digital Element yet. Netblock is 67.214.48.0/20 - was reg'd a couple of weeks ago so folks who pull ARIN assignments regularly will have it. Those who care but don't check ARIN regularly may want to see if they think it's in Chile, and change it to Denver, Colorado if so. -> However, the ecommerce issue is a bit worse, because there's some -> of'em out there, like one of the biggest hosters in the states, that -> have 2 year old data. Yeah, it's those types that I'm hoping to locate as well... Google and Akamai were immediately noticed by the test users, and have also responded very quickly (thanks, guys), but ideally we'd like to be proactive and get as many of these updated *before* the real customers hit the network and start having problems. -Robert.- -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968
Re: Netblock reassigned from Chile to US ISP...
On Fri, Dec 12, 2008 at 14:38, Nicolas Antoniello wrote: > How about US tourists in Chile trying to buy something with it's US > based credit card? :) It just doesn't work. -Jim P.
Re: Netblock reassigned from Chile to US ISP...
Sorry for my ignorance... but may some one explain how this fraud-prevention service works? How about US tourists in Chile trying to buy something with it's US based credit card? :) Thx, Nic. Frank Bulk wrote: > Is there an easy way to get past history on an IP block? Most sites will > show you aspects of that *now* > > Frank > > -Original Message- > From: Robert Tarrall [mailto:tarr...@ecentral.com] > Sent: Thursday, December 11, 2008 9:45 PM > To: nanog@nanog.org > Subject: Re: Netblock reassigned from Chile to US ISP... > > Martin List-Petersen wrote: > -> Contact Google. > > Somebody from Google replied off-list. Sounds like Google maybe > had this updated even before he looked at it. > > -> Again. Akamai is helpful. Contact them. > > Somebody from Akamai replied off-list and they're looking into it. > > -> 3) End-user unable to complete an online e-commerce transaction > -> due to a fraud-prevention service thinking he was a Chilean user > -> trying to buy something with a US-based credit card. > -> > -> There's no fast fix for this, but have you talked to MaxMind about > -> chaning the Geo location ? They'll implent it fast and it's in their > -> DB within a week, max 2, but it'll take 2 months at least, before it > > MaxMind was the first place I checked; they already had the correct > info when I looked. IP2Location don't have the right info, but they > think it's a Speakeasy.net IP in Washington DC which probably won't be a > problem. No idea about Digital Element yet. > > Netblock is 67.214.48.0/20 - was reg'd a couple of weeks ago so folks > who pull ARIN assignments regularly will have it. Those who care but > don't check ARIN regularly may want to see if they think it's in Chile, > and change it to Denver, Colorado if so. > > -> However, the ecommerce issue is a bit worse, because there's some > -> of'em out there, like one of the biggest hosters in the states, that > -> have 2 year old data. > > Yeah, it's those types that I'm hoping to locate as well... Google > and Akamai were immediately noticed by the test users, and have also > responded very quickly (thanks, guys), but ideally we'd like to be > proactive and get as many of these updated *before* the real customers > hit the network and start having problems. > > -Robert.- > > >
RE: Netblock reassigned from Chile to US ISP...
Is there an easy way to get past history on an IP block? Most sites will show you aspects of that *now* Frank -Original Message- From: Robert Tarrall [mailto:tarr...@ecentral.com] Sent: Thursday, December 11, 2008 9:45 PM To: nanog@nanog.org Subject: Re: Netblock reassigned from Chile to US ISP... Martin List-Petersen wrote: -> Contact Google. Somebody from Google replied off-list. Sounds like Google maybe had this updated even before he looked at it. -> Again. Akamai is helpful. Contact them. Somebody from Akamai replied off-list and they're looking into it. -> 3) End-user unable to complete an online e-commerce transaction -> due to a fraud-prevention service thinking he was a Chilean user -> trying to buy something with a US-based credit card. -> -> There's no fast fix for this, but have you talked to MaxMind about -> chaning the Geo location ? They'll implent it fast and it's in their -> DB within a week, max 2, but it'll take 2 months at least, before it MaxMind was the first place I checked; they already had the correct info when I looked. IP2Location don't have the right info, but they think it's a Speakeasy.net IP in Washington DC which probably won't be a problem. No idea about Digital Element yet. Netblock is 67.214.48.0/20 - was reg'd a couple of weeks ago so folks who pull ARIN assignments regularly will have it. Those who care but don't check ARIN regularly may want to see if they think it's in Chile, and change it to Denver, Colorado if so. -> However, the ecommerce issue is a bit worse, because there's some -> of'em out there, like one of the biggest hosters in the states, that -> have 2 year old data. Yeah, it's those types that I'm hoping to locate as well... Google and Akamai were immediately noticed by the test users, and have also responded very quickly (thanks, guys), but ideally we'd like to be proactive and get as many of these updated *before* the real customers hit the network and start having problems. -Robert.-
Re: UDP DoS mitigation?
On Dec 13, 2008, at 2:27 AM, David Kotlerewsky wrote: 2. As far as hardware is concerned, we're in the same boat as far as various UDP/ICMP floods, and our Juniper M10i's handle it with no issues (running multiple BGP sessions, OSPF, firewall sets/access lists). Right - a hardware-based platform is required to deal with high pps rates (the Cisco equivalent is the ASR1000; I'm not familiar with boxes from other vendors, but I'm pretty sure there are others in this same class). --- Roland Dobbins // +852.9133.2844 mobile History is a great teacher, but it also lies with impunity. -- John Robb
RE: UDP DoS mitigation?
Couple of things come to mind: 1. Take a packet capture to see some UDP traffic characteristics, based on which traffic rate-limiting may be configured by your upstream providers, so that this traffic doesn't saturate your pipes, and maybe the ISP can even drop it. That is if they're willing to help you. 2. As far as hardware is concerned, we're in the same boat as far as various UDP/ICMP floods, and our Juniper M10i's handle it with no issues (running multiple BGP sessions, OSPF, firewall sets/access lists). Sincerely, David Kotlerewsky, Sr. Network Engineer - OVERSEE.NET 515 S. Flower Street, Suite 4400 Los Angeles, CA 90071 ph 213.408.0080 x1458 cell 310.350.0399 www.oversee.net dkotlerew...@oversee.net Confidentiality Warning: this email contains information intended for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in it, or transmitted with this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. -Original Message- From: Rick Ernst [mailto:er...@easystreet.com] Sent: Friday, December 12, 2008 10:15 AM To: nanog@nanog.org Subject: UDP DoS mitigation? We've had an increasing rate of DoS attacks that spew tens-of-thousands of small UDP packets to a destination on our network. We are getting roughly 2x our entire normal pps across all providers through one interface, or about 4x normal through the individual interface. The Cisco 7206VXR/NPE-G1 CPU melts (>95% load vs 15% average, 20% normal peak) when this hits. I'm using CEF and ip-route-cache flow on the outside interface. Unicast RPF is also enabled on the interface. Unicast RPF in conjunction with a BGP black-hole generator handles TCP attacks fairly well. Two questions: - Are there any knobs I should be turning in the Cisco config to help with mitigate this? - Are there any platforms that deal with high PPS/small packet more gracefully? We are looking at a network refresh and aren't locked into Cisco as a vendor (although our current IP network consists entirely of Cisco gear). Our current aggregate (all providers, in- plus out-bound) bandwidth is ~500Mbs, but projected growth is 1Gbs within the year. Thanks, Rick
Re: UDP DoS mitigation?
On Dec 13, 2008, at 2:15 AM, Rick Ernst wrote: - Are there any platforms that deal with high PPS/small packet more gracefully? S/RTBH can deal with any type of packet-flooding DDoS at layer-3, up to the capacity of the platform in question. It sounds as if a) you should investigate getting DDoS mitigation assistance from your upstreams and/or b) moving from your currently software-based platform to a hardware-based platform at your edge to provide increased performance (this holds true irrespective of which vendor you select for your edge platform). If you move to a hardware-based edge platform, be sure to first investigate all the particulars of its uRPF implementation so as to ensure that you can use it for S/RTBH, and if at all possible, test it before buying. --- Roland Dobbins // +852.9133.2844 mobile History is a great teacher, but it also lies with impunity. -- John Robb
UDP DoS mitigation?
We've had an increasing rate of DoS attacks that spew tens-of-thousands of small UDP packets to a destination on our network. We are getting roughly 2x our entire normal pps across all providers through one interface, or about 4x normal through the individual interface. The Cisco 7206VXR/NPE-G1 CPU melts (>95% load vs 15% average, 20% normal peak) when this hits. I'm using CEF and ip-route-cache flow on the outside interface. Unicast RPF is also enabled on the interface. Unicast RPF in conjunction with a BGP black-hole generator handles TCP attacks fairly well. Two questions: - Are there any knobs I should be turning in the Cisco config to help with mitigate this? - Are there any platforms that deal with high PPS/small packet more gracefully? We are looking at a network refresh and aren't locked into Cisco as a vendor (although our current IP network consists entirely of Cisco gear). Our current aggregate (all providers, in- plus out-bound) bandwidth is ~500Mbs, but projected growth is 1Gbs within the year. Thanks, Rick
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 13 Dec, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 274910 Prefixes after maximum aggregation: 131479 Deaggregation factor: 2.09 Unique aggregates announced to Internet: 134428 Total ASes present in the Internet Routing Table: 30074 Prefixes per ASN: 9.14 Origin-only ASes present in the Internet Routing Table: 26178 Origin ASes announcing only one prefix: 12740 Transit ASes present in the Internet Routing Table:3896 Transit-only ASes present in the Internet Routing Table: 96 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (42115) 21 Prefixes from unregistered ASNs in the Routing Table: 529 Unregistered ASNs in the Routing Table: 194 Number of 32-bit ASNs allocated by the RIRs: 68 Prefixes from 32-bit ASNs in the Routing Table: 10 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:210 Number of addresses announced to Internet: 1970066112 Equivalent to 117 /8s, 108 /16s and 210 /24s Percentage of available address space announced: 53.2 Percentage of allocated address space announced: 63.5 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 74.6 Total number of prefixes smaller than registry allocations: 134988 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:63380 Total APNIC prefixes after maximum aggregation: 22998 APNIC Deaggregation factor:2.76 Prefixes being announced from the APNIC address blocks: 60296 Unique aggregates announced from the APNIC address blocks:27407 APNIC Region origin ASes present in the Internet Routing Table:3488 APNIC Prefixes per ASN: 17.29 APNIC Region origin ASes announcing only one prefix:937 APNIC Region transit ASes present in the Internet Routing Table:535 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 390867936 Equivalent to 23 /8s, 76 /16s and 43 /24s Percentage of available APNIC address space announced: 77.7 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:122980 Total ARIN prefixes after maximum aggregation:64546 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks:92217 Unique aggregates announced from the ARIN address blocks: 35011 ARIN Region origin ASes present in the Internet Routing Table:12650 ARIN Prefixes per ASN: 7.29 ARIN Region origin ASes announcing only one prefix:4886 ARIN Region transit ASes present in the Internet Routing Table:1205 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 402263840 Equivalent to 23 /8s, 250 /16s and 15 /24s Percentage of available ARIN address space announced: 82.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153
[NANOG-announce] NANOG 45 Agenda Posted
On behalf of the NANOG Program Committee and Merit I'm pleased to announce that an updated Agenda is available and posted at: http://www.nanog.org/meetings/nanog45/agenda.php We're excited about the quality of the agenda and we hope you are, too. I want to thank all of the members of the Program Committee who worked hard to recruit, review and select the presentations and tutorials that make up this program. I also want to thank everyone who submitted a proposal. The quality and variety seemed very high this time around. Please note that there remain a very small number of slots open for late-breaking or especially topical presentations, so if the Internet melts down completely between now and January, feel free to submit a presentation explaining what happened. Lighting Talk slots will officially open after the first of the year. If you have not already registered for the conference and reserved your hotel room, now is a great time to do that. See http://nanog.org/meetings/nanog45/ and in particular https://nanog.merit.edu/registration/ to get started. Remember that Hotel expenses are fantastically low this time, with rooms as cheap as $104 and cheap flights are still available to the SDQ airport. The overall cost of this NANOG should be the same or lower as previous ones. I mention this because I know that many travel budgets are tight and I hope that this information might be useful to your management. I look forward to seeing all of you in Santo Domingo. Todd Underwood Chair, NANOG Program Committee toddun...@gmail.com ___ NANOG-announce mailing list nanog-annou...@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce
The Cidr Report
This report has been generated at Fri Dec 12 21:18:53 2008 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
05-12-08290432 177961
06-12-08292661 177588
07-12-08294362 177884
08-12-08294699 172849
09-12-08282262 172817
10-12-08282192 173193
11-12-08282545 173526
12-12-08282624 174029
AS Summary
30159 Number of ASes in routing system
12832 Number of ASes announcing only one prefix
4373 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
89828608 Largest address span announced by an AS (/32s)
AS27064: DDN-ASNBLK1 - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 12Dec08 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 282952 173938 10901438.5% All ASes
AS6389 4373 356 401791.9% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4197 1719 247859.0% TWTC - tw telecom holdings,
inc.
AS209 2979 635 234478.7% ASN-QWEST - Qwest
Communications Corporation
AS17488 1442 336 110676.7% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS4766 1501 455 104669.7% KIXS-AS-KR Korea Telecom
AS1785 1703 719 98457.8% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1178 200 97883.0% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS22773 992 62 93093.8% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS8151 1405 539 86661.6% Uninet S.A. de C.V.
AS6478 1604 804 80049.9% ATT-INTERNET3 - AT&T WorldNet
Services
AS11492 1229 454 77563.1% CABLEONE - CABLE ONE, INC.
AS18566 1060 336 72468.3% COVAD - Covad Communications
Co.
AS18101 783 95 68887.9% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS19262 938 256 68272.7% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS2386 1590 915 67542.5% INS-AS - AT&T Data
Communications Services
AS3356 1104 458 64658.5% LEVEL3 Level 3 Communications
AS2706 543 21 52296.1% HKSUPER-HK-AP Pacific Internet
(Hong Kong) Limited
AS7545 678 171 50774.8% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS4808 632 159 47374.8% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS4134 905 438 46751.6% CHINANET-BACKBONE
No.31,Jin-rong Street
AS855580 119 46179.5% CANET-ASN-4 - Bell Aliant
AS17676 522 64 45887.7% GIGAINFRA BB TECHNOLOGY Corp.
AS9443 525 84 44184.0% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS20115 1850 1412 43823.7% CHARTER-NET-HKY-NC - Charter
Communications
AS7018 1425 990 43530.5% ATT-INTERNET4 - AT&T WorldNet
Services
AS24560 630 195 43569.0% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS22047 553 121 43278.1% VTR BANDA ANCHA S.A.
AS4804 515 87 42883.1% MPX-AS Microplex PTY LTD
AS4668 691 276 41560.1% LGNET-AS-KR LG CNS
AS4780 730 329 40154.9%
BGP Update Report
BGP Update Report Interval: 05-Nov-08 -to- 06-Dec-08 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS4538 232133 1.9% 45.7 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9583 228435 1.9% 180.9 -- SIFY-AS-IN Sify Limited 3 - AS6389 130689 1.1% 29.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS29282 101489 0.8% 33829.7 -- EMENTOR-AS Enfo Oyj 5 - AS180394573 0.8% 66.6 -- ICMNET-5 - Sprint 6 - AS662984972 0.7%1307.3 -- NOAA-AS - NOAA 7 - AS629883856 0.7% 38.4 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 8 - AS24863 83220 0.7% 121.8 -- LINKdotNET-AS 9 - AS815173001 0.6% 33.2 -- Uninet S.A. de C.V. 10 - AS209 71988 0.6% 23.2 -- ASN-QWEST - Qwest Communications Corporation 11 - AS20115 63026 0.5% 30.4 -- CHARTER-NET-HKY-NC - Charter Communications 12 - AS647861690 0.5% 35.2 -- ATT-INTERNET3 - AT&T WorldNet Services 13 - AS432354750 0.5% 12.9 -- TWTC - tw telecom holdings, inc. 14 - AS645854576 0.5% 121.8 -- Telgua 15 - AS764352459 0.4% 32.4 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 16 - AS238651415 0.4% 31.0 -- INS-AS - AT&T Data Communications Services 17 - AS346249113 0.4% 244.3 -- HINET Data Communication Business Group 18 - AS17488 48606 0.4% 33.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 19 - AS17854 0.4% 26.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 20 - AS35805 42761 0.3% 206.6 -- UTG-AS United Telecom AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS29282 101489 0.8% 33829.7 -- EMENTOR-AS Enfo Oyj 2 - AS14106 32024 0.3% 16012.0 -- LEPMED01 - Leprechaun, LLC 3 - AS302874928 0.0%4928.0 -- ALON-USA - ALON USA, LP 4 - AS30306 19541 0.2%3908.2 -- AfOL-Sz-AS 5 - AS41007 18540 0.1%3708.0 -- CTCASTANA CTC ASTANA, KZ 6 - AS46115 36509 0.3%3650.9 -- LUTHER - Luther College 7 - AS413016771 0.1%3354.2 -- UPITT-AS - University of Pittsburgh 8 - AS32398 26554 0.2%3319.2 -- REALNET-ASN-1 9 - AS155612969 0.0%2969.0 -- CDS-ITALY C.D.S. Informatica S.r.l. 10 - AS239172755 0.0%2755.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 11 - AS477312735 0.0%2735.0 -- ISDC-AS SC ISDC ROMANIA SRL 12 - AS30969 21860 0.2%2732.5 -- TAN-NET TransAfrica Networks 13 - AS503321730 0.2%2414.4 -- ISW - Internet Specialties West Inc. 14 - AS285197180 0.1%2393.3 -- Universidad Autonoma de Guadalajara 15 - AS439254293 0.0%2146.5 -- MOLDCELL_AS Moldcell SA Autonomous System 16 - AS481312096 0.0%2096.0 -- VANGUARD-BG-AS Vanguard SA 17 - AS319012083 0.0%2083.0 -- THECHIMES - The Chimes, Inc. 18 - AS257992000 0.0%2000.0 -- HOLMAN - Holman Enterprises 19 - AS190171988 0.0%1988.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 20 - AS149 1725 0.0%1725.0 -- DNIC - DoD Network Information Center TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 77.95.144.0/2271003 0.6% AS29282 -- EMENTOR-AS Enfo Oyj 2 - 221.134.222.0/24 60022 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 210.214.151.0/24 58695 0.5% AS9583 -- SIFY-AS-IN Sify Limited 4 - 221.135.80.0/24 38881 0.3% AS9583 -- SIFY-AS-IN Sify Limited 5 - 124.7.201.0/2434334 0.3% AS9583 -- SIFY-AS-IN Sify Limited 6 - 217.69.48.0/2030450 0.2% AS29282 -- EMENTOR-AS Enfo Oyj 7 - 192.102.88.0/24 27094 0.2% AS6629 -- NOAA-AS - NOAA 8 - 192.35.129.0/24 26804 0.2% AS6629 -- NOAA-AS - NOAA 9 - 198.77.177.0/24 26722 0.2% AS6629 -- NOAA-AS - NOAA 10 - 41.204.2.0/24 25863 0.2% AS32398 -- REALNET-ASN-1 11 - 64.162.116.0/24 21556 0.2% AS5033 -- ISW - Internet Specialties West Inc. 12 - 8.192.154.0/2417463 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 13 - 150.212.224.0/19 16681 0.1% AS4130 -- UPITT-AS - University of Pittsburgh 14 - 192.12.120.0/24 16423 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 15 - 65.44.76.0/24 14561 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 16 - 89.4.131.0/24 11665 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 17 - 203.63.26.0/2411403 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 18 - 196.27.104.0/21 10553 0.1% AS30969 -- TAN-NET TransAfrica Networks 19 - 19
