NANOG via RSS
By any chance is this list available via xml/rss? Thanks, Mike
Re: NANOG via RSS
On 19 Jan 2005, at 08:17, Mike Callahan wrote: By any chance is this list available via xml/rss? Try http://rss.gmane.org/gmane.org.operators.nanog Joe
Re: NANOG via RSS
Mike Callahan [EMAIL PROTECTED] writes: By any chance is this list available via xml/rss? There are several email to rss gateway software packages out there; it would be trivial to roll your own. YMMV, but after reading a couple of other mailing lists that were gatewayed to rss, my sense is that RSS is not the right technology for reading NANOG unless one were to create a first article only feed. Due to different ways of looking at data than one would usually think of when designing a mail or usenet reader, all RSS readers of my admittedly fairly narrow acquaintance are lacking in one critical (imnsho) feature for reading NANOG-L: kill thread. ---Rob
Re: NANOG via RSS
On Wed, 19 Jan 2005 09:11:20 -0500, Robert E. Seastrom [EMAIL PROTECTED] wrote: YMMV, but after reading a couple of other mailing lists that were gatewayed to rss, my sense is that RSS is not the right technology for reading NANOG unless one were to create a first article only feed. Due to different ways of looking at data than one would usually think of when designing a mail or usenet reader, all RSS readers of my admittedly fairly narrow acquaintance are lacking in one critical (imnsho) feature for reading NANOG-L: kill thread. This is a much better way than RSS - http://blog.gmane.org/gmane.org.operators.nanog?set_skin=zawodny -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: NANOG via RSS
Mike Callahan [EMAIL PROTECTED] writes: By any chance is this list available via xml/rss? Thanks, Mike You can get it via blog and rss format from here - http://blog.gmane.org/gmane.org.operators.nanog?set_skin=zawodny -srs
Re: NANOG via RSS
On Wed, 2005-01-19 at 09:11 -0500, Robert E.Seastrom wrote: Mike Callahan [EMAIL PROTECTED] writes: By any chance is this list available via xml/rss? There are several email to rss gateway software packages out there; it would be trivial to roll your own. YMMV, but after reading a couple of other mailing lists that were gatewayed to rss, my sense is that RSS is not the right technology for reading NANOG unless one were to create a first article only feed. I am actually wonder if RSS has an advantage at all compared to a mailinglist, especially as RSS is a pull mechanism, if there is nothing or not a lot happening it will be polling the server a lot of times needlessy, thus causing server resources. While of course a mailinglist has the overhead of the email headers. But I am quite convinced of the idea that a push * 25.000 subscribers is lighter load on the server than having a continues pull by those 25.000 subscribers... Next to that, my mailbox simply shows the articles I have not read and I throw out what I did read and can easily reply to what I like to reply to. Personally thus RSS has not much value, just like NNTP actually, even though NNTP comes quite close to email. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Registrars serve no useful purpose
[EMAIL PROTECTED] wrote: It is a matter of choosing a registrar that has the right business model and services to suit the registrant. What if a company doesn't want to deal with any registrar? What if they just want to register their domain name and have it stay registered. For some companies, their registered domain name is a critical part of their network infrastructure. Why should these companies be forced to deal with third parties who add no value to the service? I disagree, in part. (1) The purpose of registrars is processing paperwork for verification of registrants. (2) The purpose of the registry is to run servers, as efficiently and inexpensively as possible. It's a reasonable division of labor. There is no free market when ICANN forces companies to deal with 3rd parties rather than deal directly with the registry that provides the mission critical DNS service for their domain name. There's only 1 registry, so there's never a free market there -- that's a monopoly by design. The competition between registrars is a good thing that has brought the registration process to a commodity market. However, having any market requires penalties when the registrars fail to perform their function. And not just a reputation penalty, although that's certainly germaine. An actual financial penalty. Markets are all about financial exchange. That's why (as originally designed) every registrar posts a large performance bond up front. Clearly, Mel-IT failed in its responsibilty to correctly process the paperwork for registration. That Mel-IT has a business model where they farm out the registration to incompetent third parties called resellers is of no interest. The third party is acting as an agent for Mel-IT, and Mel-IT is ultimately responsible. Moreover, the Mel-IT president/CEO/attorney/et alia egregiously demonstrated negligence when notified of the problem. I expect that Mel-IT will be assessed a reasonable penalty for their failure. The usual penalty is 3 times actual (liquidated) damages. Since Mel-IT has already demonstrated a failure to perform, in addition their performance bond to continue as a registrar should be raised to at least 10% of their annualized gross income. It costs money to clean up their messes. Those are the things required for a free market. Accountability. Responsibility. Free markets are not without cost. Perhaps this is another area where a membership-based NANOG could help by standing up and explaining the operational importance of DNS stability to the bureaucrats in ICANN. We have a membership-based NANOG. Everybody who joins NANOG is on this mailing list. Everybody who joins this mailing list is part of NANOG. We (in NANOG) have an interest in ensuring that the bureaucrats assess the penalty on behalf of our members -- that panix.com is made whole. Accountability. Responsibility. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
209.225.34.161 (vsc.gsa.gov)
Can someone from this network contact me offlist - we are having routing issues with your network. Thanks ** Richard J. Sears Vice President American Internet Services [EMAIL PROTECTED] http://www.adnc.com 858.576.4272 - Phone 858.427.2401 - Fax INOC-DBA - 6130 I fly because it releases my mind from the tyranny of petty things . . Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching.
Re: NANOG via RSS
On Wed, 19 Jan 2005 15:55:19 +0100, Jeroen Massar [EMAIL PROTECTED] wrote: On Wed, 2005-01-19 at 09:11 -0500, Robert E.Seastrom wrote: Mike Callahan [EMAIL PROTECTED] writes: By any chance is this list available via xml/rss? There are several email to rss gateway software packages out there; it would be trivial to roll your own. YMMV, but after reading a couple of other mailing lists that were gatewayed to rss, my sense is that RSS is not the right technology for reading NANOG unless one were to create a first article only feed. I am actually wonder if RSS has an advantage at all compared to a mailinglist, especially as RSS is a pull mechanism, if there is nothing or not a lot happening it will be polling the server a lot of times needlessy, thus causing server resources. While of course a mailinglist has the overhead of the email headers. But I am quite convinced of the idea that a push * 25.000 subscribers is lighter load on the server than having a continues pull by those 25.000 subscribers... Next to that, my mailbox simply shows the articles I have not read and I throw out what I did read and can easily reply to what I like to reply to. Personally thus RSS has not much value, just like NNTP actually, even though NNTP comes quite close to email. Greets, Jeroen Try pointing your subscription to Gmail. Plenty of space to hold a nice archive. Quickly Searchable, accessible from anywhere, automatic threading. Make a label and matching filter for each mailing-list...make's thing nice and sorted automatically. Your Gmail acc't can be accessed via rss too, so there's that. --chip Just my $.02, your mileage may vary, batteries not included, etc
Re: NANOG via RSS
On Wed, 2005-01-19 at 11:36 -0500, chip wrote: SNIP Try pointing your subscription to Gmail. Why the peep would I want to rely on a service provider like Gmail or Hotmail or whatever for something as as important as my email ? I also like to use my own domain for sending mail, it will never change unless I go bankrupt or the internet disappears completely. Especially folks in the ISP business should be able to pretty easily setup much more sophisticated systems without having to rely on a third party at all. You can then pick any combination of tools you want to use to process it ranging from a Windows95 box to a superduper Earth Simulator, just depending on the size of your pocket (and the money that will not be in it afterwards) and your own capabilities. Do you have any idea how much mail you can store on your local NetApp ? :) Plenty of space to hold a nice archive. Quickly Searchable, accessible from anywhere, automatic threading. Make a label and matching filter for each mailing-list...make's thing nice and sorted automatically. People call this procmail and their other favourite tool of choice ;) Your Gmail acc't can be accessed via rss too, so there's that. If you didn't notice from my message I don't see the need for RSS at all because it is not at all useful for many things, especially as email gateways. Greets, Jeroen PS: Another nice feature of your own mail system is that you can actually configure your real name completely and nicely capitalized in the from address ;) signature.asc Description: This is a digitally signed message part
Re: NANOG via RSS
[EMAIL PROTECTED] (Robert E.Seastrom) writes: By any chance is this list available via xml/rss? ... Due to different ways of looking at data than one would usually think of when designing a mail or usenet reader, all RSS readers of my admittedly fairly narrow acquaintance are lacking in one critical (imnsho) feature for reading NANOG-L: kill thread. we gateway nanog@ (it's not called NANOG-L, really, plz stop saying that) into a local usenet newsgroup here. the netnews feature i use most often isn't actually kill by thread, but rather kill by author. i can't imagine how any of you read this forum using a normal e-mail tool. -- Paul Vixie
RE: NANOG via RSS
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Vixie Sent: Wednesday, January 19, 2005 11:59 AM To: nanog@merit.edu Subject: Re: NANOG via RSS [EMAIL PROTECTED] (Robert E.Seastrom) writes: By any chance is this list available via xml/rss? ... Due to different ways of looking at data than one would usually think of when designing a mail or usenet reader, all RSS readers of my admittedly fairly narrow acquaintance are lacking in one critical (imnsho) feature for reading NANOG-L: kill thread. we gateway nanog@ (it's not called NANOG-L, really, plz stop saying that) into a local usenet newsgroup here. the netnews feature i use most often isn't actually kill by thread, but rather kill by author. i can't imagine how any of you read this forum using a normal e-mail tool. Merit could treat the mailing list as an asset and not allow redistribution and instead offer multiple formats for readers to peruse or react in near real time. RSS, NNTP, and SMTP are all options in my mind. It's about choices. More is better. -M
Re: NANOG via RSS
On Wed, 19 Jan 2005 17:48:07 +0100, Jeroen Massar [EMAIL PROTECTED] wrote: On Wed, 2005-01-19 at 11:36 -0500, chip wrote: SNIP Try pointing your subscription to Gmail. Why the peep would I want to rely on a service provider like Gmail or Hotmail or whatever for something as as important as my email ? I also like to use my own domain for sending mail, it will never change unless I go bankrupt or the internet disappears completely. Especially folks in the ISP business should be able to pretty easily setup much more sophisticated systems without having to rely on a third party at all. You can then pick any combination of tools you want to use to process it ranging from a Windows95 box to a superduper Earth Simulator, just depending on the size of your pocket (and the money that will not be in it afterwards) and your own capabilities. Do you have any idea how much mail you can store on your local NetApp ? :) Plenty of space to hold a nice archive. Quickly Searchable, accessible from anywhere, automatic threading. Make a label and matching filter for each mailing-list...make's thing nice and sorted automatically. People call this procmail and their other favourite tool of choice ;) Your Gmail acc't can be accessed via rss too, so there's that. If you didn't notice from my message I don't see the need for RSS at all because it is not at all useful for many things, especially as email gateways. Greets, Jeroen PS: Another nice feature of your own mail system is that you can actually configure your real name completely and nicely capitalized in the from address ;) Jeroen, I agree with you on pretty much everything you said. The only thing I use this gmail account for is mailing lists. I don't want to clutter up my inbox with all the stuff that happens on 10 different lists. I also don't want to have to deal with the spamming issues that are a result of the lists. And why should I pay for space, equipment, and time when someone's giving me 1Gb for free with all the handy tools already installed. Anyhow, to each his own, was just pointing out another option. -- chip Just my $.02, your mileage may vary, batteries not included, etc
Re: NANOG via RSS
On Wed, 2005-01-19 at 16:59 +, Paul Vixie wrote: i can't imagine how any of you read this forum using a normal e-mail tool. With some difficulty... ;) -- Cheers Dg off to investigate the various options proposed
Re: Registrars serve no useful purpose
[a dated, biased (what isn't?), insightful, and relevant interview] Published on Policy DevCenter (http://www.oreillynet.com/policy/) http://www.oreillynet.com/pub/a/policy/2002/12/05/karl.html Karl Auerbach: ICANN Out of Control by Richard Koman 12/05/2002 Editor's note: Strong forces are reshaping the Internet these days. To understand these forces-- governmental, business, and technical--Richard Koman interviews the people in the midst of the changes. This month, Richard talks to Karl Auerbach, a public board member of ICANN and one of the Internet governing body's strongest critics. October's distributed, denial-of-service attack against the domain name system--the most serious yet, in which seven of the thirteen DNS roots were cut off from the Internet--put a spotlight on ICANN, the nongovernmental corporation responsible for Internet addressing and DNS. The security of DNS is on ICANN's watch. Why is it so susceptible to attack, when the Internet as a whole is touted as being able to withstand nuclear Armageddon? It's religious dogma, says Karl Auerbach, a public representative to ICANN's board. There's no reason DNS shouldn't be decentralized, except that ICANN wants to maintain central control over this critical function. Worse, Auerbach said in a telephone interview with O'Reilly Network, ICANN uses its domain name dispute resolution process to expand the rights of trademark holders, routinely taking away domains from people with legitimate rights to them, only to reward them to multinational corporations with similar names. Auerbach--who successfully sued ICANN over access to corporate documents (ICANN wanted him to sign a nondisclosure agreement before he could see the documents)--will only be an ICANN director for a few more weeks. As part of ICANN's reform process, the ICANN board voted last month to end public representation on the board. As of December 15, there will be zero public representatives on the ICANN board. How does ICANN justify banishing the public from its decision-making process? Stuart Lynn, president and CEO of ICANN, said the change was needed to make ICANN's process more efficient. In a Washington Post online discussion, Lynn said: The board decided that at this time [online elections] are too open to fraud and capture to be practical, and we have to look for other ways to represent the public interest. It was also not clear that enough people were really interested in voting in these elections to create a large enough body of voters that could be reflective of the public interest. This decision could always be reexamined in the future. In the meantime, we are encouraging other forms of at-large organizations to self-organize and create and encourage a body of individuals who could provide the user input and public interest input into the ICANN process. Former ICANN president Esther Dyson is also supporting the move away from public representation on the board. I did believe that it was a good idea to have a globally elected executive board, [but] you can't have a global democracy without a globally informed electorate, Dyson told the Post. What you really need [in order] to have effective end-user representation is to have them in the bowels (of the organization) rather than on the board. Auerbach isn't buying. ICANN is pursuing various spin stories to pretend that they haven't abandoned the public interest, he says in this interview. ICANN is trying to create a situation where individuals are not allowed in and the only organizations that are allowed in are those that hew to ICANN's party line. In this interview, Auerbach makes a number of strong criticisms of ICANN, beyond the issue of public access: * ICANN uses its domain name dispute resolution process to expand the rights of trademark holders, routinely taking away domains from people with legitimate rights to them, only to reward them to multinational corps with similar names, Auerbach says. * ICANN unnecessarily maintains the domain name system as a centralized database, making it vulnerable to attack. * ICANN has failed to improve network security since September 11 and has ignored Auerbach's suggestions for improving DNS security. * ICANN staff takes actions without consulting the board, withholds information from the board, and misleads board members. * Finally, Auerbach charges that ICANN is guilty of corporate malfeasance. Koman: On October 21, there was a denial-of-service attack on DNS, which was widely reported as the most serious yet. Something like seven of the thirteen root servers were unavailable for as long as three hours. What is ICANN's responsibility for DNS, and how vulnerable is it to attack? Auerbach: On the Internet, there are a couple of areas that arguably need some centralized authority. One of these is IP address allocation--addresses need to handed out with some notion of
RE: NANOG via RSS
i can't imagine how any of you read this forum using a normal e-mail tool. I've used Outlook 2003 since Beta, and couldn't imagine not using it for emailing. Just setup a rule to send NANOG emails to their own folder and let 'em roll in. I'll browse every so often and decide I don't care about a topic and just mark that day's emails as read. Plus my phone/pda can sync across the Sprint network with Exchange and download the most recent emails when I get bored on the train or at lunch. Joe Johnson
Re: Registrars serve no useful purpose
the panix.com incident, a few nights of dreaming solutions, and this interview lead me wonder about p2p dns. david
Re: Registrars serve no useful purpose
And, on this point, I believe Karl was right. $.02, - ferg -- David M. Besonen [EMAIL PROTECTED] wrote: Auerbach: The public interest is not being served. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
___ From: [EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 9:58 AM To: 'nanog@merit.edu' Subject: BOGON Filtering IP Space? Our NOC is opening a lot of tickets for customers that live on our 72.14.128.0/19 network going towards local and federal government sites in particular. I'm curious if providers / vendors / managed service providers are BOGON filtering this network range as it's relatively new IP space allocated by ARIN that used to be BOGON space. If anyone has these in the BOGON list, please remove - it's real space. :-) I'd appreciate any feedback on ways to notify / check if providers are BOGON filtering this network. Regards, James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] 760-807-5129 24x7 NOC contact 951-541-9688 office ---BeginMessage--- Can you forward this to the nanog list for me? It doesnt appear to be showing up at all when I send it in. From: [EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 9:58 AM To: 'nanog@merit.edu' Subject: BOGON Filtering IP Space? Our NOC is opening a lot of tickets for customers that live on our 72.14.128.0/19 network going towards local and federal government sites in particular. Im curious if providers / vendors / managed service providers are BOGON filtering this network range as its relatively new IP space allocated by ARIN that used to be BOGON space. If anyone has these in the BOGON list, please remove its real space. J Id appreciate any feedback on ways to notify / check if providers are BOGON filtering this network. Regards, James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] 760-807-5129 24x7 NOC contact 951-541-9688 office ---End Message---
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
Yes - the space in question was allocated last January - it looks like not everyone has updated their bogon access lists to remove this space from the bogon list. On Wed, 19 Jan 2005 13:51:11 -0500 Kurt Kruegel [EMAIL PROTECTED] wrote: from http://www.cymru.com/Documents/bogon-list.html Changes in version 2.5 (02 AUG 2004) 71/8 and 72/8 allocated to ARIN (AUG 2004). Removed from the bogon lists. Changes in version 2.4 (28 APR 2004) 58/8 and 59/8 allocated to the APNIC (APR 2004). Removed from the bogon lists. Changes in version 2.3 (01 APR 2004) 85/8, 86/8, 87/8, and 88/8 allocated to the RIPE NCC (APR 2004). Removed from the bogon lists. Changes in version 2.2 (15 JAN 2004) 70/8 allocated to ARIN (JAN 2004). Removed from the bogon lists. At 10:20 AM 1/19/2005 -0800, Richard J. Sears wrote: ___ From: [EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 9:58 AM To: 'nanog@merit.edu' Subject: BOGON Filtering IP Space?Our NOC is opening a lot of tickets for customers that live on our 72.14.128.0/19 network going towards local and federal government sites in particular. I'm curious if providers / vendors / managed service providers are BOGON filtering this network range as it's relatively new IP space allocated by ARIN that used to be BOGON space. If anyone has these in the BOGON list, please remove - it's real space. :-)I'd appreciate any feedback on ways to notify / check if providers are BOGON filtering this network. Regards, James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] 760-807-5129 24x7 NOC contact 951-541-9688 office Return-Path: X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from smtp01.adnc.com (smtp01.adnc.com [206.251.248.151]) by pop3-02.adnc.com (Postfix) with ESMTP id D869735C056 for ; Wed, 19 Jan 2005 10:18:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp01.adnc.com (Postfix) with ESMTP id BA3601BCC6D for ; Wed, 19 Jan 2005 10:17:17 -0800 (PST) Received: from smtp01.adnc.com ([127.0.0.1]) by localhost (smtp01.adnc.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 20263-01-59 for ; Wed, 19 Jan 2005 10:17:15 -0800 (PST) Received: from sandcaexch01.pcipros.net (unknown [207.158.33.163]) by smtp01.adnc.com (Postfix) with ESMTP id 2B9E01BC7DA for ; Wed, 19 Jan 2005 10:17:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 MIME-Version: 1.0 Subject: FW: BOGON Filtering IP Space? Date: Wed, 19 Jan 2005 10:24:27 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BOGON Filtering IP Space? Thread-Index: AcT+TgcBXRcsgfNZT8u0oENeEuZ2VQAAjpjgAADzviA= From: James Laszko To: Richard J. Sears X-Virus-Scanned: by amavisd-new at smtp01.adnc.com X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on pop3-02.adnc.com X-Spam-Status: No, hits=-4.6 required=3.0 tests=BAYES_00,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.61 X-Spam-Level: X-UIDL: It doesn#8217;t appear to be showing up at all when I send it in#8230;#8230;#8230;. From: [EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 9:58 AM To: 'nanog@merit.edu' Subject: BOGON Filtering IP Space?I#8217;m curious if providers / vendors / managed service providers are BOGON filtering this network range as it#8217;s relatively new IP space allocated by ARIN that used to be BOGON space. If anyone has these in the BOGON list, please remove #8211; it#8217;s real space. JI#8217;d appreciate any feedback on ways to notify / check if providers are BOGON filtering this network. Regards, James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] 760-807-5129 24x7 NOC contact 951-541-9688 office Kurt A Kruegel, CCNP, DP, SP, CISSP#30711 Senior Network Administrator Network Systems American Museum of Natural History Central Park West at 79th Street New York, New York 10024 (P) 212-496-3601 (F) 212-496-3555 (E) [EMAIL PROTECTED] (W) http://www.amnh.org ** Richard J. Sears Vice President American Internet Services [EMAIL PROTECTED] http://www.adnc.com 858.576.4272 - Phone 858.427.2401 - Fax INOC-DBA - 6130 I fly because it releases my mind from the tyranny of petty things . . Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching.
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
--- Richard J. Sears [EMAIL PROTECTED] wrote: Yes - the space in question was allocated last January - it looks like not everyone has updated their bogon access lists to remove this space from the bogon list. I think that Cisco's Autosecure feature is part of the problem here: http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_feature_guide09186a008017d101.html While it says that bogon filters change, and provides a URL to check it, what percentage of folks who would use a feature like autosecure would ever update their filters? sigh. = David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
72.18.160.0/19 Please Check Filters - BOGON Filtering IP Space 72.0.0.0/8
Our NOC is opening a lot of tickets for customers that live on our 72.14.128.0/19 network going towards local and federal government sites in particular. Our customer - Angelo State U was recently assigned IP space 72.18.160.0/19. They have also seen some issues getting packets to government and other sites. For example, USGS.gov was filtering based on an old bogon list. Rob T - this should be a periodic FAQ: http://www.cymru.com/Bogons/ At your service, -bryan bradsby DIR Capnet Texas State Government Net NOC: 512-475-2432 877-472-4848
[Fwd: Cisco Security Advisory: Vulnerability in Cisco IOS Embedded Call Processing Solutions]
. FYI if you haven't seen this yet. Gadi. ---BeginMessage--- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Vulnerability in Cisco IOS Embedded Call Processing Solutions Revision 1.0 For Public Release 2005 January 19 1500 UTC +-- Contents Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: FINAL Distribution Revision History Cisco Security Procedures +-- Summary === Cisco Internetwork Operating System (IOS®) Software release trains 12.1YD, 12.2T, 12.3 and 12.3T, when configured for the Cisco IOS Telephony Service (ITS), Cisco CallManager Express (CME) or Survivable Remote Site Telephony (SRST) may contain a vulnerability in processing certain malformed control protocol messages. A successful exploitation of this vulnerability may cause a reload of the device and could be exploited repeatedly to produce a Denial of Service (DoS). This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20050119-itscme.shtml Cisco has made free software upgrades available to address this vulnerability for all affected customers. There are workarounds available to mitigate the effects of the vulnerability. This vulnerability is documented by Cisco bug ID CSCee08584. Affected Products = Vulnerable Products +-- This issue affects all Cisco devices running any unfixed version of Cisco IOS code that supports, and is configured for ITS, CME or SRST. A Cisco device running ITS or CME will have the following line in the configuration: telephony-service A Cisco device running SRST will have the following line in the configuration: call-manager-fallback To determine the software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS Software will identify itself as Internetwork Operating System Software or simply IOS. On the next line of output, the image name will be displayed between parentheses, followed by Version and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product running IOS release 12.0(3) with an installed image name of C2500-IS-L: Cisco Internetwork Operating System Software IOS (TM) 2500 Software (C2500-IS-L), Version 12.0(3), RELEASE SOFTWARE The release train label is 12.0. The next example shows a product running IOS release 12.3(6) with an image name of C2600-JS-MZ: Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-JS-MZ), Version 12.3(6), RELEASE SOFTWARE (fc1) Additional information about Cisco IOS release naming can be found at http://www.cisco.com/warp/public/620/1.html. Products Confirmed Not Vulnerable + ITS, CME and SRST are IOS-only features. Devices that do not run IOS are not vulnerable. Details More information about Cisco's IOS Telephony Service (ITS) and Cisco CallManager Express (CME) can be found here: http://www.cisco.com/en/US/products/sw/voicesw/ps4625/index.html More information on Cisco's Survivable Remote Site Telephony (SRST) can be found here: http://www.cisco.com/en/US/products/sw/voicesw/ps2169/index.html ITS, CME and SRST are features that allow a Cisco device running IOS to control IP Phones using the Skinny Call Control Protocol (SCCP). SCCP is the Cisco CallManager native signaling protocol. Certain malformed packets sent to the SCCP port on an IOS device configured for ITS, CME or SRST may cause the target device to reload. This issue is documented in Cisco bug ID CSCee08584. The following commands can be used to determine if ITS or CME are running. A device that does not have ITS or CME enabled will display: Router#show telephony-service telephony-service is not enabled A device that has ITS or CME enabled will show something similar to: Router#show telephony-service CONFIG (Version=3.0) = Cisco CallManager Express ip source-address 192.168.1.1 port 2000 max-ephones 2 max-dn 2 max-conferences 8 max-redirect 5 time-format 12 date-format mm-dd-yy keepalive 30 timeout interdigit 10 timeout busy 10 timeout ringing 180 edit DN through Web: disabled. edit TIME
Large Enterprise IP mgmt
The archives didn't show a hit for IP address management when it comes to a large MS AD shop. We went from NetID to home-grown scripts... Men and Mice have given some presentations on their tool. Any others out there that do not force a switch to some other vendor's DNS/DHCP servers? Just looking to manage the MS AD... Thanks, Brad
Graphing Peering
Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. Thank i appreciate it in advance. Andrew
Re: 72.18.160.0/19 Please Check Filters - BOGON Filtering IP Space 72.0.0.0/8
Hi, Bryan. ] Rob T - this should be a periodic FAQ: ] ]http://www.cymru.com/Bogons/ That's a great idea! Everyone knows I don't send out nearly enough email. :) Seriously, we'll try to be better about sending out regular reminders. Thanks! Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
NANOG 33 Peering BOF VIII
Peering Coordinators attending NANOG in Las Vegas - We have a very exciting (and very full) Peering BOF agenda...Let me give you a flavor for what we are doing this year. At 9PM we'll start out with a State of the Peering Internet and, with the audience, identify a few key trends and the most pressing issues of the Peering Coordinator Community. Next we repeat last year's highly successful Great Debate, this time on the topic of Remote Peering : the good vs. the bad and the ugly. Remote Peering is peering without a local physical presence : tunneling ethernet frames across the ocean over MPLS into a peering fabric for example. Stephen Wilcox has graciously stepped up to present the con position - the bad and the ugly of remote peering. I have a couple volunteers to present the pro position, but I would prefer to have a Peering Coordinator that is actually using remote peering to advocate its use. If noone volunteers I have two backup debaters that have agreed to present the pro side of the debate and to debate Stephen on this matter. At the end, the audience will vote by show of hands for who made the more compelling case. If anyone would like to volunteer a prize for the winner please let me know ;-) Next, Richard Steenbergen will briefly share his Peering Coordinator community work with peeringdb.com, a resource for Peering Coordinators to obtain and share contact information. We will finish off with the Peering Personals, a chance for Peering Coordinators to introduce themselves to the group, talk about their network, what they are looking for in a peer, where they peer, their AS# and contact info, etc. I will use the RSVP form below to make sure that the relevant information is ready for Peering Coordinators in the audience to jot down in case they don't meet up with the speaker. We have found in the past that Peering Personals is very effective in facilitating peering. If you are a Peering Coordinator and would like to participate in Peering Personals, it is a great way for others to put a face to a network and AS, and to meet the North American Peering Coordinator Community. Please fill out the following form and e-mail to me ([EMAIL PROTECTED]). We only have time for about 10 Peering Coordinators, so please respond asap: Name: Email: Title: Company: AS#: Check each that applies: ___ We are an ISP (sell access to the Internet) --OR-- ___ We are a Non-ISP (content company, etc.) ___ We are Content-Heavy --OR-- ___ We are Access-Heavy ___ Peering with Content Players or Content Heavy ISPs is OK by us ___ We generally require peering in multiple locations OR ___ We will peer with anyone in any single location ___ We have huge volumes of traffic (lots of users and/or lots of content) (huge: 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require Contracts for Peering Current Peering Locations: ___ Planned (3-6 mos) Peering Locations: ___ After the BOF we will break for beers and exchange of business cards. Bill
Re: Graphing Peering
no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. On Wed, 19 Jan 2005 22:25:37 + (GMT), Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Wed, 19 Jan 2005, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. do you mean how to graph traffic to each host on a lan..? what platform do you have? Steve
RE: Graphing Peering
Andrew, You could probably whip something up with a shell script, and pipe the results to something like cacti (www.cacti.net). Cacti is one of the easiest utilities I've worked with to graph other types of data besides bits in/out. Check it out. = TC -Original Message- From: andrew matthews [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 4:38 PM To: nanog@merit.edu Subject: Re: Graphing Peering no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. On Wed, 19 Jan 2005 22:25:37 + (GMT), Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Wed, 19 Jan 2005, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. do you mean how to graph traffic to each host on a lan..? what platform do you have? Steve
Re: Graphing Peering
If you're already using MRTG, hopefully you're at least passingly familiar with perl and SNMP. If so, you can do some hackery to identify your BGP peer interfaces automatically and then use it to reference existing interface graphs. Take a peek in the BGP4 mib, specifically at the BgpPeerEntry subtree. You may need to do some correlation inside the ifTable or maybe even ifX, depending on platform and implementation, to correctly identify the interface of your peer. - billn On Wed, 19 Jan 2005, andrew matthews wrote: no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. On Wed, 19 Jan 2005 22:25:37 + (GMT), Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Wed, 19 Jan 2005, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. do you mean how to graph traffic to each host on a lan..? what platform do you have? Steve
Re: Graphing Peering
Andrew's issue is this - he's got an Ethernet port on a public peering switch with a bunch of peers. He can see the interface stats just fine but he's having trouble figuring out how much traffic is going to (or coming from) each peer. One interface, many peers, confusing problem. There isn't one VLAN per peer on most public peering switches - its one big Ethernet segment with each peer getting an IP out of a common subnet. Welcome to the world of broadcast multi-access peering. The classical way to do this is mac accounting. This can be pretty rough - its not really useful for anything more than a ratio, from what I've seen - the numbers tend to not add up properly. Another possibility (on Cisco) is using BGP Policy Accounting, although support can be spotty depending on hardware. For other platforms, there's some good information here: http://www.switch.ch/misc/leinen/snmp/monitoring/bucket-accounting.html The link on that page for Juniper's Destination Class Usage (DCU) is broken. Try this one instead: http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-interfaces /html/interfaces-family-config25.html - Dan On 1/19/05 5:56 PM, Bill Nash [EMAIL PROTECTED] wrote: If you're already using MRTG, hopefully you're at least passingly familiar with perl and SNMP. If so, you can do some hackery to identify your BGP peer interfaces automatically and then use it to reference existing interface graphs. Take a peek in the BGP4 mib, specifically at the BgpPeerEntry subtree. You may need to do some correlation inside the ifTable or maybe even ifX, depending on platform and implementation, to correctly identify the interface of your peer. - billn On Wed, 19 Jan 2005, andrew matthews wrote: no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. On Wed, 19 Jan 2005 22:25:37 + (GMT), Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Wed, 19 Jan 2005, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. do you mean how to graph traffic to each host on a lan..? what platform do you have? Steve -- Daniel Golding Network and Telecommunications Strategies Burton Group
Re: Graphing Peering
Ah, completely different animal altogether, that. Thanks for the clarification. My initial read was multiple peers on separate interfaces, which isn't overly complex to track. - billn On Wed, 19 Jan 2005, Daniel Golding wrote: Andrew's issue is this - he's got an Ethernet port on a public peering switch with a bunch of peers. He can see the interface stats just fine but he's having trouble figuring out how much traffic is going to (or coming from) each peer. One interface, many peers, confusing problem. There isn't one VLAN per peer on most public peering switches - its one big Ethernet segment with each peer getting an IP out of a common subnet. Welcome to the world of broadcast multi-access peering. The classical way to do this is mac accounting. This can be pretty rough - its not really useful for anything more than a ratio, from what I've seen - the numbers tend to not add up properly. Another possibility (on Cisco) is using BGP Policy Accounting, although support can be spotty depending on hardware. For other platforms, there's some good information here: http://www.switch.ch/misc/leinen/snmp/monitoring/bucket-accounting.html The link on that page for Juniper's Destination Class Usage (DCU) is broken. Try this one instead: http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-interfaces /html/interfaces-family-config25.html - Dan On 1/19/05 5:56 PM, Bill Nash [EMAIL PROTECTED] wrote: If you're already using MRTG, hopefully you're at least passingly familiar with perl and SNMP. If so, you can do some hackery to identify your BGP peer interfaces automatically and then use it to reference existing interface graphs. Take a peek in the BGP4 mib, specifically at the BgpPeerEntry subtree. You may need to do some correlation inside the ifTable or maybe even ifX, depending on platform and implementation, to correctly identify the interface of your peer. - billn On Wed, 19 Jan 2005, andrew matthews wrote: no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. On Wed, 19 Jan 2005 22:25:37 + (GMT), Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Wed, 19 Jan 2005, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. do you mean how to graph traffic to each host on a lan..? what platform do you have? Steve
Re: panix hijack press
http://www.theregister.co.uk/2005/01/19/panix_hijack_more/ Panix.com hijack: Aussie firm shoulders blame By Lucy Sherriff Published Wednesday 19th January 2005 16:49 GMT An Australian domain registrar has admitted to its part in last weekend's domain name hijack. of a New York ISP. Melbourne IT says it failed to properly confirm a transfer request for the Panix.com domain. Ed Ravin, a Panix system administrator, says the Melbourne IT error enabled fraudsters using stolen credit cards to assume control of the domain. Thousands of Panix.com customers lost email access for the duration of the occupation, and many emails will never be recovered. The mistake was compounded by the unavailability of Melbourne IT staff over the weekend - the company rectified its mistake late on Sunday evening, US time. Speaking to ComputerWorld Ravin said he was unable to contact anyone in support at Melbourne IT until the company's offices opened on Monday morning. Bruce Tonkin, Melbourne IT's CTO, offered the following explanation: In the case of Panix.com, evidence so far indicates that a third party that holds an account with a reseller [UK based Fibranet] of Melbourne IT, fraudulently initiated the transfer. The third party appears to have used stolen credit cards to establish this account and pay for the transfer. That reseller is analysing its logs and cooperating with law enforcement. A loophole that allowed the error, that caused the problem has now been closed, he added. The roots of the affair lie in new rules governing the transfer of domain name ownership. These rules, which came into effect last November, mean that inter-registry transfer requests are automatically approved after five days unless countermanded by the owner of a domain. When ICANN proposed the new procedures, many in the industry warned that as well as making it easier to move domains around, the change would make it easier for people to hijack domains. Network Solutions, for example, took the precautionary step of locking all its customers' domains. Panix.com says its domain name was locked, and that despite this, it was still transferred. ®
Re: panix hijack press
On Wed, 19 Jan 2005, Darrell Greenwood wrote: customers' domains. Panix.com says its domain name was locked, and that despite this, it was still transferred. ® I seem to recall someone saying it wasnt locked, now theyre saying it was? -Dan
Re: [NANOG-LIST] Re: Graphing Peering
Well with mac accounting i've found that the results are not correct number they have to multiplied or something. I have a GigE and it has multiple peering sessions on it. Flowscan can't keep up, i have to export it in samples and that just defeats the purpose. I'm trying to find a way to graph indivual peers with totals. If there was a way to do it in perl i would... but i can't find the traffic on a per session basis. I'm running a cisco 12000 series router, with a current ios. I know juniper makes it really easy, but i have cisco :) Thanks everyone who has contributed. I really do appreciate it. On Wed, 19 Jan 2005 16:41:18 -0800, Brent Van Dussen [EMAIL PROTECTED] wrote: Hello, Something like this would be possible with an Sflow stream if your ethernet device supports it. By parsing out the src/dst mac addresses you could at least visualize which MAC is using up most of your ethernet. -Brent At 02:37 PM 1/19/2005, you wrote: no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. On Wed, 19 Jan 2005 22:25:37 + (GMT), Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Wed, 19 Jan 2005, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. do you mean how to graph traffic to each host on a lan..? what platform do you have? Steve
Re: panix hijack press
On Wed, 2005-01-19 at 15:51 -0800, Dan Hollis wrote: On Wed, 19 Jan 2005, Darrell Greenwood wrote: customers' domains. Panix.com says its domain name was locked, and that despite this, it was still transferred. I seem to recall someone saying it wasnt locked, now theyre saying it was? -Dan panix claims it was locked but I dont think it was. Like was mentioned they locked there other domains after panix.com was taken over. Why would they just lock one domain?
Re: panix hijack press
Thornton wrote: On Wed, 2005-01-19 at 15:51 -0800, Dan Hollis wrote: On Wed, 19 Jan 2005, Darrell Greenwood wrote: customers' domains. Panix.com says its domain name was locked, and that despite this, it was still transferred. I seem to recall someone saying it wasnt locked, now theyre saying it was? panix claims it was locked but I dont think it was. Like was mentioned they locked there other domains after panix.com was taken over. Why would they just lock one domain? Upon what verifiable facts do you base your endless speculation? (1) Stop blaming the victim! (2) Registrants can't lock domains, it's a registrar-lock. Users can only ask that domains be locked. Stupid policy, bad results. (3) This is a red-herring issue anyway, since there is no evidence that Mel-IT ever sent notification, or even waited 5 days for a response. The domain was hijacked in the middle of the night, in the middle of a weekend -- a very odd time for confirming responses by a staff that wasn't in the office answering the phones (4) Mel-IT has admitted it failed to properly confirm, and a loophole caused the error. (5) Mel-IT has an executive and a lawyer that were both notified about the problem, and refused to mitigate the damage. (6) Stop blaming the victim! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: panix hijack press
On Wed, 19 Jan 2005, William Allen Simpson wrote: (2) Registrants can't lock domains, it's a registrar-lock. Users can only ask that domains be locked. Stupid policy, bad results. This is not correct, prior to the new policy many registrars were already putting control over the regsitrar-lock directly into the registrants' hands and under the new policy if the registrar employs it they must provide access to the registrant. It's just called a registrar-lock to differentiate it from the registry-lock, basically to describe at what level the lock is set. -mark -- Mark Jeftovic [EMAIL PROTECTED] Co-founder, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(416)-535-0237
Regarding registrar LOCK for panix.com
On Wed, 19 Jan 2005, Darrell Greenwood wrote: customers' domains. Panix.com says its domain name was locked, and that despite this, it was still transferred. (r) I seem to recall someone saying it wasnt locked, now theyre saying it was? The information we have so far, indicates that it was not on Registrar LOCK at the registry at the time of the transfer. Regards, Bruce Tonkin
Re: panix hijack press
Upon what verifiable facts do you base your endless speculation? (1) Stop blaming the victim! (2) Registrants can't lock domains, it's a registrar-lock. Users can only ask that domains be locked. Stupid policy, bad results. (3) This is a red-herring issue anyway, since there is no evidence that Mel-IT ever sent notification, or even waited 5 days for a response. The domain was hijacked in the middle of the night, in the middle of a weekend -- a very odd time for confirming responses by a staff that wasn't in the office answering the phones (4) Mel-IT has admitted it failed to properly confirm, and a loophole caused the error. (5) Mel-IT has an executive and a lawyer that were both notified about the problem, and refused to mitigate the damage. (6) Stop blaming the victim! i dont think anyone is blaming the victim...what evidence do you have to support the domain being locked? a user can lock a domain..they can login to the control panel for there registrar and select registrar lock, registrar-lock, or lock and i am sure there are other registrars that word it even differently. once you select that it effectively locks your domain so it cant be transfered.
Re: [NANOG-LIST] Re: Graphing Peering
On Wed, 19 Jan 2005, andrew matthews wrote: Well with mac accounting i've found that the results are not correct number they have to multiplied or something. I have a GigE and it has multiple peering sessions on it. Flowscan can't keep up, i have to export it in samples and that just defeats the purpose. I'm trying to find a way to graph indivual peers with totals. If there was a way to do it in perl i would... but i can't find the traffic on a per session basis. I'm running a cisco 12000 series router, with a current ios. the ingress/egress linecards make a large difference in your stats collection efforts... so you might want to mention what they are so those that have tackled this before can better assist. -Chris
Date of transfer request (was: Regarding registrar LOCK for panix.com)
on 1/19/05 6:46 PM, Bruce Tonkin at [EMAIL PROTECTED] wrote: The information we have so far, indicates that it was not on Registrar LOCK at the registry at the time of the transfer. Bruce, It is well known that the date of transfer of the panix.com domain from Dotster to Melbourne IT was on January 15 (EST). Can you tell us the date when the transfer request was initially solicited by the client of Melbourne IT's reseller? -Richard
Re: [NANOG-LIST] Re: Graphing Peering
On Thu, Jan 20, 2005 at 03:14:24AM +, Christopher L. Morrow wrote: On Wed, 19 Jan 2005, andrew matthews wrote: Well with mac accounting i've found that the results are not correct number they have to multiplied or something. I have a GigE and it has multiple peering sessions on it. Flowscan can't keep up, i have to export it in samples and that just defeats the purpose. I'm trying to find a way to graph indivual peers with totals. If there was a way to do it in perl i would... but i can't find the traffic on a per session basis. ip accounting mac-address input ip accounting mac-address output then collect sh arp and sh int mac-accounting to sync up with your bgp sessions and ips, and you're all set. - jared I'm running a cisco 12000 series router, with a current ios. the ingress/egress linecards make a large difference in your stats collection efforts... so you might want to mention what they are so those that have tackled this before can better assist. -Chris -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Regarding registrar LOCK for panix.com
Oki all, I wasn't going to discuss this because it is potentially confusing, but as we're ratholing on registrar lock ... --- Some 60 plus days after a party acquired a domain, s/he initiated an UNLOCK at the user interface of the operator that had arrainged to acquire this particular domain. The transaction completed. The loosing registrar showed unlocked, the gaining registrar saw the unlocked and proceeded with a transfer, which failed. The rrp.unlock() call actually never was made from the registrar to the registry, due to a transient network event between the operator network, and the loosing registrar network. The point is that locks aren't what they seem. This is a distributed system with many points of failure, not completely coherent, and it does matter from where one looks. Shorter form: error is possible. --- The registrant asked me to help. I called the operator. The CSR who took the call observed the inconsistency and re-issued the rrp.unlock(). Domain unlocked by jrandom-3rd-party in under two minutes. Granted, it was in an unusual state and the caller (me) knew more than the nice CSR. --- Posit a backhoe of unusual size operating near MIT, or that MIT does business out of Sri Lanka and the State of Nagaland has just dragged anchor across the SEA-ME-WE-III (again), or any of a dozen other real life events. We'd be chatting about the state in the central registry, not the failure to trigger a state change at the periphery of the system. --- It is possible to run a domain name based network service off of addresses provisioned by dhcp. It is possible to acquire a contiguous block, and to hold them for quite a long time. But that doesn't mean that it is sensible to build a network infrastructure for dynmaically provisioned resources. The transformation of the dns service from 1990 to the present has created dynmaic provisioned name resources -- the property absent in 1990, the competitive registrar, is dynamic, and hence so is everything else. I picked 1990 because Panix is 15 year old. I think the fundamental issue is that things that ought to be wicked stable, are in fact not. Everyone is free to draw their own conclusions, and act as they see fit, its all just risk management anyway, but if the design respected this user community, we wouldn't be reading that the correct competitive registrar can manage the risk. --- This is my last note on the subject. Eric
Re: Graphing Peering
On Wed, 19 Jan 2005 14:37:54 -0800, andrew matthews [EMAIL PROTECTED] wrote: no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. If you are looking to graph statistics about the BGP peering sessions, (rather than graphing transit router bytes in/out as suggested elsewhere), you might take a look at the sample-config for the Cricket graphing tool, specifically ~cricket/cricket-1.0.4/sample-config/routing Unfortunately this graphs counts of BGP peering messages, not bytes. Cricket can track BGP route announcements, including graphing counts (rates) of peer updates in/out along along with total BGP messages, for each peering session. You could use Cricket itself to view the data, extract the collected data from 'rrdtool', or just look at the sources to get an idea of the requisite Cisco OIDs to use in another tool entirely. More information on Cricket is available from http://cricket.sourceforge.net/ Kevin
Re: panix hijack press
Mark Jeftovic wrote: On Wed, 19 Jan 2005, William Allen Simpson wrote: (2) Registrants can't lock domains, it's a registrar-lock. Users can only ask that domains be locked. Stupid policy, bad results. under the new policy if the registrar employs it they must provide access to the registrant. I stand corrected (although I cannot find it actually _in_ the policy); it's good to learn something new every day. However, that still looks to me like Users can only ask that domains be locked. Unless you are claiming that users can send the lock request directly to the registry, and monitor its status. Thornton wrote: i dont think anyone is blaming the victim...what evidence do you have to support the domain being locked? I repeat, the domain locking red-herring has absolutely nothing to do with this domain hijacking. Gosh officer, if she'd only had a big padlock on her purse, I wouldn't have stolen it. Gosh judge, if she'd only worn running shoes instead of those sexy high heels, I couldn't catch and rape her; the shoes made me do it. Stop blaming the victim! a user can lock a domain..they can login to the control panel for there registrar and select registrar lock, registrar-lock, or lock and i am sure there are other registrars that word it even differently. once you select that it effectively locks your domain so it cant be transfered. Not that I've ever noticed. Are you actually a network operator anywhere? Are you even _in_ North America? Your email isn't But then, the domain locking red-herring has absolutely nothing to do with this domain hijacking. Stop blaming the victim! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: Regarding registrar LOCK for panix.com
Bruce Tonkin wrote: The information we have so far, indicates that it was not on Registrar LOCK at the registry at the time of the transfer. No, the information we have so far is that it *WAS* supposed to be on registrar-lock! Quoting Alexis Rosen, forwarded by TLS, Sun, 16 Jan 2005 07:08:59 +: ... Our understanding is that we had locks on all of our domains. However, when we looked, locks were off on panix.net and panix.org, which we own but don't normally use. [Your Honor, maybe she locked the door, but the door company didn't install it correctly, otherwise I couldn't have ripped it off the hinges and gone in and raped her; it's the door company's fault.] Stop blaming the victim! Stop blaming anybody else. This was a Mel-IT error. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
RE: Regarding registrar LOCK for panix.com
Hello William, Stop blaming the victim! Stop blaming anybody else. I at no stage have blamed the victim. In fact I am sincerely sorry for the damage caused to panix.com. The transfer should NEVER have been initiated. Melbourne IT has consistently acknowledged the error. I have however discussed the problem from the point of view of the overall transfer process, as I want to improve it. There have been claims made on the list that the other parts of the system did not work. I am providing factual information on what happened through the process, and exposing the process to public review on this list. I have pointed out that the process can be strengthened. This is in no way blaming the victim. It is the role of domain name registrars to educate the registrants on their options. To reiterate, for a .com name there are two optional checks/mechanisms that can be used to further prevent an unauthorised transfer (and I will say again, I agree that the transfer should not have ever been initiated). (1) A name may be placed by a registrar on Registrar-LOCK. This is optional, and it is up to a registrar to inform their customers of this option. The name was not on Registrar-LOCK at the time of the transfer request. (2) The Registry must advise the losing registrar of a transfer request. I believe this happened, as I have a copy of the corresponding email sent from the registry to the gaining registrar. This does not mean that the losing registrar actually received this email. (3) The losing registrar MAY (ie it is an option available to the losing registrar but not a requirement) send a confirmation message to the registrant. In this case it appears that this did not happen, possibly because the confirmation message in (2) was never received by the losing registrar. There is no end-to-end confirmation in the current RRP system, for Verisign to be able to confirm that the losing registrar actually received its notification. To repeat again, I am not trying to escape any blame, not cast any blame on any other party. I am interested from an engineering point of view in improving the process to avoid it happening again. Regards, Bruce
Re: panix hijack press
William Allen Simpson wrote: Not that I've ever noticed. Are you actually a network operator anywhere? Are you even _in_ North America? Your email isn't To correct my own post, I saw Au, and assumed a shill for Mel-IT. But it's Az, which is Arizona (still in North America this year). My question about actually operating a network still stands. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Confirmation of receipt of the transfer request at Verisign for panix.com
When a registrar sends a transfer request to the registry operator (and the name is not on Registrar LOCK), the registry operator sends a confirmation email to both the losing and gaining registrar. Here is the copy of the email Melbourne IT received. Regards, Bruce Tonkin From [EMAIL PROTECTED] Sun Jan 9 12:40:35 2005 Return-Path: [EMAIL PROTECTED] Received: from verisign-grs.org (snoopy.verisign-grs.net [192.153.247.4]) by galahad.inww.com (8.12.9/8.12.9) with SMTP id j091eYgt003545 for ; Sun, 9 Jan 2005 12:40:35 +1100 (EST) Date: Sat, 8 Jan 2005 20:40:34 -0500 From: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] To: Melbourne IT Reply-to: [EMAIL PROTECTED] Subject: Receipt of Transfer Request: PANIX.COM Transfer Request for: Domain Name: PANIX.COM Requesting Registrar: Melbourne IT, Ltd. d/b/a Internet Names Worldwide Current Registrar: Dotster, Inc. The VeriSign Global Registry Services has received your request to modify the domain name record for PANIX.COM to reflect the fact that the registrant has selected you to be its Registrar. By submitting the request using the Transfer command in the RRP, you have represented to the VeriSign Global Registry Services and the Current Registrar that (1) you have obtained the requisite authorization from the domain name registrant listed in the database of the Current Registrar, and (2) you have retained a copy of reliable evidence of the authorization. Pursuant to established procedures, the VeriSign Global Registry Services has notified the Current Registrar of your request. If we receive an Affirmative response to our notice within five (5) calendar days, we will make the change to the domain name record. If we receive a negative response to our notice within five (5) calendar days we will decline to transfer the domain name. If the Current Registrar takes no action within five (5) calendar days, we will make the change to the record. Sincerely, VeriSign Global Registry Services www.verisign-grs.com [EMAIL PROTECTED]
improving the registrar transfer process
Bruce Tonkin wrote: To repeat again, I am not trying to escape any blame, not cast any blame on any other party. I am interested from an engineering point of view in improving the process to avoid it happening again. Good. Thank you! Early on in the process, Eric Brunner claimed you were a decent guy, or so I interpreted it. We know how to do 3-way handshakes. Rather a fundamental of the Internet. So quickly folks forget We knew in advance that the VRSN/NetSol/whatever protocol was terrible, and that the ICANN policy change was not going to be helpful. I think the notification process should parallel what anybody competent would expect in a communications protocol. Retry. Several times. (Admittedly, I've been involved in protocol design for 28+ years, thus have a tendency to see things that way.) At the retry limit, declare the peer to be down. In this case, the peer being down means taking all their domains away and revoking their registrar status and the performance bond. Accountability. Responsibility. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: panix hijack press
On Thu, 2005-01-20 at 00:49 -0500, William Allen Simpson wrote: William Allen Simpson wrote: Not that I've ever noticed. Are you actually a network operator anywhere? Are you even _in_ North America? Your email isn't To correct my own post, I saw Au, and assumed a shill for Mel-IT. But it's Az, which is Arizona (still in North America this year). My question about actually operating a network still stands. Thats good..had me thinking..I'm not in North America..what...haha and since it isn't really relevant..short answer is yes...and no that isn't yes i am not in north America :-)
