RE: ISPs slowing P2P traffic...
> "Not Exactly".. there is a court case (MAI Systems Corp. vs Peak > Computer Inc > 991 F.2d 511) holding that copying from storage media into > computer ram *IS* > actionable copyright infringement. A specific exemption was written into > the copyright statutes for computer _programs_ (but *NOT* 'data') that the > owner of the computer hardware has a legal right to use. I wouldn't draw any special conclusions from this case. For some reason, Peak did not raise a 17 USC 109 (ordinary use / first sale) defense, which would be the obvious defense to use in this case. Whether this is because their lawyers are stupid or because the specific facts of this case prohibit such a defense, I do not know. This does not seem to have been an ordinary sale, so that defense may not have been available to them. If so, the holding in this case has no bearing in the case where a person purchased a copyright work the ordinary way. But in the ordinary case, you can copy a copyrighted work if that is reasonably required for the ordinary use of that work. Otherwise, you couldn't lawfully color in a coloring book you had purchased because that would create a derivative work which violates copyright. When you purchase a work, you get the right to the ordinary use of that work. That's what you are paying for, in fact. By law, and by common sense, "ordinary use" includes anything reasonably necessary for ordinary use. This is for the same reason the right to "drive my car" includes the right to put the keys in the ignition. DS
RE: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
> Historically, .0 and .255 have been avoided because a lot of servers > (windows) wouldn't work using that as a host address or would flag it > as invalid if you tried to connect to it or a myriad of other > problems. Note that this was a limitation of the host, not anything to > do with the network or any of the network equipment. > > This issue has not existed with any prevelance for quite some time and > almost everything of recent manufacture is quite happy to be assigned > in a supernet as well as on the .0 and .255 addresses. > > So my oppinion is don't hesistate to use it until you find a real, > reproducible problem. > > -Wayne I have seen networks where traffic to these addresses was filtered in an attempt to mitigate broadcast address amplification. Typically, end users filter their inbound Internet traffic to their own addresses. They know they don't use .0 or .255 addresses and they found this is a quick way to prevent any nodes on their internal network from being used as amplifiers without having to audit/fix their entire internal network. As we know, the "workaround" may remain in their edge router(s) long after it has outlived its usefulness. A few years ago, I noticed that an ISP blocked all traffic from its customers bound for any .0 or .255 address to prevent drones from flooding those addresses. I doubt this is typical, but I bet it's still around in at least a few places. If you're seriously considering using these addresses, these are other possible issue you need to consider. DS
RE: cpu needed to NAT 45mbs
> From my experience, a fast P4 linux box with 2 good NICs can NAT > 45Mbps easily. I am NAT/PATing >4,000 desktops with extensive > access control lists and no speed issues. This isn't over a 45Mb > T3--this is over 100 Mb Ethernet. > > --Patrick Darden > --ARMC, Internetworking Manager A second CPU or core will help tremendously. We used to use single-CPU boxes for this and we noticed that traffic sometimes stalls when the machine has to do some task other than NATting, such as expiring idle flows. Having a second CPU or core will help keep latency much more uniform. We have a few dual 3.2Ghz Xeon boxes (not the ones based on Core, the older ones) that NAT/FW across two GE interfaces. They do quite well up to about 300Mb/s, then we start to see issues. We believe the issues are due to overloading the NB-SB link. A more modern mobo probably wouldn't have this problem. DS
RE: [policy] When Tech Meets Policy...
> That doesn't make anything criminal or fraud any more than free > samples. If a > registrar wants to give a refund, I don't see anything wrong with that. It is certainly fraud to take an entire pile of free samples. Domain tasting is more like buying a plasma TV to watch the big game and then returning it to the store on Monday. However, when it's as blatant and obvious as it is now (more tasted domains than legitimate registrations), and no policies are made to stop it despite it being so easy to do so (simply limit the number of refunded domains to 10% of registrations or charge a 20 cent fee for refunded domains), you can argue that it's now an understood and accepted practice. It's not fraud if both parties know it's going to happen, can easily act to stop it, and neither one chooses to. DS
RE: How should ISPs notify customers about Bots (Was Re: DNS Hijacking
> On Mon, 23 Jul 2007, Joe Greco wrote: > > Intercept and inspect IRC packets. If they join a botnet > > channel, turn on > > a flag in the user's account. Place them in a garden (no IRC, > > no nothing, > > except McAfee or your favorite AV/patch set). > Wow, you are recommending ISPs wiretap their subscribers. > > I suspect some privacy advocates will be upset with ISPs doing that. Suppose I add a firewall rule to my router to block traffic to a particular port. Does my router thereby "wiretap" every packet passing through it because it needs to find out its destination port in order to determine if the rule applies or not? It is sometimes a tricky issue when you filter through legitimate traffic to stop illegitimate traffic. But a rule that this is always wiretapping of anything subjected to the automated inspection leads to ridiculous results. DS
RE: DNS Hijacking by Cox
> No amount of IRC redirection is going to remove bots and fix their > compromised computers. > > ... JG Let's not confuse two different forms of IRC redirection, one which I think is perfectly okay and one which is definitely not okay. In the first type, the redirection is an immediate response to a threat that is not completely understood. Clients that connect to the target of the redirect are studied. Legitimate clients are separated from compromised ones as quickly as practically possible. Legitimate clients are given a message, if possible, that the service they are trying to use is temporarily unavailable due to a current threat. If there is some other way they can access the service (for example, direct entry of the IP), they are informed of that. Compromised clients are tracked and, where possible, notified. The current level of the threat is tracked, and when it is sufficiently minimal, the redirect is removed. This model is perfectly reasonable as a response to all kinds of threats. This includes cases where a traffic has to be blocked or redirected due to a new attack. The second form is the one that causes a problem. In this case, no attempt is made to study or understand the threat once a way to block it is found. Collateral damage is ignored, no effort is made to minimize inconvenience to legitimate users. No effort is made to notify compromised users. The filter or redirect is left in place indefinitely, until and unless a large number of complaints is received. The threat is not even monitored. The filter/redirect is considered a permanent solution. While it may officially be regarded as temporary, it is effectively left there and forgotten. Now these are two very different approaches to a threat. However, they both can involve hijacking, filtering, or redirection. I used to work as a consultant, helping companies negotiate contracts with ISPs. One thing I always did was make it clear that the first type of response was perfectly permissible, even if it harmed us, but the second was not, even if it did not harm us. DS
RE: Security gain from NAT (was: Re: Cool IPv6 Stuff)
> Again, whether the lock/deadbolt come as a package deal with the screen > door or not, it is the lock/deadbolt that provide the security, not > the screen > door. Wow, I don't know what to say. I've never heard of a screen door that came with, and could not work without, a lock and deadbolt. It's totally obvious that you had no intention of implying that typical NAT implementations didn't provide any security. And, by the way, in all of my real examples, it was the actual NAT that provided the security. The Windows machines are behind a device that has but one rule configured in it, and it's a NAT rule. The NAT rule is the only thing that causes the machine to do any stateful inspection at all. That is, one single element provides the NAT and the SI, SI is the means by which the NAT is implemented, and SI is the only way to provide NAT. The device is *NOT* configured to reject inbound by default. Other machines on other parts of my private network *can* reach it through its NAT on its private addresses. Our wireless network, for example, has its own NAT to reach the Internet and its own block of private addresses, but can reach the wired Windows boxes on their private addresses. Yet you *STILL* can't log into my Linux box even with the root password. You still can't access my Windows network shares even with the administrator password. If it was on a public IP address, all other things being the same, it would take you ten seconds to get into it. These machines have never been compromised. All other things being precisely the same, without the private addresses, they would never have lasted. It is simply a fact that private addresses and NAT itself do provide some security. You can get this same security without the private addresses and without the NAT, but that changes nothing. This is the claim you are defending: "There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding." So why can't you break into these machines when the only thing stopping you is that they don't have real IPs. There is no other security of any kind in place. There is no "reject inbound by default", no firewall rules (except NAT itself). The only stateful inspection is used to make NAT work and is the *implementation* of NAT itself. All I have is the very thing you claim provides "no security gain". And it's what's stopping you. DS
RE: Security gain from NAT (was: Re: Cool IPv6 Stuff)
> On Jun 4, 2007, at 11:32 AM, Jim Shankland wrote: > > Owen DeLong <[EMAIL PROTECTED]> writes: > >> There's no security gain from not having real IPs on machines. > >> Any belief that there is results from a lack of understanding. > > This is one of those assertions that gets repeated so often people > > are liable to start believing it's true :-). > Maybe because it _IS_ true. > > *No* security gain? No protection against port scans from Bucharest? > > No protection for a machine that is used in practice only on the > > local, office LAN? Or to access a single, corporate Web site? > Correct. There's nothing you get from NAT in that respect that you do > not get from good stateful inspection firewalls. NONE whatsoever. Sorry, Owen, but your argument is ridiculous. The original statement was "[t]here's no security gain from not having real IPs on machines". If someone said, "there's no security gain from locking your doors", would you refute it by arguing that there's no security gain from locking your doors that you don't get from posting armed guards round the clock? DS
RE: Bogon Filter - Please check for 77/8 78/8 79/8
> So we're saying that a lawsuit is an intelligent method to force someone > else to correct something that you are simply using to avoid the > irritation > of manually updating things yourself??? > > That seems to be the epitomy of laziness vs. litigousness. > > Scott No, but a lawsuit may be an intelligent method to force someone to correct something that other people are using to avoid the irritation of manually updating things themselves. I agree it would be idiotic if someone using the bogon list were to sue the list operator because they didn't like what was on the list and it was harming them. If all other methods fail to get the bogon list updated, which is easier: A) Track down everyone using the bogon list and convince them to switch to manually updating their own list of bogons so that they can reach you. B) Threaten the bogon list operator with a lawsuit for falsely claiming your addresses are bogons and hope they take the simplest path and fix their list. This is a pretty classic case of someone inducing other people to rely on the accuracy of their data and then offering incorrect data (not arguably incorrect, manifestly incorrect and most likely negligently so) which those other people then rely on. It's no different from a credit report with inaccurate information affecting a consumer who did not choose to have his credit tracked by the agency providing the information. We generally recognize third parties have a right to sue to correct negligently demonstrably incorrect information about them when that information harms them. This is not like lists of spam sources where the list is correctly reporting information the spammer would prefer to suppress. This is a case where the list is wrong, and it's harming other people who stupidly relied on it and people who never chose to rely on it. If you set up a service and induce people to use it and rely on it, there definitely should be some minimum standard of quality you should be held to. I think failing to update a bogon list to reflect address space that is no longer a bogon within a week or so is negligence under any standard of care. DS
RE: Collocation Access
> On Tue, Oct 24, 2006 at 05:51:17AM -0700, David Schwartz wrote: > > Then you broke the law, assuming you had a Florida license and > > you presented > > it to the Miami facility. > > Florida law, Title 13 section 322.32(2), "Unlawful use of license" says > > "[i]t is a misdemeanor of the second degree ... for any person > > ... [t]o lend > > his or her driver's license to any other person or knowingly > > permit the use > > thereof by another." > David, it's clear you're not a lawyer, or have ever done anything that > requires that you interpret what a law means, other than the normal > everyday requirements of a citizen. > Joe Yao I am way too familiar with several cases where people were charged and convicted with violating obscure laws clearly intended for another purpose just for doing their jobs in a normal, reasonable way. Intel v. Schwartz (no relation) is a great example. http://www.eff.org/legal/cases/Intel_v_Schwartz/schwartz_case.intro It's quite possible (even likely, IMO) that when Florida makes it illegal to lend your driver's license to any other person, it actually means precisely that. DS
RE: Collocation Access
> > Then you broke the law, assuming you had a Florida license and you > > presented it to the Miami facility. > > > > Florida law, Title 13 section 322.32(2), "Unlawful use of license" says > > "[i]t is a misdemeanor of the second degree ... for any person ... [t]o > > lend his or her driver's license to any other person or knowingly permit > > the use thereof by another." > Hmmm, I read quite a bit of difference between "retain your ID" > and "permit > the use of" - maybe one of us is reading something that isn't > there. Intentionally receiving a document is usually sufficient to establish possession. Some statutes say "possess", some say "use", some say use for specific purposes. If they say "possess", you're definitely potentially screwed -- if you ask for it and receive it, you possess it. If they say, "use for purposes of [x]", then you're definitely safe (since you're probably not using it for any of the prohibited purposes). If the statute just says "use", then ask a lawyer. Use is more than possession, but it's not clear exactly how much more. With luck, rational courts will hold that "use" means to use it as a means of identification and you'll be okay. This Florida statute makes it a crime to "lend" your driver's license to any other person (punishable by up to 60 days in jail). I can't imagine how permitting someone to retain something temporarily does not constitue lending, but I suppose courts might hold that unless you use it, I haven't really lent it to you. This is murky stuff, definitely not someplace you want to go without talking to a lawyer. If you possess or transfer any government-issued identify document without lawful authority in order to facilitate any violation of Federal law, 18 USC 1028(a)(7) puts you in jail for a very long time. Are you getting into that facility to facilitate breaking some obscure intellectual property or electronic privacy law? > Quite a > few places "retain" your ID while you are on the premises, to > include places > "holding" your passport while you are there, etc, etc... In that case, they definitely possess it, you probably lent it to them, and they may or may not be using it. Read your laws carefully. Some jurisdictions really do make it a crime to possess someone else's official identification. Receiving something intentionally usually is sufficient to establish possession. IANAL. DS
RE: Collocation Access
> In recent memory, I can think of two large collocation > centers that retain your ID. One is in Miami and one in New York (I don't > think I need to name names, most of you know to which I refer). > All others > (including AT&T) have never asked to retain my ID. Then you broke the law, assuming you had a Florida license and you presented it to the Miami facility. Florida law, Title 13 section 322.32(2), "Unlawful use of license" says "[i]t is a misdemeanor of the second degree ... for any person ... [t]o lend his or her driver's license to any other person or knowingly permit the use thereof by another." DS
RE: Collocation Access
> On Mon, 2006-10-23 at 18:57 +0100, Roland Perry wrote: > I've been in and out of several colos that require you to leave your ID > (passport/DL, and business card) up at the front desk throughout your > visit. This could be for hours, or even for the whole day. During that > time I imagine my ID could have been photocopied, transcribed, > photographed, etc, without me ever knowing. > > -Jim P. Several states make it illegal to possess another person's driver's license. Many make it illegal to lend your driver's license to someone else or to trade it for something. As for passports, violating 18 USC 1544 for profit is a terrorism offense. Even the guys who rent paddleboats at the lake have learned that it is usually illegal to possess another person's identification. Maybe I've just been lucky, but I've been to some of the most secure facilities in the world, and I've never been asked to allow someone else to retain my passport or driver's license. Possession includes receipt, according to the DOJ. 18 USC 1028 makes it a Federal crime to transfer someone else's identification with intent to violate a state felony statute. This is a minefield. Have companies really run this past their legal departments? DS
RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
> Joe McGuckin typed: > >> 2) Why does ARIN believe that it can ignore a court order? > Maybe because ARIN wasn't a party to the original proceedings > that generated that order? > Let's say you're eating lunch one day, minding your own business, > and a sheriff comes up with an official looking document and > says "You need to hand your car over to Fred..." because, > unknown to you, Fred and Barney just finished court proceedings > where the judge ruled that Barney had to give Fred "his" car, > even though that car was owned by you and just loaned to Barney. > > Not a great analogy, because of the whole pink slip thing, > but you get the point. You comply with the court order to the extent that it will not do irreversible damage to you, and you contest the order in court. To the extent that the court order will do irreversible damage, you stall compliance until you can get a court to suspend the order until you have time to fully contest it. What you don't do is flat out refuse to comply with the court order with the beneficiary of the court order and make them go to court to enforce it. If you assume that all Kremen's accusations are true (and correct the obvious errors) his case seems very strong. ARIN should not have refused to comply with a court order or insisted on conditioning its reply. Even if you assume that allocations made by ARIN are not property, it's hard to argue that pre-ARIN allocations are not. They're not subject to revocation and their grant wasn't conditioned on compliance with policies. DS
RE: SORBS Contact
[combined responses] > You do realize that when we talk about "sending" data we are using > language in a very loose way, right? Data isn't actually sent. When I > "send" a packet of data, I still retain that data. If you lose it you > have only lost your copy of it, not mine. The packet includes its origin, destination, next hop, and like information. If the copy were identical to the original in all respects, it would not be a copy. There must be some distinction between the two, and it is that distinction that makes the "copy" useful. (That's why you made it.) > Are you one of those people that makes an extra photcopy when you have > to fax one to someone? Why fax something to someone at all then? If the fax really is the same as the original, why bother faxing? Obviously, there is a difference between the two copies, and the value of the duplicate is in that difference. The fact that the information can change physical form doesn't mean it isn't a coherent object. For example, my car may exchange electrons with your sidewalk, but that doesn't make it any less my car. The value of the car is not in which particular electrons it has (which can change) but in their arrangement and utility (which does not). If I have some information that I want to get to a particular place, and I make a copy and dispatch it toward its destination, that copy with its destination information behaves just like my car does. It changes on the way, but it does not ever become any less my car (or the ultimate recipient's car) regardless of whose roads it travels over. > > Your argument is similar to a mall that claims they can > > shoot people who > > It is illegal to shoot people whether they enter your mall or not. Precisely. Your obligation not to destroy someone else's data is a basic tort obligation that applies to how you must treat other people's property, even if it happens to be on "your network". > > The same would be the case if I used FedEx to return > > something of yours to > > you. If they destroyed your property, you would have a claim > > against them > > even though you didn't pay them for anything. > IANAL but I am pretty sure that my claim would be against you, not > FedEx. You would have to counter claim against FedEx because you made > the contract with them. You could make a claim against me and I could counter claim against FedEx. But you could also claim against FedEx directly. They destroyed your property. >Whatever you're smoking, you've really gotta share some with the rest of >us. :P I guarantee you that there is not a single packet that I will route >which is neither from nor to someone I have a contract with. If you want >to give away free service to people without contracts that is your right, >but I sure as hell don't have to. Transit networks route many packets that are neither from nor to anyone they have a contract with. They pass the traffic from aggregators to aggregators. This is the same as a person who walks from store to store in a mall even though he has no contract with the stores, the stores have contracts with the mall. >Packets are not property, there is no intrinsic value in returning them to >sender. Plus I guarantee you if you drop off a package with Fedex and >don't pay for it (thus entering into a contract with them for services), >they will eventually throw it in the trash rather than deliver it. Packets are property. There is no value in returning them to sender but there is value in delivering them to the recipient. If the lack of return value is evidence against property, why is the presence of delivery value not evidence for? I don't deny that you can drop a packet on the floor if nobody paid you to carry it and you did nothing to solicit its presence on your network. That is not the same as the case where somebody paid you to carry the packet, but the person who paid you is not the owner of the packet but merely someone similarly contracted by the owner. >This is no different from me authorizing Mail Boxes Etc to be my >proxy for UPS packages, and them being allowed to simply discard >anything from, say, an ex-wife. My ex-wife has no claim, in this >hypothetical, against MBE for tossing my package in the trash, >because they're acting as my agent. You are quite correct *if* they are the agent for the intended recipient. In the general case, a transit carrier will not be an agent for the intended recipient and possibly not for the originator either. >Of course, that only applies if you're dumb enough to answer '250 OK' to >the '.' after the DATA. You 5xx that puppy anywhere before that, and you >haven't taken custody of that data... Exactly. I think the mail case is simpler though because it is quite rare for an email message to wind up in the hands of someone who has no contractual relationship with either the sender or the recipient. Exceptio
RE: SORBS Contact
> Obligation to _whom_? My only obligations are to those who _pay_ me for > access to my systems/resources. If the people who *do* pay me for use of > my systems/resources "don't want" that cr*p, then I do 'have an > obligation' > to _not_ deliver that traffic. Nonsense. You have tort obligations as well as contractual obligations. Specifically, if you take custody of someone else's data, and you have no contract with that person, you have a tort obligation not to destroy it. Your argument is similar to a mall that claims they can shoot people who don't buy anything. After all, their only obligation is to those who pay them. But of course neither you nor they can do that. By setting up a network and connecting it to the Internet, you know that you will sometimes carry packets that are neither from nor to someone with whom you have a contract. Those are not your packets, and you have no contract with their owners, but you handle them in the ordinary course of your business, so you have a variety of tort obligations to them. The same would be the case if I used FedEx to return something of yours to you. If they destroyed your property, you would have a claim against them even though you didn't pay them for anything. I see the view you are expressing quite commonly among network operators and it is, IMO, dangerous. It is, of course, your network. But it handles other people's data. Of course, you can protect your own network. Just as FedEx can destroy a bomb if someone tries to ship it through them. But you cannot do whatever you want with "your packets" unless they really are your packets. I will defend your right to do anything reasonable. However, it is incorrect and dangerous to assert that because it's "your network" you can do anything you want. Even if it's your mall, you can't invite people into it and then shoot them just because you have no contract with them. DS
RE: Detecting parked domains
> Parked: >A domain hosted by a middle-man for the sole purpose of generating >revenue from pay-per-click advertising. Characterized by having no >content of value. > > This definition *might* work for NANOG, but my parking friends would > disagree with the above. If this is what you mean, then it is impossible to do so automatically. This definition requires determining the motiviation for the registration, which cannot be done by any technical means. For example, this definition would exclude a domain temporarily parked for a few months while a service is prepared and tested. If you mean determiming if a domain is likely to be parked or definitely has some other set of characteristics, it helps to work that out in precise detail. I'm not trying to be a pain, I'm genuinely trying to be helpful. For example, a commonly asked question is "how can I tell how much memory my program is using" and the canonical answer is "define what you mean by 'using memory' and the answer will be obvious (or at least you'll be on your way to getting it). (Physical memory? Virtual memory? Is the memory footprint of a shared library to be counted as 'used'? What if this is the only program that's using it? And so on.) DS
RE: www.gigablast.com
> :-) Let me add something before everyone on NANOG reminds me that > gigablast is a search engine. I know what they do, but what I don't > understand is why are they searching my systems for URLs that haven't > ever existed there before. It's as though they are doing random word > searches in hopes of striking lucky. They are "crawling" for URLs like > this: (unfortunately most people won't see these because their spam > blockers will block all the exclamation points) [list of random path names snipped] This seems to be a very wrong and bad thing to do. Google searches URLs because a human gives it permission to do so, for example by linking to that URL. (What purpose does a link have other than to be something to click on.) What gigablast seems to be doing, on the other hand, is trying to open every window in a house in the hopes that it will find one that's open. It has no invitation or permission to do this, and I would consider such behavior inappropriate. You do not have the right to make requests of other people's computers without their permission. You can certainly argue implied permission in many cases -- for example, if Ford registers the domain ford.com, and assigns an IP address to 'www.ford.com', you can certainly argue that they have invited the public to access that URL because that's the normal reason people create such things. However, you have no implied permission to try numerous combinations of random paths on the end of that in the hopes that you'll find something Ford did not invite you into. DS
RE: DNS Based Load Balancers
John Payne wrote: > On Jul 5, 2006, at 5:18 AM, Lincoln Dale wrote: > > utopia would be for DNS to be enhanced in some manner such that the > > 'end > > user ip-address' became visible in the DNS request. > > utopia would have NAT devices which actually updated that in-place > > so an > > authoritive nameserver always authoritively _knew_ the public ip- > > address of > > where the request was coming from. > That would kill all cacheability of DNS. Only if you envision an extension that adds an 'end user IP address' to the query and doesn't add a 'scope of cacheability' to the reply. I admit it's possible that an extension could be bungled that badly, but not likely. DS
RE: key change for TCP-MD5
> How often do you think keys should change? Arguably, any time someone who had access to the key is no longer supposed to have such access. > I've never had anyone ask > to change keys for about 50 session-years. I guess the question the question is whether that's because they really never needed to, really didn't think about, or really didn't want to suffer the hassle and so just accepted the risk. DS
RE: private ip addresses from ISP
> Our router is running BGP and connecting to our > upstream provider with /30 network. Our log reveals > that there are private IP addresses reaching our > router's interface that is facing our upstream ISP. > How could this be possible? Should upstream ISP be > blocking private IP address according to standard > configuration? Could the packet be stripped and IP be > converted somehow during the transition? It happens in > many Tier-1 ISP though ! > > Thank you for your information Do you mean: 1) You are seeing BGP routes for addresses inside private space? 2) You are seeing packets with destination IPs inside private space arriving at your interface from your ISP? 3) You are seeing packets with source IPs inside private space arriving at your interface from your ISP? If 1, feel free to filter them. You ISP probably uses them internally and is leaking them to you. Feel free to complain if you want. If 2, make sure you aren't advertising routes into RFC1918 space to your ISP. If not, you should definitely ask them what's up. If 3, that's normal. These are packets your ISP received that are addressed to you and the ISP is leaving to you the decision of whether to accept them or not. Feel free to filter them out if you wish. (It won't break anything that's not already broken.) DS
RE: MEDIA: ICANN rejects .xxx domain
> Why? > > If we can coral them in it and legislate to have no porn anywhere > else than on .xxx ... should fix the issue for the prudes out there. The major problem with this is that many other governments have "dangerous ideas" that they'd also like to be easily able to identify and isolate as well. If the United States gets to corral porn, why can't China corral Democracy? Why can't Russia corral advocates of "terrorism" (which some might consider independence). I think it would be an incredibly short-sighted policy on the part of the U.S. government to restrict the Internet in the hopes of controlling things like gambling and pornography. The precedent of government isolating "dangerous ideas" will be adopted by many other governments and we will have no sound ideological grounds to oppose. DS
RE: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
> I haven't seen any succinct justification for providing a > 550 message rejection for positively-identified spam versus > silently dropping the message. Lots of how-to instructions > but no whys. > > matthew black > california state university, long beach Because your father may forward a copy of a Nigeria scam from a new email address he just got with his new ISP and ask if you if he should send them money. Because a machine you own may be responsible for the spam, and someone may be forwarding you a copy of it along with the tracking information to demonstrate that you were responsible for it. Because the spam may include a trademark you own and you may need to notify your legal department about it. The spam may have been helpfully forwarded to you by someone familiar with your trademarks. Because if you say you are going to deliver a message, that's what you should do. Because being spam is not the same as being unimportant. All of these things really do happen. >Agreed, but we're willing to live with an error rate of less >than one in a million. This isn't a space shuttle. I don't think >the USPS can claim 99.% delivery accuracy. Nonetheless, to >allay worries, we are considering spam quarantines to allow >recipients an opportunity to review spam messages themselves, much >like Yahoo! Mail. It is one thing to have an error rate of one in a million, it is quite another thing to choose to have an error rate of one in a million instead of one in a billion for no rational reason at all. If the measure is what fraction of positively-identified spam the recipient would probably rather receive than not receive, it's probably more like one in 5,000. If the measure is what fraction of positively-identified spam the recipient would rather the sender get a reject than silently discard, it's probably more like one on 20,000. The argument on the other side is if the positively-identified spam comes from a business-critical mailing list that unsubscribes people if they have too many bounces. This probably isn't an issue for viruses and malware because these rarely get past the filters these lists already have. It is a big issue for spam and one of the few for which there is no good solution I know of. (Other than having the recipient whitelist the list at the MTA, which is hard to do.) DS
RE: Open Letter to D-Link about their NTP vandalism
> 2) *Who*says* there is 'malicious intent' involved? I'm going to be > travelling 'off network'(with the 'network' being defined as the one where > I have published that I'm providing time-server services to), and I happen > to have a recurring need for 32-bit units of a specifically > transformed out- > put of a local hardware-based "/dev/random". So, I put up a > server to deliver > that data when requested. For reasons of 'convenience' in my programming, > I choose to format the queries/responses like a particular 'well known' > protocol, and run it on the port associated with that well-known protocol. > Do I have any responsibility to 'announce' that I'm doing something like > that, for 'private' use? I don't understand how you can think that a hypothetical where we don't know what the intent is constitutes a response to a situation where we do know exactly what the intent is. I hope your argument is not "if you can lie and get away with it, then it's okay". That doesn't sound like a good business model to me. > again, denying service (assuming there's no explicit contract to provide > it) is unquestionably safe. i was responding to the proposal that the wrong > time be deliberately returned. you'd be betting that nobody would notice > or that it would cost nobody money -- which isn't a safe bet, since someone > can always find ways to allege that your intentional actions cost them money. > (as opposed to your deliberate inaction, as in the case of denying service.) The problem is this case is that there is no perfect way to deny service. If bums are trampling your garden to take food out of your garbage, you can lock the garbage can, but you can't poison the food. The problem becomes when the locked garbage can is a problem for the garbage collectors. I don't think anything short of legal action against D-Link is likely to solve this. I'd love to be proben wrong. DS
RE: Compromised machines liable for damage?
> There have been successful cases for pedestrians that used a train > trestle as a walk-way, where warnings were clearly displayed, and a > fence had been put in place, but the railroad failed to ensure repair > of the fence. The warning sign was not considered adequate. Would > this relate to trespassers that use an invalid copy of an OS refused > patches? Would this be similar to not repairing the fence? Clearly > the pedestrians are trespassing, nevertheless the railroad remains > responsible for the safety of their enterprise. There is a huge difference that everyone seems to keep ignoring. Most of the defective software issues we're talking about here cause no damage until a knowledgeable person with malicious intent knows the 'defect', specifically intends to cause harm with it, and uses the defect specifically to cause that harm. This, unfortunately, makes it more analogous to the 'defect' in a gun that a criminal can use it to do harm just as an honest person can use it to prevent harm. Of course, it also makes it analogous to a gun that, when you point it at a criminal, the criminal can make it blow up in your hands. DS
RE: What do we mean when we say "competition?"
> So... Microsoft has a monopoly on Windows and the basic OS costs > you $299 with virtually no server capabilities. > > In the POSIX-style OS world, where you have multiple competitors, > prices range from $0 to $179. Either these products are comparable or they are not. If they are comparable, then Microsoft has no monopoly and the prices are low, as low as $0. If they are not comparable, then the fact that one is cheaper says nothing. > True, but, this one does. There are multiple ways to skin a cat, > and, multiple versions of Windows pricing. Any way you slice it, > MicroSoft remains the most expensive OS in the market. > Everyone elses OS prices have come down since the days of Win 3.1, > Microsoft's have gone up (about 600% -- $49 to $299). Which proves that Microsoft has been *unable* to keep prices high. OS prices have fallen despit Microsoft's effort to keep prices high. > > Microsoft hardly has a monopoly on servers. If their > > prices are too high, use something else. > Microsoft has a monopoly on Active Directory servers. > Microsoft has a monopoly on Exchange servers. > > If you are unfortunate enough to need either of these things > (I thank my lucky stars every day that I am not), you have to > buy them from Micr0$0ft. Every company has a monopoly on its proprietary technologies. If you need either of them, thank your lucky stars Microsoft makes them available to you. > Agreed. Instead of granting further monopoly positions and first-arrival > advantages and again allowing the first provider into the market to > prevent all future comers, let's avoid the fight and separate the > LMI from the overlying service. Except it may be that the right and best business model is combined LMI and overlying service. It may be that some infrastructure is too expensive to provide without the added revenue from an overlying service monopoly. What is your solution to that problem? Subsidy? Or live without? > If you limit it to the scope I speak of, you are limited to an area where > very little innovation has occurred in the last 50 years, or, is likely to > occur in the next 50. Category 3 UTP hasn't changed in more than > 50 years. > Fiberoptics date back to the 1840s with singlemode being > introduced in 1961 > and adapted for telecommunications in 1966 and it's current form being > perfected around 1970. 75 ohm TV Co-Ax has also been pretty standard > for a very long time (RG58 is, I believe, the most common) I think this is a deceptive argument. There has been lots of innovation in last miles. Fiber to the home, IP over powerline, wireless, over cable, via satellite, and so on. A subsidized way of doing the last mile could damage this innovation. And I don't think you can regulate without subsidizing. (See my other posts for the arguments why regulation will compel either subsidy or shortage.) > Given universal household access to singlemode, UTP3, and RG58, I don't > believe > there is a single terrestrial facilities based communications service > available > today that would be impossible (obviously, the current cost of > DWDM hardware > and supporting backbone equipment makes OC-192 to the home impractical > today, > but, not impossible given the facilities above). And if you decide that what we have today is good enough and compel or subsidize it, then there will be no reason to develop newer technologies. This is looking at where we are and ignoring how we got here. > I cannot deny that there is a possibility someone will come up with some > super-innovative media for terrestrial facilities-based transmission, but, > I can say that there is very little effort being put into such research > at this time because single-mode fiber is so economical at this point that > nobody really feels there is a need for or significant benefit to such > an improvement. Were a compelling new media to come along, I'm sure that > someone would deploy it. If it's so economical, why can't five companies bring it to my house? How can you argue it's super-economical and a natural monopoly because of expense at the same time? How do you know that the alleged natural monoply isn't a technical problem with a solution around the corner? > Bottom line, we have achieved market competition and fair access to all > other portions of the network. LMI at layer 1 has proven to be the sticky > wicket that remains a natural monopoly no matter how hard we try to change > that. As such, I think it is time to accept the fact and deal with it > accordingly, instead of continuing to allow it to preserve destructive > monopolies in other areas. In other words, single-mode fiber to the home is *NOT* so economical. It is funny how the advocates of regulation always have to argue both sides of every issue to try to find some traction. "Monopoly means higher prices." But the prices are lower. "Well then, monopoly means lower price
RE: What do we mean when we say "competition?" (was: Re: [Latest draft of Internet regulation bill])
> > Right, and this is appropriate. Large investments in infrastructure > > should *not* be made if there's already adequate service. Better to > > invest in places where there isn't. > Is that still true if the "adequate" service is being provided at a price > which is two to three times what it should be costing and the provider > is enjoying the ability to do this because nobody else is in the market > space? It depends how much they invested. In some areas that are very expensive to serve, that may be precisely what happens. In areas that are easy to serve and customer dense, you won't get away with this for very long. You need prices to be high where it really is expensive to provide access because that's what provides the incentive to develop cheaper ways to provide access. Perhaps we don't all fly personal planes today because the government chose to build roads. > > The government can't do a good job of picking winners and > > losers, so stop > > letting it. > Agreed. So, let the government do what it does well... Manage the things > that tend to be natural monopolies and keep it out of everything else > as much as possible. Are you arguing that there should be competition > for the provision of highways, for example? Yes. > How would you see that > working? Do we stack six copies of I-80 on top of each other, or, do > we allocate multiple semi-parallel routes for freeways and let different > companies build different routes and charge what they want for each of > them? How do you see that working on a neighborhood level? Even > if you think it works at the highway level, we're really talking about > the neighborhood streets here. Now you are asking me to pick the winners and losers and claiming that if I'm not smart enough to pick the winners and losers, a free market won't work. I am the one saying nobody is smart enough to figure out how to do it. You are the one saying governments will be smart enough to build the right infrastructure and now slow innovation. (As they always have in the past despite every effort to provide 'equal access'.) > The last-mile infrastructure for terrestrial services looks a lot more > like a local roadways inside a neighborhood than any other analogy > I can think of. I have yet to see any environment where this has > been accomplished on anything other than a monopoly basis. The monopoly is not the problem. The lack of competition is the problem. Perhaps you don't see the difference. If a monopoly is the most efficient result, then competition will lead to an efficient monopoly. It's when you choose a monopoly and shut out other efficient results that you have a problem. That's the situation we have now and that's the situation you propose to maintain. If it's expensive or impractical to run eight company's fiber in a city, then make the companies pay that expense to run fiber or don't let them. That way, we'll have eight fibers if that really is the right solution and we won't if it isn't. If someone wants to run carrier-neutral fiber, they can do so. But if that's not the best model or best solution, don't shut out the others. > >> The list goes on, but, believe me when I tell you that there are > >> plenty of consumers in California that do not feel that SBC > >> is meeting their needs, but, they don't have access to a real > >> CLEC. > > > > Oh, I know that story, believe me. > So, do you really think that if SBC had the same terms for access to > the MDF<->MPOE leg that any competitor had this would not actually > change or would get worse? I don't. I think it would actually > solve many of the current problems and encourage many of the CLECs > to re-enter the market. I think if SBC had to open their circuits, they wouldn't build as many of them unless they were forced to. Living in an area with no local high-speed access options, I want them to have every incentive to build new infrastructure. If you force them to build new infrastructure, or subsidize it publically, then you are again picking winners and losers. The big losers will be the new technologies, because they'll never have a chance If a free market naturally creates a problem, then it creates an incentive for a clever solution. No person or group could engineer a solution as clever as the one the market will evolve. But your proposal requires such a group. It essentially extends exactly what we have now. > > And what about a carrier that needs different > > infrastructure to provide > > the type of service it wants to provide? > They can build it, and, if they get a competitor that wants equal access > to it, they get reimbursed for the build. You realize that that is absolutely crazy. That's like saying "you can buy a lottery ticket, and if you win, give me the ticket and I'll reimburse you its cost. > > And repeating the same problem 50 years from now when > > innovative serv
RE: What do we mean when we say "competition?" (was: Re: [Latest draft of Internet regulation bill])
> In any case, the bottom line is that whether through subsidy, "deal", > or other mechanism, the "last-mile" infrastructure tends to end up being > a monopoly or duopoly for most terrestrial forms of infrastructure. > As such, I think we should accept that monopoly and limit the monopoly > zone to that area (MPOE<->B-Box or MPEO<->MDF) and prevent an unfair > advantage by separating the management of that section of infrastructure > from the service providers offering services which use said > infrastructure. This is the same "create a free market through extensive regulation" that has created the disaster we have now. Any last mile technology whose cost of deployment can only be justified by the value of a monopoly on its deployment just won't be deployed in this model. That's not a free market. This separation model may turn out to be a very good one or a very bad one. But if we choose it and stick with it, what will happen in 50 or 100 years when it's either broken or irrelevent? Remember, we got to where we are now by choosing models that made sense in the voice telco time and make no sense at all now. Had we done this twenty years ago, the last mile would be dialup and billions of public dollars would have been spent to create and maintain an irrelevent technology. Meanwhile, the newer technologies wouldn't be deployed. > This, at least on a theoretical level creates a carrier-neutral > party managing the monopoly portion while maximizing and levelling > the playing field in all other areas. A carrier-netural party may not be technology neutral, business model neutral, or neutral in many ways that may turn out to be important. As I see it, you give up on everything that's important from the very first step. What if a non-carrier neutral last mile turns out to be the scheme most people really want when it's offered to them? Competition in last mile technologies, deployment strategies, contract terms, and the like are not just important, they're absolutely vital. If you try to pick the winners and losers, or worse let local governments do so, you'll just get another generation of publically financed mediocre solutions while the truly innovative technologies get shut out by the monopoly arrangements. DS
RE: What do we mean when we say "competition?" (was: Re: [Latest draft of Internet regulation bill])
> --On November 15, 2005 8:14:38 PM -0800 David Schwartz > <[EMAIL PROTECTED]> wrote: > >> --On November 15, 2005 6:28:21 AM -0800 David Barak > >> <[EMAIL PROTECTED]> wrote: > >> OK... Let me try this again... True competition requires > >> that it be PRACTICAL for multiple providers to enter the > >> market, including the creation of new providers to seize > >> opportunities being ignored by the existing ones. > > The worse the existing provider it is, the more practical it is to > > compete with them. If they are providing what people want at a > > reasonable > > price, there is no need for competition. If they are not, then the it > > becomes practical for multiple providers to enter the market. If you > > assume that the cost to develop existing infrastructure is not insanely > > less than the cost to develop new infrastructure, the isolation from > > competition comes directly from the investment. > 1.The existing infrastructure is usually all that is needed for > many of the services in question. Laying parallel copper > as a CLEC is not only prohibitively expensive, in most > areas, it's actually illegal. Usually, municipalities > have granted franchise rights of access to right of > way to particular companies on an exclusive basis. That > makes it pretty hard for a competitor to enter the market > if they can't get wholesale access to the existing copper. For now this may be true. But you'll set up another generation of the same problem if you continue to advocate subsidized infrastructure. At some point that infrastructure will be inadequate, and you will have done nothing to make it easier to build competitive new infrastructure. If munipalities granting monopolies is a problem, then stop such monopolies -- don't advocate them! > 2.The existing copper was actually deployed (at least in most > of the united States) using public subsidies. The taxpayers > actually paid for the network. The physical infrastructure > should be the property of the people. The ownership claim > of the telephone companies is almost as baseless as the > Verisign clame that they own the data in whois. It doesn't much matter and it can't be fixed. The static value of the infrastructure is basically depreciated to zero by now. The profits have been reaped. Don't justify future bad decisions on past inquities that can't be fixed anyway. Just start right from now on. > > For example, if Bill Gates took a few billion dollars out > > of his pocket > > and launched 80 satellites to provide wireless Internet access, it would > > be damn hard to compete with him if he wasn't trying to recover > > those few > > billion dollars. But if you spend a few billion, you get a few billion > > worth. Anyone else can spend the same amount and get the same advantage. > 3.Except when you consider that there are only so many orbital > slots that can be maintained. (see 1 above as well). If Bill > manages to launch N satellites and N leaves N/2 orbital slots > available for other uses, then, it's pretty hard to launch > another N satellites at any cost. The present infrastructure in no way impedes the construction of future infrastructure. If it did, this would be a valid point. At best this just shows that the my analogy is not so good. > > If he already has the satellites and is providing the service other > > people want at a low price, then other competitors will lose. > > But so what? > > Consumers win. And competition doesn't exist to benefit the competitors. > 4.But, what tends to happen instead is that Bill charges whatever > he can get to recoup his billions until someone else launches > their satellites (has expended the capital). Then, when they > start to go after revenue, Bill drops his prices to something > they can't sustain because they don't have his bankroll and > have to recoup their costs. They go out of business and Bill > either buys their satellites, or, they become space-junk. > Bill brings his prices back up to previous levels, and, > consumers lose and the competition loses too. This doesn't work in practice. It only does in theory. There are many, many reasons why. One is that service is often contracted for on a long term. Another is that spot competitors can compete in small areas when prices drop and you can't locally vary your prices forever because it's hard logistically. As soon as the prices go back up, the competitors come back.
RE: What do we mean when we say "competition?" (was: Re: [Latest draft of Internet regulation bill])
> --On November 15, 2005 6:28:21 AM -0800 David Barak > <[EMAIL PROTECTED]> wrote: > OK... Let me try this again... True competition requires > that it be PRACTICAL for multiple providers to enter the > market, including the creation of new providers to seize > opportunities being ignored by the existing ones. The worse the existing provider it is, the more practical it is to compete with them. If they are providing what people want at a reasonable price, there is no need for competition. If they are not, then the it becomes practical for multiple providers to enter the market. If you assume that the cost to develop existing infrastructure is not insanely less than the cost to develop new infrastructure, the isolation from competition comes directly from the investment. For example, if Bill Gates took a few billion dollars out of his pocket and launched 80 satellites to provide wireless Internet access, it would be damn hard to compete with him if he wasn't trying to recover those few billion dollars. But if you spend a few billion, you get a few billion worth. Anyone else can spend the same amount and get the same advantage. If he already has the satellites and is providing the service other people want at a low price, then other competitors will lose. But so what? Consumers win. And competition doesn't exist to benefit the competitors. If he already has the satellites but is not providing the service other people want or isn't charging a reasonable price, or both, then anyone else can make the same infrastructure investment for a comparable cost. If he's not satisfying demand, the demand is still there, and he's just losing some of the benefits his infrastructure could be giving him. > No... Actually, the lack of market forces in the beginning > is what allows the incumbent providers to have an advantage. There is only a lack of market forces if the incumbent is meeting the needs of the consumers. And if they are, there is no need for a competitor. > Nope... What I want is LESS subsidy to incumbents and > a recognition that infrastructure built with public funds > belongs to the public. Said infrastructure should be equally > open to all service providers on equal terms, regardless > of who holds the contract to maintain it. > > Imagine instead of today's scenarios, an environment where > SBC didn't think they OWNed the pipes, but, instead, the > city's owned the copper in the street and contracted with > to maintain said > infrastructure for the city. Then, all RBOCs/ILECs/CLECs > paid the same price to the City through said entity for > the same services, whether dry copper connection, dark > fiber, OC-X, etc. The city would have a term to the contract > and would put it up for rebid periodically. > > That would be market forces at work and not MORE regulation. How would governments owning the infrastructure and setting the rules not be more regulation? And how would designing a system that favors one set of business models and effectively prohibits others that would otherwise be viable not be more regulation? Competition in business models, infrastructure technology, and the like is just as important (if not more so) as competition in price and services within a given model. What happens if the government builds a copper infrastructure and someone else wants to build fiber? How can they compete with the subsidized infrastructure you propose (what else can you mean when you say the "city's owned the copper")? > What we have today is an attempt to reduce regulation without > recognizing the need to correct the damage already done > by regulation. You can't "correct" the damage. It's not possible. All you can do is pick winners and losers *again*. The previous chosen winners and losers don't really exist anymore in their previous form -- all you can do is more damage. DS
RE: What do we mean when we say "competition?"
> >> That is the exact problem with a [mon|du]opoly. The > >> incumbents drive > >> the price so low (because they own the network) that > >> it drives out an > >> potential competition. > > > > So you're complaining that the problem with lack of > > competition is that the prices are too LOW? As a > > consumer, I'm thrilled with low price, and would only > > change providers for a well-defined benefit or a lower > > price. > Low prices of the monopoly is driving out viable competition. Once > competition is gone the prices WILL be raised. I hear this claim a lot, but it's very hard to believe. Surely raising the prices will just bring the competition back. It's basically just a "damned if you do, damned if you don't". If the prices are high, then monopoly is hurting the consumer. If prices are low, then monopoly is hurting the competition. > Competition brings innovation of products and services, not just > lower prices. Right, except this destroys your previous point. If competitors can bring innovation and not just low prices, then low prices shouldn't drive out competitors. The flip side of the "everything is bad" argument is that everything is good. Specifically: 1) Low prices are good for consumers. 2) High prices are good for competitors. 3) Prices don't matter that much to competitors because they can bring innovation, not just better pricing. DS
RE: Time for a real Internet highway (?)
> I wonder what the author would have said if major medical facilities would > have had casualties because of the Level3/Cogentco debacle. Say a surgeon > speaking via VoIP to another doctor about some brain surgery and the > patient flatlines. What about a daytrader about to click on a nice sized > trade... Oops. I think that mission-critical Internet doesn't exist. I have no objection to creating it, but I do have an objection to replacing the best-effort Internet with a mission-critical one. There are legitimate reasons to want a best-effort service at the lowest possible cost. Because there isn't a mission-critical Internet yet, it is a serious mistake to put mission critical services such as the ones you speak of on the Internet. DS
RE: Cogent/Level 3 depeering (philosophical solution)
> [EMAIL PROTECTED] ("David Schwartz") writes:
> > I think the industry simply needs to accept that it's more
> > expensive to receive traffic than to send it.
> It is? For everybody? For always? That's a BIG statement. Can
> you justify?
In those cases where it in fact is and there's nothing you can do about
it,
you need to accept it. You should not expect to be able to shift the burden
of carrying your customers' traffic on your network to others. (The fact
that you can sometimes bully or blackmail and get away with it doesn't
justify it.)
> > ...
> > The question is whether the benefit to each side exceeds their cost.
> Yea, verily. But I don't think you'll find a one-cost-fits-all
> model. When
> one person's costs are lower than another and they're doing
> similar things,
> it's often called "efficiency" or "competitiveness". (Just as
> one example.)
I heartily agree.
My point is simply that the "your customers are getting more out of our
network that our customers are" argument is bull. Your customers are paying
you to carry their traffic over your network.
There can certainly be legitimate peering disputes about where to peer
and
whether there are enough peering points. If someone wants you to peer with
them at just one place, it would certainly be more cost-effective for you to
reach them through a transit provider you meet in multiple places, for
example. (You could definitely refuse settlement-free peering if it actually
increases your costs to reach the peer.)
I am not making the pie-in-the-sky argument that everyone should peer
with
everyone else. I am specifically rejecting the argument that a traffic
direction imbalance is grounds for rejecting settlement-free peering. If
your customers want to receive traffic and receiving is more expensive, then
that's what they're paying you for.
Again, carrying *your* customers' traffic over *your* network is what
*your* customers are paying *you* for. If your customers want more expensive
traffic, you should bear that greater burden.
A traffic direction imbalance is not reasonable grounds for rejecting
SFI.
The direction your customers want their traffic to go is more valuable and
it's okay if it costs more.
DS
RE: Cogent/Level 3 depeering (philosophical solution)
> Various people have stated that uneven data flows (e.g. from > mostly-content networks to mostly-eyeball networks) is a good reason to > not peer. I think the industry simply needs to accept that it's more expensive to receive traffic than to send it. So yes, Cogent sends Level 3 more traffic than Level 3 sends them. But that's because Level 3's customers want to receive a lot of traffic, and it's just a fact about the Internet that it's expensive to receive traffic. Sorry. Bill your customers or design your business model appropriately. If I want to send you a packet and you want to receive that packet, I should expect to pay the costs of sending the packet to you and you should expect to pay the cost of receiving the packet from me. If one costs more than the other, well, that's the breaks. The benefit isn't always equal, why should the costs be? The question is whether the benefit to each side exceeds their cost. Yes, that can't possibly work. It's way too simple and actually makes sense. DS
RE: Cogent/Level 3 depeering
> On Wed, 05 Oct 2005 19:27:24 PDT, David Schwartz said: > > Level 3 cut of Cogent's connectivity. Until and unless they > > give some > > reason that makes sense, they are no longer making the effort > > and are not > > part of the internet. > If I had a garden, things would grow *so* wonderfully next year > if I spread this > stuff on it. > So are you saying that if *your* AS was peered at a dozen places, and you > dropped *one* because it wasn't cost-effective, that you wouldn't > be part of > the Internet, even though you still had 11 peers going full blast? Being part of the Internet is not about communicating with 11 people and not the twelfth. It's about communicating with *anyone* (quite literally) that's willing to make a sufficient effort to communicate with you using the standards and practices that have evolved. > By the same logic, Cogent isn't part of the Internet *EITHER*, > because they're > not bending over backwards to buy transit to get the L3 routes > accessible again. Bending over backwards was never required. As I said in the part you cut off when you replied, nobody has to run a line all the way to the server in my basement that isn't connectected to anything at all. What they do have to do is make a reasonable effort to communicate with anyone who is willing to make a similar effort. When you contract for Internet access, you are contracting to reach everyone who wants to reach you. This "want" is not a mental thing, it's an action of making the effort to connect to people. > For that matter, AS1312 isn't part of the Internet either, because we're > only connected at 2 major points at the moment, and we're not > making much of > an effort to get connectivity to places that for one reason or > another don't > see a routing announcement for us, or we don't see their > announcement. And I'm > sure that with 180K routes, there's gotta be at least a dozen > that we can't > actually talk to... If they make an effort to talk to you, and you do not make a similar effort to talk to them, then you're not part of the Internet. The Internet is the network that has resulted from this philosophy. It is this philosophy that makes it the Internet. > But oddly enough, I *seem* to be on the Internet. What's wrong > with this picture? What's wrong is that you are misrepresenting yourself and your connection philosophy. You are, through your providers and peers making that effort. Buying Internet access from someone who purports to provide it is one way of trying to connect with anyone who tries to connect with you. DS
RE: Cogent/Level 3 depeering
> Without making value judgments or saying what L3 / Cogent _should_ > do, I think Matthew is saying that he paid Cogent for connectivity to > the internet. So if his GNAPS circuit dies, he does not want to be > cut off from L3 end users. Right now, he has no such guarantee. > > Exactly which part of this do you think is nonsense? Or do you think > redundant circuits only need to be partially redundant? The part that defines "internet" implicitly as including any computer he wishes to reach regardless of its actual connectivity or policy. IMO, if a site or provider is not making a genuine effort to exchange traffic with anyone else willing to make a similar effort, it's not part of the internet. Neither Cogent nor Level 3 can force someone who does not wish to accept their traffic into doing so. All they can do is make a reasonable effort to exchange traffic with anyone else who will make such an effort. Level 3 cut of Cogent's connectivity. Until and unless they give some reason that makes sense, they are no longer making the effort and are not part of the internet. The fact that Cogent could make a spectacular effort and get connectivity is not relevant. Cogent could run a 100Mpbs line from their neaest POP to the machine in my garage that isn't connected to anything else and you could reach it. That doesn't mean I get to say my machine is an internet host you can't reach. My views may be colored though. I've heard Cogent's side of the story and nobody seems to know what Level3's side is. DS
RE: OpenTransit (france telecom) depeers cogent
> Is Cogent filtering the prefixes they get from Verio? Or is Verio > filtering what they send to Cogent? Does it matter? > > I think you have a very good point - FT is buying full transit. Cogent > is the one without full reachability. > > Doesn't mean that FT didn't know this would be a problem when they took > the step, though. Cogent has offered to exchange traffic with OT in a manner that is cost-effective for both sides. OT said, "no, do it in a way that is more expensive for both of us". Which one is making a reasonable effort to exchange traffic with anyone else willing to make a similar effort? To me, that is the standard by which connectivity should be judged. DS
RE: sorbs.net
> SORBS -- like _any_ other blocklist -- is simply an expression of opinion. > if you feel that "somebody" is 'wrongly' blocking mail because of a SORBS > listing, your _first_ step should be to contact *that* party, and request > that either (a) they stop using SORBS, or (b) that they 'whitelist' you. > *THEY* are the ones that made the decision to block your mail to their > system. Come on, that's just nonsense. If the New York Times publishes a front page article about how you're an idiot, should you contact each individual person who reads the article and try to convince them you're not? Or should you try to convince the New York Times that they're incorrect and should publish a correction? DS
RE: US slaps fine on company blocking VoIP
> I don't speak for BroadVoice, but this seams to be to be stupid. Why > should the government get involved in ISPs blocking ports? If customers > don't like it, go to a new provider, what country is this?? I'm curious how you'd feel if your local telephone company started preventing you from calling its competitors. How about if you suddenly discover your car won't drive you to a competitor's dealership due to a lockout included by the manufacturer (that you neither knew about nor agreed to when you bought it). It is only in the Internet business and the software business that a company can sell you a product with no representations that it will actually do anything and with you having essentially no recourse if it doesn't meet your expectations. If I pay for Internet access, I expect to get it. And if you're not actually providing Internet access, don't clima to. The Internet is not ports, it's not machines, it's not protocols. We could change all that and it could still be the Internet. The Internet is a philosophy, and the results of that philosophy. It's about making a good faith best effort to connect to and exchange information with anyone else who makes a similar effort. Let's not lose sight of the big picture. I sympathize with the "if you don't like it go elsewhere" view, but I also believe that people should provide the service they agreed to be provide, and when they fail to do so without justification, they should be penalized for their fraud. DS
RE: Heads up: Long AS-sets announced in the next few days
> >>So, given these considerations, is everyone announcing an AS-set > >>announcing "routes that falsely claim to have passed through another > >>autonymous system"? > > > > Yes. From RFC1771: > Ok, so if everyone announcing an AS-set is announcing "routes that > falsely claim to have passed through another autonymous system", and you > are saying this shouldn't be done, then why aren't you complaining with > everyone who is announcing an AS-set? I never said that this shouldn't be done. I said it shouldn't be done without the consent of the owners of the ASes you wish to include. In addition, the things I don't complain about don't constitute a defense to the things I do complain about. > > [Quote of section 5.1.2 almost in its entirety] > > > > So you are violating RFC1771, plain and simple. To then go > > and cite one > > small section of RFC1771 in your defense is hypocritical. > > You quote Section 5.1.2, but you don't mention that if you follow > Section 5.1.2 to the letter there is no way that an AS-path may contain > an AS-set. To summarize the whole of section 5.1.2, the various cases are: > > Propagating a route learned from an UPDATE message: > > a) To another router in same AS: don't modify AS-path > b) To a neighboring AS: > 1. Path starts with AS_SEQUENCE: prepend own ASn > 2. Path starts with AS_SET: prepend new AS_SEQUENCE with own AS in it > > Originating a route: > >a) To neighboring AS: announce own ASn as only element in path >b) To another router in same AS: announce empty AS-path > > If you follow this to the letter, you must rule out both prepending "(In > this case, the AS number of the originating speaker's autonomous system > will be the only entry in the AS_PATH attribute)" and any form of > AS-set, since there is no way, following these rules, that an AS-set may > enter the AS-path in the first place. Section 9.2.4.2 documents how an AS-set can enter the AS-path as part of aggregating routes. As far as I can tell, the use of AS-sets is permitted only to aggregate routes. > If we are violating this section, then everyone else announcing an > AS-set, and - at least the way I read it - anyone doing prepending, is > doing so too. But nobody is suggesting that these things > shouldn't be done. Lovely straw man. I complained about the lack of *consent* and you talk about people prepending their *own* AS numbers? Are you suggesting they lack their own consent?! DS
RE: Heads up: Long AS-sets announced in the next few days
> The RFC also says: > > > An AS_SET implies that the destinations listed in the NLRI can be > > reached through paths that traverse at least some of the > > constituent autonomous systems. > > which is exactly what we are doing. Yes, you can cite sections of the RFC that you don't violate. That doesn't change a single thing about the sections you *do* violate. Nobody is arguing that you violate every single paragraph of the RFC. DS
RE: Heads up: Long AS-sets announced in the next few days
> David Schwartz wrote:
> >>Prepending announcements with remote AS numbers has been a well-known
> >>technique for preventing prefixes from propagating to particular ASes
> >>for a long time.
> > And therefore such use would not be considered
> > experimental. We are talking
> > about experimenting with routes that falsely claim to have
> > passed through
> > another autonymous system.
> They are experimental in that yes, we are experimenting with a new
> technique for topology discovery which to our knowledge has not been
> proposed before.
So you do not know what affect your announcements will have.
> As regards "falsely claim to have passed through an autonomous system",
> that is not accurate:
I stand by it.
> 1. RFC 1771, paragraph 5.1.6 says that in the presence of an
> ATOMIC_AGGREGATE attribute, "the actual path to destinations, [...] may
> traverse ASs that are not listed in the AS_PATH attribute." So an
> AS-path does not claim to contain all the ASes that the announcement has
> passed through.
I never said anything about what the absence of an AS entry means, I
only
talked about what the presence of an AS entry meant.
> 2. Given an AS-set such as {1,2}, if you concluded that the announcement
> had passed through both AS1 and AS2, you would be wrong (most of the
> time, at least). So an AS-path does not claim that all the ASes in the
> path are ASes that the announcement has passed through.
The issue is not what conclusions I draw from an AS-set but what the
rules
are for including an AS in an AS-set.
> So, given these considerations, is everyone announcing an AS-set
> announcing "routes that falsely claim to have passed through another
> autonymous system"?
Yes. From RFC1771:
1 AS_SET: unordered set of ASs a route in the
UPDATE message has traversed
...
AS_PATH is a well-known mandatory attribute. This attribute
identifies the autonomous systems through which routing information
carried in this UPDATE message has passed. The components of this
list can be AS_SETs or AS_SEQUENCEs.
...
In fact, RFC1771 goes on to specifically state under what conditions an
AS
can be added to the set:
b) When a given BGP speaker advertises the route to a BGP speaker
located in a neighboring autonomous system, then the advertising
speaker shall update the AS_PATH attribute as follows:
1) if the first path segment of the AS_PATH is of type
AS_SEQUENCE, the local system shall prepend its own AS number
as the last element of the sequence (put it in the leftmost
position).
2) if the first path segment of the AS_PATH is of type AS_SET,
the local system shall prepend a new path segment of type
AS_SEQUENCE to the AS_PATH, including its own AS number in that
segment.
When a BGP speaker originates a route then:
a) the originating speaker shall include its own AS number in
the AS_PATH attribute of all UPDATE messages sent to BGP
speakers located in neighboring autonomous systems. (In this
case, the AS number of the originating speaker's autonomous
system will be the only entry in the AS_PATH attribute).
b) the originating speaker shall include an empty AS_PATH
attribute in all UPDATE messages sent to BGP speakers located
in its own autonomous system. (An empty AS_PATH attribute is
one whose length field contains the value zero).
So you are violating RFC1771, plain and simple. To then go and cite one
small section of RFC1771 in your defense is hypocritical.
> > Every piece of BGP documentation I have ever seen says that
> > this attribute
> > documents the ASes that the route has actually passed through.
> I think the above paragraph of RFC 1771 disagrees with you.
Since you obviously feel totally free to violate RFC 1771, the one
paragraph that vaguely supports what you're doing really doesn't help you.
Especially since it says nothing about the *presence* of an AS set.
DS
RE: Heads up: Long AS-sets announced in the next few days
> On 2 Mar 2005, at 22:30, David Schwartz wrote: > > > Please just clarify the following point: do you intend to advertise > > paths > > containing AS numbers belonging to other entities on the public > > Internet > > without the permission of the owners of those AS numbers? You admit > > that you > > don't know what the consequences of this injection will be. > Prepending announcements with remote AS numbers has been a well-known > technique for preventing prefixes from propagating to particular ASes > for a long time. And therefore such use would not be considered experimental. We are talking about experimenting with routes that falsely claim to have passed through another autonymous system. > The AS_PATH attribute is a loop detection mechanism, and a determinant > in path selection. What other magic is there in it that requires such > careful consideration? Why should anybody need to get permission from > remote operators before deciding what attributes to include in their > own advertisements? Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through. > Do I need to get permission from Sprint before I include 1239:100 as a > community-string attribute on my own advertisement, too? You certainly need their permission before you can advertise routes that falsely came to have passed through their network! And yes, I would argue that you do need permission to attach someone else's community string to your routes and that it would be considered at least terribly bad manners to use undocumented community strings from other people's ASes. (Documentation, of course, equates to permission.) > > It seems to me that there are enough issues with this type of > > experimentation *with* the permission of the AS numbers you plan to > > use. But > > the ethical issues with using them without such permission seems to me > > to be > > insurmountable. > The ethical issues seem to be non-existent, to my way of thinking, and > hence trivial to surmount :-) I'm curious where you would draw the line then. And I'm curious what you think is the point of registering AS numbers at all, if it's okay to use other people's without their permission. DS
RE: Heads up: Long AS-sets announced in the next few days
> Ok, I realize I might have given the wrong impression here. Sorry. > > So here's what we are doing: by artificially inserting ASes into the > AS-set of an announcement, the ISP that makes the announcement can > control where the announcement is propagated and thus discover paths > followed by its announcements that are not usually visible, giving it a > more complete knowledge of network topology in the vicinity. Please just clarify the following point: do you intend to advertise paths containing AS numbers belonging to other entities on the public Internet without the permission of the owners of those AS numbers? You admit that you don't know what the consequences of this injection will be. It seems to me that there are enough issues with this type of experimentation *with* the permission of the AS numbers you plan to use. But the ethical issues with using them without such permission seems to me to be insurmountable. DS
RE: Standard of Promptness
> Bill, I'm not speaking for Bill. These are my views. >You indicate "a" known former state, which implies that you'd allow >reverting back multiple changes under your proposed scheme... You would have to. Otherwise, two quick transfers would defeat the scheme. An alternative approach would be to prohibit a transfer within one week of another transfer. >Out of curiosity, how far back would you allow one to revert to? >Any previous state within the last two weeks? Longer, or shorter? I would say two weeks would be a reasonable maximum. One week would be a reasonable minimum. One could also do it in terms of business days, but I think this may cause confusion with international issues and which days count as business days. >Given the potential for disruption through fraudulent demands >to revert, one has to carry over previous servers for at least this >interval to be safe, or do I misunderstand your proposal? This would mean that a transfer would not really be final for some number of days after the transfer was initiated. This would, of course, create a new problem with fraudulent reverts. A no questions asked revert policy would create one class of problems, whereas a requirement for proof for reversion would create another class. I personally think the best solution is as follows: 1) A domain cannot be transferred within one week of a previous transfer. 2) Once a domain that was in normal status has been transferred, it can be reverted by request of the losing registrar for one week from the time of the transfer, no questions asked, as soon as possible. (Should Verisign do this? Or the losing registrar through an automated interface?) 3) If the gaining registrar questions the reversion, the losing registrar must then provide proof of request for reversion from the previous owner and the gaining registrar can provide proof of release from the previous owner. Some method to resolve this dispute would be needed. Perhaps arbitration at the initial expense of the gaining registrar (who could, of course, bill their customer however they choose). The arbitrator could award costs to the winner of the dispute (in case of total bogus reversion requests). This would allow people to protect valuable domains by picking registrars with sensibe reversion policies. It would also prevent dishonest registrars from holding domains through reversion without authorization, though they could impose costs on the gaining registrar if they wished). The downside would be that when you acquired a new or newly-transferred domain, you would want to wait a week before using it for anything mission critical. You also couldn't consider the act of transferring a domain proof positive of intent to give it to you. You might want to wait a week before, for example, making payment. Or you would want to possess proof of the owner's intent to transfer, not just proof of a transfer. David Schwartz <[EMAIL PROTECTED]>
RE: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU
> > ah i was meaning tcp, afaik it sets DF on at least win2k > All OSes that I know of do this in order to do path MTU discovery. The > PMTUD RFC encourages implementers to detect changes in the path MTU as > fast as possible, which they took to mean "set the DF bit on ALL > packets". Which is unfortunate, because in cases where PMTUD doesn't > work, no communication is possible. Setting the DF bit on 50, 10, or 2 > % would accomplish PMTUD fine too, but it would also allow the session > to survive brokennes. This is a bad idea. This would cause the case where every single packet is fragmented to be indistinguishable from slight packet loss. > > do any of those tiny resourced internet bootstrapping hosts exist? > > perhaps we > > can deprecate DF?! > I've said I'd like to see this happen in the past. The trouble is > without DF, current PMTUD doesn't work anymore, and router CPUs will be > spending unnecessary CPU cycles on fragmentation. So some of the > packets should trigger an ICMP too big, but others should just be > fragmented. Figuring out the right mix probably requires some > experimentation. Fragmenting packets that have the DF bit set is just wrong. The problem should be fixed at the end hosts. Smart detection for MTU blackholes is needed at the hosts, and this is best done by sending large packets as early as possible, establishing that you have an MTU blackhole, and analyzing all cases of packet loss for those that look like they're created by an MTU blackhole. DS
FW: Smallest Transit MTU
Last post on this, I hope. > > The argument I am taking issue with is whether or not it's > > a mistake for a > > firewall or end system to drop packets with reserved bits set > > -- bits that > > by RFC/BCP MUST be zero on transmission. > Now I know you've not yet read BCP 60. :-) > > John Sure, it's easy to make the right decision once you know how the bits are going to be used. BCP 60 is based upon information that was not available at the time the decision was made. I am defending the decision to configure firewalls (before ECN was deployed) to drop packets that had this bit set, assuming you had the requisite cluefulness to maintain such a decision. The view I am opposing is that this decision was unreasonable to make at the time it was made. To say, "you should have anticipated ECN and BCP 60" is not only unreasonable but gets the simple reply, "well, then you change the configuration". Firewall configurations almost always have to be changed when new protocols or features are deployed. >> > I see. Can you suggest a firewall that supports "block all >> >traffic not >> > unencrypted and in American English"? >> >> You misunderstand what I mean by "whose meaning is not known". >> Deliberately, I suspect. >He *does* have a point - the fact that the firewall knows about the new >feature doesn't mean that the target host behind the firewall is able to >do something reasonable/correct with the new feature Precisely. That's why you can't make the decision without knowing what you're talking about. For firewalls, one generally errs on the side of security and accepts that changes may result in inconvenience until configurations can be maintained. >And where, exactly, do you draw the line between "firewall that blocks >unknown bits" and "virus-scanning front-end appliance that blocks unknown >MIME types" and "Great Firewall" that blocks all traffic that contains >subversive content. Wherever you need to, based upon available technology, needs, and cluefulness. I am not saying the decision doesn't need to be made, I'm defending a slightly different balance on the assumption of only slight cluefullness. A cluelessly maintained firewall is never a good thing. I'm kind of surprised this went on as long as it did. All I'm saying is that, when possible and there's sufficient clue to maintain it, firewalls should be configured to block everything unknown, to the extent possible. This includes packets with bits set in the header whose meaning is unknown and which are mandated to be cleared by existing RFCs. This imposes the slight burden that the firewall configuration has to be updated when new protocols or features are deployed -- but this is (or at least should be) always the case with firewalls. Nobody's saying this is acceptable for transit networks. Just firewalls and end hosts. DS
RE: Smallest Transit MTU
> David Schwartz: > > IMO, it's negligent to configure a firewall to pass > > traffic whose meaning is not known. > I see. Can you suggest a firewall that supports "block all traffic not > unencrypted and in American English"? You misunderstand what I mean by "whose meaning is not known". Deliberately, I suspect. DS
RE: Smallest Transit MTU
> On Thu, 30 Dec 2004 17:42:44 -0800 > "David Schwartz" <[EMAIL PROTECTED]> wrote: > I think you may be fearful that the use of reserved bits introduces > a new security risk, because of something a system may do in response > to the use of those new fields. That is a very legitimate concern > and a very real potential risk. I guess in my view of the world, in > practical terms, we're not likely to see an experimental protocol > start getting widely deployed and then suddenly discover that we have > a major security threat on our hands that we cannot easily fix before > it brings the net to a complete halt. At least not since the > publication of RFC 793. :-) The point is one of when you make the decision to allow the new protocol. Your opinion is, though I'm sure you wouldn't put it this way, before you even know anything about it. My opinion is that it should be made when you have enough information to know whether you want to allow it or not. We might be able to agree that those who need the additional level of security of blocking unknown, reserved bits should also be able to supply the additional level of cluefulness to maintain that configuration. And I might be willing to admit that commodity firewalls should not assume operational cluefulness by default. > I think the concept of reserved fields is a relatively well accepted > practice in computing by now. Security is important, but we cannot > allow security concerns to completely halt progress. It just may be > in the interest of security to allow this kind of experimentation to > occur. Sure, as a considered decision made on a case by case basis, at least for those clueful enough to make such a decision and concerned enough to attempt to do so. > > IMO, it's negligent to configure a firewall to pass traffic > > whose meaning is not known. > That means no end host to end host encryption that the network > firewall cannot understand. This might be allowed on a case-by-case basis. But it definitely should not be allowed by default except for specific cases where it's decided that the benefits outweigh the risks. > ...and for anyone else who likes to block unknown bits, then don't > let me see or hear you complain about how the net sucks, because you > are not letting it evolve so that it can be fixed. :-) Of course you have no right to complain if traffic you chose to block causes you to be unable to interoperate. And you do have a right to complain if your vendor's default firewall configuration forces you to have a higher level of cluefulness than a more sensible default configuration might have required. The insoluble (I fear) problem is simply that people don't maintain their filters. And auto-updating your filters on someone else's say so isn't a reasonable solution. People often won't update if they don't personally see the problem, and you don't usually see the traffic you don't get and don't understand. DS
RE: Smallest Transit MTU
> It's not just that ECN isn't supported that is the problem, it's when > systems by default reject packets with reserved bits set. While you > may pan ECN, it or something else that might enhance Internet protocols > like it in the future should typically be silently ignored by end hosts > that don't understand them so those experiments can at least take place. > > John I, for one, do not agree. End hosts and firewalls *should* reject all traffic they don't understand. It's precisely to prevent our unintentional participation (as end hosts) in such 'experiments' that we deploy such filters. The problem is when the policies are not maintained (or are deployed in inappropriate places like transit networks), not that they exist in the first place. IMO, it's negligent to configure a firewall to pass traffic whose meaning is not known. Of course, it's also negligent to leave a firewall configured to block traffic whose meaning is known and is known to be desirable and harmless. DS
RE: who gets a /32 [Re: IPV6 renumbering painless?]
> what the world is short of is routing table > slots, each of > which adds universal cost to the internet for the sole benefit of > the owner > of the network thus made reachable. I see this point made often, and I've never understood it. If carrying a route only benefits the party that issued the route, why do it? It seems to me that being able to reach someone is of as much value to you as it is to them. I wonder why IBM, Apple, Cisco, and Ford don't connect their corporate web servers to routers that don't contains any of these expensive routes that are only for the benefits of the entities that announce them. Perhaps you should explain to them all the money they could save. Better connectivity on either end benefits both ends of the connection. DS
RE: I want my own IPs
> 2) 2 of your providers have violated the rules by automatically handing > you a /24 with your leased lines as this is space you don't need and have > no immediate intention of renumbering into. > So, somehow its better that you announce 3 PA /24's into the global table > instead of the 1 PI /24 you can't get. Hmmm You know who to blame when sub-optimal results occur when people break the rules -- the people who broke the rules. DS
RE: Important IPv6 Policy Issue -- Your Input Requested
> Just out of interest, why do you think 1918-style space for v6 is > needed? If we could assign every entity who wanted one sufficient non-routable, globally unique space, we wouldn't need 1918-style space. There are, however, three problems with this approach: 1) It encourages massive waste. Perhaps so massive that we would run out of space. 2) There is a cost associated with assigning globally-unique space no matter how you do it. This cost could be too high for some application -- RFC-1918-style space is free. 3) There is a concern that some recipients of this globally-unique unroutable space might use political pressure to get that space routed. This could potentially lead to an explosion of the number of routes in the global table. However, there are huge advantages. Private networks could seamlessly overlay the Internet and each other where desired with no risk of a future merger causing a numbering conflict. I think the first and second problems are solvable. The third problem, however, may be the deal killer. It's a very realistic concern that the technologies we develop and promote can be designed to make things we consider bad easier or harder to do. Technologies can encourage cooperative interoperability or free riding, privacy or interceptability, and so on. DS
RE: FW: House Toughens Spyware Penalties
> "The bill also permits computer software providers to > interact with a user's computer without notice and > consent in order to determine whether the computer > user is authorized to use the software upon > initialization of the software or an update of the > software." > > I find this aspect of the Bill objectionable, since it > contradicts other laws, which make it illegal to break > into a computer. There is also no guarantee that > the person doing the snooping is above criminal intent > and would create an operational nightmare for > most prudent ISP/NSP organizations. It's really a trivial issue, because even without this provision, the license could just say (and most do), that the software will validate your authorization to use it. Without this provision, one could argue that using a hidden (location undisclosed) key in the registry to keep track of a trial start date violates the letter of the law. After all, you are storing something on someone else's computer and you don't tell them what it is or where it is. DS
RE: House Toughens Spyware Penalties
The general consensus seems to be that companies that choose to obey the law will simply disclose everything their software does in many, many paragraphs of legal language that few people will actually read. This will allow them to claim they have consent for whatever it is that they do. On the bright side, it will at least be possible for those who are sufficiently curious and diligent to determine what the software is doing by picking through the legal language. I've heard that Gator's license is 20% longer than the constitution. DS
RE: Senator Diane Feinstein Wants to know about the Benefits of P2P
> So I would like some professional expert opinion to > give her on this issue since it will effect the > copyright inducement bill. Real benefits for > production and professional usage of this technology. We have no idea what the benefits of P2P are going to be or what the technology is ultimately going to look like. It will be at least a decade before anyone has a clue and maybe much longer. And, btw, IMO the MD5 collision is sufficient to judge MD5 unsuitable for checking file authenticity in a P2P application. A denial of service attack could, potentially, be launched by anyone who could create a block with the same MD5 checksum as any block in the application. To do this, they need only create a collision for the first chunk of that block, which now seems doable. (Yes, I know the difference between producing a collision and producing a collision for a given block. It's just that this difference is all that's left.) MD5 is still perfectly suitable for any number of applications where the ability for a hacker to produce a collision to a given block is not sufficient to destroy the security of the scheme. DS
RE: Blocked port 25?
> In the last couple of days, I have received complaints from customers > not able to receive email from certain sites. If I understand you correctly, you are saying that these sites are not able to send mail to you. Assuming that they are diverse sites that don't have significant similarities, this suggests that the problem is on your end. > From these sites, I > can't connect to our mail server, on other sites, I can. I don't understand what this is supposed to mean. It's their mail servers that are supposed to try to connect to your mail server. > We have tried > sending email, and we have also tried telnet on port 25 to the server. > I can't seem to find a correlation. There is no firewall on our > network. We have an access list to filter port 25, but this server is > allowed. Our mail server is also our DNS server. From the sites that > I can't connect to our server on port 25, I can query the DNS server > using nslookup and get a response. This doesn't tell you anything about why their mailservers might not be able to reach your mailserver. > I tried tcptraceroute from one of the sites where I have a unix > account, but it is behind a firewall, and it dies after the first hop. > I'm stumped. Any suggestions. You really haven't given a clear description of the problem. When you say customers can't receive email from certain sites, I'm assuming this means people at those sites send email to your customers and the email does not appear in your customers inboxes. From this, I would conclude that their mailservers are not able to (or willing to) send the email to your mailserver. When you say you can't connect to your server on port 25, where exactly are you trying from? Did you try emailing (or calling) the administrators of those sites? If you use SPF, are your records valid? Do the senders get any bounces? Your statement of the problem is lack of specifics. We can't check your SPF records. We can't check if those domains have a common provider. So all we can do is tell you to troubleshoot. DS
RE: Spyware becomes increasingly malicious
> On 7/12/04 12:33 PM, "Michel Py" > <[EMAIL PROTECTED]> wrote: > Some peering contracts specify that behaviors that endanger a > network or its > users allow for immediate disconnection. Its a bit of a stretch to invoke > this for a spyware site. I think you could find a few experts that could argue that malware in general, and CWS in specific, has no reached the point where it is entirely reasonable to classify it as endangering the users of the network. Anyone who has dealt with a variant of CWS for which a remover was not available will tell you how much trouble it causes, rendering systems unusable until you find the magic combination, reimage the system, or wait until someone else figures out the variant. One wrong turn probing it can render a machine unusable until it's reloaded. In the meantime, let's at least blackhole all their IPs on our networks. One way to reduce malware is to reduce the benefits of creating and distributing it. Another way is to find the people benefiting and stringing them up in the town square. DS
RE: ARIN Comment
> On Jul 1, 2004, at 4:15 PM, William Allen Simpson wrote: > > I was also concerned, until I read the actual pleadings. > > > > Although nobody's ever allowed us (AS19933) more than 1 month to > > renumber, and we've always had to pay both providers during the time, > > so we've always kept it as short as possible anyway > But now you can get PI space and take well over a year to renumber into > it without fear of ARIN asking for it back. This is an example of a gross generalization, assuming that what held true in one case will be true in every case. First of all, we hav eno idea whether ARIN will ask for it back or not. This case had nothing to do with ARIN. This case was a dispute between a service provider and their customer and had nothing at all to do with the enforcement of ARIN policies. > NAC may not have posted the whole proceeding at first, but Alex was > very clear he wanted commentary only on the allocation policies. Some > of us (me included) took it a bit farther. Now it is clear from ARIN - > who is supposedly in charge of this stuff in "America" - that nothing > is wrong with taking months after your contract expires to number out > of PA space, and over a year to renumber into PI space once it is > granted. So I guess commentary is no longer needed (except maybe at > ARIN meetings?). Huh? ARIN offered no opinion that I saw on whether the renumbering was acceptable or not. ARIN is not a party to this dispute and only looked into it because of the fear that this might be a case where a judge tried to convert NP space into portable space. Since it seems rather clear that this is *not* what is happening in this case, ARIN decided nothing needed to be done. Look, Alex only wanted commentary on the allocation policies, but ARIN commented on the facts of this specific case. Now you're acting as if ARIN commented only on the allocation policies. This is just not the case. ARIN responded to the precise facts of this specific issue and did not state any general principle. They don't have to -- the general principles are in their policies. > The first is somewhat customary but by no means universally practiced. > Now it seems to be officially sanctioned. I was under the obviously > incorrect impression the latter was against ARIN policy. Again, ARIN commented only on this specific case and concluded that the TRO did not relate to a violation of ARIN policy. In fact, the TRO has nothing to do with the fact that the customer has PI space and hasn't renumbered into it. It has to do with the use of the NP space, and to my knowledge, the way NP space is being used in the case is not at all out of the ordinary. > Glad we have official clarification. We have official clarification only about how ARIN feels about how the NP space is being used in this particular case. DS
RE: (UPDATE) Can a Customer take their IP's with them? (Court says yes!)
> What I AM looking for is a commentary from the internet community, > strictly relating to the fact that a judge has issued a TRO that forces an > ISP (NAC) to allow a third-party, who WILL NOT be a Customer of NAC, to be > able to use IP Space allocated to NAC. In other words, I am asking people > to if they agree with my position, lawsuit or not, that non-portable IP's > should not be portable between parties, especially by a state superior > court ordered TRO. It is at least my opinion that this is a ludicrous argument. While this would certainly cause problems if everyone did it and it isn't the norm, it's ridiculous to argue that there could never exist a situation where this might not be the best temporary solution to a legitimate dispute between parties. Consider, for example, if I'm a large customer single-homed to one ISP. They go out of business and can't continue to provide me with service with four hours notice. They want to return their block to ARIN immediately and force me to renumber in a day. So you're saying it's unreasonable for a court to order them to delay the sale for 30 days and allow me to continue using those IPs through another provider? Why?! You can't argue this in the total abstract without the context of the actual dispute between the parties and the actual effects of allowing or not allowing this on each party. If you think the judge is out of his mind, then bluntly, you are out of yours. Yes, it would be bad if everyone did this. But if we really believe that IP addresse are non-portable for purely technical reasons and not as a weapon to use against customers, then we should be very agreeable to cases where a customer wants a reasonable time to continue using the IPs. IMO, 99.9% of the time, they should also be continuing to get service from the provider, but it would be really silly to say there could never exist an exception. DS
RE: Can a customer take IP's with them?
> > It's worth pointing out, however, that if case 2 applies and case 1 > > doesn't, then the ISP will still be providing a level of actual packet > > carrying service to the customer. > bt. if the ISPs have sensible policy implementations at the border, > nobody will be be providing free transit because of accidents of > adjacency. I wasn't talking about accidents. The draft TRO could easily be read as requiring them to hear the announcement and carry the traffic. "NAC shall permit CUSTOMER to continue utilization through any carrier or carriers of CUSTOMER's choice of any IP addresses that were utilized by, through or on behalf of CUSTOMER under the current agreement during the term thereof (the "Prior CUSTOMER Addresses") and shall not interfere in any way with the use of the Prior CUSTOMER Addresses," "(iii) by directly or indirectly causing reduced prioritization of access to and/or from the Prior CUSTOMER Addresses." It's a good point though that this requires you to effectively continue to provide the customer with service. DS
RE: Can a customer take IP's with them?
> a TRO against nacs.net has no effect on the behavior of providers > such as verio who won't honor the advertisement of the subnet > in BGP. the customer would have to, one-by-one i think, go after > everybody with the relatively common policy of ignoring such > advertisements (isn't sprint one of these? that'd be a pretty big > hunk of internet to be disconnected from. sprint having no > contractual relationship with the idiot, er, customer in question, > it'd be hard for the customer to get anywhere there.) > > in other words, by itself the requested TRO incompletely solves > the problem, making it fairly pointless. We don't know enough about the specifics to know if this argument works or not. There are two obvious cases where it doesn't: 1) The block in question is large enough (or located in legacy space) such that most/all providers will listen to it anyway. 2) The customer's new provider meets with their old provider directly and the new block is inside a larger block the original provider will continue to advertise. (This is a very common case if both providers are large.) It's worth pointing out, however, that if case 2 applies and case 1 doesn't, then the ISP will still be providing a level of actual packet carrying service to the customer. It is grossly unfair to expect a provider to do this for free, assuming they didn't do something equally unfair to the customer. Which is why it will really come down to the merits of the actual dispute between the customer and the ISP. The TRO is an interesting sideshow, but really in the scheme of things not a particulary big deal. Remember, to get a TRO you must show that you (likely) deserve it equitably, otherwise the hardship issue doesn't come into play. It is, however, a good warning for ISPs. Make sure your contracts with your customers stipulate that IP assignments are to follow ARIN's published policies and that they may be revoked by you or ARIN for non-compliance with standard practices. Also clearly state what your renumbering policies and advertisement by other provider policies are. What's obvious to you may not be obvious to your customers and you can't expect to be assured of being able to enforce your contracts with ARIN on your customers. DS
RE: Can a customer take IP's with them?
> additionally, how is the ISP to account to ARIN for this block should > they go back for more space? They show ARIN a copy of the TRO. Really. > there is a widely accepted understanding of how this is all supposed > to work, and if the ex-NAC customer succeeds in gaining this TRO, > and it becomes a pattern across the industry, then everybody's > connectivity, router tables, and support budget will likely suffer. Unfortunately, courts are generally not impressed by the "if everybody did it" argument. In each case, they'll look at the actual incrementlay harm the TRO will do in that particular case. I do agree, however, that it's very important that if these cases do come to court, the ISPs win as many of them as possible. Each loss makes the next loss easier. The reason I'm pointing out which strategies are unlikely to work is not because I hope they won't work but because I want him to make sure to emphasize the strongest possible arguments. IMO, these are: 1) The emergency is of the customer's own creation. He had plenty of time to renumber and didn't. 2) There is no significant harm in renumbering immediately. Techniques such as 1-to-1 NAT exist for exactly this purpose. 3) DNS creates a portable namespace, so there's no legitimate portability issue here. This is not like bringing your phone number with you when you change providers but like bringing your phone *line* with you when you move across the country. I would not try to argue that it harms you significantly to allow them to continue using the IP space. I just don't see any honest way to show that there's real harm. Perhaps in your specific situation there's such a way. But defending abstract principles about router table sizes isn't likely to work. The court will weigh the harm of the one advertisement. Don't forget, though, the customer can't get the TRO, regardless of the balance of the hardships, unless they're likely to be entitled to it. So look into the details of how the contract got terminated, and if it's because of the customer's own actions, they're not likely to be entitled to the relief the TRO seeks to get anyway. DS
RE: Can a customer take IP's with them?
> Not directed at anyone specifically, but has anyone noticed that on > these lists, people tend to focus on whether or not people's analogies > are correct, rather than trying to answer the original question? So long as you continue to focus on the analogy as it relates to the original question, rather than picking at aspects of the analogy that have nothing to do with the original question, you're fine. Unfortunately, it's very common to attack the analogy rather than show why the analogy doesn't apply. In cases where we're dealing with things that have not been dealt with before, analogy is a powerful tool of persusasion. I'm sure arguments like "IP addresses are just like telephone numbers" has been used and will continue to be used to argue that IP addresses must be portable to preserve competition. In this case, it's perfectly reasonable to argue that they're not alike because they are routed in very different ways but totally unreasonable to argue that they are not alike because they differ in length. Analogy is formalized in law in the form of precedent. Lawyers will argue that their case is exactly like some other case that was ruled in favor of the litigant they analogize their client to. It's critical to be able to distinguish your case from apparently similar cases when the ruling in the apparently similar case isn't the one you want. This particular case isn't about ownership at all. It's about whether or not the ISP can or cannot continue to allow the customer to use those IP addresses. It's about what hardship will be placed on the customer if they are not allowed to continue to use them against what hardship will be placed on the ISP if they do. To get a TRO, you need to show two things. One is that the balance of the hardships favors you. That is, that you will be more seriously hurt if you don't get the TRO than the other side will be if you do. Unfortunately, it will be hard to argue that in this case. It really doesn't hurt the ISP too much if they allow their customer to continue using the IPs for, say, 6 months. At least, unless there's something very unusual about this case that we don't know. Courts are not impressed usually with theoretical harm. The ARIN arguments are just that. Theoretically, if everyone ported their IP space, we'd all be harmed. However, there is no real harm in compelling the ISP to continue to allow their customer to advertise the IP space for a few months. The customer will argue that forcing them to renumber in less time will cause them real harm. (This may or may not be true and a court may or may not find the argument impressive. I'm just saying that trying to argue theoretical harm due to principles will likely not work.) The court will likely look at the harm imposed on the ISP for this one block. However, you also must always show that it is more likely that you will prevail in your main claim than that you will not. No matter how much the balance of hardships tips in your favor, you will not get a TRO if you cannot show the court that you are quite likely to be found entitled to the relief the TRO asks for if there were a full trial to determine such. We don't know anything about the actual issues in dispute in this case, so we can only speculate on this. I think courts will in general follow the contract between the ISP and the customer. If the contract doesn't say, industry practice is (at least IMO and experience) to allow the customer a reasonable period to renumber (3 months? 6 months?) unless the customer terminated the contract for no reason at all. (If the ISP raised the price, then the renumbering period would likely apply. If the customer just decided to end the contract when the ISP would extend it at the same price, then no renumbering period applies since the customer can continue to buy service through the renumbering period at terms they already found reasonable.) Harder cases include when the ISP terminates the customer for cause or when external situations change the ability of the customer to continue to use the ISP's services. IANAL. It certainly wouldn't hurt to clearly state your expectations in this regard in your contracts though. Don't rely on your contracts and policies with ARIN to be enforceable against third parties. DS
RE: Can a customer take IP's with them?
> Is this analogy really accurate? In your analogy, the person who > initially purchases the shrimp actually *owns* the shrimp at that point. > With IP address space, the ISP does not own the space that it allocates. > It's really just sub-letting the space already allocated to it. Doesn't matter. This issue has nothing to do with ownership. It just has to do with the ISP continuing to allow their customer to use the IPs. The ISP certainly has the ability and authority to do that. > IANAL, but it appears that from a contractual perspective it is clear > that ARIN retains all 'ownership' rights to the address space. They > subdivide it to those who are willing to contractually agree to their > conditions, but the ownership is never transferred. I would think that > that is an important distinction to make. Why? Nobody cares who owns the IPs, just whether or not the ISP allows the customer to continue using them, which the ISP certainly has the ability to do. DS
RE: Can a customer take IP's with them?
> If you ran a museum, and you contracted for the use and display of an > artifact, and then somehow entered into a contract to sell somebody else > that artifact (even though you had no property rights), the original > contract supercedes the second contract. Additionally, because there is no > alternate source for the item in question (being an artifact and all), the > museum can't be forced to acquire the same item (potentially at a loss) to > complete the second contract; they would just have to return the money. Your analogy is valid, it just doesn't show what you think it shows. A court could certainly order the museum to provide the buyer the artifact to the extent that they were able to do so. That's all the TRO is asking for. The TRO doesn't say anything about property rights, it just asks to prevent the ISP from interfering in their use of those IPs. DS
RE: Can a customer take IP's with them?
> On Tue, 22 Jun 2004, David Schwartz wrote: > > > In other words, customer is asking a court to rule whether or > > > not IP space > > > should be portable, when an industry-supported organization (ARIN) has > > > made policy that the space is in fact not portable. It can be further > > > argued that the court could impose a TRO that would > > > potentially negatively > > > affect the operation of my network. > > A court will likely decide this based upon the terms of > > your contract and > > what the court thinks is fair. They will likely give very little > > consideration to common practice or ARIN's rules. > Actually, I don't think that's the case. ARIN still owns the numbers, NAC > is just leasing them. Therefore, ARINs rules supercede anything > contractual between NAC and the customer. Yes, but the court won't care about that. They'll simply enjoin the ISP from interfering with the customer's use of those IP addresses. ARIN can do whatever they want about it, but that would be a totally separate issue. > For instance, if what you say were true, all an ISP would have to do in > order to "sell" their IP space is to create a contract stating that they > are doing so. Exactly. If they did that, a court would likely enjoin them from making any action to interfere with the customer's use of those IP addresses. A court would likely find the contract binding upon the parties that entered into it. > Contracts are rarely as binding as people think they are. Of course, I'm > no lawyer, I just hate paying them. Let me try to give you a hypothetical to show you why ARIN is irrelevent. Suppose I am a member of the Longshoreman's assocation and you have a contract to buy shrimp for $8/pound provided you only resell it to members of the LA. You then enter into a contract with me to sell me shrimp for $10/pound. But then I leave the LA. Ooops, now you can no longer resell me the shrimp. So you break our contract and I sue you. Does your contract with your shrimp provider matter? If you continue to sell me shrimp even though I'm not in the LA, who does your shrimp supplier sue? You or me? DS
RE: Can a customer take IP's with them?
> David, > > Isn't renumbering an obligation? > > >I wonder if their ARIN application says anything about planning to > >renumber their existing space from NAC into the newly assigned space... > > > >-davidu It's hard to see how his customer failing to meet obligations to ARIN is going to be considered relevant to his relationship to his customer. ARIN isn't a party to the dispute, and the ARIN renumbering requirements aren't directly intended to benefit the ISP. In fact, one could argue that a customer renumbering is to the detriment of their ISP because it reduces lock in. A court is going to look very specifically at three things: 1) What is the hardship to the customer if the TRO is not granted. 2) What is the hardship to the ISP if the TRO is granted. 3) Is the customer likely to prevail in whatever is the actual claim that gave rose to the TRO (which we have no clue). I think it doesn't impose a significant hardship on the ISP for the court to grant the customer the right to continue using the IPs and advertise them from another provider for some reasonable amount of time. How much of a hardship forcing the customer to renumber immediately is, I don't know. And what the real claim is, I don't know either. The tack I would take is to use the kettle defense -- to attack all the prongs. First, I'd argue that there is no hardship to the customer in forcing them to renumber immediately, spreading the pain out over time doesn't lessen it. I'd further add that the TRO's false urgency was created by the customer -- they already had plenty of time to renumber, so if losing the IPs was such a hardship, it's only because they failed to mitigate it by acting diligently. Second, I'd argue that letting them keep the IPs is a significant hardship on me, because it makes me responsible for resources over which I have no control whatsoever. A security problem might require immediate filtering to protect my other customers, and I won't be able to do that. Third, I'd argue that the customer always knew that the ISP's were his only so long as he continued to buy my service, and so he is asking for something to which he knows he has no entitlement. All of this assumes that you didn't disconnect him for a bad reason and were reasonable in negotiations with him. You weren't really trying to lock him in and using his IPs and his difficulty with renumbering to blackmail him for more money, were you? DS
RE: Can a customer take IP's with them?
> In other words, customer is asking a court to rule whether or not IP space > should be portable, when an industry-supported organization (ARIN) has > made policy that the space is in fact not portable. It can be further > argued that the court could impose a TRO that would potentially negatively > affect the operation of my network. A court will likely decide this based upon the terms of your contract and what the court thinks is fair. They will likely give very little consideration to common practice or ARIN's rules. > Another VERY important issue to bring up: If customer is granted the legal > right to continue to use IP space that is registered to NAC by ARIN, NAC > runs into the very serious problem of being liable for all of the Spam > that could be generated by the customer and all of the RBLs that the > carrier may be added to [that of course will effect all of NAC's > customers] with no ability to revoke the IP space to protect itself. This > has to potential to effect the NAC network in a catastrophic manner. You'll just have to explain to people that the traffic didn't originate on, terminate on, or transit your network and therefore there is no justification for holding you responsible. When arguing against the TRO in court, make sure to point out that this TRO would make you responsible for behavior over which you have no control. However, the court will likely find that failure to grant the TRO puts a greater hardship on your soon-to-be-former customer than granting the TRO puts on you. Courts do not look well on artificial attempts to penalize a customer for changing providers. Lock in is considered anti-competitive. They will likely see your revocation of the IP addresses (or failure to offer them separately for a reasonable fee) as a case of lock in. Standard industry practice, AFAIK, is to allow customers to keep their IP addresses for a reasonable amount of time unless you have always had a policy of not allowing customers to advertise any of your IP space through any other providers ever. IANAL, seek competent legal advice from a lawyer with experience in this area. I'm sure you can work out some sort of compromise where you let them keep using their IP space for a reasonable period of time (3 months? 6 months?) and they renumber in that time. I'm fairly sure they don't expect to keep your IPs forever and I'm fairly sure you don't need them back immediately. DS
RE: Points on your Internet driver's license (was RE: Even you can
> On Sun, 13 Jun 2004, Paul Vixie wrote: > > > If you didn't do them, why do you think other people should? > > so you aren't going to google for "chemical polluter business > model", huh? > I hope you also google for Nonpoint Source Pollution. > ISPs don't put the pollution in the water, ISPs are trying to clean up > the water polluted by others. ISPs are spending a lot of money cleaning > up problems created by other people. ISPs do put the pollution in the water. They own/run the pipes that carry the pollution into the ocean. Nobody cares about pollution inside the ISP's own network, we only care about the pollution they put into our water. They own, run, and manage the pipes that put the pollution where it can harm others. They have continuous control over the process and ultimately decide who does or does not put things into those pipes and influence the policies. I think there's a serious disconnect between how ISPs see this issue and how their customers do. I hold ISPs responsible for their customers behavior once they are aware of that behavior. It has been many years since "I just pass the traffic my customers tell me to pass" was an acceptable answer. In fact, ISPs that take that attitude are (properly) ostracized today. If an ISP knows or suspected or should know that their customer is putting pollution into the communal waters, they have an obligation to do whatever it takes to stop that pollution. If that's notifying the customer, disconnecting the customer, filtering, whatever, that's between the ISP and the customer. I'm willing to make all kinds of allowances for what is and is not possible. I don't expect a filter in minutes. I don't expect them to disconnect a customer because they couldn't reach them. However, I do expect them to track the issue with their customer until it's resolved. If they do not do so, I hold them responsible to the extent that I am able to do so. Again, as I said, this in no way diminishes the responsiblity of the customer, the author of the malware, the person who failed to install the patch, the person who misconfigured the firewall (or decided they really didn't need one). Responsibility does not have to sum to 100%, it's possible for any number of parties to be wholly responsible. It amazes me how quick ISPs are to blame others, as if this diminshes their responsibility. It does not. If I leave your car unlocked and someone steals your CDs, no amount of blame I place on the thief diminshes my responsibility. DS
RE: Even you can be hacked
> Why does Webmaster put the entire risk on the customer, including warning > that the security mechanism has inherent limitations? Shouldn't Webmaster > be responsible if their customer suffer a loss whatsover the cause, even > if it wasn't due to any negligence on the part of Webmaster? I never argued that the ISP should be responsible for losses that weren't created by their own negligence. > Seems like Webmaster is requiring customers to be experts in Webmaster's > products. Shouldn't it be Webmaster's responsibility to analyze and > warn customers about every possible problem they could ever experience, > secure the customer against all possible harm, and compenstate the > customer for all losses? I never said an ISP should compensate a customer. How about sticking to the arguments I actually *used* rather than straw men? I'm talking about a case where the provider had continuing control over the use of the item involved. I'm talking about a case where the provider knew or should have known that there was abuse that was injuring third parties. I'm talking about a case where the provider is billing the customer for the specific act of harming the third parties. When you sell software, you have no idea what someone is going to use it for. You have no ability to continue to control the product over time. You have no way to know how the customer is actually using the product. You have no ability to shut off their usage at any particular time. You have no way to know or suspect that their usage is harming third parties. Again, every analogy fails. You have to look at this particular case and the particular facts. DS
RE: Even you can be hacked
This will be my last post on this issue. In this case: 1) Almost certainly the traffic was due to a worm. 2) Almost certainly the ISP knew (or strongly suspected) the traffic was due to a worm. 3) Quite likely, the ISP never carried most of the traffic to its destination. Once they knew it was worm traffic, they were probably filtering by port. 4) The ISP should not have carried the attack traffic, if they actually did. Doing so is negligent and creates additional innocent victims. Maybe they would give their customer a short time to straighten things out, but that's it. 5) An ISP should not be paid for traffic they only carried out of their own negligence. This doesn't negate the customer's responsibility to anyone but the ISP and only if the ISP is actually negligent, not just the customer. Yes, given the facts we know, it's possible that the ISP really does deserve to be paid, this traffic wasn't due to a worm, or there was no way the ISP could be sure. However, far more likely, the facts are as I state them above. So why does everyone think the ISP is almost certainly entitled to be paid? Is it because they're ISPs? Is it because it's easy to blame someone else? DS
RE: Even you can be hacked
> This thread is quite amusing and interesting at the same time. If I read > the original post right, Mr. Mike Bierstock was informed that he was > generating an unusual amount of traffic, traffic he would have to > pay for. > He got the bill and had to deal with the consequences. What is wrong with > that? Does it matter how this traffic was generated? Well, it depends upon the contract between the customer and the ISP. It matters if the traffic was actually delivered. For example, if the traffic was attack traffic that hit the ISP's filter, is it fair to charge the customer for the traffic because it came over their line? If the ISP had an obligation to stop attack traffic from their customers from getting onto the Internet, yes, it matters if the costs are due to the ISP failing in that obligation. As I understood this example, this was traffic that the ISP knew was generated by a worm. The ISP had an obligation to stop this traffic with filters or customer disconnection. They may or may not have complied with their obligation. Either way, it's hard to see why the customer should pay for traffic the ISP did not or should not have delivered. The customer could justifiably be billed for the extra costs he imposed upon his ISP in dealing with his attack traffic, but not for the traffic itself once it was identified. As I said, at the point the ISP should not have delivered it. Doing so creates more victims, and the ISP has a greated responsibility than the customer because they have greater knowledge and control. It doesn't matter much what the contract says if the ISP wrote it and the customer didn't understand it. Ask yourself a single yes or no question -- does an ISP have a responsibility to stop worm traffic generated by their customers from getting onto the Internet once they have identified it? And is so, does it matter whether or not the customer cooperates? DS
RE: Even you can be hacked
> > Of course, except in this case, the phone company can't > > easily tell the > > legitimate calls from the illegitimate ones and block only the > > illegitimate ones. Every analogy will break down, so don't expect to be > > able to convince people with analogies that seem so obviously right to > > you. Nothing is exactly accurate except the actual situation itself. > And how, exactly, did you expect the ISP to tell which packets you were > sending were legitimate and which were from the malware running on your > computer? Please enlighten me as to how I tell a customer's legitimate > outbound email from his system apart from the email from the same system > which is being sent not by him, but, by the malware that has infected his > system? In this case, the ISP informed the customer that there was illegitimate traffic. If it's your position that the ISP can't tell the difference, then the notification that we know happened would have been impossible. Presumably they even identified the particular customer responsible for the traffic, given that they notified him about it! Since it's obvious in this case that the customer would have preferred being disconnected to having to pay for the traffic, and the ISP could certainly have disconnected him, the question becomes, why didn't they? Especially since they knew the attack traffic was creating other innocent victims. My guess is that they *were* filtering it (probably by port) and never delivered the attack traffic to its destination anyway. They probably still billed the customer because they bill for traffic over the customer's line, regardless of whether it hits their emergency or bogon filters. > > And, again, almost every contract has some insurance elements to it. > > There will be unusual cases where it's actually possible for the utility > > to lose money if something unusual happens. My main point is that the > > understanding that seems so obviously right to you may not seem so > > obviously right to your customers. > No sane ISP will insure a usage-based customer against traffic sent by > that customer's infected machines AFTER he has informed the customer > of the problem. No sane ISP will allow attack traffic to continue to hit the Internet after they know it's coming from one of their customers regardless of what the customer does or does not do. So why should the customer pay for "Internet traffic" that their ISP likely did not (and certainly should not have) actually sent or delivered? > > As for all the people who talk about turning off their DSL > > access when > > they're away from home, they're missing the point. Obviously a person > > could do that. We could shut off our electricity when we leave home. We > > could have our telephone service temporarily disabled when we go on > > vacation too. A person could do all of these things. My point is that > > it's also perfectly reasonable for a person not to do these things. > > Because in general an ISP has more ability to control these > > things and it > > makes very little sense for a home user to insure an ISP, it makes more > > sense for the ISP to insure the user. > I still don't understand why you insist that my ISP has (or should have) > more control over what traffic my systems deliver to my internet > connection > than I do. This simply isn't the case, and I would be very unhappy if > it were to become the case. For the classes of service I'm talking about, like home DSL, they do. They choose which ports to block and they have a responsibility to monitor their customers for machines that are causing problems for others. In this case, they actually did that and detected the problem -- good for them. But they then decided that instead of remedying the problem, they'd bill their customer for it. Maybe they blocked the attack traffic, maybe not. If so, why charge for traffic you won't deliver? If not, then that's serious negligence, no? > > In any unfortunate situation, you can find a hundred things > > that anyone > > could have done differently that would have avoided the situation. But > > that is not how you establish responsibility, financial or moral. You > > look at people who failed to use reasonable prudence. > And you don't think that a person who is informed that their system is > infected and chooses not to fix it has failed the reasonable prudence > test? You think an ISP that knows that their customer is sending attack traffic but neither blocks the traffic nor shuts off the customer has failed the reasonable prudence test? And who should be more subject to a reasonable prudence test for Internet practices, a home DSL customer who may not know very much about computers, or an ISP that specializes in Internet access that has monitoring equipment a trained staff 24/7? Your customers expect you to deal with this stuff. You may or may not find their expectations reasonable, but dammit, y
RE: Even you can be hacked
> At 7:07 PM -0700 2004-06-10, David Schwartz wrote: > > Most of the people on this list see things from the ISP's > > perspective. > > However, step back a bit and see it from the user's perspective. Do you > > expect to pay for phone calls you didn't make or do you expect > > the person > > whose deliberate conscious action caused those calls to be made? Do you > > expect to be responsible for patrolling your electric lines to > > make sure > > someone hasn't plugged into your outside outlets? > If you had a PBX in your home that was misconfigured and allowed > people to dial-in and then dial back out and get free long distance, > and your telephone company warned you about this weakness, forgives > your first month overages due to your being hacked, and yet you still > refused to fix the system, then you're toast. > > Under those circumstances, if someone makes $10M worth of long > distance calls via your PBX, then you're going to have to pay up. Of course, except in this case, the phone company can't easily tell the legitimate calls from the illegitimate ones and block only the illegitimate ones. Every analogy will break down, so don't expect to be able to convince people with analogies that seem so obviously right to you. Nothing is exactly accurate except the actual situation itself. And, again, alomst every contract has some insurance elements to it. There will be unusual cases where it's actually possible for the utility to lose money if something unusual happens. My main point is that the understanding that seems so obviously right to you may not seem so obviously right to your customers. As for all the people who talk about turning off their DSL access when they're away from home, they're missing the point. Obviously a person could do that. We could shut off our electricity when we leave home. We could have our telephone service temporarily disabled when we go on vacation too. A person could do all of these things. My point is that it's also perfectly reasonable for a person not to do these things. Because in general an ISP has more ability to control these things and it makes very little sense for a home user to insure an ISP, it makes more sense for the ISP to insure the user. In any unfortunate situation, you can find a hundred things that anyone could have done differently that would have avoided the situation. But that is not how you establish responsibility, financial or moral. You look at people who failed to use reasonable prudence. And, of course, the ISP always (or very nearly always) insures the user against the costs of inbound attack traffic that exceeds his line rate. The more demands you make of your customers, the more you decrease the value of your very own product. Frankly, if I ruled the world, obtaining Internet access would require a serious cluefulness test and you'd take a lot more responsiblity for generated traffic. I know a lot of people on this list wish things were the same way and sometimes want it so much that they're able to convince themselves that this is the way things actually are in the real world today. But they're not, and you may find that outside your group of friends, your views are found to be very odd by the majority of 'normal' (but, admittedly, inferior) people. The arguments that seem so obviously right to you may be greeted by amusement and the analogies you think work will be found unconvincing. This is because this argument is largely about other people's expectations. DS
RE: Even you can be hacked
> On Jun 10, 2004, at 10:07 PM, David Schwartz wrote: > > It all depends upon what the agreement between the customer and the > > ISP > > says. It's no unreasonable for the ISP to 'insure' the customer against > > risks he isn't able to mitigate which the ISP is, even if that means > > shutting off his service. > While it may not be unreasonable, it is also not unreasonable for the > ISP to *not* insure the customer against such risks. > > It all depends. :) Well, it depends upon the class of service. For lower classes of service, it's generally a non-issue because the service isn't billed based upon usage. But I would argue that for low-end service (like home DSL) that is billed based upon usage, it's unreasonable for the ISP to bill customers for attack traffic. Obviously, it's possible that someone could offer this and get a customer to agree to it, but I'd be really suspicious as to whether they actually had a meeting of the minds with the customer about the consequences. > Also, you did not really address my question: Are you willing to sell > me the service I asked for above? I've acted as a negotiator for several companies who were looking to obtain connectivity. I've had no trouble negotiating agreements where the customer does not pay for attack traffic. Some companies want a 'per incident' fee, some don't. Usually these fees are reasonable and include firewalls and tracking and other things that are worth paying for. You can certainly get flat rate connections and you can get connections where if your service goes over X dollars, they rate limit you unless you agree to let more in. Yes, you can get almost any combination of service features. Obviously, some cost more than others. However, you can certainly get your ISP to insure you if you want. Heck, buy a flat rate 100Mbps line from any carrier and they're paying for any attack traffic over 100Mbps. Put in a filter and they're paying to carry all the attack traffic to the filter. > > Most of the people on this list see things from the ISP's > > perspective. > > However, step back a bit and see it from the user's perspective. Do you > > expect to pay for phone calls you didn't make or do you expect the > > person > > whose deliberate conscious action caused those calls to be made? Do you > > expect to be responsible for patrolling your electric lines to make > > sure > > someone hasn't plugged into your outside outlets? > > Actually, I Am Not An Isp. (Yes, that is really what is stands for.) > I do see things from a user perspective. And I still do not agree with > you. > > For instance, I do believe if someone comes by and plugs something into > an outside socket on my house that I should pay the bill. The power > was used, it cost something, and the power company sure as hell was not > responsible. Of course, if I can find the culprit, I can force him to > pay. But that does not mean the power company should eat the > difference. It does if the person got to your house over the power company's lines. It does if the power company knows about it. Unfortunately, every analogy breaks down. > Take some responsibility. How does a person with a DSL line at home take responsibilty if he's away for a month? Is he supposed to hire someone? > This whole thing reminds me of when we were > kids and I loaned my middle brother my walkman. He left it on the > floor where my baby brother was playing - who promptly smashed it with > some random toy and destroyed it. My middle brother claimed it was not > his fault, my baby brother did it. I was out a walkman (big bux in > those days!), but I learned a valuable lesson: Never trust someone who > is not willing to take responsibility. Certainly it was both of their faults and you're technically entitled to collect from either of them. > Since you seem to disagree with me, care to put your money where your > mouth is? Sell me a service where I only pay for what I expect. I'm > happy to have you shut me off if you notice traffic out of profile, but > don't expect me to pay more than what I think I should. Oh, and you > should be prepared to turn the service back on when I "fix" the problem > (even if it is just going to happen again, and again, and again, and > again...). As I said, this kind of service is *definitely* available. You can get flat rate service where you only pay what for traffic you expect. You can get service where you can set a rate limit dynamically. You can get service where filters are put up at your whim and you do not pay for traffic that hits the filters. I think you're mostly being glib
RE: Even you can be hacked
> On Jun 10, 2004, at 2:06 PM, Laurence F. Sheldon, Jr. wrote: > The "victim" in the case Sean posted knew he had a worm, got some of > his first bill forgiven, yet did nothing to correct it and acts > surprised when the same thing happens the next month. YES, he is at > fault. Anyone who thinks differently .. uh .. can I buy b/w from you? > :) Oh, and since you feel responsible, I'm only going to pay for the > amount of traffic I think I should have gotten on my web page, even if > I get /.'ed or something. Does $25/Mbps sound good? I plan to use > about 1 Mbps, but I will need an un-rate-limited GigE connection. It all depends upon what the agreement between the customer and the ISP says. It's no unreasonable for the ISP to 'insure' the customer against risks he isn't able to mitigate which the ISP is, even if that means shutting off his service. If someone blows up my water line and $1,000,000 worth of water is wasted, I don't think the water company is going to expect me to pay for it. This is especially true if the water company knew about the leak, could have done something to mitigate it, and failed to do so. Even if that means shutting off my water, that's what I'd expect them to do, shut it off until someone fixes it. Most of the people on this list see things from the ISP's perspective. However, step back a bit and see it from the user's perspective. Do you expect to pay for phone calls you didn't make or do you expect the person whose deliberate conscious action caused those calls to be made? Do you expect to be responsible for patrolling your electric lines to make sure someone hasn't plugged into your outside outlets? For most classes of service, it makes the most sense to only charge the customer for the traffic he wants and have the ISP take the responsibility for dealing with attacks to the extent they can do so. This is because the customer can't afford to hire a full time person to guard his always-on DSL connection while he's away for two weeks but his ISP can. This may mean that you're disconnected until they can coordinate with you -- such is life. Just be aware, your customers may not have the same expectations you do, and you should make your understanding *very* clear to your customers in your contracts. DS
RE: Worms versus Bots
> On Thu, 6 May 2004 [EMAIL PROTECTED] wrote: > > > connectivity, not even wireless. But it does have an internal > > 100baseTx Ethernet port that uses a non-standard connector. > > And it also includes a router unit running off the same > > power supply as the PC but otherwise completely independent. > > Urg, a horrible idea. Why not just make the software on the host > secure? Because then you would have to limit the ability to modify the software to only those trusted not to affect network security. It's the same answer as the answer to "why not run everything as root"? DS
RE: What percentage of the Internet Traffic is junk?
> Perhaps now I'm the one being pedantic, but you're confusing "somebody" > with the owner of the resources involved in the sending. Look, we're the ones asking what percentage of Internet traffic is junk, so we're the somebody. We know what we mean and can do a reasonably good job of explaining it. Basically, it's junk if the sender wouldn't have wanted to send it, the receiver wouldn't have wanted to receive it, the owner of a computer was duped or tricked into sending it, or it's an attack, and so on. It's not complicated. We do have to pass some value judgments. But any number of things we measure requires such value judgments. DS
RE: What percentage of the Internet Traffic is junk?
> I'm not sure that I'd agree with this statement. What > about the traffic from compromised sources? The pps > floods or spam emails are not being created with the > knowledge of the source, so it would be hard to say > that the source "wanted" to send it. Exactly. A great example is a web server struggling to continue to accept connections in the face of a spoofed SYN flood. The SYN/ACK packets are junk. The definition of "junk" is that the sender would not have wanted to send it or the receiver would not have wanted to receive it if either had had a chance to have the appropriate human or humans investiage the transaction in full detail. Traffic you are duped into sending by traffic you wish you hadn't received or cannot distinguish from legitimate traffic is junk.
RE: Microsoft XP SP2 (was Re: Lazy network operators - NOT)
> Firstly, who enforces it? The reason it "works" with cars is that > the state > (or province for those of us north of the border) effectively says "you > can't drive a car without this lovely piece of paper/plastic that > we'll give > you" and "if we find you driving a car without the lovely piece of > paper/plastic, you're going to be in serious trouble". Are you proposing > that each jurisdiction that currently licences drivers also > licence Internet > users and tell ISPs "sorry, but if they don't give their licence, > you can't > give them an account"? That's not a problem. The state licenses drivers but it also owns the roads. > Secondly, HOW do you enforce it? Motor vehicles only require a > licence to be > operated on public roads in all jurisdictions I'm aware of. IANAL, but if > some 14 year old kid without a licence wants to drive around on > his parents' > private property, that is not illegal. So? If you want to mess around on your private network, I don't care either. > Now, the instant that > vehicle leaves > the private property, it's another story (assuming, of course, cops around > to check licences. In some jurisdictions, this is more true than > in others). Exactly. You want to go on someone else's roads, you do so only by their rules. > My point is, driving is ONLY regulated when it is done in public view, for > obvious reasons. Computer use is an inherently private activity, so how do > you propose to verify that the person using a computer is in fact > licenced? > Mandatory webcams? :P So you can drive however you want on *my* driveway? That's not public view, is it? If there only private roads, I'll bet you that private road owners would have come up with a licensing system quite similar to what we have today, for liability reasons if nothing else. You might also notice that you can't get liability insurance without a license even though that insurance is issued privately, and there aren'y many road owners who let you drive on their roads without insurance. > Thirdly, WHO do you enforce it against? It's pretty difficult > (and illegal) > for $RANDOM_JOE (or $RANDOM_KID, etc) to just go out and drive > someone's car > without their explicit knowledge and permission. (Okay, so you > can hotwire a > car, but...) It's very easy for someone other than the computer > owner or ISP > contractholder to have access to it and abuse it and stuff. I'm not sure I understand why you think this is so. My kids know that my computer is off-limits to them just like they know my car is off-limits to them. They are physically capable of obtaining access to either without my permission. > So what do you > propose? Mandatory cardreaders on all computers? Fingerprint scanners > integrated into keyboards? How else can you avoid Mom logging online, and > then letting the unlicenced kids roam free online, allegedly to > do "research > for school"? Do you want to fine/jail/etc Mom if the kids > download a trojan > somewhere? I would presume that a license would include the rights to allow others to use your access under appropriate supervision or with appropriately restrictive software. > Fourthly, as someone pointed out, the first generation always complains. I > hate to show how young I probably am compared to many on this list, but my > jurisdiction introduced graduated driver's licencing a few years before I > was old enough to get a driver's licence, and it angers me that the random > guy who's out on the road driving like a moron had to go through way less > bureaucracy, road tests, etc than me simply because he was born ten years > before me. That said, if no reforms are made to make this system stricter, > I'm sure the next generation won't see this system as an outrage simply > because they won't remember an era when the bureaucracy. > Currently, people can buy computers/Internet access/etc unregulated at the > random store down the street. You're proposing that some regulatory > authority require licencing... Why should these voters accept it? Because their failure to cooperate will result in ostracism. That's how the Internet has always worked. > Especially > since, unlike with cars, the damage done by poorly-operated computers is > rather hard to explain to a technologically-unskilled person. Most would > respond something like "well, it's not my fault some criminal wrote a > virus/exploit/whatever. Put that person in jail, and let me mind my own > business." Good luck educating them on the fallacies in that statement. The point is, you don't have to. You just have to not let them on your roads. If they think the things they have to do to get on your roads are worth the value of those roads, they'll do them. If not, not. You don't care why people comply with your rules. People don't get driver's licenses because they think the piece of paper makes them a better driver, they do it because that is what's required for th
RE: Lawsuit on ICANN (was: Re: A few words on VeriSign's sitefinder)
By the way, do we even know what we're talking about? Specifically, has VeriSign produced a set of specifications for exactly what SiteFinder is and does? For example, is it guaranteed to return the same A record for all unregistered domains? Is it guaranteed that that A record will not change? Until VeriSign produces a technical specification for what it is they intend to do, they cannot expect other people to opine about what effects their changes will have. VeriSign has not yet even started the notification and analysis period. Isn't VeriSign's lawsuit premature? I mean, ICANN has not yet said no to any specific technical proposal from VeriSign, at least as far as I know. Is VeriSign arguing that they should be able to do whatever they want with the root DNS, with no advance notice to anyone? DS
RE: Latest IE patch breaking non username:password@encoded websites?
> Yes they broke basic auth in a URL. > > I am uncertain as to why it was necessary to remove this functionality. > > Bryan Apparently, there were ways to use this to make one URL look like the URL of another site. According to Microsoft, it isn't just '[EMAIL PROTECTED]/foo', but there were other problems involving being able to completely fool even technically savvy people (that is, nothing on the screen would reveal the real source of the web page you were looking at and every visible indicator was spoofable). DS
RE: GSR, 7600, Juniper M?, oh my!
> On Tue, Jan 13, 2004 at 02:01:48AM +0100, Jesper Skriver wrote: > That would depend what is causing the CPU usage. If it is software based > IP header lookups, you're not going to get any more peformance out of it > by trying to do more lookups than your CPU can handle. Surprisingly, that's usually not true. The cost of the IP header lookup is generally much less than the cost of a task switch. So when the system is at 100%, it's probably doing this: IP header lookup, wait for work / task switch, IP header lookup, wait for work / task switch, repeat As the load increases, it will start doing two IP header lookups before each task switch or yield. Then three. Then four. DS
RE: MS's new antispam idea
> > Stephen J. Wilcox wrote: > > So either this doesnt work because spammers don't > > actually use their own PCs to send email > Indeed; it doesn't do any good against spammers that control large > numbers of zombie machines; they'll just distribute the processing load > all over the place. And it would make life miserable for people that > send large numbers of legitimate emails. True. > Besides, the deployment is sketchy: before it can be activated, it needs > to be deployed at the vast majority of servers that send legitimate > mail, which means that in the interim one still has to accept emails > that don't use the system, which in turn produces no incentive to deploy > it in the first place. False. > Michel. While I think this scheme is a pretty bad idea, the argument above is just not correct. Obviously, until this scheme is widely-deployed, you have to accept email from sources that won't perform this validation, but that doesn't mean that there's no benefit to performing the validation or requesting it. If we assume 100% deployment of this scheme would be effective, then there are incentives to apply it yourself even if deployment is less than 100%. For example, one could filter sites that comply with this check less agressively than those that don't since since they're less likely to be spam. Similarly, as senders, we could get our mail subject to less stringent filters, which is presumably a benefit. Whenever we do the computation, we gain the benefit of being filtered less heavily. Any anti-spam scheme that provides benefits at 100% deployment also provides incremental benefit at less than 100% deployment. Recipients can filter compliant mail less agressively and thereby drop less legitimate mail. Senders can get less of their legitimate mail dropped on the floor by complying with the scheme where sites respect that compliance. DS
RE: data request on Sitefinder
> A number of people havce responded that they don't want to be forced to > pay for a change that will benefit Verisign. That's a policy issue I'm > trying to avoid here. I'm looking for pure technical answers -- how > much lead time do you need to make such changes safely? You can't separate them. How long something takes to do depends upon who is paying for it and how much they are paying. With a blank check, I can do almost anything in a week. On the other hand, if it's an unexpected expense without an accompanying unexpected source of funds, the same task can take years. If the beneficiary is not paying, things take very much longer. In any event, this question is currently impossible to answer from a purely technical perspective because we don't know what Verisign intends to change. For example, what will be the new correct way to determine whether or not a domain exists in the DNS, say for purposes of spam filtering? Will the wildcard A record be guaranteed to always point to the same, single address or not? We don't know what the target is, so we don't know what's involved in hitting it. When Verisign releases a specification, then we can talk about what's needed to meet it. DS
RE: NTP, possible solutions, and best implementation
> > It depends upon how low a probability failure you're willing to consider > > and how paranoid you are. For one thing, the U.S. National > > Command Authority > > could decide that GPS represents a threat to national security > > and disable > > or derate GPS temporarily or indefinitely over a limited or > > unlimited area. > Derating GPS wouldn't affect the time reference functionality. Turning off > GPS entirely would seriously affect military aviation operations. Not so: "Selective Availability (SA) is the deliberate introduction of error by either altering the precise timekeeping of GPS satellites or the position of the satellites in space, through the on-board software, thereby reducing both positioning and timing accuracy for civilian users." GPS accuracy is generally reduced by adding noise to the timing. Now you would have to derate GPS pretty significantly before timing accuracy would be significantly affected. But it's possible that some time references would refuse to lock on at all with sufficient derating. The affects of more extreme derating than SA are, at least to some extent, unknown. > > Aviators try very, very hard not to trust their lives to GPS. > As opposed to LORAN ? Generally, aviators don't like SPOFs. So they try very hard not to trust their life to any one thing. GPS is used in conjunction with VORs, pilotage (navigation by reference to fixed objects), and dead reckoning. GPS is used for instrument approaches, but only under extremely controlled conditions by very experienced pilots. A significant fraction of instrument training is how to cross-check instruments and detect failures. GPS approaches are individually approved by the FAA and factors such as runway lighting are critical. FAA approved GPS units must be used and one of the things these GPS units must do is monitor signal integrity (RAIM). From time to time, you will read FAA accident reports of people who attempted to perform GPS approaches with just a handheld GPS. DS
RE: NTP, possible solutions, and best implementation
Eliot Lear writes: > [EMAIL PROTECTED] wrote: > > Beware the single point of failure. If all your clocks come > > from GPS, then > > GPS is the SPOF. > Can you describe what would be involved to cause this sort of single > point of failure to fail? It depends upon how low a probability failure you're willing to consider and how paranoid you are. For one thing, the U.S. National Command Authority could decide that GPS represents a threat to national security and disable or derate GPS temporarily or indefinitely over a limited or unlimited area. It is well known that GPS is vulnerable to deliberate attacks in limited areas, perhaps even over large areas (see Presidential Decision Directive 63). Backup systems are officially recommended for "safety-critical applications" and the US government is actively intersted in developing low-cost backup systems (presumably because they're concerned about GPS as a SPOF too). The US government, and other entities, do perform "GPS interference testing". This basically means they interfere with GPS. The government is also actively investigating "phase-over to private operation", which could mean changes to operation, fee system, or reliability of the GPS system. One could also imagine conditions that would result in concurrent failures of large numbers of satellites. Remember what happened to Anik E-1 and E-2 (space weather caused them to spin out of control). If you do develop a system with GPS as a SPOF, you should certainly be aware of these risks and monitor any changes to the political and technical climate surrounding GPS. I do believe that it is currently reasonable to have GPS as a SPOF for a timing application that is not life critical (that is, where people won't die if it fails). Aviators try very, very hard not to trust their lives to GPS. DS
RE: Blacklisting: obvious P2P app
> Each mailserver could keep a cryptographically verified list, the > list is distributed via some P2P mechanism, and DoS directed at the > 'source' of the service only interrupts updates, and only does so until > the source slips an updated copy of the list to a few peers, and then > the update spreads. Spam is an economic activity and they won't DoS a > source if they know it won't help their situation. If anyone who attempts to distribute such a list is DoSed to oblivion, people will stop being willing to distribute such a list. Yes, spam is an economic activity, but spammers may engage in long-term planning. You can't keep the list of distributors secret. I'd be very interested in techiques that overcome this problem. I've been looking into tricking existing widely-deployed infrastructures into acting a distributors, but this raises both ethical and technical questions. DS
RE: Detecting a non-existent domain
> At 3:15 PM -0700 9/23/03, David Schwartz wrote: > > How would you do this before? Does an A record for a hostname > >mean that a > >host with that name exists? If so, then all *.com 'hosts' now 'exist'. If > >not, what did you mean by exist before? > Okay, let's be very specific. I need to know if a given name has > either A or MX records which are *not* the same as those provided by > the a wildcard in the appropriate TLD. Okay, but what does that have to do with Verisign? That question would apply to .museum as well, for example. It also applies equally to lower-level domain. It's not Verisign's fault that DNS doesn't provide any 'wildcard' flag in its responses. If we're going to challenge Verisign, we should be very careful to precisely phrase our queries so that Verisign has no wiggle room. For example, I suggest, "If I don't like SiteFinder, don't agree to its terms, and don't want to use it, or if I can't comply with its terms because my usage is commercial, how do I avoid it?" DS
RE: Detecting a non-existent domain
Lee Hinckley wrote: > At 2:46 PM -0700 9/23/03, David Schwartz wrote: > > He asked for the "optimal way" "to see if a given host truly > >exists" and > >you told him how to confirm or deny the "existance of a domain". He asked > >about hosts, you answered about domains. > In fairness I was ambiguous. Although Verisign ought to be > describing all of these techniques. But depending on the > circumstances I primarily need to check for A records or MX and A > records. I was both confused and confusing myself. Previously, you could consider any response other than 'NXDOMAIN' to an 'ANY' query in the COM/NET domain to mean that the domain was registered, at least. Now you can't. There was no way to use DNS to tell for sure that a domain is available. There still isn't. There was no way to use DNS to tell for sure that a domain is registered. There still isn't. If we're going to challenge Verisign, we have to make sure we ask the right questions. One question to ask them is how are we supposed to tell whether an A record was placed by the owner of the domain. If we don't agree to SiteFinder's terms, how do we avoid using it? How do we use DNS for commercial purposes? And so on. DS
RE: Detecting a non-existent domain
> Getting practical for a minute. What is the optimal way now to see > if a given host truly exists? You first have to define what you mean by 'exists'. I have a machine here that I call 'stinky'. It's not on the Interent though. Does the 'host' 'stinky' exist? > Assume that I can't control the DNS > server--I need to have this code run in any (*ix) environment. > Assume also that I don't want to run around specialcasing specific IP > addresses or TLDs--this needs to work reliably no matter what the > domain. User gives me a string, and I need to see if the given host > is a real machine. How would you do this before? Does an A record for a hostname mean that a host with that name exists? If so, then all *.com 'hosts' now 'exist'. If not, what did you mean by exist before? > An answer from Verisign would be most appropriate here, since they > have done "extensive research" on the impact of their new service, so > presumably they figured out the answer to this problem and have code > samples available for distribution. However I get the feeling from > their press releases that they've forgotten there is more to the > internet than just the web. Forgive me for defending Verisign, but if you want to know if a given DNS name corresponds with an A record, you can still determine that. If you want to determine something else, you can still do that, depending upon what that something else is. As for 'fsck.de', a good argument can be made that this is not really a legal domain. It's a host. Checking for an SOA is a good way to tell if a domain is valid, depending upon what you mean by 'domain' and 'valid'. I'm reminded of the classic programmers question, "how do you tell if a machine is online?". The answer is "define what you mean by a machine being online and test for that". So you aren't asking a comprehensible question yet. DS
RE: Detecting a non-existent domain
> On Tue, 23 Sep 2003, Kee Hinckley wrote: > > Getting practical for a minute. What is the optimal way now to see > > if a given host truly exists? Assume that I can't control the DNS > Look for a SOA record for the domain - this should be the proper way to > check for the existance of a domain, instead of looking for A, NS or MX > records.. He asked for the "optimal way" "to see if a given host truly exists" and you told him how to confirm or deny the "existance of a domain". He asked about hosts, you answered about domains. DS
RE: Kill Verisign Routes :: A Dynamic BGP solution
> > I think the whole idea of getting into an escalating > > technical war with > > Verisign is extremely bad. Your suggestion only makes sense if > > you expect > > Verisign to make changes to evade technical solutions. Each > > such change by > > Verisign will cause more breakage. Verisign will either provide a way to > > definitively, quickly, and easily tell that a domain is not > > registered or > > Verisign will badly break COM and NET. > Who said they're logical in their decision making process. While they > experiment with .com/.net, countermeasures are called for. And they have > badly broken .com/.net. It's precisely because they may not be logical that I don't think it's wise to get into an escalation battle with them. Mutually assured destruction works well when your adversary is logical and very badly when they're not. > This is just an evolution of the blackhole solution, doing it dynamically. And if Verisign escalates, do you escalate again? Now you've indirectly caused a second wave of breakage. And then what? You escalate again for a third wave of breakage? > Keeps us from having to find out they changed it/moved it/etc. And, if > *.com goes away, so does the route :). It would be a major escalation for Verisign to use technological means to dupe people into again getting to SiteFinder despite their clear, explicit configuration to the contrary. If you really think such an escalation is inevitable, then the escalation will be sufficient to defeat whatever mechanism is deployed at that time. So deploying more complex mechanisms before that point is pointless. If you're hoping to push Verisign into an escalation to use that escalation for a lawsuit or PR angle, a number of small escalations is better than one big one. People are already employing means to avoid sitefinder, so if they think it's worth escalating to get around that, they already have to. In any event, Verisign's policy descisions will likely be driven primarily by actions taken by Microsoft, AOL, and perhaps ICANN and the DOC. The plain and simple truth is that if you want to use .COM and .NET, you have to trust Verisign. Sad, but true. DS
RE: Kill Verisign Routes :: A Dynamic BGP solution
> I wanted to discuss the merits of the following: > I have written a proof of concept solution to nuke a route to sitefinder. > Code to those who care or to the list if anyone cares. Perl is > your friend > :) > Basic concept: Use Net::BGP to set up a peering session with my route > server. Query DNS for *.com and *.net on x interval. Then take > the answers > (if they are valid A records) and inject them into the route server (which > in our case is used solely to feed a blackhole network to sink > traffic from > APNIC space, etc). > If an address no longer appears in the DNS (i.e. the idiots > switched hosts), > withdraw the route. If they set up multiple hosts, it will catch each one > of them. You can set the polling interval as you please. > Thoughts? I think the whole idea of getting into an escalating technical war with Verisign is extremely bad. Your suggestion only makes sense if you expect Verisign to make changes to evade technical solutions. Each such change by Verisign will cause more breakage. Verisign will either provide a way to definitively, quickly, and easily tell that a domain is not registered or Verisign will badly break COM and NET. DS
RE: DNS anycast considered harmful (was: .ORG problems this evening)
> On Thu, 18 Sep 2003, Leo Bicknell wrote: > > A truely robust anycast setup has two "addresses" (or networks, or > > whatever), but only one per site. From the momentary outage while > > BGP reconverges to the very real problem of the service being down > > and the route still being announced there are issues with all anycast > > addresses going to one site. > Yes, this is the fatal miscalculation in the ultradns setup. > However, the other aspect, hiding most servers and only showing two at > a time, isn't exactly the best idea ever either. First of all, it limits > the number of usable DNS servers available at any specific location > unnecessarily, and second, BGP metrics are a very poor substitute for > RTT measurements. Another issue is that packet loss has a huge affect on DNS resolve times. For those of use who use high-performance recursive resolvers that track packet loss and bias which name servers they use for each zone based on that, we like to have as many geographically diverse DNS servers to pick from as possible. DS
RE: News of ISC Developing BIND Patch
> > Any solution which requires uniqueness also requires a singular ultimate > > authority. > Not really. You can just take random numbers. If you have enough bits > (and a good RNG) the probability of collision would be less than > probability of an asteroid wiping the life on Earth in the next year. That doesn't help in this case. You need a way to verify ownership of an identifier. I don't want anyone else to be able to claim my identifier. Perhaps we can devise a scheme where I generate a random number and morph it into a 'private key'. Then I pass it through some algorithm to generate a 'public key' which is the identifier that I use. I then use the private key to prove my ownership of the public key. Nobody else can claim my public key because they don't know the corresponding private key. In fact, you could just use an RSA public key as the identifier directly. This is likely not the best algorithm, but it's certainly an existence proof that such algorithms can be devised without difficulty. In fact, I'm going to call my patent attorney instead of sending this email. ;) DS
RE: Change to .com/.net behavior
> > > ... shouldn't they get to decide this for themselves? > > Returning NXDOMAIN when a domain does not exist is a basic > > requirement. Failure to do so creates security problems. It is > > reasonable to require your customers to fix known breakage that > > creates security problems. > that sounds pretty thin. i think you stretched your reasoning too far. Feel free to point out the step that's stretching too far. There definitely do exist security validation schemes that rely upon domain existence that are fooled by Verisign's bogus reply. > > VeriSign has a public trust to provide accurate domain > > information for the COM and NET zones. They have decided to put their > > financial interest in obscuring this information ahead of their public > > trust. > i'm not sure how many people inside verisign, us-DoC, and icann agree > that COM and NET are a public trust, or that verisign is just a caretaker. > but, given that this is in some dispute, it again seems that your > customers > should decide for themselves which side of the dispute they weigh in on. Then who does ICANN represent? Doesn't ICANN operate under the authority of the DOC? Doesn't Verisign operate pursuant to a contract with ICANN? Aren't we all intended third party beneficiaries of those contracts? Is this really in dispute? > > Microsoft, for example, specifically designed IE to behave in a > > particular way when an unregistered domain was entered. Verisigns > > wildcard record is explicitly intended to break this detection. The > > wildcard only works if software does not treat it as if the domain > > wasn't registered even though it is not. > then microsoft should act. and if it matters to you then you should act. I would hope that Microsoft would respond with a lawsuit rather than a patch. Otherwise, Verisign will respond with a 'technical solution' and we'll be in a war with the people we have to trust. > but this is not sufficient justification to warrant a demand by > you of your > customers that they install a patch (what if they don't run bind?) or that > they configure delegation-only for particular tld's (which ones > and why not > others?) It really depends upon the specifics of the contractual situation. What if one of your customer's customers lets through some spam because Verisign broke their validation check? And what if that person is sued? Now, where does that leave you, aware of the problem and having not taken actions to correct it that you could have taken? > > Verisign has created a business out of fooling software through > > failure to return a 'no such domain' indication when there is no such > > domain, in breach of their public trust. As much as Verisign was > > obligated not to do this, others are obligated not to propogate the > > breakage. ISPs operate DNS servers for their customers just as > > Verisign operates the COM and NET domains for the public. > the obligations you're speaking of are much less clear than > you're saying. Yes, oviously they are much less clear to Verisign. I want to hear from IANA how they feel about a.net being pointed to Verisign. Simply put, Verisign is telling me that 'a.net' has address '64.90.110.11' and it does not. DS
RE: Change to .com/.net behavior
> > I've implemented the official ISC Bind hack on every single one of my > > name servers and am pushing it and the configuration changes out to my > > customers as a *required* upgrade. > that seems a bit extreme. shouldn't they get to decide this for > themselves? Returning NXDOMAIN when a domain does not exist is a basic requirement. Failure to do so creates security problems. It is reasonable to require your customers to fix known breakage that creates security problems. VeriSign has a public trust to provide accurate domain information for the COM and NET zones. They have decided to put their financial interest in obscuring this information ahead of their public trust. Microsoft, for example, specifically designed IE to behave in a particular way when an unregistered domain was entered. Verisigns wildcard record is explicitly intended to break this detection. The wildcard only works if software does not treat it as if the domain wasn't registered even though it is not. Verisign has created a business out of fooling software through failure to return a 'no such domain' indication when there is no such domain, in breach of their public trust. As much as Verisign was obligated not to do this, others are obligated not to propogate the breakage. ISPs operate DNS servers for their customers just as Verisign operates the COM and NET domains for the public. DS
RE: What do you want your ISP to block today?
> > Once upon a time there was a proposal for a protocol which allowed > > clients to > > push a filter configuration to the edge router to both classify traffic > > and filter > > unneeded things. > Nice idea. I am sure clients will figure that out. As quickly as they > caught on to 'Windows Update' and 'Setting up a VCR clock'. Lets face > it: Some things are better left to the "experts". If the clients don't figure it out, they get the default, which can be as permissive or as restrictive as make sense for people who can't figure out how to control filtering. DS
