- NANOG - lists.nanog.org

Finding clue at comcast.net
by Howard C. Berkowitz 09 Oct '03

09 Oct '03

I'm rapidly beginning to believe this is equivalent to finding the pot of gold at the end of the rainbow. When my broadband alternative is Verizon and it's looking better, this is scary. Sometime today, their SMTP server started bouncing messages with more than 3 addressees. When I called customer support, I was told "we only handle troubleshooting, not mail service." The operator "guessed" they might be doing software updates on the mail service, had no information, and said there was no person to which it could be escalated. She insisted that I call my local cable office to find out when the "server repair" would be completed, because "they schedule all repairs." Is this a bad dream?

1 0

DoS Attacks
by Brian Bruns 09 Oct '03

09 Oct '03

Oh boy, what a fun night this was. After a 4 or so hours downtime, my servers are back up and running. Heres the gorey details. At about 7pm EST, we began having unusual issues with our network, the router, and several machines on the network. For the first part of the attack, we were held down for a good 30-60 minutes. Took us a while to figure out which one of our machines was being targeted. Turns out to be our NAT firewall box. We tried several things to drop the attack, but it still kept coming in strong (mind you, we don't have very much bandwidth, but we can usually ride out DoS attacks pretty well - this was an exception) Then suddenly, out of the blue it dropped. Outside connectivity was restored and things were back to normal. 20 minutes later, the relentless attack began again. This time, we were ready and waiting with tcpdump and several other handcrafted tools we use for this type of thing. The attack was coming from a single source machine, unspoofed (ballsy if you ask me), 128.186.11.215. Packets were UDP, random from 2100-2299 source and 2400-2699 dest. So, now for the fun part. Being offsite, I wasn't the one to place the calls, but my admin on site started with FSU's abuse desk. No help whatsoever. Claimed that because the abuse desk was gone, they had no authority to deal with the problem. Frustrated, annoyed, and pissed off, he tried again, and got hung up on twice. Nice people eh? Our next call was a bit later (at this point, we were very unhappy and ready to start raising hell with anyone we could find) - this time, to their upstream Qwest. After dealing with the operator, they finally sent him to one of the NOCs. Unfortunately, they sent him to the wrong NOC and not the Qwest MD NOC. Luckily, we got someone with a clue - a nice guy by the name of Richard Stein who tried to help us, but found that the other NOC was unresponsive and couldn't do anything himself to solve the problem. After hanging up with Qwest, we got a call back from FSU. After a good 20 minutes or so of talking with the net admin from FSU, things were finally set in motion. After another good 10 minutes or so, connectivity was restored and everything was back to normal. According to my guy, they yanked the whole subnet at FSU. Problem solved. So here I am, asking if anyone here has any advice on dealing with these issues in the future? Its painfully apparent noone takes these situations seriously enough. What should we do when we are put in a position like this? Just sit back and hope it goes away itself? Also, any ideas on how to deal with these attacks on lower bandwidth connections? Right now, 2mbit.com / sosdg.org is sitting on a 1.5/256 business DSL line. I really can't afford to be buying T1s or T3s just to hold up to attacks like this. As always, thanks. -------------------------- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511

10 11

Re: Verisign on Process
by Howard C. Berkowitz 08 Oct '03

08 Oct '03

At 2:51 PM -0400 10/8/03, Dean Anderson wrote: >On Wed, 8 Oct 2003, Howard C. Berkowitz wrote: > >> >VeriSign's vice president for its registry service. Citing concerns >> >of proprietary information and competitive advantage, he added that >> >he didn't think he could guarantee any advance notice of similar >> >changes in the future. >> >> >> Gomes' position truly bothers me if a registry, given that it meets >> the formal definition of a technical monopoly, is planning around >> competitive advantage. > >This is incorrect. Verisign is not a monopoly. There are many registrars >of .net and .com domain names which compete with Verisign. > > --Dean It is not a monopoly in its regiSTRAR function. It is a monopoly as regiSTRY of .net and .com. It couldn't have inserted the wildcards if it wasn't. Having control of the TLD servers makes you a monopoly for that TLD.

2 1

Old Lorain Rectifier Manual availability?
by Marius Strom 08 Oct '03

08 Oct '03

Does anyone know where to find old Lorain Rectifier manuals (Specifically model #A50F50)? Google (groups and www) turns up nothing. (A PDF would be nice, but I don't have my fingers crossed) -- /-------------------------------------------------> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-------------| Alan Frame |---------------------->

2 1

Re: News coverage, Verisign etc.
by John Neiberger 08 Oct '03

08 Oct '03

>>>> "Steven M. Bellovin" <smb(a)research.att.com> 10/8/03 1:54:12 PM >>> >>In these days of corporate malfeasance scandal coverage, you'd think that >>Verisign's tactics would have whetted the appetite of some bright >>investigative reporter for one of the major publications. > >For all that I'm critical of wildcards in TLDs -- I spoke at the >meeting yesterday, and my slides are on my Web page -- I don't think >there are any issues of malfeasance. No one has been looting >Verisign's coffers, they're not cooking the books, etc. I see three >issues: is this technically wise, did Verisign have the right to do >this under their current contract with ICANN, and should they have such >a right. I don't see anything resembling dishonesty. The dishonesty came later in the form of press releases and 'commentary' by Mark McLaughlin. Well, perhaps dishonesty is too harsh a term. Let's be kind and say they are being disingenuous instead. John --

1 0

Verisign on Process
by Howard C. Berkowitz 08 Oct '03

08 Oct '03

Both here and in private mail, people have been talking about Verisign's view of the process. Unfortunately, I was only able to attend the afternoon part of yesterday's ICANN ISSC committee meeting. But Declan McCullough was there, and picked up an interesting quote from Verisign: >By Declan McCullagh >Staff Writer, CNET News.com >http://news.com.com/2100-1038-5088128.html > >Legal and policy questions were not on the agenda, and VeriSign >representatives repeatedly objected when the discussion veered in >that direction. > >"Are we going to focus on security and stability, or usability?" >asked VeriSign's Ben Turner, saying the committee's mandate was too >narrow to include broader questions about Site Finder. > >Stephen Crocker, one of the Internet's original architects and the >ICANN committee's chairman, asked VeriSign why the wild card was >introduced without giving network operators any warning. "I know for >a fact that VeriSign has no problem finding its way to those >(technical discussion) forums," Crocker said, referring to the >company's ongoing participation in them. > >"I don't want to go beyond the agenda," replied Chuck Gomes, >VeriSign's vice president for its registry service. Citing concerns >of proprietary information and competitive advantage, he added that >he didn't think he could guarantee any advance notice of similar >changes in the future. Gomes' position truly bothers me if a registry, given that it meets the formal definition of a technical monopoly, is planning around competitive advantage. Other speakers pointed out that the functionality of Sitefinder could be implemented at the edge, not breaking the end-to-end assumption and still allowing innovation. Internet Explorer, for example, has such functionality. MS and VS. Reminds me of some recent wars where observers were sad that only one side could lose. :-)

3 2

Re: Sitefinder fan - this guy needs a clue.
by Robert Boyle 08 Oct '03

08 Oct '03

At 02:06 PM 10/8/2003, you wrote: > > Let's hope we can append "not for long" if they keep this stuff up. :) > >The great thing about the web is a newspaper can bury its mistakes without >having to admit it in the "Corrections" page. > >ZD.NET has modified the article the originally posted. ZD.NET added the >biography and changed the byline in the last hour or so. > >The original article did not identify Mark McLaughlin nor include his >biography. Correct! If it had, I never would have posted. :) R Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey

1 0

Sitefinder fan - this guy needs a clue.
by Robert Boyle 08 Oct '03

08 Oct '03

Wow. This guy is completely delusional. http://zdnet.com.com/2100-1107_2-5087746.html I have been up for 24 hours working on a router upgrade and a simultaneous DS3 problem so I'm in no frame of mind to respond. Perhaps one of the more eloquent (and less tired) folks here can politely beat this guy with a clue stick. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey

8 8

Re: Sitefinder fan - this guy needs a clue.
by John Neiberger 08 Oct '03

08 Oct '03

>>>> Owen DeLong <owen(a)delong.com> 10/8/03 10:29:15 AM >>> > >On the CNET article that ZDNET seems to have copied lock stock and barrel, >he did actually identify himself as a Verisign VP in the by line. As such, >I think this is ZD's fault, not McLaughlin's. I don't have any love lost >for Verisign, but, I think we need to be very careful to stick to criticisms >that can stick to them. Otherwise, they will divert attention to our false >claims and use them to prove that we are the net.kooks they are trying to >make us out to be. > >Owen ZDNet has fixed the attribution on their article. They now mention before and after the article that McLaughlin is a Verisign VP. John --

1 0

10,000 foot view of DNS/Sitefinder/Verisign
by Howard C. Berkowitz 08 Oct '03

08 Oct '03

After attending the afternoon ICANN Security & Stability Committee meeting, I realized that the issues involved fall into several related but independent dimensions. Shy person that I am *Cough*, I have opinions in all, but I think it's worthwhile simply to be able to explain the Big Picture to media and other folk that aren't immersed in our field. In these notes, I'm trying to maintain neutrality about the issues. I do have strong opinions about most, but I'll post those separately, often dealing with one issue at a time. For those of you new to the media, it's often best to put things into small, related chunks. 1. Governance issues -------------------- Did Verisign have the right, regardless of technical merit, to do what it did without prior warning? I'm simply saying "did they do anything contractually or otherwise legally forbidden", not "was it strongly counter to the assumptions of the Internet" or "were they mean and nasty." The news/political interest here is whether any other group should or could have affected this, or if we need new governance mechanisms. Has this revealed any conflict of interest issues? To what extent should a registry be able to act unilaterally? These points are meant to be examined here in the context of law, regulation and governance, as opposed to the less formal points in #2. 2. Process (slightly different than governance) issues. ------------------------------------------------------ Moving away from the letter of their contracts, what should they have done (if anything) about open comment and forming consensus? This is vaguely making me wonder if they had evidence of WMDs....oops, wrong controversy. Assume they had no requirement for prior discussion. What, if any, requirements did they have for testing and validating their approach, given that a top-level registry is in a unique connectivity position with special privileges. 3. Internet architectural impact (slightly different than effects on innovation and/or effect on existing software). -------------------------------------------------- I think it's reasonable to state that Sitefinder, and changes of "internal" behavior, violates at least the traditional end-to-end and robustness principles. This should be considered in the spirit of the core vs end state discussion in RFC 3439, and the architectural work going into midboxes. A general question here is to what extent is it important that the Internet be consistent with its relatively informal architectural assumptions? Even among the newer technical folk, when teaching, I rarely hear anyone aware of the architecture work---they think "7 layers" is the ultimate answer [1]. [1] I spent over five years of my life in OSI research, development and promotion. We may have had the answer, but, unfortunately, we never could articulate the question. That is a lesson here 4. Is the Internet the Web? Are all Internet users people? ---------------------------------------------------------- I don't think it's unfair to say Sitefinder is web-centric. The current responses may be useful for people who can interact with it. Apparently, there are patches that will help with mail response and even anti-spamming tools. But what of other protocols, especially those intended to run without human intervention? What about failover schemes that employ DNS non-resolution as an indication that it's time to pick an alternate destination? Is the apparent trend to move from "everything over IP" to "everything over HTTP" a good one? _could_ it be a good one in well-defined subsets of the Internet? 5. Effects on innovation ------------------------ Innovation and stifling innovation has come up quite a bit. If one looks at the End-to-End Assumption, the historic perspective is that the "killer apps" appear at the edges and depend on a consistent center (e.g., web and VoIP, the latter with a QoS-consistent center [2]). Development in the core tends to be more evolutionary and subject to discussion (e.g., CIDR). Other development in the core tends to be with the implementations (e.g., faster routers and lines). [2] Remember that the access links to an ISP usually aren't the QoS problem. Once you get to the POP, voice and other delay-critical services can go onto VPNs or other QoS-engineered alternatives to the public Internet. Verisign says Sitefinder is innovative, and let's assume that it is. But, if so, it's an innovation in the core, which is not the "time-proven way". When I speak of time-proven, I certainly don't mean that there isn't innovation -- this message did NOT reach you over a 56 Kbps line between IMPs. Internet Explorer, for example, has a means of dealing with domain typos, but it is contrary to the way Sitefinder does things. IE also does it at the edge. How do we deal with potential commercial wars between the edge and core as far as competition for innovation? 6. Stability ------------ Assume that Sitefinder and the associated mechanisms are ideal. In such a case, users would expect it. Unless a large number of users learn to spel and tipe gud, these instances will be points of heavy traffic. What are the availability requirements to make the service dependable? This includes clustered servers at individual nodes, as well as distributed nodes. There has to be sufficient bandwidth to reach the nodes, and even if the node has adequate connectivity bandwidth, there are subtle congestion issues. It was pointed out that wireless implementers, used to expecting a small error message in their bandwidth-limited edge environments, are less than thrilled about getting a 17K HTML response. Remember, if these concepts prove themselves in .com and .net, users will expect them in all TLDs -- or we get to the generally undesirable situation of different behavior in different domains. Let's assume Verisign has an adequate track record of running reliable servers -- but what would be the requirements for a new operator of .com and .net for people expecting the Sitefinder functionality. In a new TLD, what has to be the support on Day 1? A very different question is whether business models associated with this service are sufficiently robust to be sure it stays present once users expect it.

2 1