Re: Trends in network operator security
On Wed, 8 Jan 2003 [EMAIL PROTECTED] wrote: Arent these more the attack trends of tier-3 providers and not network operators. Maybe. I don't see too many tier-1 network operators attacking other tier-1 network operators. The trend I continue to see affecting network operators is customer security incidents, i.e. compromised end-user applications. Seems to me that The the real issues is when the tier-2 and tier-1 infrastructure come under attack. Otherwise these others are all at the applications layer - which so few on this list are interested in. There are lots of interesting problems, but I don't know if 2003 is the year. DOS is just too much fun. Route hijacks/bogus origins Compromised infrastructure MLPS alteration Authentication attacks Physical intrusion
MSN IM Outage last week.
If you haven't seen it regarding last weeks outage: Microsoft: Human Error Was The Cause Of Five-Hour Instant Message Outage The service went out due to configuration errors when setting up new routers that were -- ironically enough -- installed to make the service more reliable. http://update.internetweek.com/cgi-bin4/flo?y=eKGj0BfFir0V30BpZb0Ad It's the interface between the chair and the keyboard... Best regards, __ Al Rowland
Re: Trends in network operator security
Unnamed Administration sources reported that Sean Donelan said: There are lots of interesting problems, but I don't know if 2003 is the year. DOS is just too much fun. Route hijacks/bogus origins Compromised infrastructure MLPS alteration Authentication attacks Physical intrusion This last one just hit the big bell atop the pole. Don't recall if NANOG mentioned it, but mid-December someone broke into a DOD-contractor HMO's server farm; and stole all the drives. Google-news on TriWest... It was clearly an organized identity theft. They got 500,000 names, medical records and SSNs. What data do YOU have that people might want to steal? Is it encrypted? -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: Trends in network operator security
On Thu, 9 Jan 2003, Sean Donelan wrote: On Wed, 8 Jan 2003 [EMAIL PROTECTED] wrote: Arent these more the attack trends of tier-3 providers and not network operators. Maybe. I don't see too many tier-1 network operators attacking other tier-1 network operators. The trend I continue to see affecting network operators is customer security incidents, i.e. compromised end-user applications. Would be nice to see all tier-X service providers provide more (working) knobs and response teams to help their customers and peers track, diagnose and defend and protect themselves against security attacks. Pete. http://pete.kruckenberg.com/blog
Re: Trends in network operator security
On Thu, 9 Jan 2003, Pete Kruckenberg wrote: Would be nice to see all tier-X service providers provide more (working) knobs and response teams to help their customers and peers track, diagnose and defend and protect themselves against security attacks. Symantec charges between $1,000-$2,000/month for a small or mid-size company. http://www.washingtonpost.com/wp-dyn/articles/A28625-2003Jan8.html Every major tier-1 service provider I know has a professional services consulting team customers can hire to help with security.
Verio yesterday
Verio appears to have had a number of problems yesterday: We noticed a tremendous packet loss spike and a loss in reachability to various sites. Verio states that it had issues [!] with www1501 and that customers in Boca Raton may have experienced delays. Anyone know what happened? Peter
Re: Trends in network operator security
On Thu, 9 Jan 2003, David Lesher wrote: Don't recall if NANOG mentioned it, but mid-December someone broke into a DOD-contractor HMO's server farm; and stole all the drives. It was clearly an organized identity theft. They got 500,000 names, medical records and SSNs. Repeat, for those who didn't get the import of that: They took the _medical records_ of _half a million_ US _soldiers_ and their families. Regardless of the identity-theft aspect, it's hard to imagine them not seeing a lucrative aftermarket for that batch of data. -Bill
Re: Trends in network operator security
They took the _medical records_ of _half a million_ US _soldiers_ and their families. Regardless of the identity-theft aspect, it's hard to imagine them not seeing a lucrative aftermarket for that batch of data. And just think, courtesy the USA Patriot act, next time it won't just be -military- records they get, it will be yours. America is starting to look more and more like the movie Minority Report. -Bill
NYT on Thing.net
I realize that this is skirting the edge of operational, but I think it is notable that Verios security policy and incident response allowed for an entire ISP to be disconnected at their discretion. I suppose that any ISP can turn off a connection they deem a threat to the rest of their operations, but I think this incident can serve as an example of how ISP's can get dragged into political spats. It shows how Verio was manipulated by Dow to squelch critics, but also how their incident response was used to martyr the ISP they shut down. It is also worth noting how Verio allowed themselves to be PR collateral damage, taking one of their customers down in the process, when the conflict was between a group of artists and Dow. If only large providers were this responsive to spam. Cheers, -- Forwarded message -- Date: Mon, 23 Dec 2002 15:25:20 -0100 From: nettime's_roving_reporter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: nettime NYT on Thing.net [ via [EMAIL PROTECTED]] http://www.nytimes.com/2002/12/23/arts/design/23ARTS.html?pagewanted=printposition=top Cyberspace Artists Paint Themselves Into a Corner By MATTHEW MIRAPAUL In a 1950's horror movie the Thing was a creature that killed before it was killed. Now in a real-life drama playing on a computer screen near you, the Thing is an Internet service provider that is having trouble staying alive. Some might find this tale equally terrifying. The Thing provides Internet connections for dozens of New York artists and arts organizations, and its liberal attitude allows its clients to exhibit online works that other providers might immediately unplug. As a result the Thing is struggling to survive online. Its own Internet-connection provider is planning to disconnect the Thing over problems created by the Thing's clients. While it may live on, its crisis illustrates how difficult it can be for Internet artists to find a platform from which they can push the medium's boundaries. Wolfgang Staehle, the Thing's founder and executive director, said the high-bandwidth pipeline connecting the Thing to the Internet would be severed on Feb. 28 because its customers had repeatedly violated the pipeline provider's policies. While the exact abuses are not known, they probably involve the improper use of corporate trademarks and generating needless traffic on other sites. If Mr. Staehle is unable to establish a new pipeline, the 100 Web sites and 200 individual customers, mostly artists, that rely on the Thing for Internet service could lose their cyberspace homes. In a telephone interview from the Thing's office in Chelsea, Mr. Staehle (pronounced SHTAW-luh) said, It's not fair that 300 of our clients will suffer from this and I might be out of business. The Thing's pipeline is currently supplied by Verio Inc. of Englewood, Colo., which declines to comment on its troubles with the Thing. Mr. Staehle said that he had not received official word from Verio, but that the company's lawyers told the Thing the service would be cut off because of the violations. For some digital artists, these are perilous times. With the Internet's rise have come increased concerns about everything from online privacy to digital piracy. Naturally artists are addressing these matters in Internet-based works. So an online project about copyright violations inevitably violates some copyrights, and a work that warns how a computer could be spying on you could very well be spying on you. Most Internet service providers yank such works offline whenever legal challenges are raised, so open-minded providers like the Thing become an important alternative. But as Alex Galloway, a New York artist, said, There really are no true alternative Internet service providers because connectivity is still controlled by the telecommunication companies. Mr. Staehle has learned this the hard way. The project that overheated Verio's circuits was probably a Web site created by an online group of political activists called the Yes Men. The site, at dow-chemical.com, resembled Dow Chemical's real site, at dow.com. But the contents were phony news releases and speeches that ridiculed Dow officials for being more interested in profits than in making reparations for a lethal gas leak at a Union Carbide plant (now owned by Dow) in Bhopal, India, in 1984. The hoax's supporters said it was a parody. But Dow's lawyers contacted Verio to complain that the site infringed on its trademarks, among other sins. Initially it seemed to be just another fracas over corporate logos and other forms of intellectual property on the Internet. What happened next stunned Mr. Staehle. The Yes Men project had been put online by RTMark.com, a politically active arts group that uses the Web as its base and gets its Internet service from the Thing. After Dow complained about the fake Web site, Mr. Staehle said, Verio alerted the Thing, where a technician said he was not authorized to act.
Re: Trends in network operator security
On Wed, 8 Jan 2003, Sean Donelan wrote: :Its 2003 and everyone is making their predictions. What trends are :network operators seeing for Internet security? - Backdoors will be found in every major OS after they have been shipped on disk. - More reports of trojaned packages. - Resurgance of the cc conspiracy that says all code is backdoored by the compiler. - Dealing with mountains of IDS data. Especially as customers and investors demand the use of these kinds of technologies. - Demands from LEO's regarding tracking users of wireless networks. General legal attacks on any technology that facilitates anonymity. - Blame shifted to the service provider for vulnerabilities, more ISP's will get into the managed security business. They will be the next big vertical for MSS companies. - Spam will finally be widely recognized as a security issue. My pet definition of spam being any message that relies on the lack of policy enforcement features in mail protocols for delivery, will be widely adopted. - Lots of new exploits affecting image processing and multi-media libraries and applications. :Any other trends network operators are seeing? Multi-payload and multi-attack vector worms and viruses. More hostile code that uses mail and file shares to spread. Tunneling protocols and applications to evade firewalls, and detection. Security, security and more security. How did peoples predictions from last year fare? -- batz
RE: Weird networking issue.
In the real world, auto-negotiation on fiber vs. auto-negotiation on copper have been two different animals. Most of the compatibility issues result from 10/100 auto-negotiation on copper as this was the first major deployment of the technique in Ethernet devices. Most devices engineered recently should auto-negotiate properly. In the early to mid 90's this was only true within the product line of a single vendor. Many of the products Cisco sells were engineered by different companies and often have problems auto-negotiating to other Cisco gear made by other companies. Also remember that many of the products that Cisco still sells have roots back 5 or more years. There is a good chance that any 3600 copper interface could have the same issues that its cousins did in 1997. The question of hard-setting speed/duplex on these types of interfaces is about as murky an issue as spanning-tree. You solve some problems and create others. I suppose the primary goal is to eliminate support calls and outages within your own environment. In my experience, connections which as static (servers, routers, etc...) should be hard coded on both sides as incorrect negotiations can and do occur. It is also frustrating to discover that your primary file server has been running at half duplex for a week. It may also be interesting to know that IEEE 802.3-2002 says that auto-negotiation is optional (in section 28.1.2.) It may also be interesting to know that if a device does support auto negotiation it must allow manually overriding of the function (IE.. an unconfigurable device is not allowed to auto-negotiate.) -Original Message- From: Mikael Abrahamsson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 2:39 AM To: [EMAIL PROTECTED] Subject: RE: Weird networking issue. On Wed, 8 Jan 2003, Stephen J. Wilcox wrote: So thats human error not a problem with using forced settings, eliminate the human error and I think you'll see forced always works, autoneg sometimes works. (For future reference dont employ incompetent people to run your networks folks!) Problem with autoneg is that you always have to have manageble equipment and you always have to check both ends after changing anything. In an ISP environment that is generally not a problem luckily, apart from the equipment you connect to on the customer side, some customers insist on using cheapo stuff. Autoneg does add good things, especially on GigE. Autoneg on a GigE yields the most desireable effect of link loss return, ie if you lose fiber link one way the link goes down at both ends. Have you looked at what autoneg is.. its horrible, a hack to help out the above incompetent engineers who dont know how to force duplex. Hmm, I might draw the same conclusion regarding automatic gear boxes on cars but I think I should not considering the situation in the US regarding that perticular issue :) Personally I think the idea with autoneg is really a good thing, why shouldnt two units advertise their capabilities and then act accordingly to what they both can do? We do the same on SMTP (EHLO) and so on. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
frame relay to atm conversion tool?
I'm trying to locate a tool (eg, spreadsheet) to convert throughput on a frame circuit to an ATM circuit. So, for example if you have a 512k CIR with burst to 1024k and 80% of the time you get your burst bandwidth and you want to convert that link to ATM, what corresponding SCR/PCR/MBS values would you need. I'm less concerned with Frame vs ATM protocol overhead than I am with calculating the difference in the way the burst bandwidth is meted out. Any recommendations? Supposing no one knows of such a tool. Would anyone be interesting in helping me put one together? Best Regards, -BM
Re: hotmail problem
On Thursday, January 9, 2003 @ 2:11:02 PM [-0700], Oscar Valdez wrote: some problem with www.hotmail.com right now??? the page doesnt open. I believe the problem is not at the destination but somewhere in between... 8 gar1-p360.stwwa.ip.att.net (12.123.203.169) 30.418 ms 30.371 ms 30.326 ms 9 * * * 10 * * * -- Matt
Re: hotmail problem
Im finding it reachable at the moment. But MSN messenger just started having problems again. 18:29. Let's see if it disappears quickly this time. They may be cutting something over. David At 14:22 -0800 1/9/03, Matt Thoene wrote: On Thursday, January 9, 2003 @ 2:11:02 PM [-0700], Oscar Valdez wrote: some problem with www.hotmail.com right now??? the page doesnt open. I believe the problem is not at the destination but somewhere in between... 8 gar1-p360.stwwa.ip.att.net (12.123.203.169) 30.418 ms 30.371 ms 30.326 ms 9 * * * 10 * * * -- Matt
Re: US-Asia Peering
At 10:35 AM 1/3/2003 -0800, Bill Woodcock wrote: clearly, interconnecting their exchange points to create a richly- connected Internet 'core' is a natural progression if their customers don't complain too loudly. not that it's a bad long-term plan... Actually, it is. It's failed in every prior instance. I'd like to understand your viewpoint Bill. The LINX consists of a handful of distributed and interconnected switches such that customers are able to choose which site they want for colo. Likewise for the AMS-IX and a handful of other dominant European exchanges. By most accounts these are successful IXes, with a large and growing population of ISPs benefiting from the large and growing population. So I don't see the failure cases. It's one of the many, many ways in which exchange points commit suicide. I'd love to see a list of the ways IXes commit suicide. Can you rattle off a few? -Bill
Re: US-Asia Peering
The LINX consists of a handful of distributed and interconnected switches such that customers are able to choose which site they want for colo. Likewise for the AMS-IX and a handful of other dominant European exchanges. Correct. Within the metro area. That is, as has been documented many times over, a necessary condition for long-term stability. It's one of the many, many ways in which exchange points commit suicide. I'd love to see a list of the ways IXes commit suicide. Can you rattle off a few? 1) Cross the trust threshhold in the wrong direction. 2) Cross the cost-of-transit threshhold in the wrong direction. 3) Increase shared costs until conditions 1 and/or 2 are met. Those are sort of meta-cases which encompass most of the specific failure modes. Of course, you can always declare yourself closed or obsolete, a al MAE-East-FDDI, which I guess would be a fourth case, but rare. -Bill
Re: US-Asia Peering
On Thu, 9 Jan 2003, Bill Woodcock wrote: The LINX consists of a handful of distributed and interconnected switches such that customers are able to choose which site they want for colo. Likewise for the AMS-IX and a handful of other dominant European exchanges. Correct. Within the metro area. That is, as has been documented many times over, a necessary condition for long-term stability. Theres an increasing number of psuedo-wire connections tho, you could regard these L2 extensions an extension of the switch as a whole making it international. Where the same pseudo wire provider connects to say LINX, AMSIX, DECIX your only a little way off having an interconnection of multiple IXs, its possible this will occur by accident .. Steve It's one of the many, many ways in which exchange points commit suicide. I'd love to see a list of the ways IXes commit suicide. Can you rattle off a few? 1) Cross the trust threshhold in the wrong direction. 2) Cross the cost-of-transit threshhold in the wrong direction. 3) Increase shared costs until conditions 1 and/or 2 are met. Those are sort of meta-cases which encompass most of the specific failure modes. Of course, you can always declare yourself closed or obsolete, a al MAE-East-FDDI, which I guess would be a fourth case, but rare. -Bill
Re: US-Asia Peering
Where the same pseudo wire provider connects to say LINX, AMSIX, DECIX your only a little way off having an interconnection of multiple IXs, its possible this will occur by accident .. and l2 networks scale s well, and are so well known for being reliable. is no one worried about storms, spanning tree bugs, ... in a large multi-l2-exchange environment? this is not a prudent direction. randy
Re: US-Asia Peering
At 06:07 PM 1/9/2003 -0800, Randy Bush wrote: Where the same pseudo wire provider connects to say LINX, AMSIX, DECIX your only a little way off having an interconnection of multiple IXs, its possible this will occur by accident .. and l2 networks scale s well, and are so well known for being reliable. is no one worried about storms, spanning tree bugs, ... in a large multi-l2-exchange environment? this is not a prudent direction. Well, first I think we need to agree that there are two different cases here: 1) interconnecting IXes operated by the same party, vs. 2) interconnecting IXes operated by different parties. In the first case an IX operator can shoot himself in the foot, but there is only one gun and one person, so you can easily figure out why the foot hurts. In the latter case, there are more people with more guns. Without perfect information distributed among the operators, this is clearly a more dangerous situation and diagnosing/repairing is more difficult and time intensive. I believe we are really talking about the first case. Secondly, some of the issues of scaling l2 infrastructure have been addressed by VLANs, allowing the separation of traffic into groups of VLAN participants. This reduces the scope of an L2 problem to the VLAN in use. Since the role of the IX operator is to provide a safe stable scaleable etc. interconnection environment, distributed VLANs are a tool that can help extend the peering population while mitigating the risk of any single ISP from wrecking the peering infrastructure. Bill randy
RE: frame relay to atm conversion tool?
On 9 Jan 2003 at 17:45, Swaminathan, Sekar wrote: Instead of Frame Relay frames, you have to look at the payload which is usually IP packets. Here is the formula that I would use: [...] Specifying an average packet size is rough: I've observed that on an average Internet connection around 35% of packets are 64 bytes, 35% 1500 bytes, and the remainder scattered about. The average is guaranteed to be a poor match for at least 70% of your traffic. Not that it matters. Most carriers configure FRATM VCCs as 1536kbps frame relay = 4500cps, treating fractions accordingly. The last thing you want to do is exceed this cell rate (around 1710kbps at a 1500-byte packet size), as on a policed link you'll lose nonconforming cells. (Actually, a 1536kb frame relay seems to be closer to a 1705kb ATM VCC. Eh, the IWF has to buffer some anyway.) If you increase your cell rates you potentially oversubscribe your frame link (and the IWF may disallow it in any case). So if you're tempted to exceed this ratio be very certain of your link characteristics. Add to that: when a sustained rate is defined (VBR service category) the ATM peak rate probably doesn't mean what you would expect, so I recommend sustained = peak. (ABR is the best match for data, but isn't often used.) As to the original question, I wouldn't recommend translating a burstable frame to ATM unless you can order an ABR VCC or get UPC and/or frame discard disabled on your link (don't bet on it). It's not likely you can match parameters, so without flow control you're essentially looking at reduced performance or packet loss under load. Whatever you do get, I recommend you ask your carrier for a spec. You have plenty of variables and relatively robust protocols, meaning you could take a shot, miss, and only find out for certain that you had when you'd really rather not. Get it reasonably right, though, and it'll do right by you. Huh. Now that I look at it, I need to rethink my own figures yet again (I haven't even implemented the last rethink) as I appear to have tended toward the conservative in some areas. Grrr. Take it easy. Peter E. Fry
Re: US-Asia Peering
Well, first I think we need to agree that there are two different cases here: 1) interconnecting IXes operated by the same party, vs. 2) interconnecting IXes operated by different parties. In the first case an IX operator can shoot himself in the foot, but there is only one gun and one person, so you can easily figure out why the foot hurts. well, now we know you have ever had to debug a large L2 disaster randy
Re: US-Asia Peering
Well, first I think we need to agree that there are two different cases here: 1) interconnecting IXes operated by the same party, vs. 2) interconnecting IXes operated by different parties. PAIX has successful implementations of both of these (I count our metro strategy as an instance of the first sort, and our varied interconnections to other switch fabrics operated by other people as an instance of the second). With both, as I stated earlier, a thorough understanding of the shortcomings of L2 fabrics as a place for different parties to meet is crucial to avoiding service-affecting outages. The lessons learned along the way are very helpful in debugging quickly and thoroughly when a service-affecting outage creeps through. Stephen VP, Eng. PAIX
Re: US-Asia Peering
At 08:14 PM 1/9/2003 -0800, Randy Bush wrote: Well, first I think we need to agree that there are two different cases here: 1) interconnecting IXes operated by the same party, vs. 2) interconnecting IXes operated by different parties. In the first case an IX operator can shoot himself in the foot, but there is only one gun and one person, so you can easily figure out why the foot hurts. well, now we know you have ever had to debug a large L2 disaster Randy - You snipped out what I said out of context. Below is the complete paragraph (and admittedly I should have said relatively easily rather than easily.) The point is that I don't think we are talking about interconnecting switches operated by different parties, and I think you would agree that if it is difficult diagnosing problems with a single large scale l2 fabric, it is even more difficult with multiple administrative domains. That was the point. Original Paragraph: In the first case an IX operator can shoot himself in the foot, but there is only one gun and one person, so you can easily figure out why the foot hurts. In the latter case, there are more people with more guns. Without perfect information distributed among the operators, this is clearly a more dangerous situation and diagnosing/repairing is more difficult and time intensive. I believe we are really talking about the first case. Woody - I'd still like to hear about the failures in every prior instance. clearly, interconnecting their exchange points to create a richly- connected Internet 'core' is a natural progression if their customers don't complain too loudly. not that it's a bad long-term plan... Actually, it is. It's failed in every prior instance. Thanks.
Re: Trends in network operator security
Unnamed Administration sources reported that John Fraizer said: Does anyone know the answers to the following: (1) Why was this datacenter unmanned? Why are CO's unmanned Saturday nights? ISP's? Could the cost of manpower having anything to do with it? (2) If it was manned, how did the perps get physical access to steal the drives? Once in the building, one article mentioned they'd found an access card to the machine room in a PHB's office. No PINs? (3) Has the contractor been removed from the list of authorized vendors? (4) If not, why on earth NOT? The vender peddles aspirin, not data services. You propose to now deny those 500K families medical care, after raping their privacy? -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: US-Asia Peering
On Fri, 10 Jan 2003, Stephen J. Wilcox wrote: Theres an increasing number of psuedo-wire connections tho, you could regard these L2 extensions an extension of the switch as a whole making it international. Where the same pseudo wire provider connects to say LINX, AMSIX, DECIX your only a little way off having an interconnection of multiple IXs, its possible this will occur by accident .. Yes, that's an unfortunate accident that's occurred before. -Bill
Re: Trends in network operator security
On Thu, 9 Jan 2003, Sean Donelan wrote: On Thu, 9 Jan 2003, Pete Kruckenberg wrote: Would be nice to see all tier-X service providers provide more (working) knobs and response teams to help their customers and peers track, diagnose and defend and protect themselves against security attacks. Symantec charges between $1,000-$2,000/month for a small or mid-size company. http://www.washingtonpost.com/wp-dyn/articles/A28625-2003Jan8.html Every major tier-1 service provider I know has a professional services consulting team customers can hire to help with security. I think pete's thing was more that all isp's should have 24/7 security folks on call/staff that can track attacks/incidents and hand that tracking off to their partners at other isp's as they reach the edge of their network. Say, what about a consulting service that does this for all large isps :)
Re: US-Asia Peering
what a morass of confusion. on the one hand we have a metro peering fabric, which as linx, exchangepoint, paix, and lots of others have shown, is good. on another hand we have a metro peering fabric, which as mfs and ames showed, can be really bad. because we have a lot of hands we also have exchange-level peering, which as paix and six has shown, can be done safely. there's also a hand containing multiple instances of exchange level peering which was not done safely (and i'm not double counting ames and mfs here.) finally we have intermetro (wide area) peering, which has been shown to be a complete joke for peering for any number of reasons. before any of you argue further, please carefully define your terminology so the rest of us will know how to fill out our scorecards. -- Paul Vixie
hotmail problem
some problem with www.hotmail.comright now??? the page doesnt open. -- Oscar
