January 2005 - Test - lists.nanog.org

New Virus in the wild
by Nils Ketelsen 18 Jan '05

18 Jan '05

We see a lot of requests of the following format in our proxy logs: 1105979310.010 240001 10.3.12.211 TCP_MISS/504 1458 GET http://84.120.14.236:25204/2005/1/17/11/23/32/ - NONE/- text/html 1105979314.020 240009 10.3.12.211 TCP_MISS/504 1458 GET http://67.171.84.104:25238/2005/1/17/11/23/41/ - NONE/- text/html 1105979316.077 240068 10.3.12.211 TCP_MISS/504 1460 GET http://213.188.227.50:25401/2005/1/17/11/23/43/ - NONE/- text/html The Port these clients are trying to connect to seem to be in the range between 25000 and 26000 all the time. All requests have the timestamp in the URL (/2005/1/17/11/23/43 for example). We are currently investigating together with NAI what that is. We have a bunch of internal hosts producing these requests and the numbers are rising. The load is starting to render our proxies unusable. Any hints are very welcome. Nils

4 8

Intelsat Reports Loss of IS-804
by Fergie (Paul Ferguson) 18 Jan '05

18 Jan '05

http://www.intelsat.com/aboutus/press/release_details.aspx?year=2005&art=20… - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

Re: netblazer Was: baiting
by Hannigan, Martin 18 Jan '05

18 Jan '05

"You win. I give. Uncle." (And I was serious, not sarcastic, about the 'blazer. YMMV,) -M --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. -----Original Message----- From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> To: North American Network Operators Group <nanog(a)merit.edu> Sent: Mon Jan 17 06:56:11 2005 Subject: Re: Association of Trustworthy Roots? [I first met Eric when I was a consultant helping put together the NetBlazer for Telebit. With my ISP hat on, we used NetBlazers for many years, very stable. I only wish that BellSouth had been as stable. We eventually switched to PortMasters for the improved diagnostics of BellSouth's continually flapping lines. However, we continued to use the old NetBlazers for internal routing up until a year or so ago. They worked well, and supported AppleTalk, too.] At Martin's insistence, and with Eric's kind permission: Eric Brunner-Williams in Portland Maine wrote: >I didn't point out to him what he already knew. That he wrote me Sunday >morning (Sun, 16 Jan 2005 07:05:42 EST), a reply off-list to my note to >Perry before going to bed around midnight. "What did I miss? Why would >they call MIT's attorney?", and that I called his cell and office about >a half-dozen times until I got him around 8am, and after 10 or so minutes >of exchanges of observations on the situation, punctuated periodically by >"I'm sure you understand there is nothing we can do", and "I don't work >on the GRS side of Verisign", I concluded with "I have a message for Chuck >Gomes, tell him that liability minimization (doing nothing until ICANN >process authorized) is the wrong choice. This is a stability of the >internet issue." > > > Seems to me that Eric worked pretty hard on this at no recompense to himself. And remember he was a voice of reason, cautioning this list to treat everyone as human beings. Martin may have finally gotten the job done, and it may have been beyond his formal job description, but I wish he'd remember to treat the rest of us as human beings, too. =------- Original Message -------- From: "Hannigan, Martin" <hannigan(a)verisign.com> Date: Mon, 17 Jan 2005 00:50:46 -0500 Why isn't this on NANOG where it started? -M PS: I used the netblazer in 93 and it was a POS. --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. =----Original Message----- From: Eric Brunner-Williams in Portland Maine <brunner(a)nic-naa.net> To: Hannigan, Martin <hannigan(a)verisign.com> Date: Sun Jan 16 16:57:52 2005 Martin, Bill and I worked together on the first demand-dialup router, the NetBlazer. That was in 1991. Scott may have a different opinion, and arguably RRP registrar/registry is semantically distinguishable from EPP registrar/registry semantics (but I wrote an I-D that contained just such a comparison to show functional equivalence), but having spent 1999 - 2003 focused on provisioning and registrar/registry semantics, I have an opinion on the correctness of the events of yesterday and today. Earlier today I wrote off-list this: Just to be formal and clear however, we had an incoherent dns, and caching resolver operators introduced the incoherency to correct for an error published by the authoritative resolver operator. As one of the EPP authors, I see provisioning and publication as two distinct functions. How state change in the registry database was provisioned -- the registrar error, is not controlling on what the registry publishes as a zonefile. VGRS erred in publication of bad data, and its error persisted for at least 12 hours, if not 24 or more, after notice. Everything else is just policy. Your milage obviously varies. VGRS's publication of the authoritative panix.com data was incorrect. Bill wrote: The domain owner and ISP and registrar all clearly stated that they had received no notification, and had not approved the transfer. I'd have used a different gramatical construct, and not distinguished between panix the registrant and panix the isp, and I've no private knowledge of Dotster's having made an affirmative response, but the registrant's claim of non-receipt of transfer is sufficient. Bill wrote: Notification and approval are required by the process. The weaker condition is simply notification, already asserted lacking by the controlling authority, the registrant. Bill wrote: Therefore, it was proven to be circumvented. QED. Xfr w/o notice is the result, but not the condition, so yes, QED. Bill wrote: Now, as to the actual mechanism of circumvention, that has not yet been revealed here. Knowlege is partial, however, unless VGRS makes the complete transactional history public, it can't make a defense that any claim is invalid based upon a claim that the knowledge is partial. Bill wrote: All we know is that a registry *supervisor* stopped the workers from finishing their investigation. I don't know how Bill knows that, but I know that I don't know the complete transactional history from VGRS, and the reason for non-disclosure of the state of the database is policy, and policy originates in supervisorial VGRS staff, not operations staff. Bill wrote: Clearly, this .com registry operator is not trustworthy. I think everyone in the DNSSEC community holds this view, and we're all attempting to work towards trust in the DNS. It may not be possible for the .com zone, for reasons that frankly appear to be policy based rather than mechanism based, but as things stand, the .com registry operator is not trustworthy. There are registry operators to who's operational art even less trust can be associated, e.g., NeuStar, my former employeer, and registry operators to who's operational art more trust can be associated, e.g., SWITCH. I'm sorry you felt that citing Martians was responsive to Bill's comments. I don't think they were. I'm rather fond of Martians. Bogons too. Eric -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

4 5

RE: Gtld transfer process
by Bruce Tonkin 18 Jan '05

18 Jan '05

Hello Brandon, Thanks for your feedback. > > My experience has been that getting auth_info (which criminal > staff would have access to) from bad registrars is almost > impossible, with registrar-LOCK too they have enough control > to negate the gain in being able to pull a domain to a new > registrar - you still need the cooperation of the old one so > it's just as bad as the old way but lots more risk for everyone > > EPP is thus of no advantage and registrar pull is dangerous Thus are you basically proposing that the registrant rely on cooperation with the old registrar, and if that fails, rely on ICANN to enforce compliance if the old registrars doesn't cooperate? I think in any model, unless ICANN enforces compliance the model will fail. We use the EPP model with registrar pull in Australia, and I haven't heard of any recent instances of abuse. There is no mechanism for the losing registrar to deny a transfer. The difference is that the ICANN equivalent in Australia (auDA) rigorously enforces compliance by the gaining registrar. Regards, Bruce

2 1

RE: Gtld transfer process
by Bruce Tonkin 18 Jan '05

18 Jan '05

Hello Alexei, > > Problem - you are talking about changing registrar, but in > reality you describe changing of domain owner. Yes you are right in that often a number of domain name variables change at around the same time. > > Why (what for) is it allowed to transfer from one registrar > to another with changing NS records and other owner information? Usually it is NS records that change, as a transfer can be associated with moving a domain name to a new service provider for email or web hosting. It is often the change in other services that prompts the transfer request in the first place. > Why don't separate this 2 events - changing registrar, and > changing domain owner/information? Is it any need in reality > changing registrar with simultaneous changing domain information? > I agree with respect to "ownership" change that this should be separated by some time period from registrar transfer. Note that only the registrar transfer process is regulated by the ICANN agreements. Apart from changes in the identity of the legal holder of the domain name agreement, other details such as postal address, phone numbers and email addresses are often updated at the time of customer contact with respect to the transfer. Usually this information represents the most up-to-date contact information. > What should happen in normal situation: > - someone requested transfer of domain (without real authorisation); > - even if all checks pass and transfer was allowed, new > registrar should maintain the same NS and other information > as old one, so no real damage could happen; > - domain owner received e-mail, see frauded transfer and > disputed it (having domain in working condition on the new registrar); > - new registrar OR old registrar OR VeriSign roll back transaction. This is effectively what happened in the panix.com case. As soon as facts were verified the NS records were rolled back by the gaining registrar to their previous state. The issue was that it took hours to occur. It is a separate discussion as to whether the registry operator (Verisign in this case) should do this roll back in the case of a network outage in the absence of instructions from registrars. Regards, Bruce

1 0

Re: Gtld transfer process
by Brandon Butterworth 18 Jan '05

18 Jan '05

> The loophole that led to this error has been closed. Perhaps for you but this process leaves a lot of registrars in position to do damage, accidentally or by the criminal action of staff. > In some cases registrars delegate the obtaining of the approval from a reseller Though well intentioned to make it easier to move away from bad registrars all this does is put everyone else at far greater risk - not only from registrars but also their resellors who are likely to be unvetted. It seems quite easy for criminals to gain conrol > Many registrars now put names on lock by default So we're back to needing the cooperation of the old registrar, may as well have stuck with the old, less risky, way > (7) If the registry receives no response from the losing registrar > after a 5 day period, the transfer will be completed. Adding the risk of not noticing and it just going through unchallenged > (9) If the losing registrar believes that a transfer was unauthorised, > the losing registrar may contact the gaining registrar for a copy of the > authorisation in step 2 to arrange for the transfer to be reversed. Too late, the damage is done > In the case of panix.com, the step (2) failed at the gaining registrar. > I can't comment on steps taken by the losing registrar. It doesn't matter, the system is broken by design - they had to trust you to be correct > The principle of the process, is that a registrant can move to another > domain name provider (registrar or reseller) at any time, and can > initiate a transfer from the new provider. This relies on the new > provider authenticating the request. I'm only paying my registrar to be trustworthy, I don't want to have to trust the rest > The integrity of the process is greatly improved through the use of the > auth_info password in the EPP protocol. This has been operating > effectively in .org, .info., .biz and .name. I disagree (the new whois sucks too) > My personal view is that the current transfers policy WITH the use of > auth_info and WITH the use of registrar-LOCK is a reasonable balance > between security and allowing registrants to easily move their name. My experience has been that getting auth_info (which criminal staff would have access to) from bad registrars is almost impossible, with registrar-LOCK too they have enough control to negate the gain in being able to pull a domain to a new registrar - you still need the cooperation of the old one so it's just as bad as the old way but lots more risk for everyone EPP is thus of no advantage and registrar pull is dangerous > I am interested to hear what members of the NANOG list believe would be > a better transfers process. Everyone has their ideas but the people running a $1.2B business should be able to do better brandon

1 0

panix: theregister.co.uk article
by Gadi Evron 17 Jan '05

17 Jan '05

http://www.theregister.co.uk/2005/01/17/panix_domain_hijack/ Gadi.

1 0

fwd: Re: [registrars] Re: panix.com hijacked
by Eric Brunner-Williams in Portland Maine 17 Jan '05

17 Jan '05

Oki all, Delivery of RC mail to me is fairly desultory. Apparently there is an earlier thread. Post-Rome the very purpose of the RC seems to me to be doubtful (advocacy for registrars other than NetSol+4), and post-Elana the process of the RC left me disinterested. I'm particularly enamored by Ross' notion of what is going on on NANOG. Cheers, Eric ------- Forwarded Message Return-Path: owner-registrars(a)gnso.icann.org Delivery-Date: Sun Jan 16 11:14:04 2005 Return-Path: <owner-registrars(a)gnso.icann.org> Received: from greenriver.icann.org (greenriver.icann.org [192.0.35.121]) by nic-naa.net (8.13.1/8.13.1) with ESMTP id j0GBDxgx036293 for <brunner(a)nic-naa.net>; Sun, 16 Jan 2005 11:14:04 GMT (envelope-from owner-registrars(a)gnso.icann.org) Received: from greenriver.icann.org (greenriver [127.0.0.1]) by greenriver.icann.org (8.12.11/8.12.11) with ESMTP id j0GEx1Qg006202; Sun, 16 Jan 2005 06:59:01 -0800 Received: (from majordomo@localhost) by greenriver.icann.org (8.12.11/8.12.11/Submit) id j0GEx0hJ006201; Sun, 16 Jan 2005 06:59:01 -0800 X-Authentication-Warning: greenriver.icann.org: majordomo set sender to owner-registrars(a)gnso.icann.org using -f Received: from pechora.icann.org (pechora.icann.org [192.0.34.35]) by greenriver.icann.org (8.12.11/8.12.11) with ESMTP id j0GEwxrw006198 for <registrars(a)greenriver.icann.org>; Sun, 16 Jan 2005 06:59:00 -0800 Received: from tomts16-srv.bellnexxia.net (tomts16-srv.bellnexxia.net [209.226.175.4]) by pechora.icann.org (8.11.6/8.11.6) with ESMTP id j0GEwBA16293 for <registrars(a)dnso.org>; Sun, 16 Jan 2005 06:58:11 -0800 Received: from [192.168.2.101] ([67.71.54.206]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050116145857.SKGA1836.tomts16-srv.bellnexxia.net(a)[192.168.2.101]>; Sun, 16 Jan 2005 09:58:57 -0500 Message-ID: <41EA80BF.7020608(a)tucows.com> Date: Sun, 16 Jan 2005 09:57:03 -0500 From: "Ross Wm. Rader" <ross(a)tucows.com> Reply-To: ross(a)tucows.com Organization: Tucows Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Jeftovic <markjr(a)easydns.com> CC: Registrars Constituency <registrars(a)dnso.org> Subject: Re: [registrars] Re: panix.com hijacked References: <Pine.LNX.4.58L0.0501160024320.11253(a)c3po.easydns.com> In-Reply-To: <Pine.LNX.4.58L0.0501160024320.11253(a)c3po.easydns.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-registrars(a)gnso.icann.org Precedence: bulk On 1/16/2005 12:29 AM Mark Jeftovic noted that: > There's a thread on NANOG to the effect that panix.com has been > hijacked from Dotster over to MelbourneIT and it has pretty > well taken panix.com and its customers offline, see > http://www.panix.net/ I don't see what you are looking at - .net and .com point to the same place with no indication of anything awry...of course, I'm late to the game and the DNS probably tells a different story... > > Looks like this may be among the first high-profile unauthorized > transfer under the new transfer policy. Looks like a bunch of guys on the NANOG list engaging in a lot of conjecture without the benefit of a lot of facts. > Maybe there needs to some sort of emergency reversion where at least the > nameservers can be rolled back immediately while the contesting parties > sort it out. Might be interesting - what criteria would trigger the process? - -- Regards, -rwr "In the modern world the intelligence of public opinion is the one indispensable condition for social progress." - Charles W. Eliot (1834 - 1926) ------- End of Forwarded Message

12 13

Re: Association of Trustworthy Roots?
by William Allen Simpson 17 Jan '05

17 Jan '05

[I first met Eric when I was a consultant helping put together the NetBlazer for Telebit. With my ISP hat on, we used NetBlazers for many years, very stable. I only wish that BellSouth had been as stable. We eventually switched to PortMasters for the improved diagnostics of BellSouth's continually flapping lines. However, we continued to use the old NetBlazers for internal routing up until a year or so ago. They worked well, and supported AppleTalk, too.] At Martin's insistence, and with Eric's kind permission: Eric Brunner-Williams in Portland Maine wrote: >I didn't point out to him what he already knew. That he wrote me Sunday >morning (Sun, 16 Jan 2005 07:05:42 EST), a reply off-list to my note to >Perry before going to bed around midnight. "What did I miss? Why would >they call MIT's attorney?", and that I called his cell and office about >a half-dozen times until I got him around 8am, and after 10 or so minutes >of exchanges of observations on the situation, punctuated periodically by >"I'm sure you understand there is nothing we can do", and "I don't work >on the GRS side of Verisign", I concluded with "I have a message for Chuck >Gomes, tell him that liability minimization (doing nothing until ICANN >process authorized) is the wrong choice. This is a stability of the >internet issue." > > > Seems to me that Eric worked pretty hard on this at no recompense to himself. And remember he was a voice of reason, cautioning this list to treat everyone as human beings. Martin may have finally gotten the job done, and it may have been beyond his formal job description, but I wish he'd remember to treat the rest of us as human beings, too. =------- Original Message -------- From: "Hannigan, Martin" <hannigan(a)verisign.com> Date: Mon, 17 Jan 2005 00:50:46 -0500 Why isn't this on NANOG where it started? -M PS: I used the netblazer in 93 and it was a POS. --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. =----Original Message----- From: Eric Brunner-Williams in Portland Maine <brunner(a)nic-naa.net> To: Hannigan, Martin <hannigan(a)verisign.com> Date: Sun Jan 16 16:57:52 2005 Martin, Bill and I worked together on the first demand-dialup router, the NetBlazer. That was in 1991. Scott may have a different opinion, and arguably RRP registrar/registry is semantically distinguishable from EPP registrar/registry semantics (but I wrote an I-D that contained just such a comparison to show functional equivalence), but having spent 1999 - 2003 focused on provisioning and registrar/registry semantics, I have an opinion on the correctness of the events of yesterday and today. Earlier today I wrote off-list this: Just to be formal and clear however, we had an incoherent dns, and caching resolver operators introduced the incoherency to correct for an error published by the authoritative resolver operator. As one of the EPP authors, I see provisioning and publication as two distinct functions. How state change in the registry database was provisioned -- the registrar error, is not controlling on what the registry publishes as a zonefile. VGRS erred in publication of bad data, and its error persisted for at least 12 hours, if not 24 or more, after notice. Everything else is just policy. Your milage obviously varies. VGRS's publication of the authoritative panix.com data was incorrect. Bill wrote: The domain owner and ISP and registrar all clearly stated that they had received no notification, and had not approved the transfer. I'd have used a different gramatical construct, and not distinguished between panix the registrant and panix the isp, and I've no private knowledge of Dotster's having made an affirmative response, but the registrant's claim of non-receipt of transfer is sufficient. Bill wrote: Notification and approval are required by the process. The weaker condition is simply notification, already asserted lacking by the controlling authority, the registrant. Bill wrote: Therefore, it was proven to be circumvented. QED. Xfr w/o notice is the result, but not the condition, so yes, QED. Bill wrote: Now, as to the actual mechanism of circumvention, that has not yet been revealed here. Knowlege is partial, however, unless VGRS makes the complete transactional history public, it can't make a defense that any claim is invalid based upon a claim that the knowledge is partial. Bill wrote: All we know is that a registry *supervisor* stopped the workers from finishing their investigation. I don't know how Bill knows that, but I know that I don't know the complete transactional history from VGRS, and the reason for non-disclosure of the state of the database is policy, and policy originates in supervisorial VGRS staff, not operations staff. Bill wrote: Clearly, this .com registry operator is not trustworthy. I think everyone in the DNSSEC community holds this view, and we're all attempting to work towards trust in the DNS. It may not be possible for the .com zone, for reasons that frankly appear to be policy based rather than mechanism based, but as things stand, the .com registry operator is not trustworthy. There are registry operators to who's operational art even less trust can be associated, e.g., NeuStar, my former employeer, and registry operators to who's operational art more trust can be associated, e.g., SWITCH. I'm sorry you felt that citing Martians was responsive to Bill's comments. I don't think they were. I'm rather fond of Martians. Bogons too. Eric -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

1 0

RE: Regarding panix.com
by Bruce Tonkin 17 Jan '05

17 Jan '05

Hello Matthew, > > > What sort of support would you give a not-for-profit Org such > as SORBS.net or an Org such as Spamhaus.org if our domains > were hijacked maliciously (or not)....? As others have pointed out, any procedures will need to ensure that they can be applied to all domain name records. > > I note that Spamhaus.org is set 'CLIENT TRANSFER PROHIBITED' > and 'CLIENT UPDATE PROHIBITED' so in theory this shouldn't be > a problem, but the various earlier comments indicating that > panix.com was thought to be 'LOCKED' before the issues of the > last few days provide more food for thought. > I doubt that panix.com was "LOCKED" at the registry, as the transfer could not have been initiated. Some registrars use the term "lock" to refer to an internal security procedure that is unrelated to a lock that can be placed on the name in the registry. Note that different registries have different locking mechanisms. Regards, Bruce Tonkin

1 0