Re: [cacti-announce] Cacti 0.8.6j Released (fwd)
On 1/24/2007 3:05 PM, Paul Vixie wrote: glibly said, sir. but i disasterously underestimated the amount of time and money it would take to build BIND9. since i'm talking about a scalable pluggable portable F/L/OSS framework that would serve disparite interests and talk to devices that will never go to an snmp connectathon, i'm trying to set a realistic goal. anyone who want to convince me that it can be done for less than what i'm saying will have to first show me their credentials, second convince david conrad and jerry scharf. (after that, i'm all ears.) Trying to do a comprehensive monolith will certainly make it a 5-year process. It seems that such an effort is doomed from the start though (as you say, who would fund it?) so I'm not really sure why it would be offered up as the only available outcome. Take a different approach, it wouldn't be that hard to develop the framework alone. The killer for all these things is in the widgets that hang off them, but if the framework was usable and the widgets were easy to write (say, documented better than BIND9's API for example), the users would take care of providing the widgets. Look at all the noobs writing plugins for cacti and spamassassin and... users will write the plugins if the framework is accessible. Don't give me a package that tries to provide everything, give me a daemon with inter-process messaging, event triggers, an extensible OO inheritance model and I'll do my own damn widgets... It wouldn't take five years to write that. It's a summer project. Some of the things I want in an NMS that I can't find in end-all-be-all monolithic packages: self-config stuff default polling cycle authentication data-storage interfaces etc. host/device information static info (hostname, etc) dynamic info (hardware inventory, software inventory, etc) browser interface MIB browser CIM browser others polling events ICMP SNMP GET WBEM script interface TCP connection interface etc. alarm events SNMP traps WBEM notifications syslog eventlog etc. action events alerts (mail, pager, whatever) run local script run remote script manipulate escalation interface event unanswered, chain to other event event cleared, chain to other event reporting browser meters (eg, watch this mib with realtime tachometer) long-term graphing trend analysis/reporting etc. Really it comes down to having a framework in place that can be extended by end-user admins. IOW it's the section heads, not the list items. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: [cacti-announce] Cacti 0.8.6j Released (fwd)
On 1/24/2007 2:46 PM, Ray Burkholder wrote: WMI requires Windows Authentication, and if one is running Linux tools, there are issues. I havn't come a cross an easy way to get to WMI from Linux yet. Anyone have any suggestions? I've been working on this for a while actually. WMI is WBEM, except that WMI uses DCOM as a transfer protocol instead of using HTTP like WBEM. The big problem for Linux is that there aren't any implementations. However there are some interesting tools that provide gateway services that get around the problem. Part of the openpegasus tarball is a program called wmimapper that provides a WBEM to WMI gateway. Basically you send it WBEM queries with HTTP authentication etc, and it converts those into WMI requests. It runs on Windows (to generate the DCOM), and it's source-only so you'll need to compile it yourself (although IBM and HP also include older ports in their server monitoring software). I've been using it to pull Everest sensor data off Windows boxes into Cacti on Linux for a while. There are some problems with the whole thing, but it pretty much works. SNMP Informant has a WMI-SNMP gateway agent that makes some/most Windows data available through SNMP, which is handy. nsclient also provides access to some perfmon and static data through a custom agent/proxy protocol too. http://forums.cacti.net/viewtopic.php?t=11752 http://www.openpegasus.org/ http://www.snmp-informant.com/ http://nsclient.ready2run.nl/ -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: WorldNIC nameserver issues
On 10/17/2006 2:36 PM, David Ulevitch wrote: We're seeing a number of issues with WorldNIC nameservers failing from multiple points on our network this morning and was wondering if anyone was seeing similar problems. I saw it here with ns89 and ns90 earlier (spent a while tracking down the problem, and their servers were all timing out on queries) but it seems to be working fine now. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
voip calea interfaces
I'm looking into the FCC ruling to require CALEA support for certain classes of VoIP providers, as upheld by the DC circuit court a couple of weeks ago [1]. The portion of VoIP that is covered by this order is pretty narrow (ie, you provide telephony-like voip services for $$ [read the specs for the real definition]), and the FCC is looking at narrowing it down further but has not done so yet. Meanwhile, the deadline for implementation -- May 14, 2007 -- is starting to get pretty close. The operational part of this subject, and the reason for this mail, is the implementation of the wiretap interface. Obviously there are going to be a range of implementation approaches, given that there are a wide variety of providers. I mean, big-switch users probably just enable a feature, but small providers that rely on IP PBX gear with FXO cards will have to do something specific. Are vendors stepping up to the plate? Did you even know about this? Off-list is fine, and I'll summarize if there's interest. Thanks [1] http://pacer.cadc.uscourts.gov/docs/common/opinions/200606/05-1404a.pdf -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: voip calea interfaces
On 6/20/2006 1:33 PM, Fred Baker wrote: Yes, the vendors are aware of this. Our legal people track it pretty closely, and we have been dealing with the issues in Europe, Australia, and a number of other places for quite a while. We talk directly with legislators, regulators, and various police entities. I was more curious about operators but this is interesting http://www.ietf.org/rfc/rfc3924.txt 3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker, B. Foster, C. Sharp. October 2004. (Format: TXT=40826 bytes) (Status: INFORMATIONAL) This is interesting approach. For one, it seems to cover a lot more technology than CALEA requires. I suppose that is an artifact of trying to serve multiple countries' requiresments in a single architecture. Also, to my knowledge the FCC/FBI have not yet agreed to accept any kind of pure packet-level intercept interfaces as meeting LEA requirements. The only approved interfaces I know of are for telco and cellular networks (see http://www.askcalea.net/standards.html). Until they approve a packet-based interface like you describe, it remains unapproved by default, meaning that it would not count to satisfy the CALEA requirements, right? You said that you put this to ETSI; have you put it to the FCC and FBI for approval as a qualified interface? Along those same lines... given that the covered VoIP providers are mostly going to be interfacing to PSTN, my general assumption is that they will use 3rd party gear to provide the supported CALEA interfaces, and then interface that device into their VoIP infrastructure somehow (this assumes the operator isn't using a real switch with CALEA interfaces already built-in). A pure packet-based interface would be cheaper and better than that, but given the reasons above it seems unlikely in the short term. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: VoIP calea interfaces
On 6/20/2006 2:57 PM, Hoffpauir, Dusty wrote: The FCC/FBI have left it up the industry to define a standard, they are not defining it themselves. Right. But they do have veto power, and they do not appear to have given approval yet. Meanwhile the deadline continues to close. This is an awkward situation. There are 2 standards being discuss/worked on for packet delivery of intercepted voice and call data. One is being done by ATIS and is t1.678 which is still in draft. The other is packetcable by cable labs and that's been in use and on going for a couple of years now Yeah those are mentioned in FCC-05-06 as near completion. It looks like t1.678 is most applicable to the area I'm primarily interested in, since it describes voice-over-packet interfaces in general, and mappings for SIP and H.323 in particular (although it seems that the LEA interface is undefined, and also seems to assume some kind of circuit- or local delivery, all of which is quite curious--this is what the IETF guys call out as hand-waving). Cisco is packet cable compliant today. For the DOCSIS equipment you mean? That's a whole 'nother world from the RFC3924 stuff. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Welcome back, Ma Bell
On 3/5/2006 7:10 PM, Steve Sobol wrote: Eric A. Hall wrote: What are people worried about here exactly? The same lack of competition in telecommunications that we had in the 1980s? Well that's an overreach. And if the primary concern is consolidation then we should have blocked NYNEX and Bell Atlantic from merging back in 1997, since this deal is basically SBC + BellSouth/Cingular, which is mostly indistinguishable from the earlier one. I think people are reacting to the brand, the ATT ghost really, since there's none of it left. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Welcome back, Ma Bell
Nice rant. But since this isn't your blog you'll probably have to grace us with some substance. None of ATT exists anymore--SBC acquired that corpse last year, so the company currently calling itself ATT isn't even really ATT. The new deal is basically SBC buying up BellSouth and getting the rest of Cingular in the deal. I just don't see how this is all that different from the stream of MAs that produced Verizon back in the 90s. Sure it's a big deal, just like that one was. Another giant telco, hoorah. Nightsweats about the ghost of Ma Bell rising? lol no. On 3/5/2006 10:24 PM, Fergie wrote: An overreach? Really? I'd say that you're not paying attention. And how do you come to that conclusion? By the fact that very little of the original ATT is in the current monolith? Well, given the entire 'two-tiered' money-grab-tastic issues involved, I'd say you're a little out of touch. - ferg -- Eric A. Hall [EMAIL PROTECTED] wrote: On 3/5/2006 7:10 PM, Steve Sobol wrote: Eric A. Hall wrote: What are people worried about here exactly? The same lack of competition in telecommunications that we had in the 1980s? Well that's an overreach. And if the primary concern is consolidation then we should have blocked NYNEX and Bell Atlantic from merging back in 1997, since this deal is basically SBC + BellSouth/Cingular, which is mostly indistinguishable from the earlier one. I think people are reacting to the brand, the ATT ghost really, since there's none of it left. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Computer systems blamed for feeble hurricane response?
On 9/13/2005 5:23 PM, Joseph S D Yao wrote: SEF [is] unique in that it can detect what appear to be telnet connections to Port 25 and drop the connection. This is probably because telnet connections send one character at a time whereas real SMTP clients send all the strings at once. While we're beating a dead tangent, TELNET clients are often configurable to use line-mode (preferred for those of us with fat fingers, where we need backspace to work on the local line buffer before it is transmitted). Many of them will also avoid sending TELNET options when the non-default port is used (they've learned by now that there's little reason to do so, and lots of reasons not to). -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Question about propagation and queuing delays
On 8/22/2005 11:14 AM, David Hagel wrote: This is interesting. This may sound like a naive question. But if queuing delays are so insignificant in comparison to other fixed delay components then what does it say about the usefulness of all the extensive techniques for queue management and congestion control (including TCP congestion control, RED and so forth) in the context of today's backbone networks? Latency is cumulative. Knocking a little time off Part A will still act to shorten total time, regardless of the time occupied by Part B Queuing behaviors are also significant when you are suffering congestion, apart from the delay factors -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: KVM over IP suggestions?
On 8/22/2005 11:15 AM, Drew Weaver wrote: Howdy, I'm looking for a way to give our remote users access to their servers, perhaps a KVM-IP solution. Any suggestions would be helpful. http://www.nwc.com/shared/article/printFullArticle.jhtml?articleID=168500010 -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: New N.Y. Law Targets Hidden Net LD Tolls
On 8/19/2005 12:41 PM, John Levine wrote: I agree that life would be simpler if there were some straightforward way to ask telcos whether a call from a-b was local or toll. As I remember Tennessee's rules, the PSC requirement was that every adjacent county was to be considered local. Area codes could usually cover multiple counties, but you usually know what city your calling destination is in. With ISP dial-in numbers, you might not, but that's pretty much the exception. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: New N.Y. Law Targets Hidden Net LD Tolls
On 8/17/2005 10:04 PM, Fergie (Paul Ferguson) wrote: A new law that's apparently the first in the nation threatens to penalize Internet service providers that fail to warn users that some dial-up numbers can ring up enormous long-distance phone bills even though they appear local. aka, make ISPs liable for other people's fraud. What's the thinking here, anybody know? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: New N.Y. Law Targets Hidden Net LD Tolls
On 8/18/2005 2:59 AM, Richard A Steenbergen wrote: On Thu, Aug 18, 2005 at 02:44:59AM -0400, Eric A. Hall wrote: On 8/17/2005 10:04 PM, Fergie (Paul Ferguson) wrote: A new law that's apparently the first in the nation threatens to penalize Internet service providers that fail to warn users that some dial-up numbers can ring up enormous long-distance phone bills even though they appear local. aka, make ISPs liable for other people's fraud. What's the thinking here, anybody know? Erm... Requiring that ISPs notify customers that phone numbers in the same area code may not be local has WHAT exactly to do with making ISPs liable for other people's fraud? If there's a penalty for failing to ~adequately track and notify customers then that's a liability, by definition. Seems to me the appropriate response is for the AG office to pursue the people who are running the toll scams, not to push enforcement out to uninvolved third parties. Having dealt with AGs in the past, I know that's just whistling dixie, but still the notion of introducing liability is kind of spooky. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: New N.Y. Law Targets Hidden Net LD Tolls
On 8/18/2005 3:54 AM, Richard A Steenbergen wrote: I'm not sure which part of this seems to have nothing to do with toll scams wasn't clear the first time around, but this response still seems to have no basis given the facts... Is the NY AG authorized to regulate other-than illegal activity? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
FCC Rules For VoIP E911 Challenged
http://www.advancedippipeline.com/168602003?cid=RSSfeed August 16, 2005 FCC Rules For VoIP E911 Challenged Nuvio files appeal of FCC's order for VoIP providers to implement emergency calling systems. By The Associated Press WASHINGTON (AP) -- A provider of Internet phone calls is challenging new Federal Communication Commission rules requiring the company to ensure reliable 911 emergency call service. Nuvio Corporation, which has about 10,000 subscribers, has filed a motion with the U.S. Court of Appeals for the District of Columbia asking the court to hear the case, company spokeswoman Heather Carmichael said Monday. ``We have worked diligently to provide our users with 911 access,'' said Jason Talley, president and chief executive of Nuvio. But, he said, ``the 120-day requirement imposed by the FCC is arbitrary and capricious and without support in the record.'' Nuvio, based in Overland Park, Kan., is a provider of Voice over Internet Protocol, also known as VoIP. The company asked the court to expedite the case and rule by Nov. 7. If there's no decision by then, Nuvio warned it will have no choice but to start suspending some customers. In May, the FCC ordered Nuvio and other providers of Internet-based phone calls to certify that their customers will be able to reach an emergency dispatcher when they call 911. Dispatchers also must be able to identify the caller's phone number and location. The companies were given until Nov. 28 to comply. The FCC declined to comment on Nuvio's appeal. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: fcc ruling on dsl providers' access to infrastructure
From: Randy Bush [EMAIL PROTECTED] Date: Sun, 7 Aug 2005 11:22:23 -1000 To: Christopher L. Morrow [EMAIL PROTECTED] Subject: Re: fcc ruling on dsl providers' access to infrastructure and, for this morning's pop quiz, what is the classic term for an economy of private ownership and government control? On 8/8/2005 8:23 AM, Scott McGrath wrote: I believe it is called facism. A big bald Italian mentioned something about trains running on time. Let's not confuse deregulation with the big 'F', which was state and ~trade union as much as ~business or anyone else. I mean, using the ultra-relativistic measure that is being loosely applied here, the previous existing regulations were also fascistic. We now return to our regularly scheduled broadcast of shrill, one-sided and uneducated diatribes -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Switch advice please - followup
On 7/22/2005 2:39 PM, Nicole wrote: completely forgot abt Foundry so they are my next stop! Don't forget Extreme, my favorite of old. Their product line isn't as broad as some others but they have pretty solid stuff in my experience. Oddly no one mentioned 3com. I don't know if that's good or bad. 3Com has a history of abandoning and re-entering markets (only to be outdone by Intel), and that works against them. Their 5500 series looks pretty nice (gigE + PoE) and has a competitive price point, but I haven't played with any of it. The sad part is I hate Cisco. Well I hate IOS. If anyone makes a switch with this type of menuing that can actually pass lots of bits well and is not a consumer toy. I want to know :) The linksys gigE switches (like the SRW2024) have a menuing interface and a web interface. No layer3 support but they have a pretty complete L2 feature set. Not sure how you feel about buying at that market level. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: OT? /dev/null 5.1.1 email
On 7/6/2005 1:32 AM, Pekka Savola wrote: Make your secondary mx aware of all the valid recipient addresses. Are there mechanisms in postfix or sendmail to do this automatically, or should this be done out-of-band? I've tried looking for this feature, but found nothing; maybe I don't know the right terms to search for. Just about any MTA that is serious enough to be used also supports some kind of networked database for recipient lookups. With postfix, check the docs for local_recipient_maps. I don't remember how this is done in Sendmail, but it's possible there too. There can be a second step here, of separating the recipient lookups from the known (local) delivery mailboxes. Getting the lookups and the remote delivery to work together can be non-obvious and tricky. With postfix, check http://www.postfix.org/LDAP_README.html for a discussion on using virtual maps to make this work. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: OT? /dev/null 5.1.1 email
On 7/5/2005 10:47 PM, Patrick Muldoon wrote: Even better if you can implement something that auto blacklists people that connect to your secondary MX's when you know that your primaries are up and accepting e-mail. http://wiki.apache.org/spamassassin/WrongMXPlugin is a SpamAssassin plugin that determines if an email was sent to a lower preference MX when a higher preference MX was likely available. Haven't used it but it's an interesting idea on my to-examine list -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 7:08 AM, Mikael Abrahamsson wrote: I've been debating whether the TOS header information must be left untouched by an ISP, or if it's ok to zero/(or modify) it for internet traffic. Does anyone know of a BCP that touches on this? My thoughts was otherwise to zero TOS information incoming on IXes, transits and incoming from customers, question is if customers expect this to be transparent or not. Reading http://www.sanog.org/resources/sanog4-kaulgud-qos-tutorial.pdf it looks like in the Diffserv terminology, it's ok to do whatever one would want. Any feedback appreciated. Long ugly history here that I will try to avoid. IP is end-to-end and you aren't supposed to muck with the packets that are sent by your customers (or worse, sent by *their* customers). You don't know what the bits mean to their applications (unless you are one of the end-points of course) and screwing around with that stuff is a good way to make people very angry. They're not your packets--leave them alone unless you are being paid to do otherwise. Little history here, one of the claims of justification for overwriting the tos bits with diffserv was that ISPs were supposedly already blanking out the data. I asked several of the proponents for just one example of this and nobody could produce one. I got a few comments like I think ISP X is doing it but then I would ping a host in that network (with TOS flags on the ICMP message's packet) and would get the flags back thereby disproving the anecdotal claims. To my knowledge, nobody was rewriting this data prior to diffserv, or at least if they did it, they preserved the original bits somewhere. Dunno about now, but I would imagine a few providers have fallen for the everybody else is doing it invented justification, and thus became the self-fulfilling claim themselves. I reference this history in the hope that you will do similar tests--if you think you can/must do this because of competitive reasons, probe your competitor networks and see if they're really doing it or not. It doesn't seem to me that diffserv has picked up momentum and its not something I hear people whining for. If it were me, I'd limit rewriting the flag data to clients that requested it, and otherwise try to preserve the original markings. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 1:54 PM, Kevin Oberman wrote: Date: Wed, 25 May 2005 12:35:56 -0400 From: Eric A. Hall [EMAIL PROTECTED] the original bits somewhere. Dunno about now, but I would imagine a few providers have fallen for the everybody else is doing it invented justification, and thus became the self-fulfilling claim themselves. ESnet does QoS with expedited forwarding enabled in our core. To prevent the unauthorized use of these bits, we have long had a policy of clearing them at our border for all traffic not authorized for the expedited service. If we receive packets marked for less than best effort (scavenger) service, the bits are reset. Here's the correct model (imo): 1) You are under no obligation to provide expedited service to anybody who hasn't paid for it. Packets marked with flags for services that haven't been paid for should simply be ignored. 2) Following therefore, you only need to process flags for customers that have paid for the expedited service. 3) You should only shuffle the bits around if they ask/need you to do it, since the customer probably wants to flag their important packets/flows themselves. The default is to not modify -- only to process differently. 4) The default of no-modify should also apply to non-payinng customers since they may be flagging their packets for special processing on their own networks (and they don't want the flags to poof away when the traffic crosses your hop). In sum, premium packages are for expedited processing, which is what they are buying. Rewriting any packets without consent/request is not needed and unrelated, and is bad mojo in general. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 1:39 PM, Sam Stickland wrote: While it's true that IP is end-to-end, are fields such as TOS and DSCP meant to be end to end? A case could be argued that they are used by the actual forwarding devices on route in order to make QoS or even routing decisions, and that the end devices shouldn't actually rely on the values of these fields? The markings may be used on customer networks too, even if they are not interpreted or processed by intermediary networks (you). I mean, maybe they are tagging different kinds of database traffic at egress and ingress so that they can do their own congestion management. Unilaterally rewriting all of the packets that cross your network imposes unnecessary penalties on them and is generally rude. It's also near blackmail--pay us or we'll overwrite your packets. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 2:50 PM, Saku Ytti wrote: Beatiful idea, how in practice do you suggest this is done, how will my router know if it should just ignore the TOS bytes or do expedited forwarding as configured for given value of TOS byte? VLANs? Different route paths? Any of a dozen other ways to limit special processing to the networks that have paid for it and dump everybody else into the best-effort pool? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 3:11 PM, [EMAIL PROTECTED] wrote: Seems to me these are far more complex solutions than simply rewriting TOS at the borders. And yes, we also rewrite TOS at the borders for Internet traffic. All you are doing is off-loading the complexity to your customers (and their customers). What's the point in offering a premium service that doesn't make enough money to pay for the work required to offer it? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 3:42 PM, Lars Erik Gullerud wrote: I.e. my customer with two offices who run their own IPSec tunnel between, should in other words no longer be able to pay me for improved delivery without buying a full VPN offering from me (which they don't really need, or want)? If they don't need or want special handling what are they paying for? But since they are paying for it, perhaps its up to you to figure out how to deliver on your promise. And yet, getting somebody to pay for something/nothing (as the case may be) doesn't come with a license to manhandle everybody else's traffic. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 4:27 PM, Lars Erik Gullerud wrote: The general population, who does NOT pay for that privilege, gets the BE-treatment, which is what they pay for. Overwriting the tos flags is not best effort, it is degraded service Oh sure, it might be BE on your specific network, but all the user sees is loss of signal. IE, it was degraded. customers seem to understand that you get what you pay for, and special treatment in the form of QoS costs more money. Again, you are under no obligation to do anything with QoS flags from non-paying customers, and I'm not advocating for anybody to get a free ride here. Ignore the markings, but leave them alone too. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 9:06 PM, Sean Donelan wrote: Do you really think this scales well in a core network? Feasibility can be empirically demonstrated easily enough. Which of your competitors' networks do you want me to ping probe with ToS flags enabled? [Although I suppose I should add the disclaimer that things have changed for the worse in this regard since diffserv overtook the tos flags so maybe you can win this easily now. Alas.] My post-count for the day (and this topic) is now at max. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Underscores in host names
Edward Lewis wrote: It's true that the xn-- convention isn't the best way to encode IDN's, but it has proven to be the optimal one in design (at least). It's the necessary minimum for compatibilty purposes, but not anywhere near the optimal design. Moreover, those have nothing to do with each other. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Underscores in host names
David Conrad wrote: I used to be in the 952/1123 sect, but I have since reformed and continue to do penance for my sins. Your personal pendulum has no bearing on the relevance on 952/1123. Hostnames still have their own rules, apart from the media used to represent those hostnames (eg, hosts or DNS is irrelevant--a hostname is still a hostname is still a hostname). The hostname is not a domain name dodge is simply wrong. If you like, I can get a signed affadavit from the author of the DNS specifications (assuming he's in the office tomorrow) to the effect that it was always his intent that domain names be composed of any 8- bit value. There's absolutely no corrolation between those two points. Or at least, the latter point has nothing to do with the former. As for the latter point in particular, anybody is perfectly free to use any 8-bit value they want for any label in any domain name, and that point is hardly in dispute. The point for this thread however, is that 952/1123 defines its own rules for the syntax that can be used to represent a connection target on the Internet (aka hosts). Those rules are quite clear: letters, digits and hyphen only, length restrictions, etc. However, that rant was mostly irrelevant. Can you point to _ANY_ application, operating system, or anything else that has any issues whatsoever with an _ of all characters? Just one? Squid. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Underscores in host names
David Conrad wrote: 1) Squid/Squid proxy from two people (although there wasn't any indication of the actual issue, presumably Squid won't be able to contact the host to cache the content?) the resolver library barfs up an error I suspect the rest of the jihad against heathen characters such as _ should probably be redirected to namedroppers so I won't comment further. Not unless namedroppers is authoritative for /etc/hosts now too. That's the whole point here--DNS may be more powerful than what the hostname syntax rules allow, but the mere existence of that capability has zero bearing on the canonocial syntax rules. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Underscores in host names
Paul Vixie wrote: (why are we talking about this on NANOG rather than NAMEDROPPERS?) because it's not relevant to the underlying rules Check-names was a bad idea that might have been justified at the time, but pretending it remains justified by 952/1123 has got to stop sometime. at the time of check-names, i outlawed _ as a side effect of punting. in order to strip/prevent newline characters in PTR targets, i had to be able to refer to an RFC (lest people come to me with many individual sob stories about this or that special character that either should or should not be stripped/prevented in gethostbyaddr().) the only RFC i found that had any remote chance of getting me off this hook was #952. ergo, _ had to die in order that my inbox might live. but it was wrong, and the need for it is past, and it's time for redress. So, you found some pre-existing rules, used them as cover for your problem, and now that your ~problem is fixed the pre-existing rules shouldn't matter to anybody anymore? Come on now, isn't it slightly possible that those rules were pre-existing for reasons that have nothing to do with you? Consider the code-point value of $ as it is used in iso-646-us versus iso-646-de or any of the other ECMA derivatives, or any of the other ISO-* derivatives that don't have direct ASCII character mappings. That character (and many others) can have different and distinct code-point values in multiple character sets, but it has to be identical everywhere in order for it to have meaning. Thus, allowing the character to be used means mandating a specific code-point value for that character. Alternatively (and what we have in the pre-existing rules) is to forbid those characters entirely, so that nobody is forced to kautau to a specific nationalized character set. While that may feasible in protocol commands and such, it's not feasible to mandate that /etc/hosts MUST always use US-ASCII code-point values for characters that may not even exist in the local nationalized charset. Really, spend some time with the ECMA derivative sets and you'll see what I mean--there are characters in some of them that aren't in the others, or they are misplaced, or they are defined as alternates, and so forth. I'm glad you fixed your problem, but really, this isn't about DNS, it is about universal representation of hostnames despite the media that is used to convey those names. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Underscores in host names
Paul Vixie wrote: putting these checks in for master zones, slave zones, and response data was a significant over-reach on my part. THAT is what i'm apologizing for here. (and THAT is what CERT had asked me to do, since changing gethostbyaddr() would not, by itself, have protected Sendmail from newlines in its qf* files.) Alright then. Personally I've found them useful at different times in different places but that's some hair-splitting neither of us is particularly interested in. just because you own an A RR doesn't make you a hostname. just because you're pointed to by an MX RR doesn't make you a mailname. (what a relief to finally be able to say that.) At the risk of hair-splitting that I've already disclaimed, I'll halfway agree (a host that doesn't accept connections arguably isn't a host) and halfway disagree (the target of an MX must be a valid hostname). To ensure that this thread dies now, I'll point out that I categorized some of this as part of my second stab at the great white whale of i18n DNS [see http://www.ehsco.com/misc/I-Ds/draft-hall-dns-datatypes-00.txt which ensures nobody comes back] -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Memory leak cause of Comcast DNS problems
On 4/17/2005 12:29 PM, Florian Weimer wrote: * Sean Donelan: Perhaps your DNS software also has a memory leak? Anyone know which software Comcast was using? Should other ISPs be concerned they might have the same latent problem in their systems? Probably yes, especially if they don't read documentation of their DNS software. | The maximum amount of memory to use for the server's cache, in | bytes. [...] The default is unlimited, meaning that records are | purged from the cache only when their TTLs expire. That was my first guess too. Most DNS servers don't even have this switch. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Memory leak cause of Comcast DNS problems
On 4/16/2005 10:03 PM, Sean Donelan wrote: Should other ISPs be concerned they might have the same latent problem in their systems? ps v -C server-process-name will tell you how badly you're hurting Anybody that does a bunch of lookups -- whether this is forward lookups for customers or blacklist lookups on mail or whatever -- is probably using more than they think. I don't know of many directly related crash scenarios but there are other penalties like shallow caching which aren't entirely trivial. The churning strategy employed is the question that doesn't get answered. Some servers do FIFO, some do random discards, some use swap space... This whole area is treated like the embarrassing aunt in the cellar. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Auerbach Accuses ICANN Board of Dereliction of Duty on IP Allocation
I thought you were doing these on a blog now On 4/12/2005 8:25 PM, Fergie (Paul Ferguson) wrote: ...and hilarity ensued. Not. http://www.icannwatch.org/articles/05/04/11/132201.shtml - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://spaces.msn.com/members/fergdawg/ -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Auerbach Accuses ICANN Board of Dereliction of Duty on IP Allocation
On 4/13/2005 6:20 AM, [EMAIL PROTECTED] wrote: ICANN is not perfect but it is hard to see anything wrong with this particular action. what's got to be wrong about it? ICANNwatch is the unelected opposition party to ICANN's unelected majority party. Whatever ICANN does, ICANNwatch finds somebody who opposes it or comes out and opposes it themselves if they must, cause that's what opposition parties do. Being right or wrong or in the service of the community has nothing to do with it. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: The power of default configurations
On 4/8/2005 6:19 PM, just me wrote: I don't really want to speak for anyone else here, but it always appeared to me that the problem Vix keeps mentioning is queries with 1918 SOURCE ADDRESSES, not 1918-space queries. This thread, like every nanog thread, has completely lost focus of the original issue, and devolved into some brain-damaged solution to an imagined problem. I don't think it's a bad question. We just went through a similar talk in the zetroconf wg about local addresses. Besides, the question wasn't Paul's in the first place. | From: Sean Donelan [EMAIL PROTECTED] | To: nanog@merit.edu | Subject: The power of default configurations | Message-ID: [EMAIL PROTECTED] | | On Mon, 4 Apr 2005, Paul Vixie wrote: | adding more. oh and as long as you're considering whether to | restrict things to your LAN/campus/ISP, i'm ready to see rfc1918 | filters deployed... | | Why does BIND forward lookups for RFC1918 addresses by default? Sorry we are bothering you are mail spool. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: The power of default configurations
On 4/7/2005 12:05 PM, Jon Lewis wrote:
I added something like this to our binds that handle recursive queries.
Is there any reason distros (or ISC) couldn't make this a part of the
default config?
This setup works if you know the server is the last resort for your local
clients. It doesn't work as a default install unless you are also willing
to scream warnings about changing the defaults everytime named.conf is
modified for local use.
Besides which, you'd really prefer to have an internal filter kill the
queries before they are sent to the root (as part of chasing down the
delegation chain), or before it was sent to the authoritative servers for
in-addr.arpa. (if such was already learned), rather than make users
remember to change the configuration file.
btw your setup would be technically better if it didn't have the wildcard
entry since a negative answer is more accurate. negative caching doesn't
work as well as long-lived positive caching, but still, negative answers
would be more appropriate.
zone 168.192.in-addr.arpa {
type master;
file sink;
};
zone 10.in-addr.arpa {
type master;
file sink;
};
... other similar zones clipped
sink is just
@ IN SOA localhost. root.localhost. (
2002100800 ; Serial
28800 ; Refresh
14400 ; Retry
360; Expire
86400 ); Minimum
IN NS localhost.
* PTR invalid
--
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: The power of default configurations
On 4/7/2005 1:02 PM, Jon Lewis wrote: On Thu, 7 Apr 2005, Eric A. Hall wrote: Would you really have to scream? If folks were used to just adding forwarder entries to named.boot, yes, since they'd also have to remember to undelegate authority for the relevant rfc1918 address space now too. If somebody setup a network using a subset of the address space from rfc1918 space they'd have to reconfigure appropriately too. All anybody really cares about is that these queries aren't beating up the root/gtld servers, so adding a check to the referral-chasing would solve that problem and wouldn't impose additional work on the users. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: The power of default configurations
On 4/7/2005 1:21 PM, Jon Lewis wrote: On Thu, 7 Apr 2005, Eric A. Hall wrote: On 4/7/2005 1:02 PM, Jon Lewis wrote: On Thu, 7 Apr 2005, Eric A. Hall wrote: Would you really have to scream? If folks were used to just adding forwarder entries to named.boot, yes, since they'd also have to remember to undelegate authority for the relevant rfc1918 address space now too. If somebody setup a network using a subset of the address space from rfc1918 space they'd have to reconfigure appropriately too. If they're just caching forwarded queries, as long as the servers they forward to have such sink zones setup, it's not a problem...not for the roots/in-addr.arpa servers anyway. No, the cache would be authoritative for the zones, so it would null-sink the queries instead of forwarding them to the resolving server -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: The power of default configurations
On 4/6/2005 5:00 PM, Sean Donelan wrote: Why does BIND forward lookups for RFC1918 addresses by default? As has been pointed out already, caches need to be able to ask other (local) servers for the PTRs. OTOH, it might make a good feature (and eventually maybe a BCP) to block PTR queries for 1918 space from going to the roots and TLD servers. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: potpourri (Re: Clearwire May Block VoIP Competitors )
On 4/1/2005 12:34 AM, Mikael Abrahamsson wrote: on the other hand I disagree with your example that the US is inventing everything, Nope, didn't say that either. Also, look at where implementation of high-speed local access is being done, it's not in the US anyway. Also a reflection of culture. We aren't high-density as in Korea, and we don't have massive natural resource and taxation revenues to afford fiber drops into every isolated corner of a single state as in Norway, and so forth. More to the point, we're not going to move into single-room dwellings or invert our economy (both of which are suggested from time to time--the koreans/norwegians can do it, so can we...). Instead some fool will develop (and deploy) unproven technologies that may or may not eventually solve our problem, at great pain and expense to us all. Even more to the point, of course, we're glad that others are successfully using (and will be using) the technologies that work out in spite of our apparent foolishness in pursuing them. But really, all I'm saying here is that nationalizing and/or mandating technology may work great elsewhere (and even in some areas here) but generally speaking its not in our culture and the suggestion falls flat. I'm not bragging, I'm explaining why. If the PTTs can sit on their access networks without regulation, there will be no competition in the access, and then the market comes to a standstill because building new access networks costs an arm and a leg, especially if right-of-way is hard to come by and you have to negotiate with every land-owner on the way. It's in everybody's interest to reduce capitalization requirements and increase access. See voluntary tower-sharing agreements, for example. http://wethersfieldct.com/B+C/PZC_05-18-2004.html and start reading at 'tower sharing'; I'd prefer to see this made easier, certainly. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Vonage Hits ISP Resistance
On 3/30/2005 9:36 PM, Chris Adams wrote: Once upon a time, Eric A. Hall [EMAIL PROTECTED] said: Do you also block NNTP so that customers have to use your servers? Change that to SMTP and you'll get a bunch of yes answers. Why is one right and the other wrong? It's not SMTP or even Internet mail that people are blocking, it's just the server-to-server transfer part, not the client-to-server or any of the other components. And the reason the server-to-server transfers are being blocked isn't because of competition with those other servers, it's because of harrassment of those sites by ~your customers. This is all pretty different from blocking ~NNTP because you're mad that ~SuperNews is using your network to make money. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Vonage Hits ISP Resistance
On 3/31/2005 9:25 AM, Greg Boehnlein wrote: On a different tact, where I -THINK- the market will eventually end up is w/ different classes of BroadBand service, whereby QOS and priority will be given to those that wish to pay for it. The $14.95 services will be a best-effort, and the $59.95 services will have priority. We've there already. When I had my home-office DSL package from XO it was much more expensive than consumer DSL from pacbell, for example, but gave me the ability to run local servers, non-blocking network ranges, etc. Meanwhille, cable contracts are pretty much written such that the service is only supposed to be used for ~web browsing and other basic tasks, and if you want reliability or better bandwidth then call the business service number. I don't see this much in the local provider market though. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: potpourri (Re: Clearwire May Block VoIP Competitors )
On 3/31/2005 2:40 PM, Mikael Abrahamsson wrote: But I do agree, the whole US market would be better off with more regulation in all areas actually. No, we're not Europe. There is no need for a lot of parallell networks really, Our system is chaotic and annoying at times but it produces better stuff in the form of whole new technologies and in the form of incremental improvements to existing technologies. I mean, you guys can wait around and then standardize on some point in the development cycle, but we're inventing the technologies and the incremental improvements. If we did what you do then we might as well all stop and stand still now. Besides which, your exmple of parallel [and identical] networks shows that there are dumb things to be found in trying to maintain artifical competition in a non-competitive environment. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: potpourri (Re: Clearwire May Block VoIP Competitors )
On 3/31/2005 2:29 PM, Larry Smith wrote: If / when we get back to the state of monopoly on data pipes such as water and sewer are today (I doubt you have little if any choice on where your water comes from or where your sewer goes There are loads of non-municipal installs where if you want water and sewer, you dig your own holes in the ground. Regulations still exist for safety and such but that's separate from the monopoly providers found in denser installs. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: potpourri (Re: Clearwire May Block VoIP Competitors )
On 3/31/2005 7:22 PM, Brad Knowles wrote: At 6:27 PM -0600 2005-03-31, Eric A. Hall wrote: Our system is chaotic and annoying at times but it produces better stuff in the form of whole new technologies and in the form of incremental improvements to existing technologies. Don't pretend that just because you're an American, you automatically know better, I don't pretend, and it's not because I'm an American or that your system is inherently better. I didn't say the system was better, I said it produces better stuff insofar as that applies to long-term advancement, but that's nothing to say about here and now. Stability is cheap and friendly, which is arguably better when you are trying to exlain why somebody's TDMA phone won't ever work with a CDMA network. OTOH, I'm glad the world didn't stand still on X.25 and OSI, if you know what I mean. They are different models is all. But if you insist on reading something into that, then perhaps it's yourself suffering from prejudicial bias. Just a thought. It is entirely possible that the Europeans might know a thing or two It's possible I guess. I mean, a European did bother advancing beyond Gopher to create HTTP, although I suspect that says more about the low-capitalization requirements of network services than anything about the cultural differences. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Vonage Hits ISP Resistance
On 3/30/2005 11:27 AM, Greg Boehnlein wrote: On Wed, 30 Mar 2005, Fergie (Paul Ferguson) wrote: Intersting article on ISP issues regarding competitive VoIP services: http://www.lightreading.com/document.asp?site=lightreadingdoc_id=71020 Hmm.. I was quoted in it. Oh good, maybe you can clarify some things: | As much as I want to see VOIP survive and thrive, I also don't want | to bear the additional cost of my customers choosing to use a | competitor's VOIP service over my own, says Greg Boehnlein, who | operates Cleveland, Ohio-based ISP N2Net. | | Without control of the last mile, we're screwed, Boehnlein says, | which is why I can identify with Clearwire's decision and say | more power to them. Do you also block NNTP so that customers have to use your servers? And if some other service used higher cumulative bandwidth than VoIP (say, Apple's music service) and didn't ~reimburse you for the use of your network, would|do you block that service too? For that matter, do you block the various P2P systems that don't make money but that generate massive traffic? What don't you plan on blocking exactly? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Utah considers law to mandate ISP's block harmful sites
On 3/6/2005 11:45 PM, Steve Sobol wrote: A spokesman for newly elected Republican Gov. Jon Huntsman... The key words here are newly elected and Well as long as we are projecting our ghosts and guessing, I would argue the opposite. For one thing, his term started Jan 3 [1], while the law was first read Jan 28 [2], which is an awfully short time for a first-time elected official to bend a unified state congress to his will. The quotes in the CNET article don't seem to indicate any kind of ownership either, and I'd expect that. From the other end of the wire, look at the votes that the bill has enjoyed, Nobody spoke against the bill during the committee hearing [3], the general electoral trend in Utah [4], the presence of the Mormon church, the history of Utah wrt pornography law and enforcement (Hatch is principle sponsor for the federal child porno laws that have been struck down, and there are lots of other things going on), and I think it's probably fair to guess that the law was presented by the legislature as part of routine business--they probably really want to be avoid this stuff. I'd suppose, therefore, that way-of-life is probably a much more accurate descriptor for the event than suggesting that it was a stunt by a newbie governor. Of course, this is all outside-the-fishbowl stuff, since my limited experience with the state is not being able to buy any booze on one side-trip, and merely enjoying the scenery on another. But guessing at this stuff is certainly entertaining. For folks still reading, here's what the Deseret Morning News says [5]: | If HB260 is approved, it would require that Utah-based companies | begin rating their sites for potentially harmful materials, which | is primarily nudity or sexual activities, according to guidelines | established by the Utah Consumer Protection Services Division. | | At the same time, the Utah Attorney General's Office would start | developing a registry of those companies that do not rate their | sites as potentially harmful to minors, and by 2007 would allow | Internet service providers to offer that list to their customers | for filtering. | | The bill also appropriates $100,000 for marketing and advertising | campaigns to educate parents about the dangers of the Internet | and $50,000 to research the effectiveness of various filtering | technologies. | | Because the law would only apply to Utah-based companies, it | would not violate the interstate commerce clause of the U.S. | Constitution, which has hampered most other Internet control | legislation, he said. Also, consumers choosing to use the | registry to block sites would be made aware of the fact that | because the registry would only contain domain names, some | innocous material may not be accessible. | | Consumers will be informed that they are making the choice to | block this material, he said. They will also be told that | some information which is not harmful could be blocked. [1] http://en.wikipedia.org/wiki/Jon_M._Huntsman,_Jr. [2] http://www.le.state.ut.us/~2005/status/hbillsta/hb0260s03.htm [3] http://deseretnews.com/dn/view/0,1249,600113991,00.html [4] http://historytogo.utah.gov/governors.htm [5] http://deseretnews.com/dn/print/1,1442,600113991,00.html -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: US slaps fine on company blocking VoIP
On 3/4/2005 4:05 PM, [EMAIL PROTECTED] wrote: There are two sides to the issue: 1.) FCC doesn't want companies preventing other companies from competing. 2.) On the other hand, how do you tell a company what services it can or can't block? There's another factor here, which is that the gov't wants to encourage technological innovation and advancement for numerous and sundry reasons (many of them even good). Generally speaking, it's right to favor deployment and growth of new technologies and markets over old ones. All other things being equal (which they never are), tilting the hand towards VoIP providers is the right call. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: US slaps fine on company blocking VoIP
On 3/4/2005 5:45 PM, Thor Lancelot Simon wrote: Vonage has fought tooth and nail to *not* be a regulated entity. It's too early in the technology life-cycle for them to be treated that way. I mean, you can get a phone number anywhere the service provider has a pop, and if you want to feed that into existing 911 service systems you've got a lot of mapping issues to deal with, probably to the point where it's not economically feasible, meaning no deployment. Heck, how long did it take for cellular 911 to work right, and now we're demanding the same level of service from a newbie market like VoIP right away? The time will come soon enough where the market will be stable enough for all of us to mandate certain requirements, and we'll get all the regulation we need then. In the meantime, allowing the technology to develop is the best strategy. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: US slaps fine on company blocking VoIP
On 3/5/2005 12:02 AM, John Levine wrote: Vonage has fought tooth and nail to *not* be a regulated entity. It's too early in the technology life-cycle for them to be treated that way. I mean, you can get a phone number anywhere the service provider has a pop, and if you want to feed that into existing 911 service systems you've got a lot of mapping issues to deal with, probably to the point where it's not economically feasible Packet8 offers E-911 on their VoIP product right now, for a $1.50/mo surcharge which is not out of line with the POTS E-911 charge. You have to tell them where you live, and your phone number has to be local to your location. ^^ Thanks for proving my point. Regulating as-is behavior is not feasible, ergo regulation means loss of features or overhauled network(s), which is a bit unreasonable given where we are in the lifecycle. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Why do so few mail providers support Port 587?
On 2/25/2005 3:16 AM, Adrian Chadd wrote: [reposting this to nanog, as my answer might be reasonably ontopic] On Fri, Feb 25, 2005, Brad Knowles wrote: At 8:05 AM + 2005-02-25, Adrian Chadd wrote: Because your MUA doesn't support SSL on what it considers to be non-standard ports? Because your ISP won't let you set up an ssh tunnel instead? Because there would be no other way to keep your mail connection secure, if SSL and ssh are denied to you? Which MUA, that you/your users are using, won't let you run SSL on port 587? Apparently, many Microsoft MUAs don't support that kind of thing. Thats strange. I'm sure I've had outlook 200x speak SSL on 587. The problem with OE (and probably O) is that it only supports SMTP-SSL carrier sessions rather than StartTLS sessions, especially when alternate ports are involved. Note that StartTLS is the standard, not SMTPS which was registered as informational and has been deprecated to boot. If you are using lots of MS clients, you have to give up on the idea of running 100% encrypted communications over port 587. Not that anybody is stopping you from setting up TLS-only on 587 and SMTPS on some other port... -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Why do so few mail providers support Port 587?
On 2/25/2005 10:51 AM, Nils Ketelsen wrote: On Thu, Feb 24, 2005 at 11:36:40PM -0500, [EMAIL PROTECTED] wrote: I force anyone, who wants to relay to use SMTP-AUTH on port 25. Only mails for local delivery are accepted without AUTH. Whats point in opening another port? There are lots of secondary benefits. One of my favorites is that I can reject mail session on port 25 from hosts that claim to be in my domain (all such mail is authenticated on port 587 or is coming from a pre-configured list of servers that already hit an exception, so any other connections on port 25 that HELO as ehsco.com are lying). There are lots of these kinds of non-trivial benefits. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Why do so few mail providers support Port 587?
On 2/25/2005 11:17 AM, [EMAIL PROTECTED] wrote: department. I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection? It's not just authentication. Mail from local users might need some fix-up work done to it, like adding Date or Message-ID, or completing a mail-domain in an address, or doing some other kind of cleanup. You don't necesarily want to do that for server-server messages, since their absence is good spam-sign, but at the same time you do want to do it for user mail. You can also conduct different kinds of tests, perform different kinds of rate-limiting, map in different headers (auth, for example), and so forth. Separating your traffic is good management. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: UN Panel Aims to End Internet Tug of War by July
On 2/22/2005 2:34 PM, Brandon Butterworth wrote: Now ICANN are ramping up their domain tax to fund the increasing overhead they are imposing, who will tax less ICANN or ITU? Given that ICANN [probably] won't be doing things like (eg) funding Cuba's state-run proxies and content filters, I'd say ICANN. But the amount of the tax isn't the real issue in that sentence. Making me underwrite Cuban oppression is. Sorry, I know this stuff comes as a shock to BBC types. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 11/20/2004 8:18 AM, Alex Bligh wrote: But I'm not sure you'd like it applied to the internet. Firstly, in essence, PSTN uses static routes for interprovider routing (not quite true, but nearly - if you add a new prefix everyone else has to build it into their table on all switches). Secondly, IIRC porting works in the UK something like - call delivered to switch of operator who owns the block, marked as ported number, lookup in central porting database (one for all operators), operator port prefix put on dialed number, call sent back out all the way to interconnect, enters new operator network, goes to switch managing ports, further signalling info added to make call go to the correct local switch, call goes to correct local switch, dross removed, call terminated. Sounds like DNS. We also get semi-annual drive-by proposals to stick the routing info into DNS, of course. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Intel calls for Internet overhaul
On 9/9/2004 4:12 PM, Paul Vixie wrote: update SAN FRANCISCO--The Internet needs to be upgraded with a new layer of abilities that will deal with imminent problems of capacity, security and reliability, Intel Chief Technology Officer Pat Gelsinger said Thursday. hmmph. Many moons ago I used to argue that the IETF should adopt/hijack the DCE suite, and for the same basic reasons that this guy is arguing for their thingy. DCE is probably a better idea still, but his payscale and business card guarantee a wider audience so... Who knows, maybe he'll have better luck with it. I'll salute if its architected and spec'd right, with a good distributed directory, platform-neutral APIs, targetted use, etc. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: OT - 3 Free Gmail invites
On 8/19/2004 1:37 AM, Deepak Jain wrote: If we are all network operators, exactly what is the benefit of having a 1GB mailbox operated by another network? 1) sending test mail to your internal network requires access to a remote network/postoffice? 2) when users complain about failures, you can check it out? 3) get your favorite username/handle while it's still available? I've got a handful of extras if anybody else still needs one btw -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: OT - 3 Free Gmail invites
All gone On 8/19/2004 9:42 AM, Eric A. Hall wrote: On 8/19/2004 1:37 AM, Deepak Jain wrote: If we are all network operators, exactly what is the benefit of having a 1GB mailbox operated by another network? 1) sending test mail to your internal network requires access to a remote network/postoffice? 2) when users complain about failures, you can check it out? 3) get your favorite username/handle while it's still available? I've got a handful of extras if anybody else still needs one btw -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: ad.doubleclick.net missing from DNS?
On 7/27/2004 6:21 PM, John Palmer wrote: Now the question is, can one easily block all of doubleclick.net Couple of methods that have worked for me. If you have squid or similar, you can get a plugin that lets you redirect various sites/domains to a 1x1 transparent gif. This method is preferred since it only requires a single list to maintain. If you have a local nameserver and webserver, then make your dns server authoritative for the domains and redirect queries to a sink address on the web server, and config the web server to answer such requests with that 1x1 transparent gif object. This is more difficult (have to maintain the named.conf list of domains and the apache list of virtual hosts) but overruling the domain names has a lot of potential power for other uses too, possibly including spam blocking, if you are so configured. In both cases, the gif mime-type will overwrite whatever content was originally specified, and the gif is scaled to whatever is specified by the html layout, so using a 1x1 transparent gif doesn't usually cause problems. The hard part here is managing the list of blocked sites, restarting the service, etc. And like Paul said, think about the ramifications of providing such features to a secondary organization and/or user. Making them manually configure their proxy/resolver settings may be enough, but IANAL.
Re: Homeland Security now wants to restrict outage notifications
On 6/24/2004 11:57 AM, Scott McGrath wrote: http://www.theregister.co.uk/2004/06/24/network_outages/ http://www.securityfocus.com/news/8966 is the original, for those of us who have our doubts about the register as a news source To summarize: there are existing FCC requirements to report major voice outages the FCC ran a proposal up the flag pole to extend this to data and wireless networks DHS did their job by analyzing the proposal and suggesting that it might not be a good idea to make the additional data too public Further: If the FCC is going to mandate reporting, the DHS argued, it should channel the data to a more circumspect group: the Telecom ISAC (Information Sharing and Analysis Center), an existing voluntary clearinghouse for communications-related vulnerability information, whose members include several government agencies and all the major communications carriers. Data exchanged within the Telecom-ISAC is protected from public disclosure. Presumably the FCC will take this opinion into consideration and weigh it alongside clear-headed debates as: this country is becoming more like the Soviet Union under Stalin every passing day in its xenophobic paranoia all we need now is a new version of the NKVD to enforce the homeland security directives. At least the paranoia is right -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Homeland Security now wants to restrict outage notifications
On 6/24/2004 2:24 PM, [EMAIL PROTECTED] wrote: On Thu, 24 Jun 2004 11:27:10 PDT, Jeff Shultz [EMAIL PROTECTED] said: And the reporting requirements that the DHS is arguing against _aren't even in effect yet._ or any number of other sites that keep track of just how much trouble can be caused by the *threat* or *suggestion* of something Was it really your intention to imply that this recommendation (and which should have been expected, given the DHS' job) is some kind of a threat? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
insurance
What's the current state of insurance protection for things like DDoS attacks or other unbudgeted outages, and does anybody actually use it? Given the choice between buying excess bandwidth/hardware/service versus paying an insurance premium that will likely cover spikes in such costs whenever they are needed, [insert comment here]. This is for my own use. Off-list is fine. Thanks -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: ntp config tech note
On 5/20/2004 10:57 PM, Randy Bush wrote: you ask do folk run ntpd on every server. i wonder if folk run ntpd on every router. i did and do. every server, router, switch, and workstation that supports it PCs are the hardest part. you can net put time \\source /yes in the login script to smack them into synch but they'll drift if you don't have a real listener. win2k also has listeners but a little rough to config. there are third party widgets too. mcast/bcast where possible too, and dhcp config as well ntp is one of the easier services to globally config -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Barracuda Networks Spam Firewall
On 5/20/2004 8:25 AM, Randy Bush wrote: What's most interesting about the half-dozen accusations of xenophobia I've received (off-list and on) is that they've almost all come from foreigners. I promise not to read anything into that. Really. Could it be perhaps because us foreigners are conditioned by repeated exposure to the xenephobic attitudes of USofA patriots ? shut up or we'll bomb and torture you resist the cycle of violence and hate -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Barracuda Networks Spam Firewall
On 5/20/2004 2:30 PM, Rik van Riel wrote: Different people get different spam, from different sources. Yah, I've been advocating the use of a CIDR match-list from the beginning for this and other reasons. Actually what you'd want is per-entry weighting, so for me and my mailbox: CIDR 221.232.0.0/14 score = 3.0 CIDR 147.28.0.0/16 score = -3.0 The ASN matching has merit too, so maybe: ASN 4134 score = 3.0 CIDR holes punched = -3.0 etcetera -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Barracuda Networks Spam Firewall
On 5/19/2004 5:12 PM, James Couzens ([EMAIL PROTECTED]) wrote: On Tue, 2004-05-18 at 21:49, Eric A. Hall wrote: There's one rule that will wipe out ~90% of spam, but nobody seems to have written it yet. if URL IP addr is in China then score=100 ^^^ not connection address, not domain 'owner', but URL-Hostname-IP_ADDR What's most interesting about the half-dozen accusations of xenophobia I've received (off-list and on) is that they've almost all come from foreigners. I promise not to read anything into that. Really. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Barracuda Networks Spam Firewall
On 5/19/2004 6:19 PM, James Couzens wrote: On Wed, 2004-05-19 at 15:28, Eric A. Hall wrote: Going through the spam that I've got access to (and it is a substantial amount allbeit not in the millions of spam per day) I can't seem to associate the spam with chinese urls, and certainly not to the extent that you indicate (90%). extract hostname from url, dig on hostname, whois on addr, and nine times out of ten the host is in a CN netblock. that's from the spam that gets into my mailbox. let me state AGAIN that what I really want is a plugin that allows for cidr match-lists so that I can also include the handful of non-enforcing hosters in Russia, New York, Florida, etc. One responder also suggested ASN matchlists but I'm not that mad. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Barracuda Networks Spam Firewall
On 5/19/2004 6:38 PM, Stephen J. Wilcox wrote: Altho this is probably not true if you're one of the billion or so people who live in or around China or are of Chinese origin.. just check for charset=US-ASCII first. come to think of it, ASCII would probably give half the necessary weight alone. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Barracuda Networks Spam Firewall
On 5/19/2004 7:06 PM, James Couzens wrote: I just did this on 5 spam in my mail box, I got: [domains ommitted--tripped my filters] my last 10 survivors are at http://www.ehsco.com/misc/last-10-spams.eml the relevant data for them in order of occurrance is below. eight are CN, one is KR, one is Geocities, and one is dead 219.129.20.244 inetnum: 219.128.0.0 - 219.137.255.255 netname: CHINANET-GD descr:CHINANET Guangdong province network [timeout] 221.233.29.78 inetnum: 221.233.0.0 - 221.233.47.255 netname: CHINANET-HB-JZ7 descr:The Chinanet network in Jinzhou ,Hubei province 202.104.242.133 inetnum: 202.104.0.0 - 202.104.255.255 netname: CHINANET-GD descr:CHINANET Guangdong province network 221.233.29.33 inetnum: 221.233.0.0 - 221.233.47.255 netname: CHINANET-HB-JZ7 descr:The Chinanet network in Jinzhou ,Hubei province [dupe host for CN] 219.148.126.47 inetnum: 219.148.0.0 - 219.148.159.255 netname: CHINATELECOM-he descr:CHINANET hebei province network 66.218.77.68 (geocities, heh) OrgName:Yahoo! City: Sunnyvale StateProv: CA [dupe host for CN] [dupe host for CN] 218.152.186.107 inetnum: 218.144.0.0 - 218.159.255.255 netname: KORNET descr:KOREA TELECOM -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Barracuda Networks Spam Firewall
On 5/18/2004 4:22 PM, [EMAIL PROTECTED] wrote: That's going to pretty much torpedo the concept of secondary MX's. Folks still run those? No really, most people I know terminated their off-site secondaries a couple of years ago at least. The only secondary you can reasonably use these days has (1) a copy of your user list, and (2) a clone of your spam filters. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Barracuda Networks Spam Firewall
On 5/18/2004 6:44 PM, Per Gregers Bilse wrote: For a long time since then, backup MXs have been seen as a kind of value-added courtesy service; they serve no really useful purpose well, they're handy for centralizing filters against multiple domains, if you're willing to put your various primaries at the mercy of the filter service, and if the filter knows your valid recipients. what with ldap-smart servers and fancy routing, this isn't even hard anymore. but general backup MX is long-time dead. first the spammers killed our outbound flexibility by forcing everybody to close their relays, and then they killed our inbound flexibility by forcing everybody to close their generic backup MX paths. that cracking sound is stress fractures as the network gets more rigid. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Barracuda Networks Spam Firewall
On 5/17/2004 4:00 PM, Joe Boyce wrote: I Googled around and found a bunch of rulesets that once installed, started tagging those hard to get messages. http://www.rulesemporium.com/ is a good place to start if anybody else is running Spam Assassin straight out of the box. There's one rule that will wipe out ~90% of spam, but nobody seems to have written it yet. if URL IP addr is in China then score=100 support for a generic lookup list of cidr blocks would get another 9% -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Lazy network operators
On 4/12/2004 11:31 AM, Robert Blayzor wrote: address are getting lost in the fray. Having our techs/engineers go through the abuse@ box every day to play hide and seek is a bit of an agonizing task that nobody really wants, especially at the volume it is On the other hand, making me spend half an hour or more of my workday filling out forms for you just pushes the costs outside of your network and into mine. That's pretty rude, don't you think? Worse is that it's shortsighted. If everybody did this, then those reversed costs will get back to your own operation at some point. One day you'll find *yourself* spending several hours a day filling out abuse reports for other people's networks, whereas you used to be able to just forward them via email. Congratulations on raising everybody's costs, including your own. today. If there was a standard that worked for this, we would certainly follow it. Standardized scripts would also be abused. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Abuse mail boxese (was Re: Lazy network operators)
On 4/12/2004 2:53 PM, Sean Donelan wrote: I'm not sure people actually understand the scope of what some ISPs have to deal with. Percentage of revenues are about the same aren't they? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Lazy network operators
On 4/10/2004 2:26 PM, Chris Boyd wrote: NTL World no longer accepts abuse@ email. You have to go to a web form that requires javascript be enabled and enter all of the information for them. option [1] do their job for them so they can run a cheaper net, versus option [2] blacklist so that we both run cheaper nets -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Mail with no purpose?
On 4/1/2004 11:15 AM, william(at)elan.net wrote: Where as WYSIWYG html email client (no matter if its web-based or outlook or mozilla) will reference and display all images contained in email You can turn it off in Mozilla and some MS clients. It's a pretty common feature nowadays. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: disabling SMTP
On 3/28/2004 9:57 AM, Richard Welty wrote: before i write an extended explanation of why i don't like this idea much, i'd very much like to hear some of the motivation behind the proposal. It wasn't a proposal, it was a request for data. My own local data suggests that HELO is almost exclusively used by malware agents (modulo the internal appliances and user agents, which is why I referenced the local exceptions). I'm mostly wondering how representative that is. It might be feasible for some of us to disable legacy SMTP entirely. Nothing is universal, of course, and what works for me and my domains obviously wouldn't work for ~Hotmail or other large-scale providers. But since I don't manage those networks, they are not part of my local decision process either. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: disabling SMTP
On 3/28/2004 10:19 AM, Eric A. Hall wrote: might be feasible for some of us to disable legacy SMTP entirely. To be more realistic (and to close-in on any 'proposal' which might subsequently develop), it would likely be far more feasible to assign somewhat agressive negative weighting to sessions that use HELO (and further possible to assign mild positive weighting to sessions that use properly-formed EHLO), such as for use with session-wide rejects. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
disabling SMTP
I'm wondering if the installed base of legitimate messaging systems has migrated to ESMTP so as to get away with disabling plain-old SMTP except for internal devices. Anybody got any data or observations on this? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Dumb users spread viruses
On 2/8/2004 4:46 PM, Paul Vixie wrote: In this past year's tour of my friends and family, I've taken to removing their antivirus software at the same time I remove their spyware, and I've taken to installing Mozilla (with its IMAP client) as a way to keep the machine from having any dependency on anti-virus software. I switched to Communicator (and then Mozilla) a long time ago, and I also use older versions of Word or alternative products that are less prone to worms/viruses. I also run anti-virus scans on my mail server. But I still use virus checkers locally and I don't think it's a good idea for folks to be discounting their usefulness. There are too many other paths for infection -- web downloads, infected CD-ROMs (yes this still happens), and so forth. If performance is a problem then scan writes only, instead of writes+reads (you won't get infected if you scan every write to disk, while scanning reads is only going to produce a hit if you are already infected). -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Anyone from NeuLeve.bizl listening?
On 12/11/2003 9:31 AM, Joe St Sauver wrote: Speaking of NeuLevel, I believe the problems with .biz domains and incorrect registration data are more general in nature than just this one example, a point I attempt to make in an invited guest commentary for Syllabus.com: That's been my observation as well. NeuLevel does not enforce their ToS and spammers have taken advantage of the situation accordingly. NeuStar (one of NueLevel's parents) is quickly having the exact same problem with the .us registry, for the exact same reasons. The most-useful of the recent additions to my spam filters is to flatly reject mail containing URIs that point to .biz or .us domains. Not something most of us can do, but it sure works for me. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Fascinating interview with Verisign CEO
on 10/17/2003 3:17 AM Hank Nussbacher wrote: http://news.com.com/2008-7347-5092590.html First reaction is that this guy *really* needs some schooling in the value of having public-interest bodies facilitate and regulate interstate commerce in a federated system. Second reaction is that commercializing the infrastructure is a fairly dumb way to frame the debate, since we're not talking about the entire infrastructure but instead are talking about a couple of zones. Third reaction is that his opinion of what the Internet needs is not only wrong, but even if it were correct it would not give him the authority to usurp control over those zones. What next, all domains below the root have to pay a tax to the new emporer? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Fascinating interview with Verisign CEO
on 10/17/2003 12:05 PM Howard C. Berkowitz wrote: At 10:59 AM -0500 10/17/03, Eric A. Hall wrote: on 10/17/2003 3:17 AM Hank Nussbacher wrote: http://news.com.com/2008-7347-5092590.html First reaction is that this guy *really* needs some schooling in the value of having public-interest bodies facilitate and regulate interstate commerce in a federated system. Second reaction is that commercializing the infrastructure is a fairly dumb way to frame the debate, since we're not talking about the entire infrastructure but instead are talking about a couple of zones. Third reaction is that his opinion of what the Internet needs is not only wrong, but even if it were correct it would not give him the authority to usurp control over those zones. What next, all domains below the root have to pay a tax to the new emporer? A subtlety often lost in this discussion is that while we might want to get government out of the process, privatization does not necessarily mean commercialization. On one hand, privatization can go to a not-for-profit. Another alternative is to commercialize, but to treat the commercial enterprise as a regulated utility. Verisign is operating as a totally free entity. Regulated commercial activity is what we have now, and it has (mostly) been working pretty well up to now. What the interview illustrates (or rather, what the provided quotations illustrate, which may be out-of-context or erroneously summarized), is that he wants to eliminate the regulatory oversight part. He also seems unapolegitic in the inference that the unilateral wildcarding of the public zones are a natural first step down that path. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: requesting hard data sources on ramifications of verisign wildcard
on 10/16/2003 2:26 PM k claffy wrote: caida has the following request on behalf of icann's secsac committee a common theme over the last week is an admitted lack of hard data [rather than lists of theoretical breakages, and anecdotal evidence, and predictions] from the operational community on actual loss of stability in Internet performance or functionality. VeriSign's response to the IAB confirms actual breakage, but dismisses this acknowledgement by claiming that the breakages are insignificantly minor to the Internet community as a whole. This is fodder for the canonical political issue -- the original generic TLDs are public resources, and have operational and management requirements which are significantly more stringent than private TLDs. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Any way to P-T-P Distribute the RBL lists?
on 9/24/2003 9:30 PM Drew Weaver wrote: I know you all have probably already thought of this, but can anyone think of a feasible way to run a RBL list that does not have a single point of failure? Or any attackable entry? Easy. Have the master server only be reachable by replication partners through a VPN connection, and have dozens of secondaries advertising through multiple anycast addresses. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Any way to P-T-P Distribute the RBL lists?
on 9/25/2003 2:44 PM Aaron Dewell wrote: So why couldn't you follow this plan without the VPN and anycast? Multiple anycast channels would make distributed attacks ineffective, since each source would be attacking its closest target. VPNs can give you ~password protection for the master. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: VeriSign SMTP reject server updated
on 9/21/2003 11:19 AM E.B. Dreger wrote: Return NOERROR for one type of RR, but NXDOMAIN for another? Is that valid?! Hit me with a clue-by-four if appropriate, but I thought NOERROR/NXDOMAIN was returned per-host, regardless of RRTYPE requested. Giving NXDOMAIN for MX yet returning NOERROR for A RRs doesn't sound kosher. It's not valid and it won't work very well if it works at all. Your local cache will use whatever it learned on the last query. This is the seed for another problem set with the various workarounds as well, although I'm still thinking these through. Different servers that provide different kinds of glue could theoretically trip your cache. At this point, I think we're on the verge of having multiple (different) namespaces, which is extremely dangerous. At the same time, the arguments against multiple roots are pretty much going out the window. To be clear, however, I don't think the workarounds are the problem. I think VeriSign has broken DNS by conflating error codes. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: VeriSign SMTP reject server updated
on 9/20/2003 1:01 PM Matt Larson wrote: We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. You need to: 1) fatally reject mail for domains that are not delegated with 5xx -and- 2) softly reject mail for domains that are delegated with 4xx so the messages are requeed and may get to an authorized server on the next run Used to be able to use DNS for this. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: VeriSign SMTP reject server updated
on 9/20/2003 3:01 PM Sean Donelan wrote: Is it possible for the client resolver code to distinguish between a wildcard answer and an explicit answer? Or would the require another flag passed between the client and a recursive name server? If this was available, it would mail clients and other things interested in the specific domain name could get the answers they want. While other stuff would get the wildcard answers. Internet architecture generally favors abstracting higher-layer data away from lower-layer services. EG, we don't have ~BGP that routes :80 traffic separate from :25 traffic, nor do we have a URI syntax that allows you to refer to svc/tcp separate from svc/udp, nor do we have a naming service that allows for service-specific address responses. Although any of these could could be emulated, it wouldn't do anything for today's apps. My feeling is that this architectural design feature is becoming more and more of a restraint as complexity seeps in, the conflation of DNS error codes being just one of many examples. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: To send or not to send 'virus in email' notifications?
on 8/20/2003 9:25 AM Joe Maimon wrote: Considering the amount of email traffic generated by responding to forged virus laden email from culprits like sobig should email virus scanning systems be configured to send notifications back to sender or not? The least-harmful yet still-compliant mechanism is to reject the message during the transfer stage, instead of during the delivery stage. If the victim is sending their mail using an MTA that is built into the worm, that should be the end of it. If the victim is sending the mail by way of a real server (eg, a submission server or a smarthost), then the transfer rejects will probaly still result in delivery failure notifications being sent to the spoofed sender address. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Microsoft to ship new versions with firewall enabled
on 8/14/2003 9:29 AM Sean Donelan wrote: John Markoff reports in the New York Times that Microsoft plans to change how it ships Windows XP due to the worm. In the future Microsoft will ship both business and consumer verisons of Windows XP with the included firewall enabled by default. Wouldn't it make more sense to ship with all of the services disabled? I mean, if the role of the firewall is to block packets to weak services, wouldn't it be simpler to just disable the damn services since they aren't going to be usable anyway? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: OT: question re. the Volume of unwanted email (fwd)
on 6/18/2003 9:51 AM Miles Fidelman wrote: Someone on the cybertelecom list raised a question about the real costs of handling spam (see below) in terms of computer resources, transmission, etc. This dovetailed a discussion I had recently with several former BBN colleagues - where someone pointed out that email is not a very high percentage of total internet traffic, compared to all the multimedia and video floating around these days. The major cost items I've seen are increased bandwidth costs (measured rate), equipment, filtering software/services, and personnel. These costs vary depending on the size of the organization and the kinds of service the organization provides (as a dramatic example, the cost burden is proportionally higher for an email house like pobox than it would be for yahoo). There are other indirect costs too; lots of organizations have stopped sharing backup MX services because of problems with assymetrical filtering, which can translate into more outages, which can lead to ... My feeling is that any organization with at least one full-time spam staffer could probably come up with a minimal cost estimate of $.01 per message. End-users with measured rate services (eg, cellular) can also reach similar loads with little effort. But due to the variables and competitive concerns, you'll probably have to go door-to-door with a non-disclosure agreement to get people to cough up their exact costs, assuming they are tracking it. There has been much to-do about spam of late. Figures from Canarie show that SMTP transmissions account for about .5% of the volume of Internet traffic. This may be typical of backbone networks, or not. Commercial networks are jealous of revealing information of this nature. The backbone utilization isn't going to be relevant unless it is high enough to affect the price of offering the connection. The mailstore is where the pressure is at. Companies and users who sink capital and time into unnecessary maintenance have always been the victims. These costs also have secondary effects, like permanently delaying rate reductions (sorry your tuition went up again, but we had to buy another cluster), which in turn affects other parties, but the bulk of the pressure is wherever the mailstore is at. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Rescheduled: P2P file sharing national security and personalsecurity risks
on 6/13/2003 1:19 PM Richard Irving wrote: But, for this to make it to the NS Risk Assessment groups just demonstrates the licentious influence between the Current Administration Policies and Money Men. Uhh, this is a senate committee, not an administrative effort. And folks like Berman (the RIAA vigilante bill) and Feinstein (the MPAA) are Democrats. And you misused licentious. http://news.com.com/2100-1023-954591.html shows that this kind of effort has been going for a while. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Why replicate the DNS?
on 3/5/2003 8:58 PM Joe Abley wrote: I think Bill's point was that if a distributed database is required to contain routing policy, why not use existing distributed database infrastructure to host it (i.e. the DNS). I think it is fair to say that the delegation chain in the DNS is demonstrably more effective in allowing authoritative records to be located than the ad-hoc partial-mesh of mirroring and key replication currently found in the IRR. Delegation is different from content. Using DNS for delegation information makes a lot of sense, but trying to use it for complex content is just a bad idea. DNS is great for lightweight fast lookups of public-access data, but its not well suited to complex query structures, authenticated access, or multi-dimensional, time-sensitive data. As an analogy, everybody agrees that DNS should (must) be used for tasks like ~find the mail server, but nobody should seriously argue that we should use DNS to hold ~RFC822/MIME messages and entities. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Whitehouse Tackels Cybersecurity
on 9/18/2002 10:12 AM Sean Donelan wrote: On Wed, 18 Sep 2002 [EMAIL PROTECTED] wrote: A little flavor of what I'd alluded to in some of the previous threads. Any guesses what the proposal to change both BGP and DNS to improve security might entail?? The official document should be posted on WhiteHouse.GOV later today. Is it on again? Feds Delay Release of Cyber-Security Plan http://www.eweek.com/article2/0,3959,538677,00.asp September 17, 2002 The White House has decided to delay the release of its long-awaited cyber-security plan in an effort to gain more input from industry executives and government officials. Richard Clarke, chairman of the President's Critical Infrastructure Protection Board, has been planning for months to release the National Strategy to Secure Cyberspace Wednesday at a high-level event in Silicon Valley. But the board instead will release a draft of the strategy and will go back to private industry and public sector experts to seek more suggestions for the final plan, according to sources. [...] -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Microslosh vision of the future
on 8/12/2002 3:44 PM Brad Knowles wrote: Do you really think that they will ever again lift a hand against Microsoft? They only participated in the anti-trust action brought by the Clinton white house because they had no choice Yeah! The FTC actions res passport are just to throw us off the truth! http://www.infoworld.com/articles/hn/xml/02/08/08/020808hnftcboost2.xml http://www.eweek.com/article2/0,3959,449416,00.asp investigation started in this term, action concluded in this term please... somewhere else, thanks -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Stop it with putting your e-mail body in my MUA OT
on 7/10/2002 6:06 AM JC Dill wrote: list. What makes the PGP-MIME standard different, and so important, that the rest of us have to adapt to it, while eschewing other new standards? Nobody is forcing anybody to adopt it. OTOH, complaining to people who use the spec about problems with your own mailer is pretty dumb. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
