Re: manhole covers
At a University I consult for, this is a common problem, their 34.5kv lines, which incidentally travel the same hole as their fiber optics, blow open about once a month, due to failing old power lines. Get used to it, and make money off of it, is all I can say At 20:59 2/21/03 -0500, you wrote: On Fri, 21 Feb 2003, Marshall Eubanks wrote: The interesting thing is that this happens every few weeks (at least - sometimes multiple times per week), and generally they don't know why. Not in Adams Morgan. Not in Foggy Bottom. Not even in Georgetown Heights. Only in Georgetown, Its become a local joke. Well of course we know why, its the St. Elmo's Fire ;). allan -- Allan Liska [EMAIL PROTECTED] http://www.allan.org
Re: M$SQL cleanup incentives
I'll bite.. - Original Message - From: William Allen Simpson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 21, 2003 2:25 PM Subject: Re: M$SQL cleanup incentives [snip] I'm of the technical opinion that everyone will need to filter outgoing 1434 udp forever. [snip] Iljitsch van Beijnum wrote: Maybe the best approach is to try and deliberately infect the entire local net every few minutes or so to detect new vulnerable systems while the people installing them are still on the premises. Gosh, should we do that for every known virus/worm/vulnerability? Which is it? Where do you draw the line between something that's big enough to block forever and something that's not worth tracking down? You lambast him for attempting a solution that is foolish to apply for every known possible problem where if your solution was applied as such, we'd have a swiss-cheese internet in which any commonly used destination port is blocked due to the scads of IIS/bind/fingerd/ftpd/whatever worms. Have fun filtering. Or maybe you don't actually own and/or have legal and financial accountability for your own network? Or maybe he likes having a network his customers can actually use. --Doug
Re: 223.255.255.0/24
I can imagine there is some reason why this was originally reserved thats probably not valid any more.. However seems like a lot of effort to change documents and policies for a single /24 ! Steve On Thu, 20 Feb 2003 [EMAIL PROTECTED] wrote: 223.255.255.0/24 has historically been designated as a special-use network as it is the numerically highest Class C network. It is listed in RFC3330 as Reserved but open for possible future allocation. Now that 222/7 has been allocated to APNIC, the question comes up as to whether it is retaining the Reserved designation, or whether APNIC will keep it as reserved. I note that the APNIC whois servers do not denote it as Reserved. I bring this up since many bogon filters include this network for both routing and packet filtering. I have queries out to both APNIC and IANA as to the present status of that network, but I expect IANA will likely defer to APNIC. If it is no longer reserved, I've suggested that RFC3330 be updated to reflect its present status (such as prior-special-use networks are listed). In any event, pending confirmation from APNIC, I suggest folks look over their own bogon filtering. A quick check of Rob's list doesn't have this network specified. I believe that Juniper has a prebuilt bogon list, but I don't recall whether this network is on it or not. I've suggested APNIC send out email to the operations community, but if they don't, I'll send an update with whatever they send me.
Re: M$SQL cleanup incentives
Doug Clements wrote: Which is it? Where do you draw the line between something that's big enough to block forever and something that's not worth tracking down? Where it causes a network meltdown. The objective reality is pretty clear to some (many? most?) of us. You lambast him for attempting a solution that is foolish to apply for every known possible problem You bet I do! where if your solution was applied as such, we'd have a swiss-cheese internet in which any commonly used destination port is blocked due to the scads of IIS/bind/fingerd/ftpd/whatever worms. In one part of your response, you note I don't advocate a 1-size-fits- all solution, and then the second part, assume 1-size-fits-all. That's inconsistent logic in your argument. Have fun filtering. Filtering is not fun. That's why I'm trying to get everyone to cooperate in eradication of this particular problem, so that we could drop filters. (Look at the subject line.) Right now, whether you know it or not, filtering is all that's holding the Internet as a whole together If you didn't filter, you're actually depending on the good graces of the rest of us that did! Should we start using more loaded words, like parasite? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: [Re: [Re: M$SQL cleanup incentives]]
BB DNS clients will eventually timeout and fall back to another BB server, so any problems would be transient, but the packets BB were legit, right? Stateful packet filters are nice. Properly written, they protect both inbound and outbound traffic and need to track very little state. Stateful packet filtering by C sitting between A and B is fallacy since in order for C to make an intelligent decision it may need to know the details of every possible communication protocol used by A and B. Alex
Fast.Net / Netaxs down?
Our link to FastNet (formerly Netaxs) went down a while ago, and their phone lines are all busy. I can get to fast.net's website, but none of the netaxs servers, including NewsRead.com. They are at a somewhat low elevation, so I'm wondering if they're dealing with a flooding situation. Our circuit to sprintlink in Pennsauken is fine (for now). Does anybody have any info on this they can share? James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: M$SQL cleanup incentives
On Sat, Feb 22, 2003 at 09:25:24AM -0500, William Allen Simpson wrote: Doug Clements wrote: Which is it? Where do you draw the line between something that's big enough to block forever and something that's not worth tracking down? Where it causes a network meltdown. The objective reality is pretty clear to some (many? most?) of us. I see. So you're still filtering port 25 from the Morris sendmail worm. The issue I had with your argument is forever. You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory. Filtering is not fun. That's why I'm trying to get everyone to cooperate in eradication of this particular problem, so that we could drop filters. (Look at the subject line.) The first step in eradication is detection. I presume that since you're taking this stance, you're checking your filter logs and attempting to notify the appropriate partys for each hit. If you're not, then our buddy trying to infect all the machines on his network every so often is being more effective in wiping out the worm. Right now, whether you know it or not, filtering is all that's holding the Internet as a whole together If you didn't filter, you're actually depending on the good graces of the rest of us that did! If you didn't filter or don't filter? We definately filtered when the worm first came out. We don't block port 1433 anymore (nor does any of our upstreams), but we still report suspicious traffic. Regardless of what everyone else is doing, the worm is not causing a meltdown anymore. The correct course of action is to remove filters as resources allow, and investigate infected machines as they are noticed. I'm sorry, but I'm not seeing your case for implementing permament filters for this or anything else. --Doug
Reports of flooding in Tyson's Corner Virginia
The associated press is reporting that parts of Tyson's Corner is experiencing flooding, and officials are restricting access. As some folks are aware the Tyson's Corner area is/was a very dense colocation and peering center for the Internet.
Re: Reports of flooding in Tyson's Corner Virginia
Unnamed Administration sources reported that Sean Donelan said: The associated press is reporting that parts of Tyson's Corner is experiencing flooding, and officials are restricting access. As some folks are aware the Tyson's Corner area is/was a very dense colocation and peering center for the Internet. DC has ~24 of snow load, and it's been raining. In fact, we had a VERY vocal thunderstorm a few hours. You can expect flooding in the usual places in the next day or so. -- 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
SSL crack in the news
http://www.cnn.com/2003/TECH/internet/02/21/email.encryption.reut/index.html Very little real information... Mark Radabaugh Amplex (419) 720-3635
Re: SSL crack in the news
more here: http://lasecwww.epfl.ch/memo_ssl.shtml Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon [EMAIL PROTECTED] (541) 346-1774/Cell: 912-7998 On Sat, 22 Feb 2003, Mark Radabaugh wrote: http://www.cnn.com/2003/TECH/internet/02/21/email.encryption.reut/index.html Very little real information... Mark Radabaugh Amplex (419) 720-3635
Re: M$SQL cleanup incentives
On Sat, 22 Feb 2003, Doug Clements wrote: The issue I had with your argument is forever. You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory. Unlikely in this case. A reasonably fast system infected with slammer is capable of generating enough traffic to make the Cisco 2900XL switch its plugged into incapable of passing normal traffic. All it takes is one infected customer's system to really foul up the network it's attached to. The only plus side is, this is perfect justification to management for replacing any switches customers connect to with newer ones that (at least claim to) do per-port rate limiting. If your network is able to contain slammer infected boxes without melting down, who cares if you have a few infected customers? You don't need to filter, and they'll all be encouraged to fix their systems sooner. I setup inbound 1434/udp filters the 3rd time we had a customer (different ones each time) get (re-?)infected weeks after the initial outbreak. Sure, some DNS replies and assorted other packets will get dropped, but AFAIK, nobody has complained or even noticed...and we've had no more re-infections since the filters were put in place. I don't believe we'll have to filter 1434/udp forever, but I plan to leave the filters in place until we no longer need them or until they hurt more than they help. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: M$SQL cleanup incentives
Thus spake [EMAIL PROTECTED] If your network is able to contain slammer infected boxes without melting down, who cares if you have a few infected customers? You don't need to filter, and they'll all be encouraged to fix their systems sooner. As one hoster put it to me, DoS and worm traffic is billable so it's not in the hoster's interests to protect customers -- quite the opposite in fact. I don't believe we'll have to filter 1434/udp forever, but I plan to leave the filters in place until we no longer need them or until they hurt more than they help. What will you do when a similar worm appears on 53/udp or some other heavily-used port? We lucked out with Sapphire because MS/SQL is generally safe to block on public networks, but its speed can be easily applied to other protocols we can't afford to block. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: SSL crack in the news
On Sat, Feb 22, 2003 at 03:55:14PM -0500, Mark Radabaugh wrote: http://www.cnn.com/2003/TECH/internet/02/21/email.encryption.reut/index.html Very little real information... Sounds like a CNN-digested version of CAN-2003-0078, which is a (relatively minor) bug in OpenSSL which allows for a timing attack. OpenSSL CHANGES file: *) In ssl3_get_record (ssl/s3_pkt.c), minimize information leaked via timing by performing a MAC computation even if incorrrect block cipher padding has been found. This is a countermeasure against active attacks where the attacker has to distinguish between bad padding and a MAC verification error. (CAN-2003-0078) [Bodo Moeller; problem pointed out by Brice Canvel (EPFL), Alain Hiltgen (UBS), Serge Vaudenay (EPFL), and Martin Vuagnoux (EPFL, Ilion)] CNN: NEW YORK (Reuters) -- Researchers at a Swiss university have cracked the technology used to keep people from eavesdropping on e-mail sent over the Web... Typical. -- - mdz
Re: M$SQL cleanup incentives
Doug Clements wrote: I see. So you're still filtering port 25 from the Morris sendmail worm. Funny thing, I was a researcher visiting at Cornell, and had just left in the car for the 9.5 hour drive home when it struck. I've often wished I'd stuck around for a few more hours for the excitement. Anyway, we didn't need to put in a long term block, as everyone took down their systems and cleaned them. I didn't even find out about the problem until over a day later, by which time it was long gone. Ah, the days when we all cooperated Well, of course, there were fewer systems involved. ;-) Then again, there were fewer people to fix them, too. The issue I had with your argument is forever. You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory. Sure. I'll be happy to modify that *forever* to when all M$ systems have been cleaned and updated. Let us all know when that happens, will you? The first step in eradication is detection. I presume that since you're taking this stance, you're checking your filter logs and attempting to notify the appropriate partys for each hit. For some silly reason, not all operators are notifying their own customers, even when reported. Anyway, we passed the detection phase long ago, and the second step in eradication is quarantine. That's what I'm talking about! If you're not, then our buddy trying to infect all the machines on his network every so often is being more effective in wiping out the worm. Fascinating. I'm sure his legal department will have an opinion on that. However, we could help protect him from legal issues by adopting self-help as a Best Current Practice. Are you ready and willing to write up the internet-draft? If you didn't filter or don't filter? We definately filtered when the worm first came out. We don't block port 1433 anymore (nor does any of our upstreams), but we still report suspicious traffic. Regardless of what everyone else is doing, the worm is not causing a meltdown anymore. The reason is that many of us are _still_ filtering. Some who removed filters put them back. correct course of action is to remove filters as resources allow, and investigate infected machines as they are noticed. Unfortunately, I haven't seen a lot of investigation. Perhaps you can explain why the infection rate is still the same after 3 weeks? Anyway, I'll chalk you in the column for removing all filters, and hoping for the best. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
RE: SSL crack in the news
Yeah, CNN screwed up the story more than they releaed anything.. Jim -Original Message- From: Matt Zimmerman To: [EMAIL PROTECTED] Sent: 2/22/03 5:13 PM Subject: Re: SSL crack in the news On Sat, Feb 22, 2003 at 03:55:14PM -0500, Mark Radabaugh wrote: http://www.cnn.com/2003/TECH/internet/02/21/email.encryption.reut/index. html Very little real information... Sounds like a CNN-digested version of CAN-2003-0078, which is a (relatively minor) bug in OpenSSL which allows for a timing attack. OpenSSL CHANGES file: *) In ssl3_get_record (ssl/s3_pkt.c), minimize information leaked via timing by performing a MAC computation even if incorrrect block cipher padding has been found. This is a countermeasure against active attacks where the attacker has to distinguish between bad padding and a MAC verification error. (CAN-2003-0078) [Bodo Moeller; problem pointed out by Brice Canvel (EPFL), Alain Hiltgen (UBS), Serge Vaudenay (EPFL), and Martin Vuagnoux (EPFL, Ilion)] CNN: NEW YORK (Reuters) -- Researchers at a Swiss university have cracked the technology used to keep people from eavesdropping on e-mail sent over the Web... Typical. -- - mdz
Re: Reports of flooding in Tyson's Corner Virginia
In a message written on Sat, Feb 22, 2003 at 03:41:19PM -0500, Sean Donelan wrote: The associated press is reporting that parts of Tyson's Corner is experiencing flooding, and officials are restricting access. As some folks are aware the Tyson's Corner area is/was a very dense colocation and peering center for the Internet. Having just been in that area yesterday, I think I can explain a bit. To many people Tysons Corner == Tysons Corner Mall, I and II (yes, two different malls across the street from each other). I is a fairly normal american mall, II has more upscale stores in it. Anyhow, the II part has been closed twice this week, once on thursday for a bomb scare, and today due to roof issues (unclear from the reports on TV if there is an actual problem, or if they are just scared of one). As such, the mall is closed, along with a few access roads for it. The actual area is fine, and not in a flood plain. That's not to say there won't be other roof issues or clogged drains, but I don't think there's any reason to fear it's all underwater, or anything. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Reports of flooding in Tyson's Corner Virginia
Including our basement; we live a few miles from Tyson's. --Steve At 3:52 PM -0500 2/22/03, David Lesher wrote: You can expect flooding in the usual places in the next day or so.
Re: SSL crack in the news
Mark Radabaugh [EMAIL PROTECTED] writes: http://www.cnn.com/2003/TECH/internet/02/21/email.encryption.reut/index.html Very little real information... Here's the writeup I sent to the cryptography mailing list. -- Here's a fairly detailed description of how the attack works. You can also find a writeup by the authors at: http://lasecwww.epfl.ch/memo_ssl.shtml EXECUTIVE SUMMARY This is a potentially serious attack for automated systems that rely on passwords. Effectively, it potentially allows the attacker to recover an encrypted password. It doesn't appear to be serious for non-automated situations. OVERVIEW Imagine you have some protocol that uses passwords and the password always falls in the same place in the message stream. (IMAP, for instance). What happens is that the attacker observes a connection using that password. He then deliberately introduces a bogus message into the encrypted traffic and observes the server's behavior. This allows him to determine whether a single byte of the plaintext is a certain (chosen) value. By iterating over the various bytes in the plaintext he can then determine the entire plaintext. HOW THE ATTACK WORKS Basically, the attack exploits CBC padding. Recall that the standard CBC padding is to pad with the length of the pad. So, if you have an 8 byte block cipher and the data is 5 bytes long you'd have XX XX XX XX XX 03 03 03. This technique allows you to remove the pad by examining the final byte and then removing that many bytes. [0] Typically you also check that all the pad values are correct. Say the attacker intercepts a pair of consecutive blocks A and B, which are: A = AA AA AA AA AA AA AA a B = BB BB BB BB BB BB BB b And the plaintext of B corresponds to P = PP PP PP PP PP PP PP p The attacker wants to attack B and guesses that p == y. He transmits a new message A' || B where A' = AA AA AA AA AA AA AA (a XOR y) When the server decrypts B, the final byte will be (p xor y). If the attacker has guessed correctly then there will appear to be a zero length pad and MAC verification proceeds. Since the packet has been damaged, the MAC check fails. If the attacker has guessed wrong then the last byte will be nonzero and the padding check will fail. Many TLS implementations generated different errors for these two cases. This allows the attacker to discover which type of error has occurred and thus verify his guess. Unfortunately, since this generates an error, the attacker can only guess once. The attack described above was discovered a year or two ago and implementations were quickly modified to generate the same error for both cases. This attack introduces two new features: (1) The authors observed that if you were moving passwords over TLS then the password would generally appear in the same place in each protocol exchange. This lets you iterate the attack over multiple character guesses and eventually over multiple positions. (2) Even if the same error message generated the MAC check takes time. You can therefore use timing analysis to determine what kind of error occurred. This has the downside that there's some noise but if you take enough samples you can factor that out. PRACTICALITY Let's estimate how long this will take. Most passwords are 7-bit ASCII, so naively we need to try all 128 values for each character. On average we'll get a hit halfway through our search so we expect have to try about 64 values for each character position. If we assume an 8 character password this means we'll need about 8*64==512 trials. Now, you could be smarter about what characters are probable and reduce these numbers somewhat but this is the right order of magnitude. Now, things are complicated a bit by the fact that each trial creates an error on both client and server. This has two implications. First, it creates a really obvious signature. Second, it requires that the client create a lot of SSL connections for the attacker to work with. This is only likely if the client is automated. REQUIRED CONDITIONS So, under what conditions can this attack be successful? (1) The protocol must have the same data appearing in a predictable place in the protocol stream. In practice, this limits its usefulness to recovering passwords. However, this condition pretty common for things like HTTP, IMAP, POP, etc. (2) The SSL implementations must negotiate a block cipher. Many SSL implementations choose RC4 by default and RC4 is not vulnerable to this attack. (3) The attacker needs to be able to hijack or intercept TCP connections. There are tools to do this that require varying degrees of sophistication and access to use. (4) The client must be willing to initiate a lot of connections even if it's getting SSL errors. As a consequence it almost certainly needs to be an automated client. (5) The attacker and the server must have a
Re: M$SQL cleanup incentives
On Sat, 22 Feb 2003, Stephen Sprunk wrote: As one hoster put it to me, DoS and worm traffic is billable so it's not in the hoster's interests to protect customers -- quite the opposite in fact. Whether or not the traffic is billable is irrelevant if your network is effectively down. One infected host connected to a 2900XL effectively kills the switch. I was fortunate enough to be on vacation and not even have net access when the initial slammer wave hit. But when I was back and on-call, we had a single customer get (re-?)infected, killing the switch they were on and noticably slowing down the network for the whole POP. What will you do when a similar worm appears on 53/udp or some other heavily-used port? We lucked out with Sapphire because MS/SQL is generally Be screwed unless we've completed planned upgrades. But in this case, I can filter until we've upgraded our network to hardware that's better able to deal with such traffic. Just because filtering might not always work doesn't mean it shouldn't be done when it does work. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Reports of flooding in Tyson's Corner Virginia
On Sat, Feb 22, 2003 at 05:33:20PM -0500, Leo Bicknell wrote: In a message written on Sat, Feb 22, 2003 at 03:41:19PM -0500, Sean Donelan wrote: The associated press is reporting that parts of Tyson's Corner is experiencing flooding, and officials are restricting access. As some folks are aware the Tyson's Corner area is/was a very dense colocation and peering center for the Internet. Having just been in that area yesterday, I think I can explain a bit. To many people Tysons Corner == Tysons Corner Mall, I and II (yes, two different malls across the street from each other). I is a fairly normal american mall, II has more upscale stores in it. Anyhow, the II part has been closed twice this week, once on thursday for a bomb scare, and today due to roof issues (unclear from the reports on TV if there is an actual problem, or if they are just scared of one). As such, the mall is closed, along with a few access roads for it. Looks like 30 stores on the upper level were flooded (probably too strong a word, slightly moistened would seem more appropriate) due to a roof leak, and the mall was closed. Hardly a danger to the internet, unless there are more people than I know doing their private interconnects through Macy's. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Homeland Security Alert System
I'm certain the government folks working to protect us 24x7 are doing everything they can, but the fact of the matter is the public alert systems in the US suck. Some just suck less. http://www.nj.com/news/gloucester/index.ssf?/base/news-0/104590500555170.xml Butts said he often finds out about things like the change in the national threat level on CNN hours before the Communications Center receives a teletype about it. Butts is the Gloucester County Emergency Response Coordinator including the county 9-1-1 communications center. ISPs and other communication providers should be prepared to share information directly and quickly with each other. If you wait to hear from government officials to decide what sanitized information to share, it will be hours later. If ever.
Re: Homeland Security Alert System
ISPs and other communication providers should be prepared to share information directly and quickly with each other. If you wait to hear from government officials to decide what sanitized information to share, it will be hours later. If ever. If anybody is interested here, I did put together a small group to experiment with a simple system to exchange and distribute PGP signed messages quickly. The basic 'working' of the system is contained within a yet to be written perl script that will poll a couple of 'master' servers for updated messages, validate the signatures and post the messages to a particular URL. Any server pulling these messages can become a master for other servers, which makes this kind of a 'P2P network' among web servers. Gateway to usernet/email/pagers/ instant messengers would be possible. New pgp keys would be distributed as signed control messages within the system. Each PGP key has a certain number of 'points' assigned, and a message becomes 'valid' as soon as it has enough signatures to make it past a threshold. Anyway. Depending on how the water in my basement develops, I may actually get a first alpha of this out later this weekend. (if not next weekend). At that point, some testers / coders would be welcome to work on things like gateways and such. The overall goal: Make this system fast enough to reach 'everyone' within an hour. Of course, the system will not work once the internet is down, but its P2P like structure should provide for some anti-DDOS robustness. -- [EMAIL PROTECTED] Collaborative Intrusion Detection join http://www.dshield.org
Re: Reports of flooding in Tyson's Corner Virginia
On Sat, 22 Feb 2003, Richard A Steenbergen wrote: Looks like 30 stores on the upper level were flooded (probably too strong a word, slightly moistened would seem more appropriate) due to a roof leak, and the mall was closed. Hardly a danger to the internet, unless there are more people than I know doing their private interconnects through Macy's. That's good news. I would hate to think any ISP's had equipment in large buildings with flat roofs holding up 2 feet of snow and rain in the area.
Re: Reports of flooding in Tyson's Corner Virginia
On Sat, 22 Feb 2003, Richard A Steenbergen wrote: Looks like 30 stores on the upper level were flooded (probably too strong a word, slightly moistened would seem more appropriate) due to a roof leak, and the mall was closed. Hardly a danger to the internet, unless there are more people than I know doing their private interconnects through Macy's. That's good news. I would hate to think any ISP's had equipment in large buildings with flat roofs holding up 2 feet of snow and rain in the area. AHHH!!! But they DO! Who is in the old Hechinger building a stones throw from Tyson's II? I was in there and can't remember the name for the life of me.
Operating Agreement
Hello, I'm trying to track down a sample operating agreement, specifically when one network operator offers to manage another's telecommunications assets, in exchange for an IRU. Something close to this would be wonderful. Google lists many network operating agreements for power interconnection but not for telecom. Thank you for your assistance. Regards, Christopher J. Wolff, VP CIO Broadband Laboratories, Inc. http://www.bblabs.com
Re: Reports of flooding in Tyson's Corner Virginia
On Sat, Feb 22, 2003 at 10:32:11PM -0500, Jason Lewis wrote: AHHH!!! But they DO! Who is in the old Hechinger building a stones throw from Tyson's II? Until just a couple of weeks ago it was an MFN data center. Unfortunately, it was one of the sites we elected to close down as part of the bankruptcy/restructuring process. --Jeff
ENUM/E.164 books
Anyone have recommendations on good books (or similar resources) on ENUM/E.164 for education, planning, design, implementation and/or operation? Pete.
Re: Homeland Security Alert System
- Original Message - From: Sean Donelan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 22, 2003 1:47 PM Subject: Re: Homeland Security Alert System I'm certain the government folks working to protect us 24x7 are doing everything they can, but the fact of the matter is the public alert systems in the US suck. Some just suck less. http://www.nj.com/news/gloucester/index.ssf?/base/news-0/104590500555170.xml Butts said he often finds out about things like the change in the national threat level on CNN hours before the Communications Center receives a teletype about it. Butts is the Gloucester County Emergency Response Coordinator including the county 9-1-1 communications center. ISPs and other communication providers should be prepared to share information directly and quickly with each other. If you wait to hear from government officials to decide what sanitized information to share, it will be hours later. If ever. Yesterday I was asked to install a DISH Network system for the Transportation Security Administration so their folks at the Airport can get the news.s --Michael
