Sicily to Egypt undersea cable disruption
If its not one cable, its another cable. http://www.guardian.co.uk/technology/2008/jan/30/asia.internet.outage Huge swathes of the Middle East and Asia have been left without internet access after a vital undersea cable was damaged. A fault in the pipeline, which runs between Sicily and Egypt, has dramatically reduced access in countries including Saudi Arabia, Dubai and India, leaving millions of workers struggling to get online.
circuits to NASDAQ and NYSE
Is there any problem with network connectivity to Nasdaq or NYSE. Specifically on Yipes. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Blackholing traffic by ASN
I'm sure all of us have parts of the Internet that we block for one reason or another. I have existing methods for null routing traffic from annoying hosts and subnets on our border routers today (I'm still working on a network blackhole). However I've never tackled the problem by targeting a bad guy's ASN. What's the best option for null routing traffic by ASN? I could always add another deny statement in my inbound eBGP route-maps to match a new as-path ACL for _BAD-ASN_ to keep from accepting their routes to begin with. Are there any other good tricks that I can employ? I have another question along those same lines. Once I do have my blackhole up and running I can easily funnel hosts or subnets into the blackhole. What about funneling all routes to a particular ASN into the blackhole? Are there any useful tricks here? The ASN I'm referring to is that of the Russian Business Network. A Google search should turn up plenty of info for those that haven't heard of them. Thanks Justin
Re: Blackholing traffic by ASN
This is prior art. (Assuming your hardware has a hardware blackhole (or you have a little router sitting on the end of a circuit)) you adjust your route-map that would deny the entry to set a community or next-hop pointing to your blackhole location. Nowadays, most equipment can blackhole internally (to null0 say) at full speed, so it isn't an issue. Just set your next hop to a good null0 style location on route import and you are done for traffic destined to those locations. For inbound traffic from those locations you would need to do policy routing (because you are looking up on source). If you are trying to block SPAM or anything TCP related, you only need to block 1 direction to end the conversation. Sounds harsh, but hey, its your network. Deepak Jain AiNET Justin Shore wrote: I'm sure all of us have parts of the Internet that we block for one reason or another. I have existing methods for null routing traffic from annoying hosts and subnets on our border routers today (I'm still working on a network blackhole). However I've never tackled the problem by targeting a bad guy's ASN. What's the best option for null routing traffic by ASN? I could always add another deny statement in my inbound eBGP route-maps to match a new as-path ACL for _BAD-ASN_ to keep from accepting their routes to begin with. Are there any other good tricks that I can employ? I have another question along those same lines. Once I do have my blackhole up and running I can easily funnel hosts or subnets into the blackhole. What about funneling all routes to a particular ASN into the blackhole? Are there any useful tricks here? The ASN I'm referring to is that of the Russian Business Network. A Google search should turn up plenty of info for those that haven't heard of them. Thanks Justin
Re: Blackholing traffic by ASN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Paul Ferguson [EMAIL PROTECTED] wrote: -- Justin Shore [EMAIL PROTECTED] wrote: The ASN I'm referring to is that of the Russian Business Network. A Google search should turn up plenty of info for those that haven't heard of them. Not possible anymore, sorry -- they have now diversified into many different origin ASs. Up until late last year, they primarily operated out of AS40989, but no more: http://www.cidr-report.org/cgi-bin/as-report?as=AS40898 Too much negative publicity forced them to fly lower under the radar. :-) Sorry, make that: http://www.cidr-report.org/cgi-bin/as-report?as=as40989 - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHoQ4Wq1pz9mNUZTMRAo69AKCixuAjGYwoKOmuKRw8AuKciWPGYgCg6yLC Qy3ogTMN+BfqcJ+7JIFeyw4= =L5S+ -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Blackholes and IXs and Completing the Attack.
Hi, I have been working away on remote trigger blackholing and community based client initiated blackholing into transit ASes. It got me thinking that while this works great with a handful of upstream transit peers it does not really scale very well at an Internet Exchange with a high overhead configuring things for many peers. Plus if your IX connection is saturated that means legitimate traffic must be getting degraded - even if your router is coping and blackholing the interconnect is still flat lined. The only ways into an AS are via transit, public IX or private interconnects. If we want to extend the blackholing to secure IXs peers as well as into transits. So my idea Is to have an IX route reflector configured with ACLs locking it down to exclusively BGP with the IX peer IP of the member. The IX route reflector would be configured to have per peer prefix filters per peer auto generated from registered AS macro for each peer from the RIPE,ARIN,APNIC etc databases. This should mean the router will not accept announcements for any /32 that is not part of the routes announced by that AS (it would be even better to tie it down to a match on origin AS as well). Plus the router will only talk to IX peers - no global transit. This hopefully will ensure a relatively protected router that is only accessible from the edge routers we want and also secured to only accept filtered announcements for black holing and in consequence enable the system to be trusted similar to Team Cymaru. Then all a member AS of the exchange does is announce any /32 from their IP block that they would like other members to Null route in their AS to this reflector. There are people way smarter than me on this list and the above is not implemented at any of the IXs I am connected to, so why is the above a dumb idea / what have I missed that makes the above unworkable because it does seem kind of obvious now I have done some work with this. Kind Regards Ben Butler ++ C2 Internet Ltd Globe House, The Gullet, Nantwich, Cheshire, CW5 5RL E mailto:[EMAIL PROTECTED] W http://www.c2internet.net/ B1 http://c2internet.blogspot.com/ B2 http://c2noc.blogspot.com/ T +44-(0)845-658-0020 F +44-(0)845-658-0070 All quotes services from C2 are bound by our standard terms and conditions which are available on our website at: http://www.c2internet.net/legal/main.htm#tandc C2 Internet Limited is a company registered in England and Wales with company number 03910154 Our VAT Registration number is GB 752 7650 17
Re: Blackholing traffic by ASN
On Wed, 30 Jan 2008, Justin Shore wrote: I'm sure all of us have parts of the Internet that we block for one reason or another. I have existing methods for null routing traffic from annoying hosts and subnets on our border routers today (I'm still working on a network blackhole). However I've never tackled the problem by targeting a bad guy's ASN. What's the best option for null routing traffic by ASN? I could always add another deny statement in my inbound eBGP route-maps to match a new as-path ACL for _BAD-ASN_ to keep from accepting their routes to begin with. Are there any other good tricks that I can employ? You could do it with an as-path access-list. Example: router bgp 65500 no auto-summary no synchronization log-neighbor-changes neighbor 1.2.3.4 remote-as 65400 neighbor 1.2.3.4 description UPSTREAM1 neighbor 1.2.3.4 filter-list 10 in neighbor 1.2.3.4 soft-reconfiguration inbound ip as-path access-list 10 deny (_65300)+$ ip as-path access-list 10 permit .* This example should drop any prefixes you receive from your upstream that include 65300 as the origin AS in the AS path, but permit anything else. If you're concerned about prefixes that could have 65300 anywhere in the path, take the $ off of the regex. You could also probably write a route-map to redirect traffic from your network to prefixes from that AS to null0, or to a traffic analsis box. jms I have another question along those same lines. Once I do have my blackhole up and running I can easily funnel hosts or subnets into the blackhole. What about funneling all routes to a particular ASN into the blackhole? Are there any useful tricks here? The ASN I'm referring to is that of the Russian Business Network. A Google search should turn up plenty of info for those that haven't heard of them.
Re: Sicily to Egypt undersea cable disruption
What I see from our Cogent transit is that Egypt has completely fallen off the map, with a normally consistent traffic gone to zero, but traffic to Iran, Iraq, the GCC, India and Pakistan and even Yemen doesn't seem to be affected, at least not noticeably. Regards Marshall On Jan 31, 2008, at 1:56 AM, Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Sean Donelan [EMAIL PROTECTED] wrote: If its not one cable, its another cable. http://www.guardian.co.uk/technology/2008/jan/30/asia.internet.outage Huge swathes of the Middle East and Asia have been left without internet access after a vital undersea cable was damaged. For what its worth, Todd Underwood has a very good overview of the countries affected by this outage over on the Renesys Blog here: http://www.renesys.com/blog/2008/01/mediterranean_cable_break.shtml - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHoSrHq1pz9mNUZTMRAiFhAJ9y8gg/gSbXmPnYJhGKn5ZmlHXz3gCgkL7d U19z4eSg5DsEvUjhfzo9J8E= =v3bo -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Sicily to Egypt undersea cable disruption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Sean Donelan [EMAIL PROTECTED] wrote: If its not one cable, its another cable. http://www.guardian.co.uk/technology/2008/jan/30/asia.internet.outage Huge swathes of the Middle East and Asia have been left without internet access after a vital undersea cable was damaged. For what its worth, Todd Underwood has a very good overview of the countries affected by this outage over on the Renesys Blog here: http://www.renesys.com/blog/2008/01/mediterranean_cable_break.shtml - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHoSrHq1pz9mNUZTMRAiFhAJ9y8gg/gSbXmPnYJhGKn5ZmlHXz3gCgkL7d U19z4eSg5DsEvUjhfzo9J8E= =v3bo -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Sicily to Egypt undersea cable disruption
On Thu, Jan 31, 2008 at 01:56:42AM +, Paul Ferguson wrote: For what its worth, Todd Underwood has a very good overview of the countries affected by this outage over on the Renesys Blog here: http://www.renesys.com/blog/2008/01/mediterranean_cable_break.shtml while i very much appreciate the compliment, this work was all done by my colleagues at renesys earl zmijewski and alin popescu. i've been following the routing events around this cable break, though. there are some interesting findings here about who (what carriers, what countries) were critically dependant on these cable systems. we'll probably put some more effort into analyzing this situation as it develops and compare it to the taiwan outages that hit late 2006. (nanog program plug: my colleague martin a brown will be presenting and update on the way that the taiwan quake outages continue to affect transit and peering patterns in asia over a year after the original cable breaks: http://nanog.org/mtg-0802/brown.html . if you're interested in this subject you should probably register for nanog42 ( https://www.nanog.org/registration/ ) and attend.) if there's enough interest in this event, we'll do a lighting talk plug type=another lighting talk submissions are already open at: http://nanogpc.org/lighting /plug we'll monitor the situation and this community's level of interest and allocate our energies accordingly. :-) see y'all in sjc. t. -- _ todd underwood +1 603 643 9300 x101 renesys corporationgeneral manager babbledog [EMAIL PROTECTED] http://www.renesys.com/blog
Re: Blackholing traffic by ASN
On Jan 30, 2008 3:54 PM, Deepak Jain [EMAIL PROTECTED] wrote: This is prior art. (Assuming your hardware has a hardware blackhole (or you have a little router sitting on the end of a circuit)) you adjust your route-map that would deny the entry to set a community or next-hop pointing to your blackhole location. Nowadays, most equipment can blackhole internally (to null0 say) at full speed, so it isn't an issue. Just set your next hop to a good null0 style location on route import and you are done for traffic destined to those locations. ...do uRPF-loose-mode and you kill FROM these locations as well... For inbound traffic from those locations you would need to do policy routing (because you are looking up on source). If you are trying to (uRPF loose-mode) block SPAM or anything TCP related, you only need to block 1 direction to end the conversation. be cautious of 'synflooding' your internal hosts with this though... Null0 doesn't generate unreachables at packet-rate, but at a lower (1:1000 I believe on cisco by default) rate. Sounds harsh, but hey, its your network. wee! and for some extra fun, just append the bad-guy's ASN to your route announcements, force bgp loop-detection to kill the traffic on their end (presuming they don't default-route as well)
Re: Sicily to Egypt undersea cable disruption
On Jan 30, 2008 9:41 PM, Todd Underwood [EMAIL PROTECTED] wrote: On Thu, Jan 31, 2008 at 01:56:42AM +, Paul Ferguson wrote: For what its worth, Todd Underwood has a very good overview of the countries affected by this outage over on the Renesys Blog here: http://www.renesys.com/blog/2008/01/mediterranean_cable_break.shtml while i very much appreciate the compliment, this work was all done by my colleagues at renesys earl zmijewski and alin popescu. i've been following the routing events around this cable break, though. there are some interesting findings here about who (what carriers, what countries) were critically dependant on these cable systems. In the Med/IO cable case, a ship dropped an anchor on the cable, something that is 1:1,000,000 shot, but happens. At least they know where it is. The failure to contract the maintenance ship tighter on a route that turns out to be that vulnerable is probably of concer for users of that cable now as well. A lot of the impact is likely also due to people not buying protect circuits or bothering to understand the IP architecture. That is something that is becoming common globally, IMHO. Folks assume that IP will route around the damage. Sure it will, if all the physical layer paths aren't busted. Layer 1 really does rock. Watching BGP announcements seems less important in these erious performance impacting cases, to me, than understanding the underlying architecture and what the root cause a half step above the anchor and a half a step below the advertisement was. Looking forward to Rod Beck's response. :-) Best, Marty
Re: Sicily to Egypt undersea cable disruption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Martin Hannigan [EMAIL PROTECTED] wrote: In the Med/IO cable case, a ship dropped an anchor on the cable, something that is 1:1,000,000 shot, but happens. [...] Isn't that exactly what happened with the Pakistan fiber in 2005 with SEAMEWE-3? :-) - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHoXPlq1pz9mNUZTMRAsP+AJ4zaz+98bTSJM2IzwFOurjbusbbawCaAlqY 2yqlHXkWgWJsZ043fF94mfc= =PqfR -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Sicily to Egypt undersea cable disruption
On Jan 31, 2008 2:08 AM, Paul Ferguson [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Martin Hannigan [EMAIL PROTECTED] wrote: In the Med/IO cable case, a ship dropped an anchor on the cable, something that is 1:1,000,000 shot, but happens. [...] Isn't that exactly what happened with the Pakistan fiber in 2005 with SEAMEWE-3? :-) The 1:1,000,000 was without a reference so it was fugurative. Mea Culpa. If you count the amount of cables and the anchor drop cuts, it's probably much less as an afterthought. From what I read about this cut, the way it happened seemed to have figurative odds of 1:1,000,000. It looks like authorities moved the anchorage area for some undefined reason. Cables are documented on marine charts and, at least theoretically under international standards, Captains and Pilots are lawfully required to refer to them before dropping the hook. Having some experience in marine operations, it would be 'curious' for a Captain or Pilot to not notice that there was a cable marking so close to their re-designated anchorage based on the chart that they would need to refer to for low tide depths and other (un)common hazards to insure that they weren't in imminent danger. I'm sure that there is more to this story than meets the eye. -M
