May 2001 - Test - lists.nanog.org

New in-addr.arpa release
by ARIN IN-ADDR Role 25 May '01

25 May '01

On May 17, ARIN announced that it would be making changes to the way it produces the in-addr.arpa zone file. Comments on these changes have been minimual. Most were questions addressing specific networks, or were statements of approval. Therefore, ARIN will proceed with implementation on June 1. If you are concerned about possible impact on your networks, please review examples of the changes to occur at: http://www.arin.net/inaddr/ If you still have concerns after reviewing these examples, please direct specific questions about your networks to inaddr(a)arin.net. Regards, Ginny Listman Director of Engineering ARIN

1 0

RE: EMAIL != FTP
by Roeland Meyer 25 May '01

25 May '01

> From: Greg Maxwell [mailto:gmaxwell@martin.fl.us] > Sent: Friday, May 25, 2001 6:25 AM > Web browsers will only display 'funny characters' for .zip > files if they > don't have their mime-types sufficently configured. Right ... and you're going to go out an reconfigure every one of them for me .. right?

1 0

RE: Stealth Blocking
by Roeland Meyer 25 May '01

25 May '01

The original message never made that distinction. > -----Original Message----- > From: Shawn McMahon [mailto:smcmahon@eiv.com] > Sent: Friday, May 25, 2001 4:30 AM > To: nanog(a)merit.edu > Subject: Re: Stealth Blocking > > > On Thu, May 24, 2001 at 08:04:34PM -0400, Jason Slagle wrote: > > > > And, as a business we wouldn't divert you. This is only a > solution for > > Resi accounts. > > You do realize, I assume, that if somebody thinks he's sending email > directly to a certain server, and you divert it to another server, > you're intercepting it under the terms of the Electronic > Communications > Privacy Act of 1986? > > That's allowed if it's necessary to provide the service, but good luck > winning on that argument with the plaintiffs trotting out > witnesses stating > it's not necessary, just your choice. > >

1 0

RE: EMAIL != FTP
by Robert Blayzor 25 May '01

25 May '01

> along the car driving vein: > > i wonder if automobile engineers have a list to vent about the incredible > inefficiency of modern cars, and why people buy these huge vehicles called > SUV's that consume far more fuel than a much smaller yet useful > car. i bet they > also wonder why people sit for an hour+ in traffic in many parts > of the country > to take overcrowded bridges, highways and tunnels to get > somewhere that many > of them really dont want to be. There are solutions to nearly every problem, but people often don't do the right thing because it is such a major inconvenience to them. People often just don't take the time to do things right or learn how to do them right. But in both cases it comes down to people either not having the knowledge, ignorance, or people simply just don't care. -- Robert Blayzor IP Network Engineer, BOFH BiznessOnline.com, Inc. rblayzor(a)thebiz.net noc(a)thebiz.net http://www.thebiz.net/ FreeBSD, Putting the 'Operating' back into OS! -- http://www.freebsd.org/

1 0

RE: Stealth Blocking
by Roeland Meyer 25 May '01

25 May '01

> From: Jason Slagle [mailto:raistlin@tacorp.net] > Sent: Thursday, May 24, 2001 12:57 PM > We tell users that if they roam they need to use the mail > server of the place they are roaming to. Not without an NDA from us, you're not. Corp traffic stays on corp servers and anyone diverting it elsewhere will get a sharp phone call from our legal department. It'll be called industrial espionage. Kashpureff went to jail for something similar. Of course, we usually use PPTP. > As a matter of fact, we are in the process of setting up a > set of rules to > divert all port 25 bound traffic on our dialups to local mail servers. Is this your actual place of business? I will make sure that our account reps are not allowed to use your service or POPS, whilst on the road. Also, since I'll be doing business with your competition, I'll clue their marketing departments in on this wonderful opportunity for them. Since this will also prevent your downstreams from running their own SMTP servers (which more than one of them probably are), you will probably lose them as well. > If everyone diverted all local traffic to a local mail > server, the problem of open relays would go away. Problems usually go away when the customers do... You probably should talk to your marketing and legal folks, before going quite that far.

3 3

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