September 2003 - Test - lists.nanog.org

RE: Route failures to behosting.com
by Shawn Jackson 18 Sep '03

18 Sep '03

Behosting.com is accessible from AT&T with no problems. traceroute to behosting.com (216.121.96.160), 30 hops max, 38 byte packets 1 gw (12.22.x.xxx) 1.974 ms 1.939 ms 1.983 ms 2 12.118.156.29 (12.118.156.29) 8.395 ms 6.070 ms 6.015 ms 3 gbr5-p59.sffca.ip.att.net (12.123.195.130) 8.975 ms 8.543 ms 8.453 ms 4 tbr1-p013501.sffca.ip.att.net (12.122.11.73) 9.568 ms 9.286 ms 9.276 ms 5 ggr1-p360.sffca.ip.att.net (12.123.13.65) 8.584 ms 8.544 ms 8.503 ms 6 svl-brdr-02.inet.qwest.net (205.171.1.165) 141.856 ms 142.191 ms 141.599 ms 7 svl-core-03.inet.qwest.net (205.171.14.162) 142.247 ms 144.525 ms 144.658 ms 8 svl-edge-09.inet.qwest.net (205.171.14.98) 142.824 ms 141.505 ms 137.071 ms 9 65.113.32.50 (65.113.32.50) 139.001 ms 148.024 ms 139.999 ms 10 behosting.com (216.121.96.160) 144.550 ms 135.547 ms 138.744 ms Shawn Jackson Systems Administrator Horizon USA 1190 Trademark Dr #107 Reno NV 89521 www.horizonusa.com Email: sjackson(a)horizonusa.com Phone: (775) 858-2338 (800) 325-1199 x338 -----Original Message----- From: Lou Katz [mailto:lou@metron.com] Sent: Wednesday, September 17, 2003 5:23 PM To: nanog(a)merit.edu Subject: Route failures to behosting.com I am unable to reach them via several different ISPs. It looks to my naive eyes like routes to them have vanished. Can anyone shed any light on this? -- -=[L]=-

1 0

RE: Worst design decisions?
by Shawn Solomon 18 Sep '03

18 Sep '03

The 12016 does have handles on the sides, but the documentation states not to use them for lifting purposes. Yeah, I laughed too, just before realizing that bear-hugging a 16 into position takes a bit of motivation. It is definitely one big hunk of iron (300+lbs on the shipping invoice), but I just couldn't understand why in the @%$$ useful handles weren't provided. On a side note, the scissor-jacks that came with them could lift a house. Heh. http://www.cisco.com/en/US/products/hw/routers/ps167/prod_installation_g uide09186a0080188f38.html ------------------------------------------------------------------------ -------- Warning Do not attempt to lift the chassis with the handles on the back and sides of the chassis. These handles are not designed to support the weight of the chassis, and should be used only to steady and guide the chassis while it is being inserted into or removed from an equipment rack. To reduce the risk of damage to the chassis and serious bodily injury, do not use these handles to lift or support the chassis. ------------------------------------------------------------------------ -------- -----Original Message----- From: Matt [mailto:acheron@qwest.net] Sent: Wednesday, September 17, 2003 5:43 PM To: nanog(a)merit.edu Subject: Worst design decisions? Hello all, Was doing some upgrades on a UBR7246 (to a VXR), and I got to thinking about short sighted design considerations. I was curious if any of you had some pet peeves from a design perspective to rant about. I'll start with a couple. 1) Why did Cisco design the I/O controller on the 7246 with screws in the corner, which are very difficult to get at? And worse than that, why did they not include a cheap handle on the blank in this slot? 2) Why did Cisco not include side handles on the 12000 chassis? It's a heavy chassis, and I can imagine how many techs have thrown out their back moving that chassis around. I've got a couple others in my head from 3Com and a couple of others, but I thought I'd get the ball rolling. So, what do you think?

1 0

ICANN - Formal Complaint re Verisign
by Jerry Eyers 18 Sep '03

18 Sep '03

One thing I haven't seen mentioned in all this is the incredible business monopolizing effect this move will have on the TLD's in question. It dramatically shifts the domain playing field in Verisign's favor by pointing millions of potential customers to their site(s) specifically, giving them millions of dollars in free advertising eye-time over any of the competition Jerry

5 4

OT: Interesting visuals. interesting message, 560 kb, 5 min to run (if you have a moment)
by Dr. Jeffrey Race 18 Sep '03

18 Sep '03

Interesting diversion from quotidian banalities <http://www.fdnylodd.com/BloodofHeroes.html> Jeffrey Race

1 0

VeriSign responds to complaints via press release
by Jeff Wasilko 18 Sep '03

18 Sep '03

----- Forwarded message from Dave Farber <dave(a)farber.net> ----- If this was Microsoft issuing a statement like this we would really go through the roof. Since when in the Internet do we talk with technical people AFTER the fact and AFTER the disruption. In other words BULL. Can we sue them for email disruption? Dave >Delivered-To: dfarber+(a)ux13.sp.cs.cmu.edu >Date: Wed, 17 Sep 2003 19:27:49 -0400 >From: "Wingfield, Nick" <Nick.Wingfield(a)wsj.com> >Subject: VeriSign update >To: "'dave(a)farber.net'" <dave(a)farber.net> > > >Dave, >In case it's of interest to IP... >Nick > > >=WSJ: VeriSign Responds To Complaints About New Service > >Dow Jones News Service via Dow Jones > > > By Nick Wingfield > Of THE WALL STREET JOURNAL > > > SAN FRANCISCO (Dow Jones)--VeriSign Inc. (VRSN), responding to an >outpouring >of complaints about a new service that exploits the typing errors users make >when surfing the Web, said it plans to work with technologists to remedy >disruptions the service has caused to some Internet applications like >e-mail. > > At the same time, the VeriSign service triggered a huge increase in the >amount >of traffic flowing to the Mountain View, Calif., company's Web site, a >portion >of which may be the result of a hacker attack against the company, VeriSign >said. > > (This story and related background material are available on the Journal's >Web >site, WSJ.com.) > > VeriSign on Monday introduced the service, dubbed Site Finder, which >steers >users who attempt to reach nonexistent Web addresses to a site operated by >VeriSign. The company is able to take control of the traffic because it >operates >the master list, or "registry," for all Internet addresses ending in ".com" >and >".net." > > VeriSign said it designed Site Finder as a navigational aid for Web users. >It >also receives revenue from the additional traffic through relationships with >Overture Services Inc. (OVER) and Yahoo Inc.'s (YHOO) Inktomi, which guide >users >to Web sites. > > The new VeriSign service infuriated many network operators, though, who >say it >has disrupted the functioning of e-mail and other applications. Among the >complaints about the VeriSign service is that it hurts the ability of >Internet >service providers to block "spam" sent from Internet addresses that don't >exist >- a common technique normally used to stem the flow of junk e-mail. Internet >service providers and software groups have developed patches that prevent >the >VeriSign service from working on their networks. > > In a statement Tuesday, VeriSign said it would release technical >information >on its Web site that would help network operators adapt their software so >they >could block unwanted e-mail again. "In the course of implementation, various >users asked us to modify the service to accommodate anti-spam applications," >the >company said in the statement. "Because VeriSign strongly supports >appropriate >technical measures designed to reduce unwanted spam, we are reaching out to >users and the community to make appropriate adjustments to the service." > > "We remain committed to ensuring that Site Finder improves Web navigation >and >the user experience," VeriSign added. > > Despite the controversy, VeriSign's efforts to nab control of typo-prone >Internet users appears to be having a sizable impact on the volumes of users >visiting its site. Traffic to the company's Web site on Tuesday skyrocketed >to >about 1.3 million visitors from an average of about 100,000 visitors on the >previous four Tuesdays, according to measurement firm ComScore Networks Inc. > > > Some of that may have been due to malicious - not typo - traffic. A >VeriSign >spokesman said the company experienced a "denial of service" attack on its >Web >site on Tuesday, in which hackers use computers to bombard Web sites with >traffic in hopes of overloading them. The attack appeared to subside by >Wednesday, the spokesman said. A ComScore spokesman said it's "very >unlikely" >that a denial of service attack on VeriSign had a significant impact on the >ComScore traffic figures.

3 2

Re: Root Server Operators (Re: What *are* they smoking?)
by Paul Vixie 17 Sep '03

17 Sep '03

> > i don't think so. verisign is on public record as saying that the > > reason they implemented the wildcard was to enhance the services > > offered to the internet's eyeball population, who has apparently > > been clamouring for this. > > My question is, if this was to serve some need of internet users, why > does port 25 work and not port 80? i wouldn't speak for verisign on that point even if i knew the facts (which i don't) but i'm guessing that the internet today has mostly just got web browsers on it, and verisign is principally concerned with those people. > So, I'm curious as to your opinion about the bigger issue. Maybe it > has been stated somewhere else, and if it has, please direct me to > it. I've read all of your posts about this on nanog, and you do an > excellent job of staying neutral. You point out that what Verisign is > doing is technically valid and therefore shouldn't be addressed with a > technical "solution", but you also release a patch for Bind to > accomodate obvious demand (and to save users the hassle of > implementing half-assed patches with hardcoded A records). However, > you do so without actually stating whether or not you think the > wildcards are a (policy) problem or not. let me be clear on that point, then. i've now heard some people from icann's various committees and boards say that they either were not consulted, or that they were consulted and they advised against this, and they feel rather strongly that these wildcards should not have been put in. so, there is a policy problem, which is that folks don't agree as to whether verisign is the owner or the steward for .com and .net, and folks don't agree on whose permission is needed for what. i would like to see that policy problem resolved, but i have no part in it, and i don't actually care which way it's resolved, so long as it is resolved. we all need to know whether verisign is the owner or steward, and we all need to know whose permission is needed for what, and we all need to know what to expect. resolving the policy problems will give us all those things. so, i hope that someone (else) resolves those policy problems. (if y'all need me i'll be out washing my cat.) > You point out that there is high-level ambiguity about the > relationship between DOC, ICANN, and Verisign, and about whether or > not Verisign should have the public's interest in mind. speaking as an individual, and not as a party to policy discussions between the people who need to set and follow policies in this arena, i can say: > Do you think > they should have the public's interest in mind? yes. because any tld who does not do this gives ammo to the kooks who want to set up their own alternative namespace. that would be bad for the public since it would be even more chaotic than what we have now, and chaos is expensive and painful. > And do you think the > wildcards are in the public's interest? no. i liked it better when vix.com's parent domain (com) had no wildcard, so that if someone mistyped my domain name they got a hard dns error rather than a verisign search page or mail error. > I can certainly empathize with wanting to stay neutral, but I think we > need somebody who carries substantial influence in the name resolution > community to have strong opinions about such a poor policy decision. i sure hope you find her (or him). good luck with that. see you all in san diego (usenix) next month, when i shall joyously lampoon all of this bitrot during my invited talk on the subject of internet governance.

1 0

Re: Change to .com/.net behavior
by Paul Vixie 17 Sep '03

17 Sep '03

> > ... shouldn't they get to decide this for themselves? > > Returning NXDOMAIN when a domain does not exist is a basic > requirement. Failure to do so creates security problems. It is > reasonable to require your customers to fix known breakage that > creates security problems. that sounds pretty thin. i think you stretched your reasoning too far. > VeriSign has a public trust to provide accurate domain > information for the COM and NET zones. They have decided to put their > financial interest in obscuring this information ahead of their public > trust. i'm not sure how many people inside verisign, us-DoC, and icann agree that COM and NET are a public trust, or that verisign is just a caretaker. but, given that this is in some dispute, it again seems that your customers should decide for themselves which side of the dispute they weigh in on. > Microsoft, for example, specifically designed IE to behave in a > particular way when an unregistered domain was entered. Verisigns > wildcard record is explicitly intended to break this detection. The > wildcard only works if software does not treat it as if the domain > wasn't registered even though it is not. then microsoft should act. and if it matters to you then you should act. but this is not sufficient justification to warrant a demand by you of your customers that they install a patch (what if they don't run bind?) or that they configure delegation-only for particular tld's (which ones and why not others?) > Verisign has created a business out of fooling software through > failure to return a 'no such domain' indication when there is no such > domain, in breach of their public trust. As much as Verisign was > obligated not to do this, others are obligated not to propogate the > breakage. ISPs operate DNS servers for their customers just as > Verisign operates the COM and NET domains for the public. the obligations you're speaking of are much less clear than you're saying.

6 6

FW: Sendmail 8.12.9 prescan bug (a new one) [CAN-2003-0694]
by Avery Buffington 17 Sep '03

17 Sep '03

-----Original Message----- From: Michal Zalewski [mailto:lcamtuf@dione.ids.pl] Sent: Wednesday, September 17, 2003 4:20 AM To: bugtraq(a)securityfocus.com; vulnwatch(a)securityfocus.com; full-disclosure(a)netsys.com Subject: Sendmail 8.12.9 prescan bug (a new one) [CAN-2003-0694] Hello lists, -------- Overview -------- There seems to be a remotely exploitable vulnerability in Sendmail up to and including the latest version, 8.12.9. The problem lies in prescan() function, but is not related to previous issues with this code. The primary attack vector is an indirect invocation via parseaddr(), although other routes are possible. Heap or stack structures, depending on the calling location, can be overwritten due to the ability to go past end of the input buffer in strtok()-alike routines. This is an early release, thanks to my sheer stupidity. -------------- Attack details -------------- Local exploitation on little endian Linux is confirmed to be trivial via recipient.c and sendtolist(), with a pointer overwrite leading to a neat case of free() on user-supplied data, i.e.: eip = 0x40178ae2 edx = 0x41414141 esi = 0x61616161 SEGV in chunk_free (ar_ptr=0x4022a160, p=0x81337e0) at malloc.c:3242 0x40178ae2 <chunk_free+486>: mov %esi,0xc(%edx) 0x40178ae5 <chunk_free+489>: mov %edx,0x8(%esi) Remote attack is believed to be possible. ---------------- Workaround / fix ---------------- Vendor was notified, and released an early patch attached below. There are no known workarounds. Index: parseaddr.c =================================================================== RCS file: /cvs/src/gnu/usr.sbin/sendmail/sendmail/parseaddr.c,v retrieving revision 1.16 diff -u -r1.16 parseaddr.c --- parseaddr.c 29 Mar 2003 19:44:01 -0000 1.16 +++ parseaddr.c 16 Sep 2003 17:37:26 -0000 @@ -700,7 +700,11 @@ addr[MAXNAME] = '\0'; returnnull: if (delimptr != NULL) + { + if (p > addr) + p--; *delimptr = p; + } CurEnv->e_to = saveto; return NULL; } -- ------------------------- bash$ :(){ :|:&};: -- Michal Zalewski * [http://lcamtuf.coredump.cx] Did you know that clones never use mirrors? --------------------------- 2003-09-16 21:18 --

1 0

ICANN - Formal Complaint re Verisign
by matthew-l＠itconsult.co.uk 17 Sep '03

17 Sep '03

Please find below a copy of a formal complaint I have made to ICANN today regarding Verisign's wildcard change of yesterday, which may be of interest to members of this list. The text is also available at:- http://www.itconsult.co.uk/misc/icann17sep2003.htm Best wishes, Matthew ==================== From: Matthew Richardson To: Tina Dam Subject: {18876} Formal Complaint - .com & .net wildcards cause Internet destabilisation Date: Wed, 17 Sep 2003 20:46:54 +0100 Organization: I. T. Consultancy Limited, Jersey -----BEGIN PGP SIGNED MESSAGE----- {ref: 18876} To: The Internet Corporation for Assigned Names and Numbers (ICANN) For the attention of: Tina Dam I refer to our telephone conversation of yesterday morning relating to the very recent addition of "wildcard" records to the .com & .net GTLDs by Verisign. My purpose in writing, as we discussed, is to make a formal complaint to ICANN regarding Verisign's actions, and furthermore to formally request ICANN to instruct Verisign to remove these wildcard records with immediate effect, subject only to their possible reinstatement following an appropriate period of consultation. This complaint is being made in the public interest. Specifically it is that the CHANGE in behaviour within two of the largest Internet TLDs is likely to cause serious difficulties in a number of areas. The inevitable consequence of these CHANGES is that many businesses and users involved with .com & .net domains (quite a sizeable proportion of the Internet) will be involved in varying degrees of unforeseen inconvenience, failure and expenditure. Such unexpected disruption and expense seems, at the very least, somewhat inequitable to those on the receiving end, all the more so in the absence of any notice from Verisign. This is clearly a destabilising effect on a very significant portion of the Internet as a whole, which seems to be at some variance with ICANN's ongoing responsibilities as described in your announcement of today http://www.icann.org/announcements/announcement-17sep03.htm, which states "The MoU highlights ICANN's responsibility to ensure the stability of the Internet". There may be many additional (and perhaps compelling) reasons why others might suggest that change is not good, predominantly from a privacy and data protection perspective. However this complaint deals solely with the issues of the failures caused by the unexpected change and the cost of correcting them. The change appears to have been announced by Verisign yesterday and I have seen references by them in public to the documents:- http://www.verisign.com/resources/gd/sitefinder/implementation.pdf http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf The former, dated 27 August 2003, describes their wildcard implementation, citing its conformance with their latter document, which is dated 09 September 2003. Whilst the lay reader might assume that this latter document represents some form of approved Internet standard, nothing could be further from the truth. The following are merely a few very examples of the sorts of issues which will cause failures and which will cost money to fix:- (a) Unsolicited commercial email (colloquially known as "spam"), is a serious (and increasingly serious) problem. Many email servers incorporate anti-spam protections. One commonly used method is to perform a DNS check on the sender domain prior to continuing to accept the message. If it does not exist, the email is not accepted being either delayed or permanently rejected. At a low level, this is done by issuing a DNS query for the sender domain and checking for the presence of MX or A records. Verisign's changes will cause this mechanism to fail for all non-existent .com or .net domains. (b) Verisign have installed software which answers on SMTP port 25 on the IP address returned as the A record. This software, which purports to be an email server, is not even remotely compliant with rfc2821, the current standard for SMTP email. It is clearly designed to receive email connections and reject the messages, although it remains unclear what difficulties its gross non-compliance will cause. As an aside, its ability to capture sender addresses (and should it wish in the future whole email messages) which is most likely to cause significant concern to those of a privacy protection persuasion. (c) There are likely to be many applications and services around the Internet, which utilise the results of DNS lookups to test the existence of domains under .com & .net, a method which has worked correctly since the creation of these TLDs long long ago. Many of these applications will belong to those involved in the domain registration business. The addition of wildcard records will cause all such applications to fail. This appears to be understood by clearly Verisign who state in the latter document referred to above "It is important to note that this response, though generated as the result of a wildcard, does not differ from a non-wildcard-related response. The recipient cannot determine the presence of a wildcard entry in a zone from a single response generated as a result of that wildcard". (d) Blacklists known generically as "DNSBL" have evolved from the original MAPS RBL as a means of specifying IP addresses from which email can be blocked. The addition of the wildcard record may make certain retired DNSBL spring back into life listing all addresses resulting in the incorrect rejection of incoming emails. In conclusion a change of this magnitude to the operation of two of the most major TLDs on the Internet should not have been undertaken without significant consultation and notice. I therefore urge ICANN to act promptly and decisively to remove these records in furtherance of its ongoing obligations to ensure stability of the Internet. Regards, Matthew Richardson I T Consultancy Limited Jersey Channel Islands -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAgUBP2i5aQKwLwcHEv69AQFytQQAsC/XgAdvbK/tBsIFyaiemYJneDTR9d/O FGNTvmMtUbht6RCPgpPYAv/M2I4eBIXRSVYFEQQGEok24McKjEl78n4mTi/N0pLp EUcO/UnLhwaa5Vt6SAokdqsFUFQvkl2jfDiHJ8C72JCYPaOG/KGvG9z/idotZKGh BXhaA1973gY= =JRfV -----END PGP SIGNATURE-----

1 0

Re: Change to .com/.net behavior
by Paul Vixie 17 Sep '03

17 Sep '03

> How about rewriting all DNS responses to your liking? :-) > > Like if you ask for www.register.com, you would get the A record for > www.verisign.com ? done. #fh:i386# ping -c 1 www.register.com PING www.register.com (216.21.229.101): 56 data bytes 64 bytes from 216.21.229.101: icmp_seq=0 ttl=234 time=79.703 ms --- www.register.com ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 79.703/79.703/79.703/0.000 ms #fh:i386# echo 65.205.249.60 www.register.com >>/etc/hosts #fh:i386# ping -c 1 www.register.com PING www.register.com (65.205.249.60): 56 data bytes ^C --- www.register.com ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss next? the point i'm illustrating is, as an end user, i'm in charge of my own name->address translations. > Responses for the highest bidder! that would be an interesting form of symbol democracy, if it scaled to all end users. instead we have a relatively nondemocratic namespace.

1 0