- NANOG - lists.nanog.org

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

21 Jan '05

Hello All, I have had a few emails regarding a perception that we have limited support to deal with issues such as panix.com, so I will just set the record straight. We provide a standard first level retail customer service line 24 hours by 5.5 days. (which gives business hours service in all world time zones). We provide 24 hour by 7 day customer service for resellers (typically ISPs, web hosting companies etc). We provide 24 hour by 7 day second level technical operations support. Most major registrars and ICANN have direct contacts into the technical parts of Melbourne IT. I received notification from several parties via email (but I don't read email 24 hours a day). We are looking at our processes to ensure that incidents such as occurred with panix.com can be addressed more quickly within Melbourne IT, and also checking to ensure that an appropriate number of external people have access to the right contacts at Melbourne IT to fast track serious issues. Regards, Bruce Tonkin Chief Technology Officer Melbourne IT

3 4

Association of Trustworthy Roots?
by William Allen Simpson 21 Jan '05

21 Jan '05

While the Association of Trustworthy ISPs idea has some merit, we've not been too successful in self-organizing lately. ISP/C? At the moment, I'm concerned whether we have trustworthy TLD operators. It's been about 24 hours, it is well-known that the domain has been hijacked, we've heard directly from the domain owner and operator, but the TLD servers are still pointing to the hijacker. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

24 39

RE: improving the registrar transfer process
by Bruce Tonkin 21 Jan '05

21 Jan '05

Hello William, > 1. MIT receives transfer request from reseller 2. MIT sends > email confirmation to whois contact (which contact - tech, > admin?) Melbourne IT would collect the WHOIS information for the particular domain name. We would store the critical details. For .com names, we would send the email confirmation to the: Admin Contact email address The email confirmation uses this format: http://www.icann.org/transfers/foa-auth-12jul04.htm The standard form ensures that the registrant is giving explicit authorisation for the transfer and not something else (e.g a renewal). The email confirmation has a unique link (with unique code) to a Melbourne IT website. The web page again includes the authorisation information. (in the case of a name for an EPP registry, you would also be asked for the AUTH-INFO password) We would log the authorisation along with the IP address used to access the website. > 3. MIT sends email (or is it request through Verisign RRP?) > to Verisign MIT would send an RRP command to the Verisign registry. 4. The Verisign registry checks to see if the name is on Registrar LOCK. If the name is on LOCK, the RRP command will fail. 5. If the name is not on Registrar LOCK< the registry sends an email notification to both the losing and gaining registrar. I have already sent a copy of the notification used in the panix.com case. 6. MIT then waits for confirmation from the registry that the transfer is complete. This usually takes 5 days, although a losing reigstrar can explicitly confirm a transfer. > > I also would like to confirm who is responsible for denying > transfer request if LOCK is present. The registry does this. Regards, Bruce Tonkin

1 0

FW: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
by James Laszko 21 Jan '05

21 Jan '05

We've had complaints from people at the other side of Broadwing connections -- anyone here from Broadwing? Looks like you may even be stripping 72.0.0.0/8 from BGP announcements. James Laszko Pipeline Communications, Inc. james(a)pcipros.com -----Original Message----- From: Christopher L. Morrow [mailto:christopher.morrow@mci.com] Sent: Thursday, January 20, 2005 9:55 PM To: James Laszko Cc: Rob Evans; Chris A. Epler; nanog(a)merit.edu Subject: RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19 On Thu, 20 Jan 2005, James Laszko wrote: > > Wash, rinse, repeat for the other 70,000 routers you manage for > > customers... This is definitely NOT a half-rack in a colo fix. Just > > contacting the customers is a feat. > > In the same hand, do you know how hard it was to get in touch with > someone at SBC/SBC-IS/PBI/PacBell that knew what the heck I was talking > about -- much less someone that might be able to do something about it? > Every group wanted to point their finger at some other group in the > company... Sure, start with the customer and convince them that there is a problem. SBC has, like sprint/att/mci/qwest/abovenet/blah-provider-of-managed-services 12 groups that do 'similar' things for 'managed customers'. Fighting their phone tree as a non-customer is a fruitless effort. Fighting the phone-tree for gov't agency #13 to let them know that some of their 'customers' aren't able to reach them might prove simpler. -Chris

1 0

RE: improving the registrar transfer process
by Bruce Tonkin 21 Jan '05

21 Jan '05

Hello William, > > 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. The ICANN policy change had no impact on this particular incident. As the incident has been documented so far, the transfer would have occurred under both the old and the new policy. With respect to the protocol. An IETF process was used to develop the EPP protocol as a replacement for RRP. With respect to notifications of transfers, the new protocol handles this by a message queue at the registry. (ie email is no longer the mechanism). It might be useful to consider reviewing the protocol to ensure that a transfer cannot proceed unless the losing registrar system confirms receipt of the transfer request. Regards, Bruce

2 1

RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
by James Laszko 21 Jan '05

21 Jan '05

> Wash, rinse, repeat for the other 70,000 routers you manage for > customers... This is definitely NOT a half-rack in a colo fix. Just > contacting the customers is a feat. In the same hand, do you know how hard it was to get in touch with someone at SBC/SBC-IS/PBI/PacBell that knew what the heck I was talking about -- much less someone that might be able to do something about it? Every group wanted to point their finger at some other group in the company... James Laszko Pipeline Communications, Inc. james(a)pcipros.com

2 1

RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
by James Laszko 21 Jan '05

21 Jan '05

> > Whats so bad about decent secure defaults? > I don't consider a configuration that disenfranchises part of the > internet as "decent [...] defaults." :) The big problem that we're experiencing here is that the big telco ISP's, network providers and managed service providers that should have something better than a 'network monkey' running their routers are having BOGON filtering problems. We diagnosed a problem getting to east cost government sites and in working with SAVVIS, we corrected problems in a matter of hours. This has been the only positive progress we've made in unblackholing out network segment. We're going on day number 4 trying to get SBC to fix 'managed' local government routers. To tell you the truth, the little leaf nodes that have a corporation without world-accessible resources behind their router are unconsequential to us -- let them filter on old BOGON lists -- our customers need to be able to get to the resources that are behind the huge networks that are maintained by companies much larger than ours that are running out of date filters. Why more people don't use resources like what Cymru offer is beyond me... James Laszko Pipeline Communications, Inc. james(a)pcipros.com

3 2

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

21 Jan '05

Hello Mark, > That's what happened last weekend: Martin Hannigan and I got > the ball rolling on Sunday morning about 1000 EST. Our 24x7 > customer service department contacted Dotster and Melbourne > IT. Melbourne IT changed the panix.com name servers back to > their original settings and transferred the domain back to Dotster. > I can confirm that Verisign did get in touch with our Production Manager (Peter Berry) around 1pm Sunday (New York time), and our Reseller Program Manager (Steve Karabatsos) around 4:30pm Sunday (New York time). We were contacted previously by Panix around 5pm Saturday (New York time). I believe that Verisign complied with all their obligations with respect to the ICANN transfer policy, and Verisign was very cooperative in assisting us with the issue. Regards, Bruce

2 1

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

21 Jan '05

Hello Thor, > > > > (5) The registry will send a message to the losing registrar > > confirming that a transfer has been initiated. > > Can you confirm or deny whether this actually happened in the > case of the panix.com transfer? I don't have any direct visibility over this. I have asked Verisign and Dotster if they can confirm. My personal view is that I think it unlikely that this part of the system failed. Note however that Verisign would send the message via email to Dotster. Verisign could prove that they sent the email, but it is possible that it was not delivered. > > The other problem I see in this area is that the RRP > specification (if that is in fact the protocol that was used) It was. > seems to claim that this message is out-of-band and thus > beyond the scope of the protocol: so it does not (can not) > specify an ACK. If an attacker found a way to prevent this > message from being received, even if generated... > > A strictly enforced technical requirement for an ACK here > might work wonders (perhaps it would have to be enforced by > duping both the confirmation and the ACK to the "System", as > RRP so quaintly calls it, and denying future transfers > initiated by parties with too many outstanding ACKs). Not an > approval, just an ACK. Rather than further work on the RRP protocol, it would be better for Verisign to implement the EPP protocol which has gone through the IETF process. Regards, Bruce

2 1

RE: improving the registrar transfer process
by Bruce Tonkin 20 Jan '05

20 Jan '05

> > > > Accountability. Responsibility. > > I agree with you on this 100%. ICANN needs to enforce there > current policies. I agree too. > Look at totalnic/pacnames. They have been > refusing transfer requests years now until very very recent. > What has ICANN done about all those complaints and violations > that has been well documented? > nothing! > > ICANN needs to stop just accepting money and start enforcing > policies... > Interestingly, the ICANN equivalent in Australia (auDA), does pro-actively enforce policies, and even took Capital Networks to court on the basis that they could be de-accredited as a registrar for .au, if they continued not to allow transfers for .com. See: http://www.austlii.edu.au/au/cases/cth/FCAFC/2004/324.html The original judgment is at: http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/808.html

2 1