Buh bye
I'm about to be removed, forcibly, from nanog-post. Mostly, it's because I feel that the degree of stink raised by the admin team over my "send in the marines" post last week is completely out of the bounds of reason for a single, only arguably off-topic, posting which asked for, and received, no on-list replies. And, clearly, they *don't* think it's unreasonable. That's ok; I only operate very small networks, and no one's going to lose any sleep over not hearing what I have to say. And since, notwithstanding everyone's interest in *reading* best practices information on networking, none of the people who *have* it had anything to write about it on the Wikicty below (with a couple of notable exceptions), I'm probably taking that off in another direction as well. I wrote this mostly because it's a tradition. :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: level3.net in Chicago - high packet loss?!?
On Tue, Sep 06, 2005 at 10:39:12AM -0400, Adam Rothschild wrote: > On 2005-09-06-10:25:28, Network Fortius <[EMAIL PROTECTED]> wrote: > > And how exactly would you interpret the number returned by net_loss > > (int), in a column called "LOSS", in reference to reachability of a > > "hop" between two end points [...] > > I'd interpret it to mean you're hitting a control plane policer or > somesuch, with no actual bearing on end-to-end performance, judging > from the diagnostic output you've graciously provided us with. > > I find myself giving this lecture several times a week to random > "gamer" customers upset that intermediary routers don't reply to their > pings at full line rate; I'd expect slightly better critical thinking > skills from the posters on this list, but I've been wrong before. :) And yet, his client had a problem, with that link, and did not have a problem with some other link, which, presumably, did *not* show that indication. Correlation does not imply causation, given, but it's certainly a datapoint. Best Practices of wide-area diagnosis, anyone? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: DARPA and the network
On Tue, Sep 06, 2005 at 12:04:14PM +0100, [EMAIL PROTECTED] wrote: > > yes, it is. we can further dicuss that in private if you wish; however, > > claiming OpenBSD is just more vocal about security is just far off > > reality, and that had to be put in perspective. > > The real question is not whether other BSDs or > other Unices are following OpenBSD's lead. I'd like > to know how many embedded systems (routers and switches) > are implementing similar "hardening" techniques. Well, I sort of gather that the implication was "all the ones that are embedding OpenBSD". ;-) > The Internet runs on embedded systems and although many have their > roots in Unix, they don't seem to have adopted many of the security > techniques that are used in C2 or CAPP certified systems. Quite so. > The details that Henning posted are useful to list members who are > writing RFPs for new network gear. Even if vendors can't meet these > requirements today, it is good to let them know that people seriously > want secure operating systems on their routers and switches. Ah yes, the most important requirement: informed, vocal users. The more you spend per year, the better. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: TIA-942 Datacenter Standardization
On Thu, Sep 01, 2005 at 10:43:25PM -0400, Jay R. Ashworth wrote: > On Thu, Sep 01, 2005 at 10:54:26PM +1200, Simon Lyall wrote: > > also "The Practice of System and Network Administration" by Limoncelli and > > Hogan has a few pointers as well but on a smaller scale and it feels a > > little old at times. > > Tom tells me he's prepping a seconfd edition for late 96; anyone who > has comments on the first edition should codify them and ship them to > him now. Thanks to the 4 people who gave me a chuckle by telling me I gave them one; I'm sure even those of us *outside* NO can use one this week. Yes, clearly, I meant '06. Tom's sysadmin blog is at: http://www.everythingsysadmin.com/ and he has a TWiki set up for notes on specific items at: http://www.everythingsysadmin.com/twiki/bin/view/ESA/WebHome (And, of course, *I* have a wiki setup, for topics closer to home, which no one here ever seems to have time to contribute to; it's below.) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: TIA-942 Datacenter Standardization
On Thu, Sep 01, 2005 at 10:54:26PM +1200, Simon Lyall wrote: > also "The Practice of System and Network Administration" by Limoncelli and > Hogan has a few pointers as well but on a smaller scale and it feels a > little old at times. Tom tells me he's prepping a seconfd edition for late 96; anyone who has comments on the first edition should codify them and ship them to him now. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 "NPR has a lot in common with Nascar... we both turn to the left." - Peter Sagal, on Wait Wait, Don't Tell Me!
Re: redcross.org certificate problems with Akamai
On Thu, Sep 01, 2005 at 03:47:30PM -0400, Hannigan, Martin wrote: > > The donations page is Akamaized, and the certificate says > > "a248.e.akamai.net" instead of "www.redcross.org". > > > > I have the certificate signature available off-line. > > Which part of the transaction does this occur at? Do you have a > specific URL? All of the VeriSign security seals are reporting > known and trusted host and the certs are matching. > > They appear to be outsourcing their payment processing to > Convio. It's all matching up. I clicked on the "Donate NOW" box on the front page, and it happened during the redirect. I didn't get to see that they'd switched to Convio at that point, because I wanted to keep the detail around, and because hanging on that dialog suspends *all* of firefox's threads. I finally released it, and I see that it's working OK now; I also see that they switched that processing to Convio, and perhaps I got caught in an out-of-phase moment. I suppose I know better than to assume it's really broken until it breaks three times in fifteen minutes (my own rule, ironically). Sorry, all. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Ops: redcross.org certificate problems with Akamai
The donations page is Akamaized, and the certificate says "a248.e.akamai.net" instead of "www.redcross.org". I have the certificate signature available off-line. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 "NPR has a lot in common with Nascar... we both turn to the left." - Peter Sagal, on Wait Wait, Don't Tell Me!
OT: Attn Federal NS/EP types
If there's anyone in black sunglasses reading this positioned sufficiently high to do any good, please go read http://www.livejournal.com/users/interdictor/39438.html?mode=reply (Please do not reply on list to this posting. Anyone who feels the need to yell at me, please do it off-list.) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 "NPR has a lot in common with Nascar... we both turn to the left." - Peter Sagal, on Wait Wait, Don't Tell Me!
Re: Phone networks struggle in Hurricane Katrina's wake
On Tue, Aug 30, 2005 at 03:48:52PM -1000, Randy Bush wrote: > the steering committee has been discussing the idea of a nanog blog. > of course it would be directed to operational content and not your > daily pointer to some cartoon etc. Manners, Randy. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 "NPR has a lot in common with Nascar... we both turn to the left." - Peter Sagal, on Wait Wait, Don't Tell Me!
Re: Semi-on-topic: Light that travels faster than the speed of light?
On Mon, Aug 22, 2005 at 01:31:36PM -0600, Steve Meuse wrote: >On 8/21/05, Peter Dambier <[EMAIL PROTECTED]> wrote: > I have had a look into one of my microwave books. I have seen in > coax cables the speed of lite drop to 90% or 80% depending on the > insulator, the dielectric. > >I believe this is referred to as "velocity factor". Not the speed of light; the speed at which the electromagnetic wavefront travels through *that* conductor. Yep; this is velocity factor. It can go down surprisingly far. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Cingular Wireless contact?
On Mon, Aug 22, 2005 at 05:10:09PM -0700, Steve Gibbard wrote: > This is a mailing list for the wrong sort of network for this question, > but... You're correct. :-) comp.dcom.telecom.tech or alt.dcom.telecom are better places to find this sort of person, or at least, they used to be. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Qwest PSTN problems / status page?
On Mon, Aug 22, 2005 at 03:16:01PM -0600, Mike Lewinski wrote: > We have been told they are currently experiencing a major outage and > "All calls are failing out-going" (which isn't true as I've made some > calls, but am seeing intermittent congestion returned on our PRIs) > > I have also heard that it... "Seems to be on the public switching > network.Seattle can call out, Minneapolis & Ohio can't." Qwest reportedly *just* signed a new union contract today; perhaps some people didn't get the memo? http://news.google.com/news?q=qwest+-field Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 "NPR has a lot in common with Nascar... we both turn to the left." - Peter Sagal, on Wait Wait, Don't Tell Me!
Re: Qwest PSTN problems / status page?
On Mon, Aug 22, 2005 at 04:46:57PM -0500, Nick Thompson wrote: > We are currently having outbound long distance issues via Qwest right > now. > A PSTN status page would be rather convenient at this moment. Most telecom providers don't *have* status pages, for the same reason that most telecom problem tickets "mysteriously" clear: they have to report their problem metrics to the government, and if they don't admit to the problem, it makes their numbers look better. "The trouble's leaving here fine!" I do have a reasonably large list of other types of status pages collected here: http://www.microsys.us/status Any contributions from other people's crib notes won't go amiss... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: New N.Y. Law Targets Hidden Net LD Tolls
On Fri, Aug 19, 2005 at 03:15:11PM -0400, Steven J. Sobol wrote: > On Fri, 19 Aug 2005, Steven M. Bellovin wrote: > > Mine doesn't -- AT&T Wireless and Cingular GSM phones have 10D or 11D > > only, at least around here. > > Leave it up to Cingular to be stupid. :P I've been a customer of Alltel, > Northcoast PCS, Sprint PCS and now T-Mobile, and the old GTE Wireless > dating back to '93. On none of those carriers have I ever been forced to > dial 10D if I wasn't roaming, and if I was dialing a number in the same > area code my cellphone number was in. > > IOW, I'm pretty sure they're the only company doing that, though ICBW. I hang out in telecom circles, and I have no datapoints suggesting that cellular carriers are requiring or moving to requiring 10D for local calling, though Stan Cline (roamer1) would be the guy to ask. This is, of course, OT of the OT thread about ISP dialing. I would observe that there's a fairly obvious mnemonic to 7D (the same area code as my own number), but Steve's already gonna yell at me for posting on this thread, so... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Blocking certain terrorism/porn sites and DNS
On Thu, Aug 18, 2005 at 02:32:42PM +0530, Abhishek Verma wrote: > No, that wasnt my point. I just wanted to make sure that my > understanding of banning a hostname was indeed correct. We can this > way atleast block all websites with *alqaida* domain names. I believe you've mispelt "Al Q'aeda". You see the problem. Cheers, -- jr 'PDFTT' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: fcc ruling on dsl providers' access to infrastructure
On Sun, Aug 07, 2005 at 10:20:19PM -0400, Richard A Steenbergen wrote: > Clearly this is a special situation where there is a natural monopoly > given to whomever runs the wires. Maybe what we need is a certain class of > company who will be responsible for running and maintaining the public > data infrastructures. They could have lots of government regulations to > ensure that they are charging a "fair" price while still being guaranteed > a profit, and they could provide the last mile service for all those ISPs > out there who are the ones that can actually compete and innovate. We > could call them telcos, and... oh wait, nevermind. I believe you've mispronounced: municipalities. Oh, wait: Congress wants to outlaw *that*, too. Cheers, -- jr 'Second American Revolution?' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: RFC for Mask/Gateway
On Fri, Aug 05, 2005 at 03:09:53PM -0400, [EMAIL PROTECTED] wrote: > On Fri, 05 Aug 2005 13:55:58 CDT, Scott Altman said: > > Is there an RFC or other standard that specifies that IPv4 connected > > devices must support the concepts of Subnet Mask and Default Gateway? > > No, because there's plenty of applications (embedded systems, for example), > where you have no need or desire to be able to talk to things off-local-net. Which doesn't really excuse you from subnet mask, I wouldn't think. You clearly don't need a default gateway if you're not going to reply to off-net packets, but how would you idenfity broadcast packets if you didn't know the netmask? > > I have a kludgy (<- technical term) vendor that has developed a custom > > AP that only has an IP address. > > Be afraid. Be very afraid. Any vendor in *this* year who makes gear that > is supposed to connect edge devices to the rest of the net but doesn't > get the ideas of subnet masks and default gateways should be feared. Indeed, run far, far away. And yes, Scott: RFC 791. It's not just a good idea... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 "NPR has a lot in common with Nascar... we both turn to the left." - Peter Sagal, on Wait Wait, Don't Tell Me!
Re: /8 end user assignment?
On Fri, Aug 05, 2005 at 12:17:55PM -0400, Daniel Golding wrote: > Why do so many v6 folks fill their arguments with notes of alarmism? Why > don't we just make an orderly migration when it is called for, rather than > using hyperbole to scare people? I rather infer, Daniel, that the issue is "how long the lane change will take", and therefore how far in advance of the wall the migration needs to start (and how fast it needs to ramp) in order to, in fact, *be* orderly. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: /8 end user assignment?
On Fri, Aug 05, 2005 at 04:10:46AM -0700, Bill Woodcock wrote: > On Fri, 5 Aug 2005, Sabri Berisha wrote: > > With the use of anycast DNS servers on the internet, TCP is no longer an > > option for DNS. > > Bzzzt. Try again. Naw; c'mon, guys: we did this one *last* month; I still have the proof in my archives. :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: NETGEAR in the core...
On Sun, Jul 31, 2005 at 05:07:41AM -0700, Sam Crooks wrote: > SCO Unix runs on cyberguards older than 6.0 (aka Classic) > Linux 2.6 kernel runs on the 6.0 (aka TSP) as for SG line... I don't > know... The Cyberguard line was bought from Snapgear, who in turn bought it from Ozzies Moreton Bay. They have always run Linux, and they do it very well. While their user interface has improved over the years, there are still some things I'd like it to have that it doesn't, and it's not as pretty as, say, Netgear'. But from an operational perspective, I've got a couple dozen of these out as edge routers for client sites behind DSL and RoadRunner, and they Just Work. Easy install and config, gets the job done, never been attacked successfully from outside (so far as I know :-), and I have to reboot one roughly once a year, if that. Nice boxes, not too pricey. I'd shortlist them. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Boing Boing: Michael Lynn's controversial Cisco security presentation
On Fri, Jul 29, 2005 at 08:56:40AM -0700, Buhrmaster, Gary wrote: > I know, I am just being paranoid. There has never > been an exploitable PDF exploit. Oh, wait, there > has been :-) Ah, yes; but does it affect xpdf? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: 911, was You're all over thinking this (was: Re: Vonage Selects TCS For VoIP E911 Service)
On Mon, Jul 25, 2005 at 02:01:33PM +0100, [EMAIL PROTECTED] wrote: > > This whole "single number" hype should end anyway. > > In Russia it is simple, there are three numbers: > > 01 - Fire Service > 02 - Police > 03 - Ambulance/Medical response > > Easy to remember especially because the number is written > in large figures on the side of every emergency response > vehicle. You could even retrofit these numbers into other > countries because they are two digit numbers. Personally, I assert that that's bad design for two reasons: 1) they're too *short*: they pre-empt too much dialling pattern space, and they're hard to recognize as what they are, compared for example to 9-1-1 and 1-1-2. 2) it shouldn't, in general, be the place of *someone reporting an emergency* to have to decide what kind of response they want. In the US, for example, medical emergencies are often first-responded by firefighter-paramedics, because there's a firestation closer than the nearest ambulance. There's no way a caller could know what's closer... Cheers, -- jr 'ah... *telecom* :-)' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 "...the rough cannot be mean and the love cannot be true, and that's as wise as I can get at 10 o'clock in the morning." -- Bill Shatner, on being an anti-hero.
Re: London incidents
On Wed, Jul 13, 2005 at 09:26:33AM +1200, Mark Foster wrote: > > Shutting down the networks just because they can be used to trigger a > > bomb is asinine, though, yes. > > Its the first step toward the Police State mentality that I fear is going to > develop over time. > And damned if I know what to do about it. Well, the terrorists wanted to deprive us of the freedoms we enjoy, and they've talked us into doing the hard parts for them... but I see no way to configure a router to enhance personal freedom, so I guess we'll take this subthread off list. ;-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: OMB: IPv6 by June 2008
On Tue, Jul 12, 2005 at 06:43:17AM +, [EMAIL PROTECTED] wrote: > > And I'm still holding my breathe to see when a commercial company returns > > their /8. -Hank > > its already happened... over a dozen have been returned. I'd like to send thank you cards: who are they? :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: London incidents
On Tue, Jul 12, 2005 at 12:34:32PM +0200, Brad Knowles wrote: > The problem with mobile phones in the car has less to do with > taking a person's hand off the wheel (although that is something to > be concerned about), and more to do with the fact that the driver is > distracted by talking to the person on the other end. They say this, but it doesn't work that way for me, as a datapoint. It's not the conversation that's the big thing, IME; it's *holding a phone up to your ear*, which is an action we train ourselves to follow up with *ignoring what's going on around us*. When I talk while driving *without* a headset, my driving's usually fine... it's my *navigation* that fails totally. Using a headset, both are fine. YMMV. Shutting down the networks just because they can be used to trigger a bomb is asinine, though, yes. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: London incidents
On Mon, Jul 11, 2005 at 12:31:35PM +0100, [EMAIL PROTECTED] wrote: > It was an interesting experience which seems to show that > it is better to have several completely different communications > channels to choose from. In my case I had lost landline and > DSL Internet access due to moving house, and I lost mobile > voice access due to congestion. But SMS still functioned. The lower the bandwidth channel, the less likely it is to break. Cheers, -- jr 'cf: Morse Code' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: London incidents
On Mon, Jul 11, 2005 at 12:16:34PM +0200, Brad Knowles wrote: > I don't know the specifics of how much capacity is reserved, but > this sort of thing has been done on telecommunications networks for a > long time. Back before cell phones existed, you could have "flash" > traffic on the DDN or even the PSTN, and when placing a flash call > the phone system would disconnect anyone that stood in your way of > getting the connection you wanted. > > You had to be using special telephone equipment, or connected to > a special operator with the right equipment, and you had damn well > better be sure that your call was worthy of knocking anyone else off > the network, but the capability was there. Even the President would > normally make his calls at lower than "flash" priority. See also http://tsp.ncs.gov/ and http://wps.ncs.gov/ , as well as http://www.disa.mil/gs/dsn/tut_mlpp.html and http://www.disa.mil/gs/dsn/tut_precedence.html which explain those Fo, F, I and P keys on AutoVON 16-button WECo 2500s. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: ATT CDPD
On Sun, Jul 10, 2005 at 01:38:44AM -0400, Steven J. Sobol wrote: > On Sat, 9 Jul 2005, Alex Rubenstein wrote: > > AMPS, as I understand it, is required to be around until 1/1/2007, as > > mandated by tge FCC. > > I think the date actually got pushed back to '08, but I've not heard > anything about requiring CDPD. Sorry; I didn't mean to imply that I thought the FCC was requiring them to keep or dump CDPD. What I was trying to get across was that, there being a large installed base for CDPD, they wouldn't dump it completely for sometime for a replacement, unless they had to -- and not having to maintain the associated RF and antennas for AMPS, they would no longer be able to cost-justify keeping it after AMPS went down. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse
On Sat, Jul 09, 2005 at 01:51:46PM -0400, Todd Vierling wrote: > On Sat, 9 Jul 2005, Jay R. Ashworth wrote: > > It's not the *root* operators that are the problem -- it's the *TLD* > > zone operators. > > Oh, I can certainly agree with that; we've seen some gross abuses of TLDs > documented in gory detail right here on the NANOG list. > > Of course, that too is orthogonal to who provides the delegations in "." -- > except that perhaps some misguided souls are, as is relatively common, > confusing the two realms. Indeed. > > "infrastructure at risk". Justify this *far-reaching* statement, > > please. Show your work. > > AlterNIC overriding .COM and .NET listings, one of the issues leading to its > demise. (This was done in addition to the more memorable cache poisoning > attacks against INTERNIC.NET.) To the extent that you don't call that a criminal aberration -- one that could as easily have happened to one of the root servers currently *taking* the ICANN root zone -- it only affected people who were resolving off that root. That's a pretty small number, and, IMHO, doesn't rise to the level of "placing the infrastructure [of the entire net] at risk". > The risk is uncertainty of name resolution, as the root zone can in fact > override N-level records simply by posessing a more specific name. Root > servers are queried for the full host (but respond with the NS glue > delegation), not just the first component, which allows for such overriding. And that possibility is any different in the n-root case than in the 1-root case... why? > > > Oh wait, your name wouldn't *actually* be Jim Fleming, would it? > > > > > > Well, at least some folks remember. 8-) Whoa, yeah. My Linux boxes all run IPv8. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse
On Sat, Jul 09, 2005 at 06:45:38PM +0100, Stephen J. Wilcox wrote: > Those who consider ICANN the authority would disagree, I believe those > are the majority. Incidentally, Steve, clearly the USDoC NTIA is *not* in that majority. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse
On Sat, Jul 09, 2005 at 06:45:38PM +0100, Stephen J. Wilcox wrote: > Still its nice to see all the old kooks still alive and well and not > yet locked up in mental homes. I'd better do my part to feed the > trolls i guess... Ok, from what *I* can see, the people arguing *against* the topic are the ones who sound like blathering, insulting idiots (like this post), and the ones on the other side sound calm and rational. But "mental homes" is a touch rough, even for NANOG, no? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse
On Sat, Jul 09, 2005 at 11:46:11AM -0400, Todd Vierling wrote:
> On Wed, 6 Jul 2005 [EMAIL PROTECTED] wrote:
> > > 1. Security ("man-in-the-middle").
> >
> > VPNs, SSH tunnels, etc. There are ways to solve
> > this problem.
>
> You would use a VPN or SSH tunnel to do what? That's orthogonal to DNS
> security issues, and illustrates that you haven't read DNSSEC and/or 2826.
>
> > > 2. Common interoperability.
> >
> > We do not currently have common interoperability for a
> > whole range of protocols.
>
> So what? DNS is one of the protocols where interoperability is not just
> desirable, it's MANDATORY.
>
> Businesses and individuals expect that when they publish an e-mail or Web
> site hostname, that it be theirs and only theirs no matter where on the
> Internet it is accessed. FQDNs are considered fixed points of entry, and
> alternate roots put that name resolution at risk. (But if you had actually
> read RFC2826, you would already understand this.)
I'm going to dive in one more time here.
It's not the *root* operators that are the problem -- it's the *TLD*
zone operators.
> Introducing fragmented TLDs or the opportunity to supplant the common TLDs
> places the DNS infrastructure at risk. This is not just FUD -- DNS
> hijacking in alternate roots has already happened. (But if you had actually
> read RFC2826, you would already understand this.)
"infrastructure at risk". Justify this *far-reaching* statement,
please. Show your work.
> > and I appreciate the IAB's comments, but it was written at a time when we
> > didn't have as much experience with rootless networks as we do now.
>
> The DNS is not a rootless network, so this is a pointless comment.
That response appears to assume facts not in evidence in his comment.
> On the flip side, there was quite a bit of experience with alternate DNS
> roots at the time RFC2826 was created -- AlterNIC, which was run and
> advocated by people just as blinded by ignorance as you.
>
> Oh wait, your name wouldn't *actually* be Jim Fleming, would it?
Cheers,
-- jra
--
Jay R. Ashworth[EMAIL PROTECTED]
Designer Baylink RFC 2100
Ashworth & AssociatesThe Things I Think'87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
If you can read this... thank a system administrator. Or two. --me
Re: mh (RE: OMB: IPv6 by June 2008)
On Fri, Jul 08, 2005 at 01:15:42PM -0400, David Andersen wrote: > On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote: > > On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote: > >> And if you still want "the protection of NAT," any stateful firewall > >> will do it. > > > > That seems a common viewpoint. > > > > I believe the very existence of the Ping Of Death rebuts it. > > > > A machine behind a NAT box simply is not visible to the outside world, > > except for the protocols you tunnel to it, if any. This *has* to > > vastly reduce it's attack exposure. > > Not really. Consider the logic in a NAT box: [ ... ] > and the logic in a stateful firewall: Sorry. Given my other-end-of-the-telescope perspective, I was envisioning an *on-machine* firewall, rather than a box. Clearly *any* sort of box in the middle helps in the fashion I alluded to, whether it NATs or not. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: mh (RE: OMB: IPv6 by June 2008)
On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote: > And if you still want "the protection of NAT," any stateful firewall > will do it. That seems a common viewpoint. I believe the very existence of the Ping Of Death rebuts it. A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. Anyone with a pointer to an *in depth* explanation somewhere of why that assumption is invalid can mail it to me off list, and I'll shut up. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: ATT CDPD
On Fri, Jul 08, 2005 at 08:00:42AM -0400, Ronald W. Jean wrote: >Can anyone tell me the status of CDPD in the ATT network? Scheduled to die soon, if it hasn't already. I was a second-tier CDPD sub, via Earthlink, until about a year ago; they took a hit to move me to 1xRTT, because the underlying networks were scheduled to go down, in keeping with the general decommissioning of analog AMPS, during this calendar year, as I understand it. It was extended because of a couple of large PD's who needed more time to switch (or amortize their gear; take your pick). http://www.google.com/search?q=cdpd+decommissioning Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: OMB: IPv6 by June 2008
On Wed, Jul 06, 2005 at 09:46:53PM +0200, Iljitsch van Beijnum wrote: > We know how many IPv4 addresses there are. We know how many are > unusable (although this number isn't 100% fixed). We know how many > were given out. We know how many are given out now each year. What > kind of magic do you expect will make this problem that's coming go > away? >Are there > hidden pockets of yet undiscovered address space? Undiscovered? No. But unless the situation has changed since I last looked (which is possible), there are some sizeable clumps that will never get used by the people who "own" them, which it has not been practicable to reclaim. The tighter the vise, the higher the fence it will be worthwhile to jump to reclaim that space... just like prospecting for oil. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: DNS .US outage
On Thu, Jul 07, 2005 at 10:10:03AM +0200, Jeroen Massar wrote: > DNSDoctor (which even supports IPv6 :) > http://demo.dnsdoctor.org/ "avoid loosing all connectivity" Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: DNS .US outage
On Wed, Jul 06, 2005 at 11:27:39PM -0500, Church, Chuck wrote: >Anyone else having issues with .US right now (~12AM EST)? NSlookup, >etc show various .us destinations as unknown domains... Not for my site, at least: ; <<>> DiG 9.2.1 <<>> +trace microsys.us ;; global options: printcmd . 323510 IN NS F.ROOT-SERVERS.NET. . 323510 IN NS G.ROOT-SERVERS.NET. . 323510 IN NS H.ROOT-SERVERS.NET. . 323510 IN NS I.ROOT-SERVERS.NET. . 323510 IN NS J.ROOT-SERVERS.NET. . 323510 IN NS K.ROOT-SERVERS.NET. . 323510 IN NS L.ROOT-SERVERS.NET. . 323510 IN NS M.ROOT-SERVERS.NET. . 323510 IN NS A.ROOT-SERVERS.NET. . 323510 IN NS B.ROOT-SERVERS.NET. . 323510 IN NS C.ROOT-SERVERS.NET. . 323510 IN NS D.ROOT-SERVERS.NET. . 323510 IN NS E.ROOT-SERVERS.NET. ;; Received 244 bytes from 127.0.0.1#53(127.0.0.1) in 33 ms us. 172800 IN NS A.GTLD.BIZ. us. 172800 IN NS B.GTLD.BIZ. us. 172800 IN NS C.GTLD.BIZ. ;; Received 133 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 87 ms microsys.us.7200IN NS NS2.DOMAINDISCOVER.COM. microsys.us.7200IN NS NS1.DOMAINDISCOVER.COM. ;; Received 83 bytes from 209.173.53.162#53(A.GTLD.BIZ) in 40 ms microsys.us.28800 IN SOA ns1.domaindiscover.com. hostmaster.tierra.net. 3723050 86400 1800 604800 28800 ;; Received 108 bytes from 216.104.163.3#53(NS2.DOMAINDISCOVER.COM) in 98 ms 'dig +trace', incidentally, for those of you who haven't tripped over it yet, is *very* cool. I'm trying to figure out a way to shoehorn the output into something I can Nagios... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Enable BIND cache server to resolve chinese domain name?
On Mon, Jul 04, 2005 at 05:21:47PM +, Paul Vixie wrote: > > Every public root experiment that I have seen has always > > operated as a superset of the ICANN root zone. > > not www.orsn.net. Well, their website looks a lot better than the equivalent one. :-) But note that their site does *not* say that they are not a strict superset; merely that their current operating policy doesn't *guarantee* it. Their language certainly implies that they're not out to be intentionally perverse, at least to me. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Enable BIND cache server to resolve chinese domain name?
On Mon, Jul 04, 2005 at 01:25:57PM +0100, [EMAIL PROTECTED] wrote: > Personally, I think that the Internet is too young > and we have too little experience with multilingual > naming to engineer an Internationalised Domain Naming > solution that solves the problem once and for all. > This means that we should be ready for more than one > iteration to get to the solution. Alas, we didn't get it done before the 'consumers' noticed... which means there will be much more pain involved in getting the engineering right. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: OMB: IPv6 by June 2008
On Wed, Jul 06, 2005 at 07:23:01PM +0200, Iljitsch van Beijnum wrote: > In any event, in the year 2020 we're NOT going to run IPv4 as we know > it today. It's possible that the packets that travel over the wires > still look like regular IPv4/TCP/UDP packets and all the complexity > is pushed out to the application or political/economic layers, but ^ > that's not a possibility that appeals to me. Is that layer 8? Does anyone have a stateful firewall that works at that layer? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Wed, Jul 06, 2005 at 08:52:09AM +0930, Mark Newton wrote:
> > > Stipulated. But whose problem *is* that?
> >
> >The users will make it our problem, if we don't get this sorted out
> >soon.
>
> It seems to me that "this" is *already* sorted out, and that all of
> this discussion has been about whether to invent new problems, rather
> than about whether to solve existing problems.
Sorry to hear you feel that way, Mark. I'm not entitled to have
on-topicness opinions here, but Brad is, and he hasn't told me to shut
up yet. ;-)
> Alternate root servers exist for one plain simple reason: To give
> their operators their own little playpen of TLDs they can mess
> around with without ICANN getting in their faces. People who don't
> want to own and operate TLDs don't actually give a crap about that
> reason.
>
> These operators have been pushing this idea for 6 or 7 years now.
> Frankly I'm of the view that if the "benefits" of alternate roots
> were in any way desirable *to anyone other than those who operate
> them* we'd probably all be using them by now.
>
> But we aren't. And probably never will.
I dunno, The China Proposition seemed fairly believable to *me*...
> If we probably never will then the alternate root operators can
> either stop flogging their dead horse and shuffle off into the sunset,
> or they can continue to pollute mailing lists with useless discussions
> about whether they have a right to exist every time the concept is
> mentioned from now until eternity, just like they do now.
Note that I am *not* an alt-root operator, nor do I have any direct
or indirect interest in any of them, except that some of my routers are
configured to resolve off of them.
> Right now, on July 5th 2005, "The whole alternate-root ${STATE}horse"
> has absolutely zero operational impact on any network operators.
> So could y'all please perhaps take it to USEnet where it belongs
> and let this list get back to normal?
My appraisal is that it has about as much direct percentage impact on
North American networks as IPv6 and Multicast. And, as Brad notes,
there's a believable case to be made that it *might become* an issue to
this audience.
All those who disagree or don't object to being caught with their pants
down are welcome to kill the thread, which I courteously retitled and
unthreaded at the outset.
Cheers,
-- jra
--
Jay R. Ashworth[EMAIL PROTECTED]
Designer+-Internetworking--+--+ RFC 2100
Ashworth & Associates | Best Practices Wiki | |'87 e24
St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274
If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Wed, Jul 06, 2005 at 01:06:15AM +0200, Brad Knowles wrote: > > To many alt-roots? Or too many alt-TLD's? > > Too many of the former is likely to lead to having too many of > the latter. Both are bad. I don't know that I agree with either of those assertions, absent collision problems, personally, but this subthread officially makes this a religious argument; comments here off-list. > >>The problem is that they are pretty much guaranteed to get at > >> cross-purposes. > > > > Well, there have been alt-root zones available for, what 6 or 7 years > > now? And how many collisions have there actually been in practice? 2? > > 3? > > We have not yet hit the knee of the curve. Perhaps. I think those people are *much* more concerned about this than I think you think they are. > >>I don't think that's really practical. I'm sorry, I just don't > >> trust them to write a resolver that's going to get included in libc > >> (or wherever), and for which the world is going to be dependant. > > > > Well, I meant "at your customer recursive resolver servers", since the > > topic at hand was "what do IAP's do to support their retail customers", > > but... > > I don't trust them to write code that will be used in > mission-critical situations or places, regardless of where that is. Wasn't sure which them you meant here... > It's not that they don't have the best intentions -- I'm sure > that at least some of them do. It's that they don't have the > necessary experience. > > The people I would trust to have enough of the right experience > to make something like this work (if that's possible at all) are the > same people who wrote Nominum's ANS and CNS. However, I suspect that > they would probably be about the last people in the world who would > be interested in trying to make something like this work. And then I figured it out. Hmmm... again, absent TLD collisions, I don't see that writing a recursive-only server that can coalesce the TLD namespace from multiple roots ought to be *that* hard... but then I'm not Cricket, neither. > >> People will always be able to access data by pure IP address, or > >> choosing to use the real root servers. Push come to shove, and the > >> real root servers could be proxied through other systems via other > >> methods. > > > > "Real" is *such* a metaphysical term here, isn't it? :-) > > Heh. Shall we use the term IRS? As in Incumbent Root Servers? I don't have a problem with that one, the amusing connotations notwithstanding. Incumbent isn't a value judgement, it's merely descriptive. > >>The reverse problem is more difficult to deal with -- that of > >> people wanting to access Chinese (or whatever) sites that can only be > >> found in the Chinese-owned alternative root. > > > > Stipulated. But whose problem *is* that? > > The users will make it our problem, if we don't get this sorted out soon. Yup, it is. And my perception is that the cat is *out* of the bag, and fretting about how bad it would be were the cat to get out of the bag (which is my perception of most people's view of this issue) isn't especially productive; the solution is to figure out how to manage the problem. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Tue, Jul 05, 2005 at 08:38:41PM +0200, Brad Knowles wrote: > At 9:43 AM -0400 2005-07-05, Jay R. Ashworth wrote: > >> Moreover, most of them are unlikely to be > >> willing to just live with the problem, if no other suitable technical > >> solution can be found. Instead, they'll believe the sales pitch of > >> someone else who says that they can fix the problem, even if that's > >> not technically possible. > > > > Well they might. Well, actually, poorly they might. > > > > But that argument seems to play right *to* the alt-root operators, > > since the "fix" is to switch your customer resolvers to point to one of > > them. > > I disagree. The problem is that there are too many alternatives. To many alt-roots? Or too many alt-TLD's? > > (Assuming, of course, they stay supersets of ICANN, and don't > > get at cross-purposes with one another.) > > The problem is that they are pretty much guaranteed to get at > cross-purposes. Well, there have been alt-root zones available for, what 6 or 7 years now? And how many collisions have there actually been in practice? 2? 3? > >In fact, merging them at your > > resolvers might be the best solution. > > I don't think that's really practical. I'm sorry, I just don't > trust them to write a resolver that's going to get included in libc > (or wherever), and for which the world is going to be dependant. Well, I meant "at your customer recursive resolver servers", since the topic at hand was "what do IAP's do to support their retail customers", but... > The alternative roots will always be marginal, at best. The > problem is that while they are marginal, they can still create > serious problems for the rest of us. In the context which people have been discussing, I don't honestly see how they cause "the rest of us" problems. People with domains *in* those aTLD's, yes. But as I noted somewhere else in this thread, the only people who would have un-mirrored aTLD domains would be precisely those who were evangelising for the concept, and it would be in their best interest to be explaining what was going on... > > But Steve's approach doesn't seem to *me* to play in that direction. > > Am I wrong? > > I'm not sure I understand which Steve you're talking about. Do > you mean Steve Gibbard, in his post dated Sun, 3 Jul 2005 22:20:13 > -0700 (PDT)? I did mean Mr. Gibbard, yes. > If so, then each country running their own alternative > root won't solve the problem of data leaking through the edges. "Data leaking through the edges"... > People will always be able to access data by pure IP address, or > choosing to use the real root servers. Push come to shove, and the > real root servers could be proxied through other systems via other > methods. "Real" is *such* a metaphysical term here, isn't it? :-) > The reverse problem is more difficult to deal with -- that of > people wanting to access Chinese (or whatever) sites that can only be > found in the Chinese-owned alternative root. Stipulated. But whose problem *is* that? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Tue, Jul 05, 2005 at 10:01:22AM -0700, Steve Gibbard wrote: > On Tue, 5 Jul 2005, Jay R. Ashworth wrote: > > But Steve appeared to be suggesting that there was no reasonable way to > > *avoid* problems -- and that's clearly not the case. If I misinterpreted > > Steve, no doubt he'll correct me. But there are two fairly prominent, > > I don't think that was what I said. What I was attempting to say is that > the issue of alternate roots probably isn't something that's worth > worrying about. I see no reason why they'll catch on, other than perhaps > in limited cases where they'll work ok. Catch on in the consumer sense? No, probably not -- though the question is "will IAP's switch their resolver servers to an alt-root" which leads directly to: > In the general case, with alternate roots, there's a chicken and egg > problem. Right now, if you're an end user doing your DNS lookups via the > ICANN root, you can get to just about everything. If you're something > that end users want to connect to, using an ICANN-recognized domain will > mean almost everybody can get to you, while an "alternative" TLD would > mean only a tiny fraction of the Internet would be able to get to you. > So, if you're a content provider, why would you use anything other than a > real ICANN-recognized domain? And, if the content providers aren't using > real domain names, why would an end user care about whether they can get > to the TLDs that nobody is using? Two points: 1) this speaks to the same issue as my comments the other day on the IPv6 killer app, though it's admittedly even harder to posit a site which would do this. 2) Based on the events earlier in the week, I believe that's a "US Department of Commerce" approved TLD... which changes the game a little bit. > This is the same phonomenon we saw ten years ago, as the various "online > services," GENIE, Prodigy, MCIMail, Compuserve, AOL, etc. either > interconnected their e-mail systems with the Internet or faded away and > died. As the Internet got more and more critical mass, there was less and > less incentive to be using something else. It's been a long time since > I've seen a business card with several different, incompatible, e-mail > addresses printed on it, and that's because something simpler worked, not > because people screamed loudly about the falling sky. Certainly. But there weren't geopolitical implications there, merely commercial ones. I think the stakes may be a bit higher here, particularly in the case we were using as an example: China. > The exceptions to this that I see would be either when somebody comes out > with something that is so much better that it's useful in spite of a lack > of an installed userbase (Skype may be doing this to phone calls), Yup. Killer apps are great. Hard to predict; *really* hard to invent. > or when > something is rolled out to a large enough self-contained user community > that the lack of ability to communicate outside that region won't be a > significant barrier. If a few large countries were to roll out alternate > root zones nation-wide, in such a way that they worked well for domestic > communication, but couldn't be used for international stuff, *maybe* that > would be good enough to catch on. But still, anybody wanting to > communicate outside that region or userbase would probably find they were > much happier using addresses that met global standards. But again, you're positing that someone would create a root zone that *purposefully* conflicted with the current one, which doesn't seem supported by history, much less common sense. Am I wrong that you mean that? > So anyhow, that's a long way of saying that, just as this hasn't gone > anywhere any of the many other times it's been raised over the last > several years, it's unlikely to go anywhere, or cause problems, this time. Maybe. China's *really* big. America's *really* unpopular, in some places. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Tue, Jul 05, 2005 at 10:08:35AM +0200, Brad Knowles wrote: > At 10:32 PM -0400 2005-07-04, Jay R. Ashworth wrote: > > But the whole "there's a non-ICANN root: the sky is falling" thing is > > an argument cooked up to scare the unwashed; us old wallas don't buy > > it. > > That's because you understand the underlying technology, and you > understand how to deal with the problem (including understanding that > you may just have to live with it). Yep. > Most people don't understand the underlying technology or the > true nature of the problem, nor are they capable of doing so. All > they know is that their e-mail doesn't work, or they can't get to the > web pages they want. And for them, this is a very real problem. Yep. > Since there's a lot more of them than there are of us, and we're > the ones who are likely to be operating the systems and networks > where these people are our customers, when they have a problem, that > creates a problem for us. Moreover, most of them are unlikely to be > willing to just live with the problem, if no other suitable technical > solution can be found. Instead, they'll believe the sales pitch of > someone else who says that they can fix the problem, even if that's > not technically possible. Well they might. Well, actually, poorly they might. But that argument seems to play right *to* the alt-root operators, since the "fix" is to switch your customer resolvers to point to one of them. (Assuming, of course, they stay supersets of ICANN, and don't get at cross-purposes with one another.) In fact, merging them at your resolvers might be the best solution. > Okay, the sky may not be falling. Maybe it's just the Cyclorama, > or the fly grid. But when the actors are on stage and one of these > things falls, there's not much practical difference. And us techies > are the ones that have to pick up the pieces and try to put them back > together again. Isn't it the truth. But Steve's approach doesn't seem to *me* to play in that direction. Am I wrong? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Tue, Jul 05, 2005 at 01:14:08AM -0400, [EMAIL PROTECTED] wrote: > On Mon, 04 Jul 2005 22:32:52 EDT, "Jay R. Ashworth" said: > > Well, Steve; that reply is a *little* disingenuous: all of the > > alternative root zones and root server clusters that *I'm* aware of > > track the ICANN root, except in the rare instances where there are TLD > > collisions. > > And *that* is just a tad disingenuous itself. If you have 1 alternate > root that tracks ICANN's dozen-ish TLDs and the country-code TLDs, and > then adds 2-3 dozen of its own, there's little room for amusement. > If however, you have a Turkish root that tracks ICANN's dozen, and > then adds 50 or 60 of its own, and a Chinese root that tracks ICANN's > dozen, and then adds 75 or 100 of its own, it becomes interesting to > watch a Turkish user try to reach one of those 75 Chinese TLDs, or the > Chinese user try to reach one of the 50 Turkish additions, or either > of those users trying to reach the *.special-sauce domain the first > alternate root created. > > A collision isn't the only failure mode to worry about And I didn't say it was, Valdis. I am fairly familiar with the potential problems of conflicting root zones, and, to date, I observe that -- in general -- they have fairly consistently failed to occur. Indeed, though, if governments get into the act, things are more likely to get broken. But Steve appeared to be suggesting that there was no reasonable way to *avoid* problems -- and that's clearly not the case. If I misinterpreted Steve, no doubt he'll correct me. But there are two fairly prominent, widely operated alternate root zones out there, ORSC, and P-R, which don't collide as far as I know, and between them probably account for a large percentage of the .01% of networks resolving off of non-ICANN roots. Seems to me any country wanting to build an alternate ccTLD and choosing one which is available in both those roots and not known to be planned as an active TLD at ICANN would be in pretty good shape. And don't most of us consider ourselves engineering types here? You deal with what *is*, not what you'd *like* to be. Sure, multiple, only informally synchronized roots aren't the best state of affairs. But they don't exist simply because one guy thought it would be cool; this isn't Joe's Bar and Root Zone we're talking about here... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Sun, Jul 03, 2005 at 10:20:13PM -0700, Steve Gibbard wrote: > On Mon, 4 Jul 2005, Mark Andrews wrote: > >> Do I need to modify our cache server configuration to > >> enable it? > > > > Only if you wish to do all your other customers a disfavour > > by configuring your caching servers to support a private > > namespace then yes. > > There's no particular technical magic to the ICANN-run roots, except that > it's what just about everybody else is using. This means that if you > enter the same hostname on two computers far away from each other, you're > probably going to end up at the same place, or at least at places run by > the same organization. This standardization is valuable, so anybody > trying to make a different standard that isn't widely used compete with it > is going to have a hard time convincing people to switch. > > That doesn't mean a competing system wouldn't work, for those who are > using it. They'd just be limited in who they could talk to, and that > generally wouldn't be very appealing. Well, Steve; that reply is a *little* disingenuous: all of the alternative root zones and root server clusters that *I'm* aware of track the ICANN root, except in the rare instances where there are TLD collisions. I'm not aware of any such specific collisions; I stopped tracking that area when NetSol shutdown that mailing list without warning several years ago. I merely observe that they're possible. > A system that would limit my ability to talk to people in other countries > doesn't sound very appealing to me. On the other hand, the Chinese > government has been trying hard to limit or control communications between > people in China and the rest of the world for years. In that sense, > maintaining their own DNS root, incompatible with the rest of the world, > might be seen as a considerable advantage. If they don't care about > breaking compatibility with the DNS root the rest of the world uses, the > disadvantages of such a scheme become fairly moot. Eric Raymond, that polarizing ambassador for open source, likes to disseminate the word (and concept) "conflating" -- that being the habit, or attempt, by an arguer of a point to hook together two related but distinct concepts that may both be involved in a topic, but may not have the cause and effect relationship being implied by said arguer. This is a good example, IMHO: Even if China *did* maintain their own root, unless they also maintained their own copies of the 2LD's, like .com, they couldn't snip out *specific* sites they didn't want people to see. But the whole "there's a non-ICANN root: the sky is falling" thing is an argument cooked up to scare the unwashed; us old wallas don't buy it. I just hope none of the unwashed *press* decide to blow the lid off of it; the public's lack of understanding of the underpinnings of the net is painful enough now... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Fundamental changes to Internet architecture
On Sun, Jul 03, 2005 at 02:08:39PM -0700, Joel Jaeggli wrote: > On Sun, 3 Jul 2005, J.D. Falk wrote: > > On 07/03/05, "Jay R. Ashworth" <[EMAIL PROTECTED]> wrote: > >> How do we *know* there are no fundamentally new great concepts ... > >> unless we *try a lot of stuff*. > > > > Trying stuff is good -- until something's tried, none of us can > > really know what it'll do. At what point do entirely off-network > > experiments become on-topic for nanog? (I doubt anyone has an > > easy answer, I just wanted to throw the question out there.) > > > >> How many light bulbs did Edison throw away? > > edison didn't invent the light bulb... So he didn't. And me a regular Wikipedian... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: OMB: IPv6 by June 2008
On Thu, Jun 30, 2005 at 09:29:04PM -0400, Todd Underwood wrote: > heh. i guess i'll have to live without the dancing turtle, and so > will all the other Internet users. i wonder what other useful content > is not available on the real Internet and only available via ipv6. i > keep asking this question and keep getting non-answers like this. Well, with all due respect, of *course* there isn't any 'killer site' that is v6 only yet: the only motivation to do so at the moment, given the proportion of v4 to v6 end-users, is *specifically* to drive v4 to v6 conversion at the end-user level. So we're only likely to see that in exactly a case like the government mandated conversion--mean to say it will likely be some government internal b-to-b'ish site that crops up first as v6 only, and then the usual S-curve of conversions amongst other government sites, slowly dribbling over into b-to-c'ish stuff... which will be what pulls the rest of us along. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Fundamental changes to Internet architecture
On Fri, Jul 01, 2005 at 09:50:03AM -0700, Randy Bush wrote: > the problem is that there are really no fundamentally new great > concepts. so this is likely doomed to be yet another second > system syndrome. And the world demand for computers might someday approach 100? How do we *know* there are no fundamentally new great concepts ... unless we *try a lot of stuff*. How many light bulbs did Edison throw away? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Fundamental changes to Internet architecture
On Fri, Jul 01, 2005 at 10:44:33AM -0500, John Dupuy wrote: > However, philosophically: security=less trust vs. scalability=more trust. > intelligent=smart-enough-to-confuse vs. simple=predictable. Thus, a very > Intelligent Secure network is usually a nightmare of unexplained failures > and limited scope. Counter-example: SS7. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: NTIA will control the root name servers?
On Fri, Jul 01, 2005 at 03:28:23PM -0700, Randy Bush wrote: > > Basically it sounds like the U.S. Gov't (NTIA)/U.S. Dept of Commerce > > will take back control of the root name servers from ICANN at some > > point. > > no. they never let go of it. a change to a nameserver for an > african cctld has to go through the us dept of commerce. they > are saving us from terrorists such as liman. don't you feel > safe? Not that anyone around here thinks Declan McCullagh is an authority or anything (:-), but Kai Ryssdal interviewed him about this on tonight's Marketplace; the piece, modulo a couple of "root server"'s and "web address"'s, is here: http://marketplace.publicradio.org/shows/2005/07/01/PM200507012.html Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: ATM
On Wed, Jun 29, 2005 at 06:06:38PM +, [EMAIL PROTECTED] wrote: > On Wed, Jun 29, 2005 at 01:33:14PM -0400, Jason Frisvold wrote: > > On 6/29/05, Randy Bush <[EMAIL PROTECTED]> wrote: > > > indeed! i use them often. remember when you had to go into the > > > bank and wait in a queue for a teller? > > > > Hopefully soon to be replaced with RFID machines with voice activated > > commands.. :) > > > > Speaking of which.. It's 2005.. Where's my flying car? > > your flying car awaits http://www.moller.com/skycar/ So why didn't John Walton give that guy some money? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: ISP phishing
On Tue, Jun 28, 2005 at 04:35:30PM -0500, Brad Knowles wrote: > Fortunately for me, all the phishing attempts were pretty stupid, > and failed because they relied too much on Windows-specific attacks, > Windows-specific MUAs, etc In my case they were merely amusing. If there *were* an [EMAIL PROTECTED] it'd be me. Good to see some people are trying, though... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Brand X decision could mean widespread VoIP blocking
On Tue, Jun 28, 2005 at 03:51:08PM -0500, Frank Coluccio wrote: >I commented independently concerning the same issue just a little >while ago, at: > >http://www.siliconinvestor.com/readmsg.aspx?msgid=21457409 > >re: > > >"The question may now become if consumer can order Vonage, 8x8, ... >VoIP service, riding the cable Internet service." > >---begin snip: > >Agreed, that is a major question. There is nothing that binds the MSOs >to continue carrying the parasitic services you cited except for good >will, Parasitic services? Good will? I believe, Frank, that you and $LOTS_OF_CUSTOMERS_INCLUDING_ME have differing views of what service it is, exactly that broadband customers (think) we're paying for. While few of the consumer broadband providers explicitly say "unfiltered routeable IP access to 'the Internet'", *none* of them say "access to websites and we don't guarantee anything else"... at least not in letters tall enough to make the FTC happy. Oh... did I imply that broadband carriers might trigger a wash of consumer complaints to the FTC if they started blocking service the customers wanted to use without clear advance notice? :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Brand X decision could mean widespread VoIP blocking
On Tue, Jun 28, 2005 at 08:35:31PM +, Fergie (Paul Ferguson) wrote: > > -- "W. Mark Herrick, Jr." <[EMAIL PROTECTED]> wrote: > > >Jeff Pulver makes a good point in a Forbes article > > >when he says "I believe it's a matter of when, not > > >if" providers start blocking VoIP traffic from > > >competitors across their own infrastructure, especially > > >on the heels of the Brand X SCOTUS ruling. > > > > > >"If I'm a service provider offering my own voice > > >over broadband offering, and I've got the ability > > >to block my competition, why not?" > > > > Harold Willison, my peer and Director of HSI Transport, Design, and > > Engineering at Adelphia, explains exactly why that would not be a fantastic > > idea, in the following article: > > > > http://www.ct-magazine.com/archives/ct/0605/0605_internetprotocol.htm > > I tend to agree with Mr. Willison. ;-) Smartalec. :-) Willison correctly takes both sides of the issue, which, as usual, is an elephant: how you see it depends on where you stand. I thought, as you did, Ferg, that he did a good job illuminating what the sides are, and how to best interact with all of them: Don't block unless you have to to be secure; work with the providers to nudge their protocols into the most easily securable form. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Outage queries and notices (was Re: GBLX congestion in Dallas area )
On Wed, Jun 08, 2005 at 07:11:21PM -0400, David Andersen wrote: > On Jun 8, 2005, at 4:46 PM, Jay R. Ashworth wrote: > > On Wed, Jun 08, 2005 at 06:30:50PM +, Fergie (Paul Ferguson) wrote: > >> What's the matter with simply using the mailing list? > >> Don't reinvent the wheel. > > > > For precisely that reason, I, personally, am on your side. > > It's not the *best* solution, but it's probably the least worst. > > As a comment from the research side - I know several people who've > ended up combing the NANOG mailing list archives for outage reports of > various sorts (myself included). Perhaps a great middle step on this > if people were to agree on a quasi-maybe-slightly-standard format for > reporting outages to the mailing list, so that the statistics gathering > types can mine through and get at the data. > > I'm not suggesting that all mail to nanog be XML-encoded goop, but some > loose text convention might help move things along nicely. Over time, > I suspect that a general consensus style would emerge. Probably RFC-822 style headers between ==BEGIN OUTAGE== and ==END OUTAGE== or something akin to that. It remains easy to parse, especially by the most likely subect, perl. A subject-line tag is probably not out of the question, either. But, of course, we're figuring out the best way to implement something that we haven't completely decided is the best idea. :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Outage queries and notices (was Re: GBLX congestion in Dallas area )
On Wed, Jun 08, 2005 at 06:30:50PM +, Fergie (Paul Ferguson) wrote: > What's the matter with simply using the mailing list? > Don't reinvent the wheel. For precisely that reason, I, personally, am on your side. It's not the *best* solution, but it's probably the least worst. Cheers, -- jr 'guantanamo-l' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Outage queries and notices (was Re: GBLX congestion in Dallas area)
On Wed, Jun 08, 2005 at 02:35:42PM -0400, Hannigan, Martin wrote: > > Well, that's fine, at the transport layer, but I think more an > > application layer solution is called for. > > > > Something akin to news.announce.important on Usenet? > > How about [EMAIL PROTECTED] Oddly, that's my approach, yes. The problem is threefold: robustness and deployment (email tends to win, by and large), people listening, and people talking. NANOG, as a list, wins on both of the latter points. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Outage queries and notices (was Re: GBLX congestion in Dallas area)
On Wed, Jun 08, 2005 at 09:22:02PM +0300, Petri Helenius wrote: > Jay R. Ashworth wrote: > >The Internet needs a PA system. > > There is this sparsely deployed technology called multicast which would > work for this application. Well, that's fine, at the transport layer, but I think more an application layer solution is called for. Something akin to news.announce.important on Usenet? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Outage queries and notices (was Re: GBLX congestion in Dallas area)
On Tue, Jun 07, 2005 at 06:40:10PM -0400, Dave Stewart wrote: > At 06:12 PM 6/7/2005, you wrote: > >If we started posting about every fiber cut of every carrier anywhere in > >North America every time it happened there wouldn't be any room left on > >this list for talking about spam, senderid, DNS RFCs, E911 for VoIP > >carriers, err... wait which side am I arguing again? :) > > I don't operate even a mid-size network, but when there's an outage that > effects more than a handful of locations, it's useful to know about it... > > Not that there's anything I can do about it... but when customers are > calling and asking why they can't reach their application servers, it's > nice to be able to tell them there's a problem at $location and that no, I > don't know when it'll be fixed, but they can be sure it's being worked on. > > But I think NANOG is certainly an appropriate forum for medium/large-scale > outages - unless someone's created an outage list someplace. >From down here, like Dave, at the relative bottom of the food chain, I must agree with him and Steve, though I do understand Richard's concerns there, and they're valid ones. The Internet needs a PA system. Problem is, the people who are equipped to talk, and, by and large, many of the people who want to listen, are all *here*. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Battery Maint in LEC equipment
On Sun, Jun 05, 2005 at 12:56:34AM -0400, Sean Donelan wrote: > I've been wondering when the building codes will be updated. Currently > the building codes require backup generators for elevators in high-rise > buildings, but not for the telecommunications room in high-rise building > (other than the fire alarm). Instead of pulling individual copper pairs > from a POP to the high-rise building, a CLEC may install a fiber mux in > the basement and break-down individual circuits locally to copper. When > the building looses power, so does the fiber mux. > > Of course, adding batteries to the fiber mux doesn't solve the problem of > PBXs or even modern pay telephones in office buildings not working when > power fails. > > Who replaces the battery in your cell phone when it expires? How about > the battery in your cordless phone? Or the battery in your smoke alarm? > > If you don't want to do it yourself, for a fee you can hire someone else > to do it for you. But then people would complain about the fee, and how > they could do it themselves for less. Well, this seems akin to the old "FOB Point" conversation in wholesale and retail sales: "what is the service point?" Or, more clearly: "whose responsibility it is to make sure that the service is available at the service point?" It seems a contractual issue, to me, in those cases where it's not a regulatory one. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Needed : AOL Network Contact
On Mon, Jun 06, 2005 at 10:25:29AM -0400, David Brinks wrote: >I seem to have a couple Class Cs that AOL's portal servers are >blocking and I would like to contact someone at AOL to discuss getting >the blocks removed. I've tried going through their tech support but >after multiple dead-ends and being told "AOL is a content provider and >doesn't have Network Support group, nor servers nor any people who >take care of servers" multiple times I'm wondering if any one you may >have a backside phone number or email I could try. > >(I've already tried the number listed in their whois information but >that only gets met to their Postmaster group and they also tell me >they have no group that takes care of routers, IPs or servers.) This seems like a good time to point out once again Jared Mauch's list of NOC contact numbers. If that's not a sufficient hint to let you find it, now that you know it exists, let me know offlist, and I'll mail you the URL. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: OT: NOC Display's
On Thu, Jun 02, 2005 at 08:54:39AM -0400, Spencer Wood wrote: >Anyway, in our NOC we current have two LCD projectors displaying >outputs from two different computers. On one of the display's, I >would like to be able to take 4 VGA outputs from 4 workstations, and >display it on the screen (aka: Hollywood square style). Does anyone >have any recommendations for an inexpensive device that will take care >of this? I have found some nice devices in the 10k price range, which >needless to say is a little outside the budget. Security companies >sell these devices for Video for around $500, so I'm figure someone >should have a VGA version of the device. A VGA (much less XVGA, which is probably what you really need) quad splitter is likely to be pricey as crap. I'd recommend looking at using VNC from the workstation you have now to pick up the screens you need. Check out: http://www.csd.uwo.ca/staff/magi/doc/vnc/extras.html and specifically John Wilson's VNCMonitor, at: http://www.wilson.co.uk/Software/vnc/VncMonitor.htm which sounds like it will do the splitting for you. I've never used it personally, but it sounds like it might do what you need. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Stanford Hack Exposes 10,000
On Thu, May 26, 2005 at 11:10:08AM +0100, [EMAIL PROTECTED] wrote: > > > Around about whenever the US Federal Government gets the hint and > > > passes a bill which makes it illegal to use social security numbers > > > for any purpose other than the administration of social security. > > Wrong answer. Federal laws do not stop people from doing stupid > things and they do not stop people from doing illegal things. > > What we need is a Hollywood blockbuster in which some highschool > hackers wreak havoc by aquiring SSNs from gradesheets and using /// criminals > mother's maiden names to steal lots of money and identities. > Then, pointy-haired bosses will ask their sysadmins to make sure > that it can't happen in their department. > > Hollywood movies change people's behavior. Federal laws do not. "Mr President, did you see that movie about an Ebola outbreak in the US a couple of years ago?" "Yes...?" "The budget for that movie was quite a bit more then the total annual funding in the US to study Ebola and related viruses." Cheers, -- jr '' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Stanford Hack Exposes 10,000
On Thu, May 26, 2005 at 09:49:06AM +0930, Mark Newton wrote: > On Wed, May 25, 2005 at 05:12:18PM -0700, Adam McKenna wrote: > > On Wed, May 25, 2005 at 11:59:17PM +, Fergie (Paul Ferguson) wrote: > > > Yet another unfortunate disclosure... > > > http://www.techweb.com/showArticle.jhtml?articleID=163701121 > > > > I wonder when schools are going to get the hint and stop using SSN's as ID > > numbers.. > > Around about whenever the US Federal Government gets the hint and > passes a bill which makes it illegal to use social security numbers > for any purpose other than the administration of social security. Though that isn't the major problem. The major problem, as has been pointed out in Privacy and RISKS digests in the past dozens of times, is that people persist in using as authenticators things (like SSN's, Mother's Maiden Name, etc) which are patently not suitable for that. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: soBGP deployment
On Mon, May 23, 2005 at 02:00:12PM -0400, Daniel Golding wrote: > One of the Internetworking community's biggest problems is a fixation on the > perfect solution. Its natural - we're engineers, after all. We want an > elegant 100% solution to our ills. This often leads to something that never > gets implemented in real life. But it's worth noting here that there's a good reason for that: It's *miserable* to replace a fundamental protocol with insufficiently forward-thinking design decisions, too. Viz: IPv6. So the real question is: where's the happy medium? Cheers, -- jr 'first person who says "NBC" is fired' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth & Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Underscores in host names
On Thu, May 19, 2005 at 08:52:56AM -0700, Roger Marquis wrote:
> Most definitely not, and if this were 1985 I'd be {rf}commenting on
> the inadvisability of such hostnames, and those beginning or ending
> with "-", TLD names shorter than 2 or longer than 4 characters,
> spaces in hostnames, [^a-z0-9\\-\\.], and other such marginally
> useful but infinitely problematic features.
I understand your other concerns, there, but TLD length?
To preserve assumptions in old apps?
Cheers,
-- jra
--
Jay R. Ashworth[EMAIL PROTECTED]
Designer Baylink RFC 2100
Ashworth & AssociatesThe Things I Think'87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
If you can read this... thank a system administrator. Or two. --me
Re: Underscores in host names
On Thu, May 19, 2005 at 12:01:54PM -0300, MARLON BORBA wrote: > Hmm, they've always teached to me that . (dot) at the end of hostnames > indicates the (hidden) Root domain: > > blah.domain.com.[Root] This much is true. > And my teachers always said that we don't need to write the final . > because every domain belongs to the Root domain. This, not so much. Well, kinda. Specifically, as I think was noted earlier on the thread in passing, as well, that trailing dot is a hint *to your local name resolver* that says "do not attempt to apply any locally defined DNS search path to this name; look it up once, anchored to the DNS root[0], and if you get an NXDOMAIN, believe it". Semantically, that trailing dot, as it is presented to an application, *is not part of the domain name*. It's ephemeral; only existing on the machine where you type it in -- specifically, it does not get sent in queries (SFIAK), even if you typed it in. So, no, you *don't* need to write it, unless you as an application user are trying specifically to pin the name on the root... but it's invisible to the rest of the system, just as the names themselves are invisible to the TCP stack once you've looked them up and opened a stream. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Underscores in host names
On Thu, May 19, 2005 at 11:47:09AM +0200, Brad Knowles wrote: > At 3:39 PM +1000 2005-05-19, Mark Andrews wrote: > > Any tld that thinks this will ever work reliably need their > > heads read. There was a good reason all the unqualified > > hosts got moved into .ARPA. Single label hosts do not work > > well on a global scale. > > No, they don't, but .ws and .gw are not going to be the only ones > doing this kind of thing, and this problem won't go away unless > something is done to expressly prohibit this kind of behaviour. Perhaps I left my program in the men's room, but wasn't the point of this thread that "something has already been done to prohibit this"? IE: 2821 says that's an invalid address? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer InternetworkingRFC 2100 Ashworth & Associates Best Practices '87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Underscores in host names
On Wed, May 18, 2005 at 11:08:03AM +1000, Mark Andrews wrote: > In article <[EMAIL PROTECTED]> you write: > >Hello all. > >We have a client containing an underscore in the email address domain > >name. Our email server rejects it because of it's violation of the RFC > >standard. This individuals claim is that he doesn't have problems > >anywhere else and if this is going to be a problem he's "going to take > >his business elsewhere"! > > > >I understand it's a violation of the standard, but does it pose a > >security hole to the email server to allow this sort of mail? > > RFC 952 and RFC 1123 describe what is currently legal > in hostnames. > > Underscore is NOT a legal character in a hostname. > > Before anyone says that domain names allow underscore which > they do. > > RFC 1034 Section 3.3 > > For hosts, the mapping depends on the existing syntax for host names > which is a subset of the usual text representation for domain names, > together with RR formats for describing host addresses, etc. Because we > need a reliable inverse mapping from address to host name, a special > mapping for addresses into the IN-ADDR.ARPA domain is also defined. > > Mail domains follow the same rules as for hostnames. RFC > 821 and its replacement RFC 2821 havn't extended the syntax > to include underscores. Those with long memories will remember when Apple got strict on this years ago, and lots of websites became unreachable to their users... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: what will all you who work for private isp's be doing in a few years?
On Wed, May 11, 2005 at 12:29:43PM -0700, Bruce Pinsky wrote: > ISDN, and other on-demand technologies. The AUPs, filtering policies, > routing policies, etc of cable operators are simply not geared to meet the > needs of even the most simplistic of corporate requirements. FSVO "* policies". Bright Hose Tampa Bay's business account policies are certainly loose enough for all of my clients, at least, as well as my own server garden. [0] Cheers, -- jra [0] if I called 4 servers a "farm", someone would laugh at me[1]. [1] more than they already do. -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Providing location information to IP end-nodes
f the *cellphone*. The Bluetooth layer is clearly unuseful, so we ignore it. The next thing is IP. The phone is acting like either an ethernet adapter, or a cell-modem. In either case, it is (virtually) the laptop's network adapter, and it can (possibly via emulation) either acquire or send IP packets with lower-layer identifiers that will denote which tower the phone was talking to. Some piece of equipment at the carrier can then use that to do a short lookup to a locally maintained tabel (this data does not change all that rapidly, TTBOMK), and return an appropriate reply. This clearly requires bridging levels, but that's not that big a deal, is it? That was a bit of a rough example, as I'm sure you intended, but while other topologies are easier to manage, the point remains that there *is* some way to acquire *some* useful information of about the location of an endpoint, to a granularity good enough for the "which PSAP" problem, which can be designed for (and into) the necessary equipment which provides that topology. Certainly some are more difficult than others; some types of gear replacement-cycle slower than others. But it seemed to *me* that the point of the whole thread either was, or should have been, to figure out the solution before the FCC (who are guaranteed to screw it up) did it for us, no? That end doesn't seem to me to be served by the tenor of and contributions to the thread as I saw it. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: On the record - debunking technical fallacies
On Tue, May 03, 2005 at 04:40:51PM +0100, [EMAIL PROTECTED] wrote: > However, Jay Ashworth has now set up the Best Practices wiki at > http://bestpractices.wikicities.com/wiki/Main_Page > Perhaps that is a better place to have these technical > arguments? Thanks for the plug, Michael. Knowing this crowd (and I don't excuse myself, there) as I do, I've even created an obvious mechanism for dealing with the circumstance wherein different people differ on the appropriate approach to a problem or situation; hopefully this will avoid the sort of problems that get everyone mad at me here :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: FCC To Require 911 for VoIP
On Sun, May 01, 2005 at 10:56:57PM -0400, Hannigan, Martin wrote: > > The PBX intercepts the call and uses special trunks to the PSAP; > > it also has to send data telling where the caller is. > > There are no special trunks to the PSAP from a PBX. Actually, Martin, there are. For E-911 campus-type service, at least. You apparently need to use either a PRI or a CAMA trunk to extend the calling PBX extension number to the PSAP, so it can ALI the appropriate location for the dispatcher. See http://www.911etc.com/pbx_solutions.html as well as http://www.xo.com/products/smallgrowing/voice/local/psali/ Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: FCC To Require 911 for VoIP
On Sun, May 01, 2005 at 11:56:50PM -0400, David Lesher wrote: > Alas, Gamewell fire boxes are all but dead. I don't know of any > city still running them. Too bad, because it was a dirt-simple > technology that Just Plain Worked. Looks like they were first > deployed in the 1850's. I believe that there's a chance Westwood MA might still have some; they hadn't yanked them out yet by 1981 when I moved. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: FCC To Require 911 for VoIP
On Sun, May 01, 2005 at 09:20:21PM +0200, Brad Knowles wrote: > Where's the zipcode? Aw, hell, people; of course it's not a one layer problem. But only being able to participate in nanog one day a week has clearly ticked some folks off again; crawling back into my cave now. Thought this was the NFL. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: FCC To Require 911 for VoIP
On Sun, May 01, 2005 at 09:51:33AM -0700, Bill Woodcock wrote: > That said, a widely-implemented well-known anycast address that would > give you location information is a really cool idea. A smoother > imlementation might be to just have a well-known address that you'd > do a DNS LOC query against, since describing locations better than > postal-codes do is a problem the DNS folks have already solved. Which address would resolve differently, depending on which DNS server you're talking to? I'm not sure that's good enough; being able to identify the *network ingress point* is the thing I'm after. For wired connections, that's the access concentrator, for wireless ones, the nearest tower. It would be necessary to be able to tailor the response to the inquiry based on that, I think, to fulfill the requirement *I'm* trying to fulfill in this posited design -- which is not guaranteed to be the same as any possible regulatory requirement. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: FCC To Require 911 for VoIP
On Sun, May 01, 2005 at 12:55:16PM -0400, David Lesher wrote: > Speaking on Deep Background, the Press Secretary whispered: > > > How about an anycast address implement(ed|able) by every network > > > provider that would return a zipcode? > > > > > > $ telnet 10.255.255.254 > > > Connected > > > 33709 > > > Disconnected. > > > > is there a unique zipcode in shanghai? > > And even Zip+4 plus whatever they have now added to it will > not meet Big Brother's requirement in the USA. My issue, David, is not "where is the user exactly?", it's "which PSAP do I route to?". Something on the close order of a US ZIP Code is fine for that. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: FCC To Require 911 for VoIP
On Sun, May 01, 2005 at 04:38:10PM +, [EMAIL PROTECTED] wrote: > > How about an anycast address implement(ed|able) by every network > > provider that would return a zipcode? > > > > $ telnet 10.255.255.254 > > Connected > > 33709 > > Disconnected. > > $ > are you -REALLY- arguing for the return of "finger" ?? I thought it was clear that I was not. To expand: the problem is the VoIP client being able to *furnish* an approximation of where it is, to permit the selection of the proper Public Safety Access Point (or equivalent). If each end-router supplied that data, through *some* easily queriable protocol, such clients could retrieve it, and then decide (in some fashion) where to send Emergency Services Request calls (or furnish it to their carrier, if they have one, for similar purposes). I Am Not An ISP, Either, but this problem doesn't seem *all* that hard to solve to me... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: FCC To Require 911 for VoIP
On Sun, May 01, 2005 at 04:37:40PM +, Christopher L. Morrow wrote: > On Sun, 1 May 2005, Jay R. Ashworth wrote: > > How about an anycast address implement(ed|able) by every network > > provider that would return a zipcode? > > > > $ telnet 10.255.255.254 > > Connected > > 33709 > > Disconnected. > > is there a unique zipcode in shanghai? s/zipcode/unique geographic identifier on the rough order of a square mile/ Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: FCC To Require 911 for VoIP
On Thu, Apr 28, 2005 at 06:12:25PM -0700, Owen DeLong wrote: > I submit that I don't necessarily want my communications device or my > location tracked at all times by the government. My point is not the > need for location, but, that it is impractical to reliably implement > the traditional 911 model for VOIP. > > The traditional 911 model depends on being able to make determination > of at least a roughly correct 911 service provider based on connection > point. (Cell site, telco central office, service location, etc.). > > None of these are available for many VOIP services. I think that if > the focus were on delivering 911 service for fixed-location VOIP > systems, it would make much more sense. However, the FCC, so far, > does not seem to understand that this distinction is possible or > relevant. How about an anycast address implement(ed|able) by every network provider that would return a zipcode? $ telnet 10.255.255.254 Connected 33709 Disconnected. $ Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Schneier: ISPs should bear security burden
On Fri, Apr 29, 2005 at 02:07:17AM -0700, Dave Rand wrote: > Dunno what a ton of ISP buy-in is, but the MAPS DUL now contains about > 190,000,000 entries. We've been working on it very hard for the last year or > two. Most ISP-level subscribers figure it stops a pretty large percentage of > the compromised-home-computer spam. Ok, so here's a question for your, Dave: do you have a procedure for entertaining requests to be excluded from your replies from people with legitimate needs to operate MTA's, who have been given (let us say) static addresses by their providers which fall within a range you understand to be dialup? (I'm assuming you include cable and DSL end-user address pools; this is the sort of thing I'm asking about.) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Schneier: ISPs should bear security burden
On Thu, Apr 28, 2005 at 05:01:42PM -0500, John Dupuy wrote: > If one is going to use the car analogy, then the ISP is the street, not the > car. The car is the user's computer or customer premise equipment. Streets > do not have airbags. (Though that is an interesting concept.) At best, > streets have features that influence safety & traffic such as stop signs > and guard rails, but even a well designed street does not actually prevent > car accidents or dictate what kind of person is riding in a car. I disagree. The street is the transit providers. Road Runner is the car. (Well, *bus*, actually :-). If I put my kid on the bus, yes, I expect it to protect him. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Schneier: ISPs should bear security burden
On Thu, Apr 28, 2005 at 03:13:06PM -0700, Owen DeLong wrote: > Your statement that their price point is lower is absurd. It costs money > to put filters in place. It doesn't cost money to not filter, except to > the extent that irresponsible actions which filtration would prevent are > not blocked. Therefore, any increased costs in unfiltered connections > are the direct result of irresponsible use. Absent irresponsible use, > unfiltered connections will, by definition, cost less. In this context, Owen, why isn't that a circular argument? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Schneier: ISPs should bear security burden
On Thu, Apr 28, 2005 at 08:03:57AM -0500, Olsen, Jason wrote: > > You must not have used it much in those 20 years. I can > > definitely say worms, trojans, spam, phishing, ddos, and > > other attacks is up several orders of magnitude in those 20 > > years. > > The userbase has also increased by several orders of magnitude beyond > that. > > 1% "bad" traffic at 100 users: 1 > 1% "bad" traffic at 1,000,000 users: 10,000 And this raises an absolutely excellent stand-alone point that seems to me to be something that netops types should be keeping uppermost in their minds: When a problem gets big enough, it's a *different* problem, not just a bigger problem. An analogy to this (actually, a result of it) is the difference between the office policies in a 5-person company and a 500-person one, or a town of 10,000 and a city of 400,000. This seems to bear on almost everything I've seen said in this thread (which is the award winner for the year so far...) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Schneier: ISPs should bear security burden
On Wed, Apr 27, 2005 at 12:56:00PM -0700, Owen DeLong wrote: > Not only do I not know this, I find it to be patently false. Yes, I think > a high percentage of users is too ignorant to know what they need or how > to get it. However, protecting them from that ignorance only propogates > and perpetuates it. Pain is one of natures most effective educators. Fine. But the pain doesn't *hurt* the people who cause it. See also: Tragedy of the Commons. http://en.wikipedia.org/wiki/Tragedy_of_the_Commons if you didn't have a better explanation handy. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Schneier: ISPs should bear security burden
On Wed, Apr 27, 2005 at 08:06:51AM -0400, Greg Boehnlein wrote: > On Wed, 27 Apr 2005, Fergie (Paul Ferguson) wrote: > > I've been there -- I know how I feel about it -- but I'd love > > to know how ISP operations folk feel about this. > > Of course Bruce Schneider is going to allocate ISP's handling security so > he can sell them more of his crappy Counterpane products. I find it > offensive that Mr. Schneider would categorize ISPs as lazy and > unresponsible, and it does nothing but encourage me to sell anything BUT > Counterpane to my customers. He doesn't, as noted, sell much by way of "products"... and please spell his name correctly. Cheers, -- jr 'or is that the New Age spelling?' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Schneier: ISPs should bear security burden
On Wed, Apr 27, 2005 at 09:25:55AM -0400, Edward Lewis wrote: > It would be nice if the ISPs protected me from bad stuff on the > Internet - but why are they to be held to a higher standard than > similar services? Have we drifted? I thought the topic was "tragedy of the commons", not "protect the end users"...? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: clarity
On Wed, Apr 27, 2005 at 04:12:57AM -0700, Owen DeLong wrote: > > If you want to compare this to ISP, it would be like me having peering > > agreement and direct connection with few dozen content providers > > and only giving access to users to those few dozen websites. > > Perhaps I should have used electric companies as a better example. No, I think that water is actually better: it's easier for an end-user to cause problems with delivered water than with delivered electricity... though admittedly *neither* is "easy", as we usually use that term. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: clarity
On Wed, Apr 27, 2005 at 03:19:04AM -0700, Owen DeLong wrote: > > perhaps you mis-read. water companies -always- > > add things to water, to kill off germs, balance mineral content, > > etc.. they do this to -meet- the "higher" standards. > > and by their tampering, they pollute the water... > > their pollution may make the water drinkable and safe. > > does n ot change the fact that the water was tampered with. > > > Bill, I was very specific about transit. > > Yes, most water transit companies are also the water supply company, but, > in my analogy, and, in some areas, as a matter of fact, they are not the > same. The chemical tampering of which you speak is done by the water > supply company at the supply point before it is put in the pipes for > transit to the end user. And this was my point as well, Owen... but I have to admit, it didn't *look* to me like this was the point you were making in your original message; perhaps I misread you as well. > The water delivery company runs said pipes, and, my expectation from them > is that they deliver what they got from the water supply company without > any additional contaminants. Actually, no, this is the point he's making. The Florida West Coast Regional Water Supply Authority is not the one that adds chemicals and the like to the water around here; The St Petersburg Water System, or Pinellas County Utilities do that, before the water arrives at retail. > Think of the web hoster as a water supply company. The household user > is an end user. The ISP is merely a pipeline. And *here*, we get into "what's an ISP, really; and how do we distinguish that from the other things people do with packets?" Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Schneier: ISPs should bear security burden
On Wed, Apr 27, 2005 at 03:07:47AM -0700, Owen DeLong wrote: > > Sound about right? > No, not at all. > > I'm not advocating a wild west every man for himself, but, I think that > solving end-node oriented problems at the transport layer is equally > absurd. > > It's like expecting to be able to throw crude oil into a tanker at > one end and demanding that the trucker deliver gasoline at the other. Owen, I may be wrong... but it sounds to me like half the people in this conversation are talking about things *the retail gas station ought to do*, assuming that the people on the other side realize this, and the other side is reacting as if the first group is advocating that *refineries and pipeline operators* ought to be doing those things. Certainly backbone ops shouldn't be doing this sort of filtering, and if you're big enough and willing to pay enough, you ought to be able to get a hose free of such filters. But *what you're paying for* there is the right to pollute the commons, and no, people paying $1/MB's for their Verizon FTTH connection probably ought not to expect a raw unfiltered connection. It's not *just* about bandwidth... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Schneier: ISPs should bear security burden
On Tue, Apr 26, 2005 at 10:38:00PM -0700, Owen DeLong wrote: > I think it's absurd. I expect my water delivery company not to add > polutants in transit. I expect my water production company to provide > clean water. Water delivery is unidirectional, otherwise water utilities would infact have to filter out bad things introduced by notional bad actors which could cause other users problems and risks. See "tragedy of the commons". Do I think *everyone* should do this sort of thing? No. Do I think people should be regulated into doing it? Well, my knee jerk reaction is no... but it's a knee jerk reaction. Do I think that people should, by and large, be able to assume that they can treat the internet at large as a utility? (At the T-1 and up direct connect level, I mean) Yeah, probably. Does that require that consumer-level providers do some filtering...? Yeah, probably. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Slashdot: Providers Ignoring DNS TTL?
On Sun, Apr 24, 2005 at 04:40:50PM -0400, Robert M. Enger wrote: > More to the point however, I note that Jay is the author of RFC2100. > I think he's just having a little bit of fun. My apologies for > belaboring the performance issue. I'm pleased that you noticed... but possibly less so if it means you *didn't read the clarification I posted on what I actually meant*. :-} Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Slashdot: Providers Ignoring DNS TTL?
On Sun, Apr 24, 2005 at 04:00:40PM -0400, Robert M. Enger wrote: > In your note below you speak of 'moving on to something else' when > PPLB comes. No, I actually don't. > PPLB destabilizes TCP. It elicits erroneous retransmissions, squanders > capacity and lowers performance. > > You are suggesting that we replace TCP in all the computers in the > world? Nope. I was observing generically that if people who take advantage of a technology window to supply a supportive technology (video capture cards for PC's) are smart, the *really* smart people are those who are prepared to move along to something else when the mainstream catches up (DV/Firewire) and their product is no longer necessary. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Slashdot: Providers Ignoring DNS TTL?
On Sun, Apr 24, 2005 at 02:00:48AM -0400, [EMAIL PROTECTED] wrote: > > Well, PPLB isn't the end of the world. But PPLB is coming, and the smart > > people will be prepared for it. They dumb people, well, they're dumb. > > What can be expected from dumb people? > > What you seem to be missing is that the *really* smart people will be prepared > for it when it actually gets here - and will take advantage of it's lack of > arrival in the meantime. And, the even more important extension of your last comment, they'll be prepared to move on to something else, when it comes, and they can no longer take advantage of it's absence. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Verizon Offering Naked DSL in Northeast...
On Mon, Apr 18, 2005 at 05:08:51PM -0400, Andy Johnson wrote: > Alex Rubenstein wrote: > > What possible technical issue could exist that to don't have to wire the > > dslam to a pots splitter? > > > > Actually, even if they did wire it to a pots splitter, and there was no > > pots line present, it'd still work. > > My speculation is that their billing/accounting system is based on a > POTs number, and since these customers will not need one, they will have > administrative errors managing accounts. Their DSL OAM&P, at least in VerizonFL territory, is indeed tied to the associated voice DN; they don't even do *ticket* numbers at the consumer level: the tickets are tied to the DN as well. > Since VZ is doing their FTTP rollout, I imagine they have been tying > new customers to Physical Addresses now instead, moving away from the > old POTS based system. Again, all speculation based on how I see the > DSL/FTTP order process taking place now. And I've just heard from a customer for FTTP in Tampa that he loves the speed (13/1.2 stable)... but they're PPPoE at the box. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
Here we go again... http://techrepublic.com.com/5100-10595-5657417.html?tag=nl.e044 My initial reaction is "why?" My followup reaction is "Well, most workstations don't cache anyway, do they?" Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Anyone familiar with the SBC product lingo?
On Fri, Apr 15, 2005 at 08:58:50AM -0400, David Lesher wrote: > He describes it as a long drawn-out exercise in futility. A > non-trivial employee has to spend eons on the task. It's a recursive > onion peeling, or a data version of Tom Lehrer's "I Got It From > Agnes"... > > And once done... the errors found, the diversity restored, and the > report signed off; it's soon worthless...because the carriers > soon shuffle things around Yet Again. So here's the 64GB/s question: If carriers are being paid to ensure physical separation between circuits for the life of the circuit, why is it that they haven't implemented change management systems (and I don't solely mean the software) to ensure they they *can* (not even that they will) manage to ensure such separation? A simple "don't move this circuit without investigation" flag that would drill-up to higher level flows would seem to be enough -- though certainly I am not familiar with the internals of the CMSen at such scale carriers. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
