February 2008 - Test - lists.nanog.org

Jeanette Symons (1962-2008) a commerical Internet Pioneer
by John Lee 04 Feb '08

04 Feb '08

It was with great sadness that I read about the un-timely death of my friend and colleague Jeanette in a plane crash in Maine. Jeanette died flying, which was one of the activities she loved to do. I meet her before she started flying and when she moved back to California she took up flying. We would be talking on the phone and she would say that it was VFR and she needed to go. VFR - Visual Flight Rules for flying without instruments which was all she was rated for at the time. I meet Jeanette at Hayes Microcomputer Products where we were working on a project together. People would think that we were brother and sister since we both had curly back hair and looked alike. When she wanted to move back to California, which she missed, I introduced her to Rob Ryan the head of Haye's West coast operations. When she was in Georgia we would eat Chinese, made by my wife, at my place. When we were in California we would eat Sushi at several of her favorite places in Western San Francisco and Oakland. Jeanette, Rob, Jay Duncanson and Steve Speckenbach left Hayes to start Ascend Communications and developed the TNT central site dial up modem, ISDN and Ethernet switch that handled most of the dial up Internet traffic for years. Ascend was purchased by Lucent and she and Mori started Zhone Technologies. Her new venture was started because her children wanted to blog with their friends and she was worried about them being on line. Jeanette will be missed. John Lee

3 2

Blackholes and IXs and Completing the Attack.
by Ben Butler 04 Feb '08

04 Feb '08

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:ben.butler@c2internet.net 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

10 22

Re: Blackholes and IXs and Completing the Attack.
by Rick Astley 03 Feb '08

03 Feb '08

I see your point, but I think maintaining the box for the control session would also require a decent amount of work. Presumably, since you must all adhere to some quasi-standard to communicate with the control peer, you could probably also agree on creating a standard BGP community (ie. 64666:666 & no-export) to use and just skip the middle man. Granted, I am kind of new as well, and I assume if the solution were that simple more people would be using it. On Feb 2, 2008 9:07 PM, Ben Butler <ben.butler(a)c2internet.net> wrote: > Hi, > > Agreed, but when you have >100 peers that is still a fair bit of work. I > know technically how to do it and am doing this with transits but then there > are only seven of those. It is not a question of how or can, but should / > is it valuable / constructive? > > The starting point in the thought process having just done it for transits > was right ok, now how do we sensibly scale this to apply it at IXes without > everyone having to run round contacting everyone else and to see if there > was an easier way of doing things, hence the suggestion. Plus it keeps > things nice a separated, your IX peering sessions announce just the main > prefixes, the session to the "blackhole reflector" can be in a separate > peer-group and you only send the /32s to the reflector. You don't have to > worry about who uses which communities as each member that chooses to peer > with the reflector is able to apply an inbound routemaps of their own > choosing to any prefixes they receive from this reflector at each individual > IX. > > Given that an ISP has elected to Complete the attack on a host that is > being DoSed, for whatever reason, and they have chosen to send blackhole > announcements to transit the logical extension seems to be to automate the > sending of them to IXs to try to further cut down on traffic. This seems > like a easy way, internally you just community tag on the trigger box for > where you want the announcement to go, transit, internal, customers, IX > all,1 2 not 3 - whatever - and BGP sends it out. Easy, and a single system > to send out all updates when you choose to and easy to remove when you want > to take it out again. > > If you subscribe to completing the attack as a strategy, then the > suggestion seemed like an easy way of rolling it out to the next logical > point after transit. > > Kind Regards > > Ben > >

2 1

adsl line tester
by Ingo Flaschberger 03 Feb '08

03 Feb '08

Hi, I'm searching a good adsl2+ line tester. Can anynone recommend a good one? Kind regards, ingo flaschberger

3 2

IPv6 Connectivity Saga (part n+1)
by Thomas Kühne 02 Feb '08

02 Feb '08

I took a DMOZ[1] dump, extracted all unique domain-name port combinations and checked their IPv6 connectivity. 3 388 012 : 100.000% : total 3 260 296 : 96.230% : IPv4 only 122 560 : 3.620% : bad NS 3 372 : 0.100% : IPv6 working 1 694 : 0.050% : broken or "fake" IPv6 broken: TCP connect failed fake: IPv6 mapped IPv4 addresses (e.g. ::ffff:1.2.3.4) 33.4% of all services that advertised IPv6 failed to deliver or in other words the IPv6 failure rate is ten times the NS failure rate. Seems high, thus a cross check via TLDs' NS: 270 : 100.0% : TLD total (excluding the IDN tests) 268 : 99.3% : IPv4 working 2 : 0.7% : IPv4 broken (HM and KP) 177 : 65.6% : IPv6 working 8 : 3.0% : IPv6 broken 1910 : 100.0% : NS total 1500 : 78.5% : IPv4 only 31 : 1.6% : IPv4 broken 356 : 19.1% : IPv6 working 23 : 1.2% : IPv6 broken IPv6 failure rates of 4.3% (TLD) and 6.1% (NS) is lower than the above 33.4% but are still significantly higher than the IPv4 failure rates of 0.7% (TLD) and 1.6% (NS). TLD root-NSs usually are managed by dedicated infrastructure organisations thus better trouble shooting than the DMOZ listed ones get is expected and suggests the above 33.4% failure rate isn't some kind of sampling artifact. About 4 days later I did a more detailed check of the hosts with broken IPv6: 1624 : hosts total 827 : connection timed out 382 : no route to host 249 : connection refused 95 : network unreachable 54 : SixXS never received a route announcement for that block 43 : broadcast address 30 : * IPv4 in IPv6 22 : IPv6 assignments reclaimed (3ffe::/16) 16 : * no IPv6 (::) 12 : * IPv4 only 10 : * IPv6 working 4 : IPv6 never assigned 4 : local (fe80::/10) 2 : local (::1) 2 : broken NS Issues(cases not marked with a star) do tend to arise but why are fundamental issues like "connection timed out", "no route to host" and "connection refused" so frequent? (testing was done from 2a01:4d0:102::31) Thomas [1] http://www.dmoz.org/help/getdata.html

4 4

Re: Blackholes and IXs and Completing the Attack.
by Paul Ferguson 02 Feb '08

02 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Roland Dobbins <rdobbins(a)cisco.com> wrote: >On Feb 3, 2008, at 4:50 AM, Paul Ferguson wrote: > >> We (Trend Micro) do something similar to this -- a black-hole BGP >> feed of known botnet C&Cs, such that the C&C channel is effectively >> black-holed. > >What's the trigger (pardon the pun, heh) and process for removing IPs from the blackhole list post-cleanup, in Trend's case? > We have a team that does the vetting/validation and when the C&Cs are taken down (or "decommissioned") they are removed from the feed. >Is there a notification mechanism so that folks who may not subscribe to Trend's service but who are unwittingly hosting a botnet C&C are made aware of same? > Well, we try to notify the owners of the identified hosts, but it is not always successful... and sometimes the sheer churn is prohibitive. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHpTu1q1pz9mNUZTMRAu+CAJ94j6AgqZgrMQ6b8HoPLyy4zBRcNgCfejWn dAE2T+i2MtvpAJ2PNJmdTpc= =N+iF -----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/

1 0

FW: Blackholes and IXs and Completing the Attack.
by Ben Butler 02 Feb '08

02 Feb '08

Hi, Agreed, but when you have >100 peers that is still a fair bit of work. I know technically how to do it and am doing this with transits but then there are only seven of those. It is not a question of how or can, but should / is it valuable / constructive? The starting point in the thought process having just done it for transits was right ok, now how do we sensibly scale this to apply it at IXes without everyone having to run round contacting everyone else and to see if there was an easier way of doing things, hence the suggestion. Plus it keeps things nice and separated, your IX peering sessions announce just the main prefixes, the session to the "blackhole reflector" can be in a separate peer-group and you only send the /32s to the reflector. You don't have to worry about who uses which communities as each member that chooses to peer with the reflector is able to apply an inbound routemap of their own choosing to any prefixes they receive from this reflector at each individual IX. Given that an ISP has elected to Complete the attack on a host that is being DoSed, for whatever reason, and they have chosen to send blackhole announcements to transit the logical extension seems to be to automate the sending of them to IXs to try to further cut down on traffic. I guess the alernative is that if your IX interconnect is getting hammered the only other option is to admin down all the sesions over the IX and let all the traffic flow into transit and let them blackhole it. But this also seems like there might be a better way that was less disruptive. And this seems like a easy way, internally you just community tag on the trigger box for where you want the announcement to go, transit, internal, customers, IX all,1 2 not 3 - whatever - and BGP sends it out. Easy, and a single system to send out all updates when you choose to and easy to remove when you want to take it out again. If you subscribe to completing the attack as a strategy, then the suggestion seemed like an easy way of rolling it out to the next logical point after transit. Kind Regards Ben ________________________________ From: Rick Astley [mailto:jnanog@gmail.com] Sent: 03 February 2008 01:02 To: Ben Butler Cc: nanog(a)merit.edu Subject: Re: Blackholes and IXs and Completing the Attack. While I am not sure I fully understand your suggestion, I don't think it would be that hard to set up manually. Sure it would require asking the individual peers for their black hole communities, but of they don't have one they are unlikely to honor the infrastructure you describe anyway. Assume your network is set up to discard packets marked with community 13005:666 Get a list of your peers blackhole communities, when you announce the route from a location on your network, tag it with community 13005:666 but also 1111:777, 2222:888 etc. for the individual peers from the source. This prevents you from having to update multiple policies in multiple locations for each attack. As long as they accept the /32 announced to them with their black hole community, they should discard the traffic without sending it to you. Not all peers will have a blackhole community, but you need some way to know when the attack is over to know when to withdraw the route, and they are useful for this. If you are real lazy, on the router you announce the black hole from, add an export policy that says from community 13005:666, then community add 1111:777, 2222:888 etc. This way you only need to: 1. Update one policy in one place when peers change 2. Announce the route from one location adding one community to it.

1 0

RE: Blackholes and IXs and Completing the Attack.
by Paul Ferguson 02 Feb '08

02 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Ben Butler" <ben.butler(a)c2internet.net> wrote: >The effect of this would be that any BotNet controlled hosts in the >other member network would now be able to drop any attack traffic in >their network on destination at their customer aggregation routers. > >I think you might have thought I was suggesting we blackhole sources in >other peoples networks - this is definatly not what I was saying. > >So, given we all now understand each other - why is no one doing the >above? We (Trend Micro) do something similar to this -- a black-hole BGP feed of known botnet C&Cs, such that the C&C channel is effectively black-holed. At least that way, people can deal with cleaning up the end-systems in their own way, at their own pace, while the amount of malicious activity is effectively "crippled". - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHpOWyq1pz9mNUZTMRAhtLAJwLNH9Ie+mE0106NlY6Qdy43uag1gCgv7wq le4yfSlaa2kUHtchC2X+bbQ= =4P1g -----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/

2 1

Re: Sicily to Egypt undersea cable disruption
by Martin Hannigan 02 Feb '08

02 Feb '08

On Feb 1, 2008 2:25 PM, Ahmed Maged (amaged) <amaged(a)cisco.com> wrote: > > > > "Does look normal to me" is far from a global conspiracy theory. > > > Thank you for the translation but I think you got it wrong. > I agree, there should be a sanity check as I understand that they are within close proximity of each other. Two ships slipping anchors and causing cable breaks in the same area is odd, but if there's a storm in the area, that would not be that much of a surprise. There should be some logic to the madness. I think that the moral of the story is that "more" operators should try to better understand what diversity means beyond the metro. The challenge is getting the information. The Teleography series of internet/sub maps are interesting. They don't demonstrate diversity though, since they show figurative routing. Those nice and straight lines are a pipe dream. -M< -M<

11 14

Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption
by Robert Bonomi 02 Feb '08

02 Feb '08

> Date: Fri, 1 Feb 2008 14:21:00 -0800 > From: "Scott Francis" <darkuncle(a)gmail.com> > Subject: Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption > > > On Feb 1, 2008 6:37 AM, Suresh Ramasubramanian <ops.lists(a)gmail.com> wrote: > > > > http://www.marketwatch.com/news/story/third-undersea-cable-reportedly-cut/s… > > > > "We had another cut today between Dubai and Muscat three hours back. > > The cable was about 80G capacity, it had telephone, Internet data, > > everything," one Flag official, who declined to be named, told Zawya > > Dow Jones. > > The cable, known as Falcon, delivers services to countries in the > > Mediterranean and Gulf region, he added. > > this (3 undersea cables in about a week, serving the same geographic > area, with two of the cuts happening on the same day!) is leaving the > realm of improbability and approaching the realm of conspiracy ... "Never ascribe to malice that which can be explained by incompetence" comes to mind.

2 1