- Test - lists.nanog.org

Query: What policies do backbone providers use to determine IP ownership?
by Tony Mumm 25 May '01

25 May '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I'm curious to what extent everyone is checking to determine ownership of IP addresses when taking on new customers. Lately, multi-homing has become a very hot topic for even the smallest of providers. With that, customers are bringing along their IP addresses from their previous providers. Are we required, as providers, to determine if that block is actually owned by that customer, and facilitates good Internet routing? I've seen a trend lately where I'm finding out, after the fact, where pieces of larger CIDR blocks are being taken apart by a myriad of unaggregated routes. The other backbone providers freely allowed an announcement of that non-portable space to the Internet without regard to either the owning provider, or to general Internet routing. My concern is two fold: 1) This contributes to terrible Internet routing. By not addressing this with the customer right away, we'll continue to deal with a proliferation of /24s and Internet bloat. I realize the customer needs its address space to announce separately, but should we allow them to freely announce random /24's? This is only due to that the customer received IPs by growing over the years, rather than getting a single block up front. 2) It seems that other providers are allowing our customers to hijack our routing space piece by piece. I will happily participate in multihoming a customer, but I would hope it involves us. We can make a contiguous allocation from our CIDR blocks, and then work with the customer in a more consistent manner. Much of this is customer education about multihoming, but unfortunately we often find out too late. So the question becomes, what do providers do to determine where a block is coming from, and what is its implications on the global routing system? Just cutting and pasting an email from the customer into an access-list seems to be what we have now... I'd be interested to hear what others thoughts and experience are with this. Perhaps I'm just overly concerned with a normal happening on the Internet. Comments? Tony -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOwvHa89/cCqjBxGyEQLVUACfeyX9zbWUbhYQyRWP82f+jU5FhXUAoPHT pmjEerQRWEtEJHG0OvMUxDdP =t+ws -----END PGP SIGNATURE-----

6 6

Domain-Policy?
by David Howe 25 May '01

25 May '01

Got two emails in reasonably close order (this follows an argument about Netsol selectively deleting emails from the DP archive) -------------------------------- first message ------------------------------------------------------------- Subject: We Are Mad As Hell And Doing Something! NOTE: NSI is refusing to post this email message for over 10 hours. This is a disgrace and an attempt to supress information from the readers of the Domain Policy list. This same message has been posted on www.ICANNWATCH and www.ICANN Public Forum. So, as well,I am sending it directly to you and others frequently on that list who can post to the Domain Policy List. Committee For Fair Play From ICANN And DOC Greetings: I am a real person and I sent the Mike Johnson information because everybody should know what is going on with Verisign and its buddies at National Telecommunications Information Agency, the Department of Commerce and ICANN. We don't want or intend to politicize this forum. However, none of us can remain in the dark to the harm that is being done in the name of competition and improvement for our industry and the Internet. We understand why NSI dumped us off the posting last night and now want everyone to know that we are taking steps to be everywhere so we will be heard on this. We are not asking anyone for anything in our effort to obtain a fair chance for everyone who chooses to compete against Verisign, and for ICANN and the Department of Commerce to do the right thing in fully investigating every instance of abuse by the dominant Verisign. There are documents available now that prove Verisign has cheated and is abusing its position of dominance. This information will be turned over to the Department of Justice this week with a request for a formal antitrust investigation. We have asked Congresspersons to insist that a fair investigation be undertaken to determine how ICANN and the Department of Commerce can be fair and independent for this industry, and remain a dependent of Verisign. The potential for conflicts of interest and interrelated personnel offers pregnant possibilities that wrongful conduct might never be fully and fairly investigated by these bodies from here on. Some of us are lawyers and former NSI employees with friends inside Verisign who were outraged after learning of the details in the Mike Johnson litigation. We spoke to Mike Johnson today and learned that he has been provided assistance in preparing his recent filing, and despite Verisign's executives and employees being told yesterday not to render such assistance to him, access to information needed to support his Complaint is assured. Copies of the Johnson lawsuit was placed on the internal Verisign computers and printed and distributed to its employees even after Stratton yanked off the posted materials from both the external and internal server. The truth won't be quietly and easily silenced by Verisign because of its despicable conduct described in the recent lawsuit. There is no question that Verisign still is violating laws, and this is not a simple personnel matter as claimed by someone willing to remain blind to the realities we face living in this society. Having this lucrative government contract carries with it the responsibility to obey the laws designed to protect minorities and to give them a fair chance for promotion and retained employment security free of discrimination. Since this grievous conduct is obviously not deemed to be an important matter for Verisign and its buddies at ICANN and the Department of Commerce, we are announcing our support to make sure every newspaper and publication, and each relevant organization we can find, knows of this litigation against Verisign, and to organize whatever support we can to force ICANN and the Department of Commerce, the White House, and Congress to investigate and explain why there is no investigation to these horrendous facts and proofs. We can't let ICANN BOD and DOC ignore its respoinsibilities to call them as they are and take the appropriate actions to even replace Verisign with another entity more willing to comply with all laws. There can be no serious reason advanced why Verisign's behavior disclosed to ICANN and the Department of Commerce before the final negotiations were signed off last Friday was not disclosed to all Members of this House Commerce Committee before they voted approving this new transaction. The odor from this silence must be quickly investigated to reassure everyone that ICANN's independent role is still viable. We will be asking Congressmen Dingel and Markey to continue asking questions, as they voice the same concerns as others in the Senate who are now beginning to look at this situation. More than a whiff of fresh air is needed. Sincerely, Flip Leven -------------------------------- end of first message --------------------------- -------------------------------second message -------------------------------- From: Tom Newell <tomn(a)LISTS.NETSOL.COM> Subject: List deactivation To: DOMAIN-POLICY(a)LISTS.NETSOL.COM This list will be closed effective immediately. When we started the list many years ago, there were no lists specifically focusing on domain policy issues. Today there are a wide range of public lists that address this topic. Thank you very much for your participation. Please refer all queries to Brian O'Shaughnessy, of VeriSign's Corporate Communications department at boshaughnessy(a)verisign.com. --Tom -------------------------------- end of first message --------------------------- and Domain-Policy is **gone** - gone from the website (archive and all), email to the list bounces, resub requests to the majordomo fail. any ideas what is going on here (other than the obvious impression that the easiest way to stop the argument is to delete the forum)

2 2

Re: Splitting a block of Class C's
by Albert Meyer 25 May '01

25 May '01

At 07:14 PM 5/24/01 -0700, Steve Gibbard wrote: >Are you big enough to get a portable IP address block from ARIN? Since >you say you're dropping your Sprint connection in a few months, you will >presumably have to renumber then. If you want to be really nice, you >could bite the bullet and do it now, turning over the old block to your >former customer. Alternatively, it's common practice to tell your >customer that they have to renumber out of your space when they stop >buying connectivity from you, and from your perspective that's probably >the easiest way to handle the situation. I wish the timing had worked out that way, but they have to be gone by June 1, and I can't give up the Sprint IP's until July or August. The alternative to the ugly solution is to make them re-IP all of their domains, and AFAIK there is no easy way to do that. Last time I checked, NetSol makes you do each one individually.

3 2

RE: Splitting a block of Class C's
by Roeland Meyer 25 May '01

25 May '01

> From: Albert Meyer [mailto:albert@waller.net] > Sent: Thursday, May 24, 2001 9:08 PM > The alternative to the ugly solution is to make them re-IP all of their > domains, and AFAIK there is no easy way to do that. Last time > I checked, NetSol makes you do each one individually. That depends. All of my domains are run from the same zone servers. I only had to change IP addresses for those servers. No, the names NSI has are not the same ones, but the IP addresses are correct and that's all that matters. After that, it can mostly be done with SED scripts, or mass edits in each zone file. The larger problem is actually changing the addresses of all of those servers. I just went through that. It's a PITA.

1 0

Re: Stealth Blocking
by Valdis.Kletnieks＠vt.edu 25 May '01

25 May '01

On 00 Jan 00 00:00:00, Valdis.Kletnieks(a)vt.edu said: > Be careful, it's not as clear-cut as it may seem. At least in one US District > Court, portscanning was held to be legal (or more precisely, that you couldn't > count the cost of investigating one against damages)... s/was held to be legal/was not in and of itself held to be illegal/. Just a slightly different meaning there.. ;) I'll let the lawyers argue how to define "damages" as stated in 18 USC 1030(a)(5) - I wouldn't be surprised if a lawer attempted to claim that merely *FINDING* a vulnerability, but not exploiting it, causes "damage" the same way that driving past somebody's house and yelling "you have termites" causes damage if you investigate and finding that you do, in fact, have a termite problem. Of course, IANAL, and if anybody wants to cite case law please do so. ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech

6 5

Re: Stealth Blocking
by dlr＠bungi.com 25 May '01

25 May '01

[In the message entitled "Re: Stealth Blocking" on May 24, 10:23, "Eric A. Hall" writes:] > > Dave Rand wrote: > > > I'm not sure how effective rate limiting will be. Many spammers send > > one copy of the spam to an open relay, but use many (2 to 50) > > recipients. > > Rate-shapers would also work on the relays. The idea is that if ISPs would > implement a default rate-limit (let's say 4kb/s) that it wouldn't > interfere with normal use. It would interfere with spam distribution > because it would slow down the big runs dramatically. > > The negative side effect is that it cripples people who use email as a > file transfer protocol. > Ok, let's have a look. Last week, I got one spam ("get a free motorola pager") which came through 168 different open relays, bound for 4428 different recipients at bungi.com. There were 791 different connections to deliver all the spam, which meant that each time the spammer used an open relay, they delivered 5 copies of the message to my system (more or less). As was typical, they used 16 different grid.net dialups (all from ipls). Here's the dialup ports they used. Injection point IPs involved (potential source): IP Address Count Status In-addr 63.52.247.163 75 On DUL pool-63.52.247.163.ipls.grid.net 63.52.247.230 16 On DUL pool-63.52.247.230.ipls.grid.net 63.52.247.249 51 On DUL pool-63.52.247.249.ipls.grid.net 63.52.247.255 173 On DUL pool-63.52.247.255.ipls.grid.net 63.52.248.26 1 On DUL pool-63.52.248.26.ipls.grid.net 63.52.248.100 14 On DUL pool-63.52.248.100.ipls.grid.net 63.52.248.153 3 On DUL pool-63.52.248.153.ipls.grid.net 63.52.248.167 156 On DUL pool-63.52.248.167.ipls.grid.net 63.52.248.182 44 On DUL pool-63.52.248.182.ipls.grid.net 63.52.248.186 45 On DUL pool-63.52.248.186.ipls.grid.net 63.52.248.214 123 On DUL pool-63.52.248.214.ipls.grid.net 63.52.248.239 3 On DUL pool-63.52.248.239.ipls.grid.net 63.52.248.251 24 On DUL pool-63.52.248.251.ipls.grid.net 63.52.249.16 3 On DUL pool-63.52.249.16.ipls.grid.net 63.52.249.59 435 On DUL pool-63.52.249.59.ipls.grid.net 63.52.249.67 14 On DUL pool-63.52.249.67.ipls.grid.net The spam was 4K bytes, including header. That's 32K bits. Assuming that the open relays were really, really fast, that means that it would take about 2 hours to send all 4428 spams. If he had used 10 recipients per relay, it would have been 1 hour. 20 recipients would be 30 minutes. Without the rate limiting, assuming a 20 Kbps connection speed, it would have taken about 21 minutes to send the 4428 spams. Either way, rate limiting isn't very effective. Even rate limiting at 1Kbps only makes it 8 hours to send 4428 spams, or just over an hour a day (since these spams were delivered over a week time period). And they were using 4 to 8 dialups at a time. Even at 1Kbps, that's 50,000 to 100,000 spams per day, at 5 recipients per mail. If we go to 20, or 50, the numbers get very large, very quickly, even at 1 Kbps. That's why I think that port 25 blocking is the only way. That, and closing open relays, of course. --

4 3

Splitting a block of Class C's
by Albert Meyer 25 May '01

25 May '01

One of my ISP clients is leaving, and the person who was assigning IP's when they became our client chose to give them class C's scattered throughout our block. These are Sprint IP's which are assigned to us with our Sprint circuit. Our former client is getting a Sprint T1 and asking Sprint to route these class C's to them rather than us, and they tell me that Sprint appears willing. They don't have an AS, but they're getting another local ISP to advertise the IP's for them. I normally wouldn't agree to participate in such a mess, but we're shutting off the Sprint circuit in a couple of months, and I can't see making them re-IP hundreds of domains under the circumstances. Has anyone done something like this? I'm wondering how much it will increase the CPU load on my router. I'm already running at 20% average, and if it gets much over that I start dropping ICMP packets. I know enough BGP to stop advertising the appropriate class C's, but I'm not sure that this won't cause problems that I haven't considered. Will anyone refuse to accept advertisements which send adjacent /24's to different places? Is this an officially "broken" setup, or is it just ugly?

4 3

Re: Splitting a block of Class C's
by Albert Meyer 25 May '01

25 May '01

At 07:39 PM 5/24/01 -0500, Andy wrote: >It really depends on what you *want* to do. If the /24's you have assigned >to them are non-contiguous then they will want to renumber anyway so they >can advertise an aggregate. If you want to help them out, tell them to go >ahead and advertise the /24's out of your aggregate. Some providers have >stricter filtering, but generally will be reachable through other >providers, so connectivity isn't a big deal. Sprint should be advertising >an aggregate of your IP space which will bring all traffic to their >network. Once it reaches Sprint's network, the more specific routes your >customer is advertising will go to them and the rest will come to you. I >can't see that this would add any additional load to your router. > >andy It may not be that simple. I guess I should have mentioned that I don't route anything through Sprint. The only reason I've kept the Sprint circuit is to avoid re-IP-ing. Sprint isn't reliable enough to carry customer traffic. I do advertise the Sprint route, but I add a couple of hops to make sure the traffic goes through my "real" circuit.

2 1

Re: Stealth Blocking
by Richard A. Steenbergen 25 May '01

25 May '01

On Thu, May 24, 2001 at 05:47:41PM -0400, Mitch Halmu wrote: > > "Our users hated it - particularly those using MS Outlook" > > No need to describe what happens when your clients hate your service... Can't be any worse then what happens when you don't have any services that aren't blackholed. Can we find a new list for this now? :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: Stealth Blocking
by dlr＠bungi.com 25 May '01

25 May '01

[In the message entitled "Re: Stealth Blocking" on May 24, 9:46, "Eric A. Hall" writes:] > > Returning to operational traffic: > > > One thing that I think *will* help, particularly in the short term, is > > port 25 blocking of dialup ports. It's my personal opinion that this > > will have the greatest impact on spammers who abuse open relays. I've > > watched this happen over the last few months, as various large networks > > have secured their dialup ports. It's impressive. > > TCP rate-limiting on outbound traffic to *:25 would also be extremely > effective, particularly on unclassified customer traffic, and without the > heavy-handed nature of denying all dial-up traffic. Rate-limiting doesn't > interfere with low-volume legitimate mail, but it really cramps spam. > I'm not sure how effective rate limiting will be. Many spammers send one copy of the spam to an open relay, but use many (2 to 50) recipients. I'm unaware of a product that could limit (say) based on the number of connections from a given dialup port. Also, based on several providers information, one dialup account is being used by several, or many, spammer's machines at the same time, so even a per-IP port limit wouldn't have as much effect as you might think. One other way to do this might be to do port 25 blocking on new customers, but allow customers to get unblocked on request after they have been around a while... Isn't that the approach that AT&T used, to great success? It's also interesting to note that at least one dialup reseller actively markets to spammers, and attempts to negotiate unblocked dialups with the various providers. --

3 2