Re: Wildcards: ICANN and IAB posted their commentaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 Sep 2003 [EMAIL PROTECTED] wrote: > http://www.icann.org/announcements/advisory-19sep03.htm Folks, In regards to the statement above, the Security and Stability Advisory Committee is sincerely interested in your feedback regarding this issue. We are currently working on a report that details the impacts of wildcards at the TLD level, and elsewhere as appropriate. I would like to request that you restrict your comments to actual operational issues. That will help ensure that they get due consideration. We're most interested in issues related to things that worked before, but don't now; and particularly interested in non-obvious cases. Of course, if you have other points of interest on this topic, we're all ears. The e-mail address for your feedback is [EMAIL PROTECTED] Doug -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/a9//yIakK9Wy8PsRAkQqAJwPXQzltTL4Kp4NRfSJR56gwBbdgQCg+WOc Py1DIywm8FKhA3Q/v4XxrmY= =jdSM -END PGP SIGNATURE-
Re: Worst design decisions?
Frank wrote: On Thu, 2003-09-18 at 00:43, Matt wrote: 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. the orginal GSR blanks came without handles. They were also put in tight as ***. For days after, your fingers would have the imprints of the little screws on them. I once use my socks to protect my fingers when I was pulling them out. Frank You grabbed another one from that chassis I hadn't considered right away (although I do now). Yes, that was extremely annoying - I snapped a screw once on an old 5800 chassis with the same design flaw.
Re: Worst design decisions?
Casassa, Nathan wrote: The scissor-jack you are referring to that comes with the 12016 also doubles as an excellent coffee table in our office... Nathan -Original Message- From: Shawn Solomon [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 9:44 PM To: Matt; [EMAIL PROTECTED] Subject: RE: Worst design decisions? 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:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 5:43 PM To: [EMAIL PROTECTED] 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? The one I was ranting about was a 12008, but I digress.
Wildcards: ICANN and IAB posted their commentaries
You can find them here: http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html http://www.icann.org/announcements/advisory-19sep03.htm I've just checked that VeriSign has not voluntarily suspend the service Best Roque Ing.Roque Gagliano [EMAIL PROTECTED]
Re: Providers removing blocks on port 135?
> > Why do you get to decide that, I can't, from a hotel room, call my ISP and > > put up a web server on my dialup connection so someone behind a firewall > > can retrieve a document I desperately need to get to them? Why > > _SHOULDN'T_ > > I run a web server to do this over a dialup connection? Why do you get when scp or ftp over an ssh tunnel are much easier/lighter weight? or you could hand out ASNs and run third-party BGP from your hotel room back to the trusted core... there are lots of ways to get your critical content to the right party, some are more cost effective than others. The name "Rube Goldburg" comes to mind here... > The distinction may be blurrier these days, but there *is* a difference > between networking and internetworking. true enough. --bill
RE: Worst design decisions?
> overdesigned rather than poorly designed. even if nobody > can use it, it's just an extraneous feature. an atm built > into the concrete that you'd have to stop short of and > get out of your car to use. now that would be poorly > designed. Do you mean overdesigned in the sense that because that atm has features that wouldn't be needed in it's current location, that it shouldn't have those features? What about just making inventory tracking easier? (eg. "We have 32 ATMs that are all featurewise identical and they're all interchangeable" vs. "We have 22 ATMS with feature X and 10 w/o feature X") Now, to get it somewhat related to network stuff: s/atm/router/ s/features/capabilities/ s/location/network function/ \
RE: routing issue?
thanks to everyone who responded on/off list. The bad /24 announcement is now gone (pfm :) ) . Just seeing the /8 now. Keith Wallace Director, Telecommunications PC Connection Services [EMAIL PROTECTED] dot com The information in this email, and subsequent attachments, may contain confidential information that is intended solely for the attention and use of the named addressee(s). This message or any part thereof must not be disclosed, copied, distributed or retained by any person without authorization from the above named sender. -Original Message- From: Wallace Keith Sent: Friday, September 19, 2003 4:15 PM To: [EMAIL PROTECTED] Subject: routing issue? Can anyone reach the 38.221.129/24 range?I'm seeing this announced as a /24 by L3, but looks like it should be a /8 from Cogent(PSI). Just looking for another viewpoint. tnx. Keith
Re: Worst design decisions?
It's usually a legal risk deferrer decision to buy the ATM casing with Braille. Someone pointed out that Drive-Ups and Walk-Ups are the same, which it true for the internals but not Drive-Ups casing and moldings, which are adjusted for the average eye level of a person in a car, plus recessed, tiled monitors, etc. Basically, it costs x,xxx.xx to get the casing with Braille, and legal risk is valued at xx,xxx.xx (i.e. someone suing them because it doesn't have Braille). Better safe then sorry in risk management. I wouldn't view this is a lapse in deign decision, more of an obscure design decision. overdesigned rather than poorly designed. even if nobody can use it, it's just an extraneous feature. an atm built into the concrete that you'd have to stop short of and get out of your car to use. now that would be poorly designed. s.
Re: routing issue?
On Fri, Sep 19, 2003 at 04:15:20AM -0400, [EMAIL PROTECTED] wrote: > > Can anyone reach the 38.221.129/24 range?I'm seeing this announced as > a /24 by L3, but looks like it should be a /8 from Cogent(PSI). > Just looking for another viewpoint. tnx. from uunet: traceroute to 38.221.129.1 (38.221.129.1), 30 hops max, 38 byte packets 6 POS7-0.BR1.NYC9.ALTER.NET (152.63.18.221) 6.436 ms 6.135 ms 6.355 ms 7 204.6.134.170 (204.6.134.170) 6.767 ms 6.508 ms 6.351 ms 8 p14-0.core01.jfk01.atlas.psi.net (154.54.1.197) 6.634 ms 9.730 ms 10.325 ms 9 p12-0.core01.jfk02.atlas.cogentco.com (66.28.4.10) 7.470 ms 7.191 ms 6.894 ms 10 p4-0.core02.dca01.atlas.cogentco.com (66.28.4.81) 13.017 ms 12.913 ms 12.816 ms 11 p14-0.core01.atl01.atlas.cogentco.com (66.28.4.161) 25.800 ms 42.129 ms 26.144 ms 12 g0-2.na01.b000447-0.atl01.atlas.cogentco.com (66.250.11.78) 26.008 ms 26.219 ms 25.916 ms 13 38.221.129.1 (38.221.129.1) 24.880 ms 24.784 ms 24.889 ms -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
RE: Worst design decisions?
Scott Granados <[EMAIL PROTECTED]> 9/19/03 1:36:39 PM >>> > >Actually, not what I've heard. I have a contact at a large east coast >bank who told me they were charged extra for Braille per ATM. I had >assumed for years it was a case of build them all one way only to save >cost. But in fact this is not the case. > >At least for the type they use. Even if banks have to pay extra for Braille they're going to do it. Banks have a phobia regarding lawsuits or being written up during an audit. This phobia causes them to do things that don't necessarily make a lot of sense to normal people. Operationally speaking (sort of), any of you who work for banks and have had to sit through network audits performed by idiots know what I'm talking about. Sometimes these network audits are performed by clueless monkeys who make 'suggestions' that have no basis in reality or logic but we end up having to follow their recommendations for fear of being written up during the next audit! Insanity... John --
routing issue?
Can anyone reach the 38.221.129/24 range?I'm seeing this announced as a /24 by L3, but looks like it should be a /8 from Cogent(PSI). Just looking for another viewpoint. tnx. Keith
Re: Providers removing blocks on port 135?
Owen DeLong wrote: Yes. I responded to this in a previous post. We must do what we must do temporarily to keep things running. However, breaking the net is not a long term solution. We must work to solve the underlying problem or it just becomes an arms-race where eventually, no services are useful. I agree, and as a point of fact, many ISP's allow their users to opt out of spam. The ability to opt out of port filtering is a little more difficult, but it is not impossible. Most authentication methods designed have support for telling connection equipment what security lists to use and how to treat a specific user. Some systems, like mine, do not run authentication models that support this, but I consider it very wise to change. In my case, I will maintain a filter anywhere in the network that it is required in order to help protect the network and the users who rely upon the network. Currently, estimates show that removing port 135 at this junction would allow the current Blaster infected users to become infected with Nachi/Welchia which has more network impact. Some segments, despite blocks, have already had small outbreaks which we had to irradicate. In addition, dialups have very little bandwidth to begin with. The amount of traffic generated on icmp and 135 is currently high enough to severly cripple connectivity on an unprotected dialup account. I do agree that it is a temporary measure. Yet, one must remember that each network has it's own definitions of temporary, drastic, and appropriate. I now return you to contacting those infected users in your network. :) -Jack
RE: Worst design decisions?
> 2. The BAT csu/dsu, a cheap T1 csu/dsu which used red LED's to indicate > that all was well (or was it green to indicate an alarm?) As admitted by them, whatever cheap LED's they could by at Fry's on deep discount. No, I am not kidding. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: Worst design decisions?
It's usually a legal risk deferrer decision to buy the ATM casing with Braille. Someone pointed out that Drive-Ups and Walk-Ups are the same, which it true for the internals but not Drive-Ups casing and moldings, which are adjusted for the average eye level of a person in a car, plus recessed, tiled monitors, etc. Basically, it costs x,xxx.xx to get the casing with Braille, and legal risk is valued at xx,xxx.xx (i.e. someone suing them because it doesn't have Braille). Better safe then sorry in risk management. I wouldn't view this is a lapse in deign decision, more of an obscure design decision. Shawn Jackson Systems Administrator Horizon USA 1190 Trademark Dr #107 Reno NV 89521 www.horizonusa.com Email: [EMAIL PROTECTED] Phone: (775) 858-2338 (800) 325-1199 x338 -Original Message- From: Damian Gerow [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 11:34 AM To: [EMAIL PROTECTED] Subject: Re: Worst design decisions? Thus spake Mike Donahue ([EMAIL PROTECTED]) [19/09/03 15:28]: > Hi.. I might have missed the post, but braille on drive through has zero to > do with a design mistake - it's practicality. The ATM manufacturer doesn't > put out a "drive-through" and "walk-up" model - it puts out one, and then > it's up to whomever to mount it. Simpler just to put braille on the kit and > ship, and not worry about it. But the bank, who chooses to mount the Braille-enabled machine as drive through, orders the Braille added, do they not? (As to whether or not this is a good idea, I'm keeping away from.)
RE: Worst design decisions?
Actually, not what I've heard. I have a contact at a large east coast bank who told me they were charged extra for Braille per ATM. I had assumed for years it was a case of build them all one way only to save cost. But in fact this is not the case. At least for the type they use. On Fri, 19 Sep 2003, Mike Donahue wrote: > > >At 04:24 PM 9/18/2003, [EMAIL PROTECTED] wrote: > > >> The US Congress. > >> "can you say ADA - sure you can" - Fred Rodgers > >> > >>> Who thought it was a good idea to put braille on the drive up atms? > > >While I don't know if the person in question was blind or not, I *have* > seen someone use a >drive-up ATM from the back seat of a car. > > >jc > > Hi.. I might have missed the post, but braille on drive through has zero to > do with a design mistake - it's practicality. The ATM manufacturer doesn't > put out a "drive-through" and "walk-up" model - it puts out one, and then > it's up to whomever to mount it. Simpler just to put braille on the kit and > ship, and not worry about it. > > Mike >
Re: Worst design decisions?
Thus spake Mike Donahue ([EMAIL PROTECTED]) [19/09/03 15:28]: > Hi.. I might have missed the post, but braille on drive through has zero to > do with a design mistake - it's practicality. The ATM manufacturer doesn't > put out a "drive-through" and "walk-up" model - it puts out one, and then > it's up to whomever to mount it. Simpler just to put braille on the kit and > ship, and not worry about it. But the bank, who chooses to mount the Braille-enabled machine as drive through, orders the Braille added, do they not? (As to whether or not this is a good idea, I'm keeping away from.)
RE: Worst design decisions?
>At 04:24 PM 9/18/2003, [EMAIL PROTECTED] wrote: >> The US Congress. >> "can you say ADA - sure you can" - Fred Rodgers >> >>> Who thought it was a good idea to put braille on the drive up atms? >While I don't know if the person in question was blind or not, I *have* seen someone use a >drive-up ATM from the back seat of a car. >jc Hi.. I might have missed the post, but braille on drive through has zero to do with a design mistake - it's practicality. The ATM manufacturer doesn't put out a "drive-through" and "walk-up" model - it puts out one, and then it's up to whomever to mount it. Simpler just to put braille on the kit and ship, and not worry about it. Mike
Re: Worst design decisions?
On Fri, 19 Sep 2003 12:08:33 PDT, Scott Granados said: > noise anyway. So that someone looking over your shoulder will still be > there unless you've memorized the prompts on your local atm, a possibility > granted. Works for my dad - though he did have to call the bank once, turned out they had added a "Select English or Spanish" screen at the start pgp0.pgp Description: PGP signature
RE: Providers removing blocks on port 135?
> Why do you get to decide that, I can't, from a hotel room, call my ISP and
> put up a web server on my dialup connection so someone behind a firewall
> can retrieve a document I desperately need to get to them? Why
> _SHOULDN'T_
> I run a web server to do this over a dialup connection? Why do you get
> to dictate to _ANYONE_ what things they can and can't do with their most
> portable internet access? How can you say that it is negligent to refuse
> to DOS your customers unless they request it? (blocking traffic to me
> that I want is every bit as much a denial of service as flooding my link).
The distinction may be blurrier these days, but there *is* a difference
between networking and internetworking. Whereas I'd agree that
interconnections
between networks be unencumbered to the greatest degree possible, the
administrator
of a network can be slightly more draconian in order to keep the network
running
smoothly.
This statement applies, IMHO, to any provider who sells service to
individual
users. It may be a huge wide area dialup network, but it's still a network,
in which the average customer is not a professional network administrator
but
rather a user of indeterminate knowledge level.
Now, if as an ISP you operate an internetwork ("network of networks") and a
network of users, the challenge is obviously how do you draw the distinction
between user/customers and network/customers. I think it's do-able (DHCP
being
one criteria that comes to mind), but there there are a lot of permutations
to
consider.
Re: Worst design decisions?
Just to clerify, since I've gotten a ton of these. I'm totally blind have been for 28 years. Braille on walk up machines, makes good sense. As does it on lifts and microwave oven buttons etc. It does not make good sense on airplane lights and it makes less sense on drive up atms. Especialy when you think it through long enough and if someone needs to use braille chances are they are visually impaired enough to not be able to read the screens at all. Thus when the atm doesn't speak back to you as many still don't your not sure what prompt your at. Many do speak in larger cities, with braille makes them very useful. But in a car again, generally the voice will be low enough, for obvious security ; and other reasons you won't hear it over the car and surround noise anyway. So that someone looking over your shoulder will still be there unless you've memorized the prompts on your local atm, a possibility granted. Its just a problem that hasn't been well thought out and baddly engineered! On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote: > On Thu, 18 Sep 2003 16:14:39 PDT, Scott Granados said: > > > Who thought it was a good idea to put braille on the drive up atms? > > My dad's legally blind. That braille makes it possible for him to get cash > (either from the back seat or step out and walk up) if somebody's > giving him a ride, without him having to give his card and PIN to > somebody else. >
Re: apathy (was Re: .ORG problems this evening)
On Fri, Sep 19, 2003 at 01:36:41PM -0400, Todd Vierling wrote: > > On Fri, 19 Sep 2003, Rodney Joffe wrote: > > : You started from a point of having no idea that UltraDNS used anycast, > : confirmed for everyone in your second email that you had no clue about > : how anycast worked, > > Please stop the bellicose, holier-than-thou attitude because you feel like > assuming that I don't have networking experience. It's getting tiresome. > I apologize for whatever I've done to offend you. On behalf of the entire NANOG community, please stop pretending that you DO have a clue just because you believe people shouldn't assume you don't. Trust me when I say that is is no longer an assumption. Please also do not mistake apathy for annoyance at your continued incessant whining about anycast and UltraDNS. You don't have anything more useful to say, so please do us all a favor and just stop now. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Worst design decisions?
RJ45 connectors: Nasty fiddly things that never seem to work the first time you wire them up. (snip, curse, try again...) Chris -- Chris Horry "Don't submit to stupid rules, [EMAIL PROTECTED] Be yourself and not a fool. PGP: DSA/2B4C654E Don't accept average habits, Amateur Radio: KG4TSM Open your heart and push the limits."
Re: Nothing like viruses with bugs in them (Swen)
We are also filtering on the following content line: *Run attached file. Choose Yes on displayed dialog box.* (sigh) It does run counter to the sentiments expressed in the mail sig though... Related to Mr. Bellovin's latest note, how are operators (and abuse desks) dealing with the bizarre behavior of some recent mailers that send "forwards" as obviously W32-readable-only attachments? --chuck goolsbee -- __ There's only so much stupidity you can compensate for; there comes a point where you compensate for so much stupidity that it starts to cause problems for the people who actually think in a normal way. -Bill, digital.forest tech support
Re: Nothing like viruses with bugs in them (Swen)
In message <[EMAIL PROTECTED]>, "Mr. James W. Laferriere" writes: > > Hello All , > >On Fri, 19 Sep 2003, Brian Bruns wrote: >> These are exim filters which catch the damn thing when the antivirus >> software misses it. Hopefully it might be useful. It was taken from >> http://pkierski.republika.pl/filtry.shtml. >...snipped nice exim filters... > Is there an example of a procmail filter for this bugger ? > Tia , JimL Here's what I use to eliminate trash on my personal incoming mail. (I run NetBSD; I'm not likely to find .exe's useful...) MIMEINFO=`/usr/pkg/bin/reformime -i` :0 * MIMEINFO ?? ^content-name:.+[~.](asd|bat|chm|cmd|com|dll|exe|hlp|hta|js|jse|lnk|ocx|pif|scr|shb|shm|shs|vb|vbe|vbs|vbx|vxd|wsf|wsh)$ /dev/null No warranties, expressed or implied. --Steve Bellovin, http://www.research.att.com/~smb
RE: Providers removing blocks on port 135?
I disagree. In my opinion a NSP shouldn't filter traffic unless one of its customers requests it. However I strongly believe that an ISP (where it's customers are Joe Blow average citizen and Susy Homemaker) should take every reasonable step to protect it's users from malicious traffic and that includes filtering ports. For example I have no reservation about NATing basic dialup users. I also have no problem with filtering ports for services they shouldn't be running on a dialup connection (HTTP, FTP, DNS) or for services that IMHO have no business on the public internet (including every single Microsoft port I can identify). To not do so is IMHO to run a network in an extremely negligent manner. Why do you get to decide that, I can't, from a hotel room, call my ISP and put up a web server on my dialup connection so someone behind a firewall can retrieve a document I desperately need to get to them? Why _SHOULDN'T_ I run a web server to do this over a dialup connection? Why do you get to dictate to _ANYONE_ what things they can and can't do with their most portable internet access? How can you say that it is negligent to refuse to DOS your customers unless they request it? (blocking traffic to me that I want is every bit as much a denial of service as flooding my link). We do this very thing with email. We filter known malicious messages, attachments, and spam from email. I don't think there's a reasonable person among us that can complain about that. Why not do it to network traffic then? If we should allow every bit of traffic to pass unmolested by ACLs then we should allow all email to pass by unmolested by anti-virus and spam checks. It's a two-way street. I leave it to the community to decide whether I am a reasonable person or not, but, generally, I tend to think that I am viewed as such. However, I would complain about the parctices you describe above if I was your customer. If I ask you to filter SPAM, fine. If I ask you not to filter SPAM, then I should receive every email addressed to me. If I cannot, then, I won't be your customer. As far as I'm concerned, if an ISP wants to run anti-virus or spam-checks, they should run them as an opt-in value added service, _NOT_ as a "we're deleting your mail for you whether you like it or not" thing. On the other hand, what's a provider to do when their access hardware can't deal with a pathological set of flows or arp entries? There isn't [snip] A good point. Yes. I responded to this in a previous post. We must do what we must do temporarily to keep things running. However, breaking the net is not a long term solution. We must work to solve the underlying problem or it just becomes an arms-race where eventually, no services are useful. Owen
RE: Providers removing blocks on port 135?
I agree. In my opinion, at this point, the larger issue that we really need to find a way to address is to force a recall on the Exploding Pinto and get real product liability available to the victims. Not just the moron who bought the Exploding Pinto knowing it would probably explode, who, actually should have some culpability, but, more importantly, there should be actual liability on the part of the manufacturer and the reckless operator to the innocent bystander victims (ISPs, Web sites, etc.) that are forced to try to repair or work around the damage, handle the traffic, etc. The Virus-of-the-week club is not going to go away until somebody gets a multi-million dollar judgement against Micr0$0ft for the damage inflicted by their Exploding Pinto, or, until businesses start to see that there is liability for running unpatched windows systems to the tune of "If you keep driving your Exploding Pinto, you may have to pay $$$ to the victims of the explosion when it occurs." Case 1 will lead Micr0$0ft to start rethinking some of it's less secure design decisions. Case 2 will lead businesses to evaluate whether Windows is _REALLY_ a cost effective choice or not. Until at least one, preferably both of these things happens, we are going to be stuck with the consequences of other people choosing to run Whine-Doze whether we run it, or even want to know that anyone runs it or not. Owen --On Friday, September 19, 2003 10:32 AM -0700 Matthew Kaufman <[EMAIL PROTECTED]> wrote: Well, we could start by having every ISP do what we do, which is to find worm-infected customers inside our network and get them patched or turned off. But that's a lot of work. (Especially when you've got a new worm to track down every week) The scary/unfortunate part to me is that these things never seem to go away... Check your web server's log for the last hit from Code Red, for instance. (6 minutes ago, from 203.59.48.139, on the server I just checked) Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: Owen DeLong [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:23 AM To: Matthew Kaufman; 'Jack Bates'; 'Adam Hall' Cc: [EMAIL PROTECTED] Subject: RE: Providers removing blocks on port 135? OK... Obviously, you need to do what you need to do to keep things running. However, that should be a temporary crisis response. If your equipment is getting DOS'd for more than a few months, we need to find a way to fix a bigger problem. Permanently breaking some service (regardless of what we think of it. Personally, I'll be glad to see M$ go down in flames) is _NOT_ the correct answer. Owen
Re: Worst design decisions?
In a message written on Thu, Sep 18, 2003 at 03:53:44PM -0700, Ben Browning wrote: > Cisco V-notched power cables - Design "feature" geared around getting > suckers to buy a power cable for 45USD. Uh, you might want to be careful with these connections. You'll note the IEC-320 C13/C14 connectors (eg, what you find on PC's) are 15 Amps, but only 65 degC rated. The IEC-320 C15/C16 (with the notch) are also 15 Amps, but are rated to a pin temperature of 120 degC. I doubt Cisco did it to be a PITA, electrical codes probably required it for some reason. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: apathy (was Re: .ORG problems this evening)
On Fri, 19 Sep 2003, Rodney Joffe wrote:
: You started from a point of having no idea that UltraDNS used anycast,
: confirmed for everyone in your second email that you had no clue about
: how anycast worked,
Please stop the bellicose, holier-than-thou attitude because you feel like
assuming that I don't have networking experience. It's getting tiresome.
I apologize for whatever I've done to offend you.
What I didn't know at first was that UltraDNS's system was based on anycast.
Yes, it was my oversight, probably due to my own complacency with the gTLDs
Just Working for so long. Once I was notified of that fact, my perspective
on the problem changed quite a bit.
I do know how anycast routing works, and that it failed miserably in this
particular case. The implementation failure specifics are not my concern on
this point; the simple fact is that a critical gTLD resource failed.
Blindly trusting that the all-anycast implementation in use will work
"better" in the future seemed a rather bad idea to me in the context of a
gTLD. I was trying to figure out, with the help of others who have been far
more gracious, what possibilities exist that could help keep the failure
from happening again -- outside the scope of this particular anycast
implementation.
: But it's really just that other people actually take time to research
: issues before mouthing off.
Actually, my first few requests for corroborating information ("research")
received several mouthing-off responses. Much of this thread has required
me to fend off rather improper personal attacks -- this one included -- from
people such as yourself, while at the same time attempting to get assistance
to analyze a difficult to see, corner case problem with a critical resource.
I have apologized offlist to a few people whose heated remarks to me
received heated messages in response, and I apologize to all on-list right
now. That is not appropriate here in either direction.
: In the interim, feel free to post your operational experience
Ultimatum demands like this are just not called for, and I will not be a
party to it. However, I'm happy to discuss it offlist with anyone who may
be interested; there are business-vs.-personal reasons that I cannot discuss
this on-list.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
RE: Providers removing blocks on port 135?
On Fri, 19 Sep 2003, Matthew Kaufman wrote: > > I agree entirely with this. You shouldn't call yourself an ISP unless you > can transport the whole Internet, including those "bad Microsoft ports", > between the world and your customers. I disagree. In my opinion a NSP shouldn't filter traffic unless one of its customers requests it. However I strongly believe that an ISP (where it's customers are Joe Blow average citizen and Susy Homemaker) should take every reasonable step to protect it's users from malicious traffic and that includes filtering ports. For example I have no reservation about NATing basic dialup users. I also have no problem with filtering ports for services they shouldn't be running on a dialup connection (HTTP, FTP, DNS) or for services that IMHO have no business on the public internet (including every single Microsoft port I can identify). To not do so is IMHO to run a network in an extremely negligent manner. We do this very thing with email. We filter known malicious messages, attachments, and spam from email. I don't think there's a reasonable person among us that can complain about that. Why not do it to network traffic then? If we should allow every bit of traffic to pass unmolested by ACLs then we should allow all email to pass by unmolested by anti-virus and spam checks. It's a two-way street. > On the other hand, what's a provider to do when their access hardware can't > deal with a pathological set of flows or arp entries? There isn't a good > business case to forklift out your DSLAMs and every customer's matching CPE > when a couple of ACLs will fix the problem. For that matter, there isn't a > very good business case for transporting Nachi's ICMP floods across an > international backbone network when you can do a bit of rate-limiting and > cut your pipe requirements by 10-20%. A good point. Justin
RE: Providers removing blocks on port 135?
Well, we could start by having every ISP do what we do, which is to find worm-infected customers inside our network and get them patched or turned off. But that's a lot of work. (Especially when you've got a new worm to track down every week) The scary/unfortunate part to me is that these things never seem to go away... Check your web server's log for the last hit from Code Red, for instance. (6 minutes ago, from 203.59.48.139, on the server I just checked) Matthew Kaufman [EMAIL PROTECTED] > -Original Message- > From: Owen DeLong [mailto:[EMAIL PROTECTED] > Sent: Friday, September 19, 2003 10:23 AM > To: Matthew Kaufman; 'Jack Bates'; 'Adam Hall' > Cc: [EMAIL PROTECTED] > Subject: RE: Providers removing blocks on port 135? > > > OK... Obviously, you need to do what you need to do to keep things > running. However, that should be a temporary crisis > response. If your > equipment is getting DOS'd for more than a few months, we need to find > a way to fix a bigger problem. Permanently breaking some service > (regardless > of what we think of it. Personally, I'll be glad to see M$ > go down in > flames) > is _NOT_ the correct answer. > > Owen >
RE: Providers removing blocks on port 135?
OK... Obviously, you need to do what you need to do to keep things running. However, that should be a temporary crisis response. If your equipment is getting DOS'd for more than a few months, we need to find a way to fix a bigger problem. Permanently breaking some service (regardless of what we think of it. Personally, I'll be glad to see M$ go down in flames) is _NOT_ the correct answer. Owen --On Friday, September 19, 2003 10:14 AM -0700 Matthew Kaufman <[EMAIL PROTECTED]> wrote: I agree entirely with this. You shouldn't call yourself an ISP unless you can transport the whole Internet, including those "bad Microsoft ports", between the world and your customers. On the other hand, what's a provider to do when their access hardware can't deal with a pathological set of flows or arp entries? There isn't a good business case to forklift out your DSLAMs and every customer's matching CPE when a couple of ACLs will fix the problem. For that matter, there isn't a very good business case for transporting Nachi's ICMP floods across an international backbone network when you can do a bit of rate-limiting and cut your pipe requirements by 10-20%. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Owen DeLong Sent: Friday, September 19, 2003 10:03 AM To: Jack Bates; Adam Hall Cc: '[EMAIL PROTECTED]' Subject: Re: Providers removing blocks on port 135? FWIW, my opinion is that blocking this at the customer edge per customer request is fine. Any other blocking by an ISP is damage and should be routed around like any other internet damage. Owen
Re: Nothing like viruses with bugs in them (Swen)
You should be able to take the match parts of the exim filter and adapt them
to procmail. I'm not that familiar with procmail, so I'm not sure, but here
are the primary things the filters look for:
content type: multipart/mixed; boundary=.[a-z]{6}
message body: September 200[23], Cumulative Patch
and
content type: multipart/alternative;
content type: "boundary=.[a-z]{6}
message body: iframe src=3D.cid:.*height=3D0.* width=3D0.*/iframe
Maybe someone out there with procmail experience could post procmail rules
based on this?
--
Brian Bruns
The Summit Open Source Development Group
Open Solutions For A Closed World / Anti-Spam Resources
http://www.2mbit.com
ICQ: 8077511
- Original Message -
From: "Mr. James W. Laferriere" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 19, 2003 1:07 PM
Subject: Re: Nothing like viruses with bugs in them (Swen)
>
> Hello All ,
>
> On Fri, 19 Sep 2003, Brian Bruns wrote:
> > These are exim filters which catch the damn thing when the antivirus
> > software misses it. Hopefully it might be useful. It was taken from
> > http://pkierski.republika.pl/filtry.shtml.
> ...snipped nice exim filters...
> Is there an example of a procmail filter for this bugger ?
> Tia , JimL
>
> > - Original Message -
> > From: "Mark Radabaugh" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Friday, September 19, 2003 12:03 PM
> > Subject: Nothing like viruses with bugs in them (Swen)
> > > Seems like this virus/worm has a bug where it will occasionally send
out 1
> > > byte attachments rather than the correct worm payload. Since the
virus
> > is
> > > not truly attached it tends to pass through e-mail virus scanners.
> > > It's causing a fair amount of end user confusion today -- lots of 'why
is
> > > your/my virus scanner not working?' questions.
> --
>
+--+
>| James W. Laferriere | SystemTechniques | Give me VMS
|
>| NetworkEngineer | P.O. Box 854 | Give me Linux
|
>| [EMAIL PROTECTED] | Coudersport PA 16915 | only on AXP
|
>
+--+
>
Re: Worst design decisions?
On Thu, 18 Sep 2003, Ben Browning wrote: > > Cisco V-notched power cables - Design "feature" geared around getting > suckers to buy a power cable for 45USD. No! those are great!! you get to yell at the poor sap that uses your Cisco power cable on their monitor! :) And when they do, and you can't get it back, or lose it, just grab their sun's power cable and cut a notch in the right end with your poocket knife :) -Chris
RE: Providers removing blocks on port 135?
I agree entirely with this. You shouldn't call yourself an ISP unless you can transport the whole Internet, including those "bad Microsoft ports", between the world and your customers. On the other hand, what's a provider to do when their access hardware can't deal with a pathological set of flows or arp entries? There isn't a good business case to forklift out your DSLAMs and every customer's matching CPE when a couple of ACLs will fix the problem. For that matter, there isn't a very good business case for transporting Nachi's ICMP floods across an international backbone network when you can do a bit of rate-limiting and cut your pipe requirements by 10-20%. Matthew Kaufman [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Owen DeLong > Sent: Friday, September 19, 2003 10:03 AM > To: Jack Bates; Adam Hall > Cc: '[EMAIL PROTECTED]' > Subject: Re: Providers removing blocks on port 135? > > > > FWIW, my opinion is that blocking this at the customer edge > per customer request is fine. Any other blocking by an ISP > is damage and should be routed around like any other internet damage. > > Owen >
Re: Nothing like viruses with bugs in them (Swen)
Hello All , On Fri, 19 Sep 2003, Brian Bruns wrote: > These are exim filters which catch the damn thing when the antivirus > software misses it. Hopefully it might be useful. It was taken from > http://pkierski.republika.pl/filtry.shtml. ...snipped nice exim filters... Is there an example of a procmail filter for this bugger ? Tia , JimL > - Original Message - > From: "Mark Radabaugh" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, September 19, 2003 12:03 PM > Subject: Nothing like viruses with bugs in them (Swen) > > Seems like this virus/worm has a bug where it will occasionally send out 1 > > byte attachments rather than the correct worm payload. Since the virus > is > > not truly attached it tends to pass through e-mail virus scanners. > > It's causing a fair amount of end user confusion today -- lots of 'why is > > your/my virus scanner not working?' questions. -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkEngineer | P.O. Box 854 | Give me Linux | | [EMAIL PROTECTED] | Coudersport PA 16915 | only on AXP | +--+
Re: Providers removing blocks on port 135?
FWIW, my opinion is that blocking this at the customer edge per customer request is fine. Any other blocking by an ISP is damage and should be routed around like any other internet damage. Owen
Re: apathy (was Re: .ORG problems this evening)
Todd Vierling wrote:
>
> On Fri, 19 Sep 2003, Alex Bligh wrote:
>
> : > DNS site A goes down, but its BGP advertisements are still in effect.
> : > (Their firewall still appears to be up, but DNS requests fail.) Host
> : > site C cannot resolve ANYTHING from DNS site A, even though DNS site B is
> : > still up and running. But host site C cannot see DNS site B!
> :
> : What you seem to be missing is that the BGP advert goes away when the DNS
> : requests stop working.
>
> It didn't. That's the problem.
>
> I've repeatedly described how I do understand the methodology here. What's
> being expressed on this list is blind faith and trust in an anycast-only
> gTLD DNS scheme that has the possibility of routing to a single point of
> failure.
>
> This scheme has already failed once. ("When will it fail again?")
>
> Established gTLD practice has not put trust in an anycast routing scheme
> where one (1) destination might serve all queries for a host. What I've
> tried to express is that the years-established, standard DNS redundancy
> failover model could and should be implemented to complement -- not replace
> -- this anycast model for something as critical as a Big Three gTLD.
>
> That's fine; I give up due to pervasive community apathy. When this happens
> again, I'll be sure to bring up the archive URL to the head of this thread.
>
>
You started from a point of having no idea that UltraDNS used anycast,
confirmed for everyone in your second email that you had no clue about
how anycast worked, and migrated by your third email to being an expert
on how it should work. And based on assumptions that were flawed in the
very beginning, you've created a one megabyte thread and a s+n/n ration
almost unparalleled by anything I've ever seen on NANOG before. As I
told you privately, I'm working on a response that tries to deal with
all the misinformation you've spouted. There is so much, however, that
it is taking more than the 10 minutes you took to decide you knew it
all.
So you can call it apathy, or anything else you want. It seems
consistent with your way of jumping to conclusions based on flawed
assumptions. But it's really just that other people actually take time
to research issues before mouthing off.
YMMV, and apparently it does.
In the interim, feel free to post your operational experience and
qualification with tlds and their dns.
--
Rodney Joffe
CenterGate Research Group, LLC.
http://www.centergate.com
"Technology so advanced, even we don't understand it!"(R)
Re: Nothing like viruses with bugs in them (Swen)
These are exim filters which catch the damn thing when the antivirus
software misses it. Hopefully it might be useful. It was taken from
http://pkierski.republika.pl/filtry.shtml.
# Swen #
if $h_content-type matches "multipart/mixed; boundary=.[a-z]{6}" and
$message_body matches "September 200[23], Cumulative Patch"
then
logfile $home/filter.log 0644
logwrite "$tod_log - filter: *** Swen.1 *** - sender: $sender_address -
subj$
seen finish
endif
# Swen #
if $h_content-type contains "multipart/alternative;" and
$h_content-type matches "boundary=.[a-z]{6}" and
$message_body matches "iframe src=3D.cid:.*height=3D0.*
width=3D0.*/iframe"
then
logfile $home/filter.log 0644
logwrite "$tod_log - filter: *** Swen.2 *** - sender: $sender_address -
subj$
seen finish
endif
--
Brian Bruns
The Summit Open Source Development Group
Open Solutions For A Closed World / Anti-Spam Resources
http://www.2mbit.com
ICQ: 8077511
- Original Message -
From: "Mark Radabaugh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 19, 2003 12:03 PM
Subject: Nothing like viruses with bugs in them (Swen)
>
> Seems like this virus/worm has a bug where it will occasionally send out 1
> byte attachments rather than the correct worm payload. Since the virus
is
> not truly attached it tends to pass through e-mail virus scanners.
>
> It's causing a fair amount of end user confusion today -- lots of 'why is
> your/my virus scanner not working?' questions.
>
> Mark Radabaugh
> Amplex
> (419) 720-3635
>
>
>
Nothing like viruses with bugs in them (Swen)
Seems like this virus/worm has a bug where it will occasionally send out 1 byte attachments rather than the correct worm payload. Since the virus is not truly attached it tends to pass through e-mail virus scanners. It's causing a fair amount of end user confusion today -- lots of 'why is your/my virus scanner not working?' questions. Mark Radabaugh Amplex (419) 720-3635
RE: apathy (was Re: .ORG problems this evening)
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Todd Vierling
> Sent: Friday, September 19, 2003 11:37 AM
> To: [EMAIL PROTECTED]
> Subject: apathy (was Re: .ORG problems this evening)
>
>
> I've repeatedly described how I do understand the methodology
> here. What's
> being expressed on this list is blind faith and trust in an anycast-only
> gTLD DNS scheme that has the possibility of routing to a single point of
> failure.
>
Anyone know if 64.94.110.11 is done via anycast?
> This scheme has already failed once. ("When will it fail again?")
In that case, hopefully soon ...
>
Costs of not testing an implementation
Hi, I'm trying to gather some data to justify the needs of getting protocol conformance testing tools for testing out the products before deployment. Especially if there is any study on what is the cost of not doing enough testing before deployment and that cost comparing to the cost of getting the tools. If any of you can point me to any useful link, it will be great! Thanks in advance!
RE: Where to get an ASN certificate?
Thanks all for the info! -Original Message- From: Clinton Work [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:35 AM To: Nine, Jason Subject: Re: Where to get an ASN certificate? You have to apply to ARIN to get a AS number. www.arin.net = Clinton Work [EMAIL PROTECTED] Airdrie, AB - Original Message - From: "Nine, Jason" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: 19 September, 2003 9:02 AM Subject: FW: Where to get an ASN certificate? We will need to run BGP here in the next few weeks, does anyone know where you apply for an ASN certificate? Thanks
apathy (was Re: .ORG problems this evening)
On Fri, 19 Sep 2003, Alex Bligh wrote:
: > DNS site A goes down, but its BGP advertisements are still in effect.
: > (Their firewall still appears to be up, but DNS requests fail.) Host
: > site C cannot resolve ANYTHING from DNS site A, even though DNS site B is
: > still up and running. But host site C cannot see DNS site B!
:
: What you seem to be missing is that the BGP advert goes away when the DNS
: requests stop working.
It didn't. That's the problem.
I've repeatedly described how I do understand the methodology here. What's
being expressed on this list is blind faith and trust in an anycast-only
gTLD DNS scheme that has the possibility of routing to a single point of
failure.
This scheme has already failed once. ("When will it fail again?")
Established gTLD practice has not put trust in an anycast routing scheme
where one (1) destination might serve all queries for a host. What I've
tried to express is that the years-established, standard DNS redundancy
failover model could and should be implemented to complement -- not replace
-- this anycast model for something as critical as a Big Three gTLD.
That's fine; I give up due to pervasive community apathy. When this happens
again, I'll be sure to bring up the archive URL to the head of this thread.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
RE: Interesting interaction between Blaster worm variants and Verisign DNS change
Not possible is a strong statement since it has happened twice so far. The assumption you are making is the assumption that I made, which is that the resolver would first try to lookup exactly what was requested, but that is not what it does for example, with the machines domain set to clementnt.com and the default Append Primary DNS suffix to lookups checked under thae advanced TCP/IP properties the result of an nslookup from the machine for www.apple.com is to lookup www.apple.com.clementnt.com which returns 64.94.110.11 because it does not exist. It does this before actually looking up what was typed. When I say it has happened twice, I mean that I have had 2 Blaster infected machines sending spoofed IP address request to 64.94.110.11 tcp port 80 containing the windowsupdate.com in the host portion of the html header. Removing blaster using virus tools eliminated this behavior. Jeremy Powell > -Original Message- > From: Florian Weimer [mailto:[EMAIL PROTECTED] > Sent: Friday, September 19, 2003 4:44 AM > To: Jeremy Powell > Cc: [EMAIL PROTECTED] > Subject: Re: Interesting interaction between Blaster worm variants and > Verisign DNS change > > > <[EMAIL PROTECTED]> writes: > > > I think that an interesting interaction involving: > > > > 1) Blaster worm DDoS attack against windows update. > > 2) The default action of Windows 2000 and XP computers > > to automatically append the domain name under "Network > > Identification" or the suffix search list to DNS lookups. > > 3) The number of non-existent domains that exist in the > > above settings. > > 4) The change that Verisign made so that all non-existent > > domains resolve to 64.94.110.11 > > > > is the cause of the DDoS attack that Verisign is experiencing. > > This is not possible. There's a NS entry for windowsupdate.com, which > overrides the wildcard A record (in standard zone files, wildcard > records are suppressed as soon as an RR for the domain exists, even if > the types don't match). > _ Statement of Confidentiality: The contents of this e-mail message and any attachments are intended solely for the addressee. The information may also be confidential and/or legally privileged. This transmission is sent for the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction, or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail, send a copy to [EMAIL PROTECTED] and delete this message and its attachments, if any. E-mail is covered by the Electronic Communications Privacy Act, 18 USC SS 2510-2521 and is legally privileged. Date Sent (d/m/yy): 19/9/2003 - Sender: [EMAIL PROTECTED]
Re: .ORG problems this evening
--On 18 September 2003 10:05 -0400 Todd Vierling <[EMAIL PROTECTED]> wrote: DNS site A goes down, but its BGP advertisements are still in effect. (Their firewall still appears to be up, but DNS requests fail.) Host site C cannot resolve ANYTHING from DNS site A, even though DNS site B is still up and running. But host site C cannot see DNS site B! What you seem to be missing is that the BGP advert goes away when the DNS requests stop working. I have written DNS/BGP code (nothing to do with UltraDNS) and I can tell you it works very well. Even if you unplug the machine from the net you can get rapid failover by tweaking a BGP timer here or there. If you are going to say "yes but that means I don't have one of the servers up whilst routing reconverges" this is true, but (a) it happens ANYWAY, (b) as the prefered route is in general more local, the "rainshadow" from routing reconvergence in the event of disruption is smaller. Alex
Re: FW: Where to get an ASN certificate?
On Friday, Sep 19, 2003, at 11:02 Canada/Eastern, Nine, Jason wrote: We will need to run BGP here in the next few weeks, does anyone know where you apply for an ASN certificate? For an organisation based in the US, as you seem to be, see: http://www.arin.net/library/training/asn_process/index.html For advice about multi-homing and associated BGP stuff, ask google about the multi-homing workshops run by Philip Smith and others all over the place, including those run at NANOG meetings (check the presentation index, maybe, for slides). Philip is presenting another one in Chicago, I think. If you want a certificate for your ASN, you can always print out the e-mails ARIN send you and frame them :-)
Re: FW: Where to get an ASN certificate?
> We will need to run BGP here in the next few weeks, does anyone know > where you apply for an ASN certificate? > > Thanks > don't know what an ASN certificate is, but you can get an Autonomous System Number delegated from your friendly local RIR. You might want to explore the ARIN web site. www.arin.net --bill
diversion...
for the third time in nine years an ISP ran into some misconceptions wrt some address blocks that I've been piloting. Third times the charm. For ISPs that might want to know the "policy" in play for those blocks: www.ep.net/policy.html --bill
FW: Where to get an ASN certificate?
We will need to run BGP here in the next few weeks, does anyone know where you apply for an ASN certificate? Thanks
Re: Providers removing blocks on port 135?
On Fri, 19 Sep 2003, Adam Hall wrote: > Anyone know anything about prorviders removing ACLs from their routers to > allow ports 135/445/ back into their network? Curious only because > customers are calling in saying that Verizon, Cox, Bellsouth, and DSL.net > are doing so and seem to have a big problem with the fact that we're > hesitent follow their lead. Well, first you would have to find providers willing to say they had ACLs, then willing to say the ACLs that didn't exist are being removed. Although 135, 139, 445, etc ACLs still seem to be very wide-spread, they are not network or service provider wide. It may vary by region, provider, wholesale arrangement, etc. A provider may have some ACLs in Atlanta, but not in Boston. Or even in the same city, some circuits may go through different wholesale arrangements resulting in different ACLs.
Re: Providers removing blocks on port 135?
Adam Hall wrote: Anyone know anything about prorviders removing ACLs from their routers to allow ports 135/445/ back into their network? Curious only because customers are calling in saying that Verizon, Cox, Bellsouth, and DSL.net are doing so and seem to have a big problem with the fact that we're hesitent follow their lead. No two networks are the same, nor do they have the same issues. The new RPC exploit worm will be interesting to watch on the above networks if they've dropped their blocks. There's also a question of at which layer they have done so. For example, if blocks were removed from central sites in favor of blocks that were pushed out to the end users. Allowing the various scans out costs other people money. If nothing else, I'll leave 135 in place long enough to ensure that the number of users that are infected are manageable. My transit customers are all telling me the same thing. They are still pushing it to get people cleaned up and patched. They want their blocks to remain (so they don't have to pay us more). -Jack
Providers removing blocks on port 135?
Title: Providers removing blocks on port 135? Anyone know anything about prorviders removing ACLs from their routers to allow ports 135/445/ back into their network? Curious only because customers are calling in saying that Verizon, Cox, Bellsouth, and DSL.net are doing so and seem to have a big problem with the fact that we're hesitent follow their lead. Adam
RE: Worst design decisions?
1. Any device whose physical characteristics make it a likely candidate to be shelf-mounted, yet which has side ventilation ports which will be blocked by the sides of a rack shelf. 2. The BAT csu/dsu, a cheap T1 csu/dsu which used red LED's to indicate that all was well (or was it green to indicate an alarm?) 3. Routers that will accomodate high density of OCx ports but only have the bus capacity to support a fraction of them. 4. The Cleveland airport.
RE: Kill Verisign Routes :: A Dynamic BGP solution
I guess we don't really need to discuss the political ramifications, because I don't really care about VS. Our internal policy is to kill the route to the host. I'm offering up a tool to implement a technical solution to killing the route. Nothing more, nothing less. It only affects our internal network, so we don't really have a global impact, unlike some folks in Virgina. If people want it, its here. If not, they're free to delete this. Key is, they have choice. Eric > -Original Message- > From: David Schwartz [mailto:[EMAIL PROTECTED] > Sent: Friday, September 19, 2003 4:04 AM > To: J.A. Terranson > Cc: [EMAIL PROTECTED] > Subject: RE: Kill Verisign Routes :: A Dynamic BGP solution > > > > > On Thu, 18 Sep 2003, David Schwartz wrote: > > > > I think the whole idea of getting into an escalating > > > technical war with > > > Verisign is extremely bad. Your suggestion only makes sense if > > > you expect > > > Verisign to make changes to evade technical solutions. Each > > > such change by > > > Verisign will cause more breakage. Verisign will either > provide a way to > > > definitively, quickly, and easily tell that a domain is not > > > registered or > > > Verisign will badly break COM and NET. > > > > DS > > > With all due respect, this line of logic is the same one used > in the US to > > prevent people from defending themselves from other types of > > crime, and it's totally bogus. > > Really? I've never seen anyone attempt such an argument, > but it would be > rather amusing to see. Which part would you use? > > Would you argue that criminals aren't likely to take steps > that obviously > are attempts to reduce the effectiveness of guns? And if they do, > they will > have to deal with the likely PR and government pressure that would result. > > The whole point here is that it's not clear to everyone > that Verisign is > analogous to the criminal. The point is to make it clear that they are and > that won't happen if you look very much like them. > > > We have been, in a literal sense, attacked by Verislime, any and > > all defenses > > are appropriate. > > No. The defenses have to be reasonable and have to avoid > collateral damage > to innocent parties. If not, Verisign will have a reasonable argument that > we are the bad guys. They caused some breakage? So what, so did we. They > distorted the true data that should have been in the zone? So what, so did > we. > > You are welcome to see this as an attack, but the response > should not be > out of proportion. If a measured response leads to an escalation, then you > can consider "any and all defenses". > > DS > > >
The Cidr Report
This report has been generated at Fri Sep 19 21:47:52 2003 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
12-09-03124543 88827
13-09-03124711 88736
14-09-03124535 88697
15-09-0312 88796
16-09-03124819 88837
17-09-03124894 88815
18-09-03124780 88746
19-09-03124625 88474
AS Summary
15713 Number of ASes in routing system
6223 Number of ASes announcing only one prefix
1454 Largest number of prefixes announced by an AS
AS701 : ALTERNET-AS UUNET Technologies, Inc.
73351168 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 19Sep03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 124256884633579328.8% All ASes
AS4323 662 194 46870.7% TW-COMM Time Warner
Communications, Inc.
AS701 1454 1010 44430.5% ALTERNET-AS UUNET
Technologies, Inc.
AS7018 1398 982 41629.8% ATT-INTERNET4 AT&T WorldNet
Services
AS7843 518 138 38073.4% ADELPHIA-AS Adelphia Corp.
AS3908 909 536 37341.0% SUPERNETASBLK SuperNet, Inc.
AS6197 612 282 33053.9% BATI-ATL BellSouth Network
Solutions, Inc
AS6198 493 207 28658.0% BATI-MIA BellSouth Network
Solutions, Inc
AS4355 392 109 28372.2% ERMS-EARTHLNK EARTHLINK, INC
AS1221 977 695 28228.9% ASN-TELSTRA Telstra Pty Ltd
AS6347 350 92 25873.7% DIAMOND SAVVIS Communications
Corporation
AS1239 901 650 25127.9% SPRINTLINK Sprint
AS27364 319 68 25178.7% ACS-INTERNET Armstrong Cable
Services
AS22773 268 28 24089.6% CCINET-2 Cox Communications
Inc. Atlanta
AS17676 262 30 23288.5% GIGAINFRA Softbank BB Corp.
AS25844 241 14 22794.2% SKADDEN1 Skadden, Arps, Slate,
Meagher & Flom LLP
AS209503 294 20941.6% ASN-QWEST Qwest
AS6140 343 135 20860.6% IMPSAT-USA ImpSat
AS4134 324 117 20763.9% CHINANET-BACKBONE
No.31,Jin-rong Street
AS11305 230 38 19283.5% INTERLAND-NET1 Interland
Incorporated
AS4519 1804 17697.8% MAAS Maas Communications
AS6327 200 26 17487.0% SHAW Shaw Communications Inc.
AS2386 371 200 17146.1% INS-AS AT&T Data
Communications Services
AS2048 256 87 16966.0% LANET-1 State of Louisiana
AS14654 1702 16898.8% WAYPORT Wayport
AS9498 187 20 16789.3% BBIL-AP BHARTI BT INTERNET
LTD.
AS705415 252 16339.3% ALTERNET-AS UUNET
Technologies, Inc.
AS17557 288 136 15252.8% PKTELECOM-AS-AP Pakistan
Telecom
AS9800 203 52 15174.4% UNICOM CHINA UNICOM
AS19262 212 65 14769.3% VZGNI-TRANSIT Verizon Global
Networks
AS3602 231 86 14562.8% SPRINT-CA-AS Sprint Canada
Inc.
Total 13869 6549 732052.8% Top 30 total
Possible Bogus Routes
24.119.0.0/16AS11492 CABLEONE CABLE ONE
61.12.32.0/24AS7545 TPG-INTERNET-AP TPG Internet Pty Ltd
61.12.34.0/24AS7545 TPG-INTERNET-AP TPG Internet Pty Ltd
64.30.64.0/19AS14900 USLEC-CORP-1 USLEC Corp.
66.41.192.0/18 AS13367 ATT-BBND-B AT&T Broadband
132.0.0.0/10 AS568 SUMNE
site finder performance
The redirect port 80 server seems to gain on performance, I wonder if that´s due to Verisign fixing issues or enough people blocking it so the load lowers? We´ve gone from 22 seconds average transaction time yesterday, to about two seconds so far today. Minimum achieved is 239 milliseconds, which is also about the theoretical minimum from our neck of woods because of light speed limitations. Pete
RE: News of ISC Developing BIND Patch
> I would say _supposed_ to be unique. Surely some cheapo manufacturer > has recycled addresses from their old ISA card days. I've seen at least one manufacturer ship multiple cards with the same MAC address. One shop in Tottenham Court Road, London sold several people on the same LAN cards with identical MAC addresses.
