|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: real-time DDoS help?
>>>>> "Matthew" == Matthew McGehrin <[email protected]> writes: Matthew> Why would you need to re-invent the wheel? Matthew> There are multiple EFNET servers run by Nanog members Matthew> including: irc.servercentral.net irc.nac.net Matthew> irc.easynews.com irc.he.net Matthew> To name a few. Matthew> #nanog It is important to emphasize a couple of things, now that the topic has come up. First and foremost, the #nanog IRC channel has absolutely nothing to do with the nanog mailing list, other than it shares some common personalities. Operational discussion is rarely experienced, the most often-experienced relevant question is "how do I configure BGP", and you can guess how that makes engineers who are on the channel feel about answering questions. I recommend that those who see this channel mentioned on the mailing list ignore it as if it does not exist - because it does not for purposes of operational talk (although it may be useful for the occasional drop-in "does anyone here work for X?"). Secondly and perhaps most notably, IRC is in no way, shape, or form a protocol or communications method one would describe as resilient or operationally relevant. Neither are the instant messaging networks or Jabber servers. IRC does not meet the "needs" of operators. Describing these needs is a separate topic and probably not appropriate for this mailing list, even though you could describe the topic as operationally relevant. The operations community is, unfortunately, not conveniently segregated into backbone operators, regional/tier operators, and small operators. What this means is that, with the lack of hierarchy, an operations staff member at UUNET/MCI, for instance, may not view it as high on his/her list of priorities to handle a complaint from your local engineer at an apartment complex that provides broadband access. My point here is that the needs are different in each individual "operational sphere", and there is no real shared survival instinct instilled among operations houses, although I like to think that generally operators are nice folks and will do what they can. I (for one) tend to think that the operations community needs a little more structure attached to it. There are efforts (as Jared mentions) to help with the interchange of information among providers, and others (myself included) are working on additional operational problems at length. Until these issues are identified, rationalized, and discussed, the idea of a solid operational communications framework is a long way off, though I tend to think that INOC-DBA, INCH, and the other efforts out there probably serve the intermediate need without handling future requirements. Technical matters aside, a code of conduct among operators (speaking in the corporate sense) would go a long way, but as we have seen evidenced in the past couple of years (and to some degree rightfully so), corporations will abdicate from your view of morality when confronted with their view of the bottom fiscal line. To summarize, I'd have to say that the best recommendation for the interim operational communications are SILC servers run by major backbone players with dedicated personnel responsible for communicating between providers. That being said, nsp-sec already fulfills this goal, and as Tim Battles once mentioned to me at Chicago NOG, the real challenge of operational security and communication is already handled by the address book and the cellular telephone. Tim
|