- Test - lists.nanog.org

Re: Verisign changes violates RFC2821, and spam implications
by Stewart, William C (Bill), RTSLS 17 Sep '03

17 Sep '03

Avleen Vig suggests that it's very wrong for Verisign's bad-domain catcher to begin to accept SMTP messages and just reject all recipients with 550s rather than rejecting the whole transaction with a 554. I'm glad I'm not the only one who thinks that - is there some conceivable case for which this system _would_ accept a message, e.g. postmaster(a)real-name-for-that-machine.verisign.com ? On the other hand, it has very interesting implications for spam handling. While there are bad side effects that can be caused by Verisign's claim that any non-existent domain name now exists (since it's harder to reject that mail), the Internet now has one obvious happy destination for spam from harvested addresses. If your spider bait starts leaving around alice(a)bogusdomain-alice.com ... zebra(a)bogusdomain-zebra.com and thousands of similar addresses, the harvesters are going to start catching them and sending them spam, and the less intelligent harvesters aren't going to validate the domains against Verisign's IP address, and any badly administered machines with open smtp relays are certainly not going to be checking for it, so they'll be creating SMTP sessions with Verisign. It's even more fun with dictionary attacks, where the spammer targets aaaaaa(a)bogusdomain.com through zzzzzzzzz(a)bogusdomain.com - A DNS rejection would cause a direct attacker or (more likely) a relay attacker to give up quickly, and a 554 might do that also, while rejecting all 26**8 recipients one at a time is probably just the kind of behaviour that spamware is happy to talk to all day. Now all Verisign needs to add is a teergrube function to generate its responses very slowly after the first couple of them and they'll stay tied up for months, especially since many of them won't notice that bogusdomain1.com through bogusdomain32767.com are all going to the same IP address, since that's not uncommon virtual hosting behaviour. bill.stewart at pobox.com

4 3

Re: News of ISC Developing BIND Patch
by Simon Waters 17 Sep '03

17 Sep '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: Valdis.Kletnieks(a)vt.edu > > To pull a stunt like that at the root, they'd have to get the OTHER 9 > or 10 organizations to buy in, or they'd find themselves outvotes 13 > servers to 2, or whatever the exact numbers are.... - From a purely technical perspective, DNS servers don't run ballots, so it matters not so much how many servers say something, but what they say, how long they claim it to be valid for, as well as how quickly they answer. It is much easier to give a long lived lie, than a short lived truth, in the DNS world. As such any root server operator can potentially hijack a significant amount (majority?) of Internet traffic, at least if no one notices something odd, and figures out what is going on too quickly. This is DNS security 101... A single rogue root server could be very messy to cleanup after if the person in control of the rogue server were skilled in the art (and root server operators are suppose to be so skilled to get the job). Paul is I suspect the best regular NANOG poster to judge the trustworthyness of various root server operators. And I am comforted somewhat by his faith in the Verisign employees tasked with this. However the whole episode does cast Verisign in a bad light, and IANA should presumably review whether the company is a suitable contractor. I for one believe a swift reversal of the Verisign position would earn it a lot of credit, 900 seconds later and it is all forgotten. Simon -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/aEtUGFXfHI9FVgYRAjRuAJsG1ZyxvbGaLFJk5ZszS7VF26bppgCfWD/B oya3kkWpGzgMD7dUsVGtVr4= =y111 -----END PGP SIGNATURE-----

2 1

IP telephony
by Christopher Bird 17 Sep '03

17 Sep '03

There has been much buzz of late about using IP telephony solutions in place of the more common analog based solutions. Traditional telephony has very high reliability (many years without loss of dial tone for some companies). From what I have seen in this group about networking, router behaviors, etc. it seems to me that the IP networks that exist aren't yet ready for the prime time of IP telephony. As we move buildings, my company is looking at installing an IP telephony based solution (packet switched) instead of a traditional analog based solution (circuit switched). I am worried that the reliability will likely be lower than I am used to. However the cost savings look quite compelling, so I am torn. The more I read in here about threats and attacks against IP networks and the amount of maintenance we need to have in place to keep our IP networks hanging together, the more I am concerned about the viability of an IP telephony solution. Does anyone here have any thoughts, experiences, etc. about the use of IP telephony in corporate environments? Thanks in advance Chris

4 4

Verisign insanity - Distributed non-attack
by RoDent 17 Sep '03

17 Sep '03

After reading the posts on this list about Verisign's insane behaviour regarding the .com and .net TLD wildcards, I'd like to make a suggestion: Anyone remember the old RC5, distributed.net or Seti@Home projects? If Verisign continues with this irrational behaviour I propose developing a distributed client that will inundate their wildcard hosts with invalid requests, thus making harvesting useful information from any HTTP, or SMTP traffic that they hijack nigh impossible. I nice distributed effort, a simple win32, and Unix client, and a stats based reporting system will make this a project where everyone can vote with their IP address. I've also taken a look at the BIND code myself, to see how to rid myself of these falsely reported A records, but the fact is that unless EVERYONE joins in on running such a version of bind, Verisign will still get away with it. It's ridiculous that I as an administrator have to take steps to correct the greedy self-righteousness that is the halmark of their "experiment" in an effort to get some of the FUNDAMENTALS of DNS behaviour to operate as expected. Inundating them with requests (such as the small Lynx shell script posted earlier), will force bigger ISP's to take a stance against this behaviour as well, since they'll be the ones footing the bill in terms of transparent cache servers being filled with invalid requests, sitting on expensive disc, and expiring other more cache-worthy documents, and filling up processing queues. Effectively this would amount to "denial of service" attack, but since there is nothing illegal about making an http request to an invalid hostname, Verisign will be bringing the denial of service attack upon themselves, and unfortunately dragging ISP's with them. Why ISP's haven't publically taken a stance against this yet is fascinating. I'm a mild mannered programmer/administrator by day, but blatantly monopolistic practices such as this requires decisive mass action, and makes my blood boil. There are enough issues to deal with on a day to day basis just to combat the loopholes there currently are for spammers. Having Verisign give spammers free FROM: domains to spam from has just made the task all the more unpleasant... If Verisign doesn't retract their mal-implemented "White Paper" and it's insiduous behaviour from the internet within the next week, I WILL start developing a client that allows netizens to vote with their IP's and HTTP, or SMTP traffic. I will personally put up a 100$ prize for the client that according to statistics have made the most requests to invalid .com/.net domains within the period required to get them to stop. Cheers, Roelf Diedericks Systems Programmer "I might be on the other end of a 56k modem, but I have a lot of friends with 56k modems..."

8 7

Not the best solution, but it takes VeriSign out of the loop
by Mike Damm 17 Sep '03

17 Sep '03

Who's up for creating a network of new gTLD servers? I'm sure it wouldn't be too hard to reconstruct 90% of the com/net zones from publicly available data (http://www.deleteddomains.com/newlist.shtml?cid=11673-11084 would be a good start). Constantly farming for missed zones, and maybe even querying the "real" servers for missing data. The updates would be a day or two behind the "real" zones, but once you got a good number of eyeballs looking to your servers instead of VeriSign's, you could probably convince quite a few registrars to start sending you updates too. I'm sure this breaks many an RFC, and has an unfathomable number of other problems, but I see it this way: we can complain and whine about mismanagement as much as we want, but until there is a viable alternative available their will never be a change. *hops into his fireproof undies* Comments anyone? --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com

7 6

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

17 Sep '03

> Following Internet Standards and to improve performance for all Internet > users, what if Verisign decided to start including other A records > directly in the .COM/.NET zones? > > For example, the A records for the servers for the .COM/.NET zones? funnily enough, that would work fine, since it would be in-zone glue, and would arrive in referrals, rather than arriving in answers. the zone would still be "delegation-only" according to the functionality we're releasing. > Or "interesting" sites that Verisign has a relationship with? that would not work very well for a recursive server who had declared com or net to be delegation-only. > I wouldn't be surprised if tomorrow, Verisign is the playing the victim > and calling ISC the out-of-control hooligans. that's doubtful. i've seen people here today advocate "wet teams", null routing, patches that hard coded A RR values, cutting off uncooperative root name server operators from internet connectivity, and even writing letters to congress. isc's actions are at best a minor sideshow here. the question you should be asking yourselves is, what will aol and uSoft do? will microsoft add "delegation-only" features to its recursive dns implemenation? will aol or msn enable this in the recursive servers that face their customers? i guess what i'm trying to say is, the folks who are complaining about this wildcard on nanog, are not the ones verisign was probably hoping would buy stuff. "these aren't the eyeballs you're looking for." the real action is occuring somewhere else entirely.

1 0

Re: News of ISC Developing BIND Patch
by Paul Vixie 17 Sep '03

17 Sep '03

> I trust your assessment of the DNS techs. But what about [their] bosses? the ones i've met in recent years seemed like reasonable people. > They ordered some pretty lumpy things be done with .com and .net. > Given that track record, whats to stop them from ordering [the techs] > from doing something equally lumpy. root zone content is tied up in all kinds of red tape. the root server operators won't modify it in any way; we publish only what we get from iana. iana and verisign and the united states department of commerce all have to agree on changes to it. imagine a "mexican standoff" with three people and six guns. with the ietf/iab as referee and scorekeeper, and the rootops as an interested audience. ("entertain me!") i'll say it again. nothing that happens in dot-com or dot-net has any relevance at all to the root zone, or to the root server operators.

1 0

Heads up -- potential problems in 3.7, too? [Fwd: OpenSSH Security Advisory: buffer.adv]
by Alex Lambert 17 Sep '03

17 Sep '03

3.7.1 was just released. Two patches for similar issues in a very short timeframe. Who do they think they are -- Microsoft? <grin> apl -------- Original Message -------- Subject: OpenSSH Security Advisory: buffer.adv Date: Wed, 17 Sep 2003 01:13:30 +0200 From: Markus Friedl <markus(a)openbsd.org> To: misc(a)openbsd.org This is the 2nd revision of the Advisory. This document can be found at: http://www.openssh.com/txt/buffer.adv 1. Versions affected: All versions of OpenSSH's sshd prior to 3.7.1 contain buffer management errors. It is uncertain whether these errors are potentially exploitable, however, we prefer to see bugs fixed proactively. Other implementations sharing common origin may also have these issues. 2. Solution: Upgrade to OpenSSH 3.7.1 or apply the following patch. =================================================================== Appendix A: patch for OpenSSH 3.6.1 and earlier Index: buffer.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/buffer.c,v retrieving revision 1.16 retrieving revision 1.18 diff -u -r1.16 -r1.18 --- buffer.c 26 Jun 2002 08:54:18 -0000 1.16 +++ buffer.c 16 Sep 2003 21:02:39 -0000 1.18 @@ -23,8 +23,11 @@ void buffer_init(Buffer *buffer) { - buffer->alloc = 4096; - buffer->buf = xmalloc(buffer->alloc); + const u_int len = 4096; + + buffer->alloc = 0; + buffer->buf = xmalloc(len); + buffer->alloc = len; buffer->offset = 0; buffer->end = 0; } @@ -34,8 +37,10 @@ void buffer_free(Buffer *buffer) { - memset(buffer->buf, 0, buffer->alloc); - xfree(buffer->buf); + if (buffer->alloc > 0) { + memset(buffer->buf, 0, buffer->alloc); + xfree(buffer->buf); + } } /* @@ -69,6 +74,7 @@ void * buffer_append_space(Buffer *buffer, u_int len) { + u_int newlen; void *p; if (len > 0x100000) @@ -98,11 +104,13 @@ goto restart; } /* Increase the size of the buffer and retry. */ - buffer->alloc += len + 32768; - if (buffer->alloc > 0xa00000) + + newlen = buffer->alloc + len + 32768; + if (newlen > 0xa00000) fatal("buffer_append_space: alloc %u not supported", - buffer->alloc); - buffer->buf = xrealloc(buffer->buf, buffer->alloc); + newlen); + buffer->buf = xrealloc(buffer->buf, newlen); + buffer->alloc = newlen; goto restart; /* NOTREACHED */ } Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.194 retrieving revision 1.195 diff -u -r1.194 -r1.195 --- channels.c 29 Aug 2003 10:04:36 -0000 1.194 +++ channels.c 16 Sep 2003 21:02:40 -0000 1.195 @@ -228,12 +228,13 @@ if (found == -1) { /* There are no free slots. Take last+1 slot and expand the array. */ found = channels_alloc; - channels_alloc += 10; if (channels_alloc > 10000) fatal("channel_new: internal error: channels_alloc %d " "too big.", channels_alloc); + channels = xrealloc(channels, + (channels_alloc + 10) * sizeof(Channel *)); + channels_alloc += 10; debug2("channel: expanding %d", channels_alloc); - channels = xrealloc(channels, channels_alloc * sizeof(Channel *)); for (i = found; i < channels_alloc; i++) channels[i] = NULL; } =================================================================== Appendix B: patch for OpenSSH 3.7 Index: buffer.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/buffer.c,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- buffer.c 16 Sep 2003 03:03:47 -0000 1.17 +++ buffer.c 16 Sep 2003 21:02:39 -0000 1.18 @@ -23,8 +23,11 @@ void buffer_init(Buffer *buffer) { - buffer->alloc = 4096; - buffer->buf = xmalloc(buffer->alloc); + const u_int len = 4096; + + buffer->alloc = 0; + buffer->buf = xmalloc(len); + buffer->alloc = len; buffer->offset = 0; buffer->end = 0; } @@ -34,8 +37,10 @@ void buffer_free(Buffer *buffer) { - memset(buffer->buf, 0, buffer->alloc); - xfree(buffer->buf); + if (buffer->alloc > 0) { + memset(buffer->buf, 0, buffer->alloc); + xfree(buffer->buf); + } } /* Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.194 retrieving revision 1.195 diff -u -r1.194 -r1.195 --- channels.c 29 Aug 2003 10:04:36 -0000 1.194 +++ channels.c 16 Sep 2003 21:02:40 -0000 1.195 @@ -228,12 +228,13 @@ if (found == -1) { /* There are no free slots. Take last+1 slot and expand the array. */ found = channels_alloc; - channels_alloc += 10; if (channels_alloc > 10000) fatal("channel_new: internal error: channels_alloc %d " "too big.", channels_alloc); + channels = xrealloc(channels, + (channels_alloc + 10) * sizeof(Channel *)); + channels_alloc += 10; debug2("channel: expanding %d", channels_alloc); - channels = xrealloc(channels, channels_alloc * sizeof(Channel *)); for (i = found; i < channels_alloc; i++) channels[i] = NULL; } ===================================================================

6 6

NANOG29 Topics
by Susan Harris 17 Sep '03

17 Sep '03

Greetings - here are the topics we've lined up so far for NANOG29 (Chicago, Oct. 19-21, our 2nd joint meeting with ARIN.) Stay tuned, we're still adding new talks: http://www.nanog.org/mtg-0310/topics.html Sunday Tutorials ---------------- - "Implementing a Secure Network Infrastructure" Level: Introductory (Merike Kaeo) - "Deploying IP Anycast" Level: Introductory (Kevin Miller, CMU) - "BGP Troubleshooting Techniques" Level: Introductory/Intermediate (Philip Smith, Cisco) - "MPLS Applications Overview" Level: Introductory (Ina Minei, Juniper) General Session (Monday - Tuesday) --------------------------------- - Panel: "Watching Your Router Configurations and Detecting Those Exciting Little Changes" Randy Bush, IIJ, moderator; Henry Kilmer, Terrapin Communications; John Heasley, Verio - BGP: Good MEDs Gone Bad! Danny McPherson, Arbor - Panel: "Simple Router Security, What Every ISP Router Engineer Should Know and Practice" Randy Bush, IIJ, moderator; George Jones, MITRE; Rob Thomas, Cisco/Team Cymru - "A Systematic Approach to BGP Configuration Checking" Nick Feamster and Hari Balakrishnan, MIT - "Update on Anomalous DNS Behavior" Duane Wessels, Packet Pushers - "Flawed Routers Flood University of Wisconsin Internet Time Server" Dave Plonka, University of Wisconsin - Madison - "The Blaster Worm: The View From 10,000 Feet" Jose Nazario, Arbor - "GBIC Interface Standards Support in the Telecommunications Industry" Dave Wodelet, Shaw Communications - "An Overview of the Global IPv6 Routing Table" Cathy Wittbrodt Research Forum -------------- - "Passive Internet Health Monitoring With BGP" Kenneth McGrath, Dartmouth - "AutoFocus: A Tool for Automatic Traffic Analysis" Cristian Estan, UCSD - "How to Compute Accurate Traffic Matrices for Your Network in Seconds" Yin Zhang, Matthew Roughan, Albert Greenberg, David Donoho, Nick Duffield, and Carsten Lund, AT&T Monday Evening BOFs ------------------- - ISP Security BOF IV Barry Raveendran Greene, Cisco, moderator

1 0

RE: Delivery Status Notification (Failure)
by Mike Damm 16 Sep '03

16 Sep '03

Who's up for null routing all of Merrill Lynch? (See VeriSign thread to find humor) On a serious note, anyone have any contacts there? --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com -----Original Message----- From: Haesu [mailto:haesu@towardex.com] Sent: Tuesday, September 16, 2003 4:05 PM To: Michel Py; nanog(a)merit.edu Subject: Re: Delivery Status Notification (Failure) I'm seeing the same... -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu(a)towardex.com Cell: (978) 394-2867 On Tue, Sep 16, 2003 at 03:51:00PM -0700, Michel Py wrote: > > Mee too. > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Mike Damm > Sent: Tuesday, September 16, 2003 3:17 PM > To: nanog(a)merit.edu > Subject: FW: Delivery Status Notification (Failure) > > > Is anyone else seeing a sort of mail loop issue at ml.com? > I'm getting odd bounces to list postings as well as a few duplicates of > list > mail. > > -Mike > > --- > Michael Damm, MIS Department, Irwin Research & Development > V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com > > > -----Original Message----- > From: postmaster(a)win.ml.com [mailto:postmaster@win.ml.com] > Sent: Tuesday, September 16, 2003 2:46 PM > To: MikeD(a)irwinresearch.com > Subject: Delivery Status Notification (Failure) > > This is an automatically generated Delivery Status Notification. > > Unable to deliver message to the following recipients, because the > message > was forwarded more than the maximum allowed times. This could indicate a > mail loop. > > nanog(a)merit.edu > MikeD(a)irwinresearch.com > ahu(a)ds9a.nl > > >

1 0