- NANOG - lists.nanog.org

NANOG MEETING UPDATE
by Pam Ciesla 27 May '97

27 May '97

The attendee list for the June NANOG Meeting in Tampa has been updated. The registration cut-off date is Wednesday, May 28th. Registration and payment is due by the 28th. Registration & payment recieved after this date will be $120. There is a $20 charge for any cancelations recieved after the 28th. Please note that checks sent on or before the 28th but recieve after the 28th will be accepted at the $100 fee. If you are not sure of your registration status please check the attendee list on the nanog web page. Any problems let me know. Thanks xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

Re: Murkowski anti-spam bill could be a problem for ISPs
by Russell Nelson 26 May '97

26 May '97

Matthew James Gering writes: > Unauthorized use of mail relays is already illegal -- no explicit law is > necessary to make it so. Unauthorized use of mail relays is already preventable. Why legislate against something (which merely establishes a penalty for it) when you can stop it from happening, cold. Just install qmail -- by default it prevents relaying. http://www.qmail.org. [ For the sake of truth, I run that site, and I also provide commercial support for qmail -- but I do both of those because qmail helps stop spam. ] -- -russ <nelson(a)crynwr.com> http://www.crynwr.com/~nelson Crynwr Software sells network driver support | PGP ok 521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom: Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)

2 1

Re: Murkowski anti-spam bill could be a problem for ISPs
by Matthew James Gering 26 May '97

26 May '97

The problem with spam is not the inability of persons and companies to create policies, but to enforce those policies due to to the inability to identify spam, and measures taken to prevent its identification. We do not need government to create policies for us, and the goverment has no additional ability to enforce policy except through the use of force (police, courts, guns). Unauthorized use of mail relays is already illegal -- no explicit law is necessary to make it so. Forgery of headers to falsely implicate an innocent party is already illegal -- no explicit law is necessary to make it so. I oppose any explicit goverment regulation of the Internet, good intentions or not. The governments hold no particular control over the Internet itself (except US, which cannot practically excercise it) -- geographic borders are too easily circumvented. Regulation based on the geographic location of information and equipment creates an influence that opposes efficiency in Internet traffic, routing, caching, etc. The top-level power in the Internet derives from the delegation TLD's, IP space, and the policies and peering contracts of the default-free tier 1 providers. This is global and unescapable. Where it involves purely technical issues to insure the continued viability and operation of the Internet, this is where regulation should derive from. It must be technical, unbiased and non-judgemental. Putting aside where and who regulates, the only thing that is necessary to solve them problem is as follows: * reinforcement of the illegality of unauthorized use mail relays * reinforcement of the illegality of header forgery to implicate an innocent party. And in the effort to allow the identification of spam, a required SMTP header: precedence: [ high | normal | low | bulk | uce ] This will allow policies to be enforced, and maintain the freedom of creating that policy. Matt

2 1

Re: Murkowski anti-spam bill could be a problem for ISPs
by Dave O'Shea 24 May '97

24 May '97

---- From: John R Levine <johnl(a)iecc.com> To: nanog(a)merit.edu Date: Friday, May 23, 1997 10:02 PM Subject: Murkowski anti-spam bill could be a problem for ISPs >No, this isn't a rant about spam. It's about a misguided anti-spam >bill that puts potentially onerous rules on every ISP in the country. > >Sen. Frank Murkowski of Alaska filed a bill earlier this week that's >intended to solve the spam problem. His intentions are clearly good, and >based on his press release, he seems to understand many of the issues, >but his bill is very unfortunate. It says: > >* Commercial e-mail must be tagged with "advertisement" Delightful! /advertisement/j to all of 'em. >* All ISPs must provide tag filtering on inbound mail If the ISP maintains your e-mail account, this seems like a simple patch to sendmail or popd. If, by "ISP" you mean "anyone who provides a circuit", obviously much more difficult. >* Commercial e-mail must provide a real return address, and accept remove > requests. They have 48 hours to act on a remove request. Given that virtually all e-spammers are simply unemployable trash, this seems pointless. >* The FTC can discipline misbehaving ISPs. Makes sense, if the ISP actually takes part in the transaction, rather than simply forwarding packets. >* Various penalties for unsigned ads, for ISPs that don't provide > filtering, for spammers who continue to send ads after receiving a remove. I'm not thrilled about having to muck around with mail forwarding, but if there was an impetus to do it, and sandards were established, it would be fairly simple. On the other hand, I get a nice little warm feeling from slapping some sh*t-fer-brains in Miami with a summons & complaint demanding liquidated damages of $50,000,000. There are advantages to having a legal department that fills an entire floor. :-) > >There's a press release and a full copy of the bill on the senator's web site >at http://www.senate.gov/~murkowski/press/EMail052197.html > >Seems to me that if this were enacted into law, it'd be bad news for ISPs, >since the volume of spam would increase (since it'd be officially legal) and >ISPs would have to provide filtering on mountains of inbound spam. And, of >course, opt-out lists don't work. Can't see it. If you can perform effective filtering, the spam would almost certainly decrease. Opt-out lists would be fairly redundant. >People say they've been talking to Murkowski, he's amenable to argument and >will probably revise his bill next week. If you think this bill would affect >your business (he's a pro-business conservative Republican, after all), it's >worth a phone call. Sounds like it is.

1 0

Re: Congestion control/QoS
by Vadim Antonov 24 May '97

24 May '97

Dirk Harms-Merbitz <dirk(a)orlando.power.net> wrote: >Seems to me that a good way of limiting damage from runaway >networks/hosts would be a modifaction of RED (Random Early >Drop). >Controlled Early Drop (CED? I just made this up, suggestions?) >would allow a router to give a preference to connected >networks/hosts. Packets from certain networks would have a higher >chance of being dropped from a router queue then packets from >other networks. This is a packet classification problem. Here's a fragment from a test configuration file for my boxes-as-being-developed: ------------------------------------------------------------- ip-classifier FILTER1 { if( srcaddr = [192.40.77.20 : 192.40.77.90] and ((proto = tcp and srcport <> [smtp, telnet, 512]) or (proto = udp and dstport = domain)) ) { priority-select { 0: class PRIORITY 1,2: { if( tos = bulk ) blackhole goto l1 } } reject } if( tos = [interactive, bulk, 017] ) class INTERACTIVE l1: if( dstaddr = 199.0.55.1 and tcp-syn ) reject class ROUTINE } ip-classifier DEFAULT { priority-select { 0: class ROUTINE 1: class PRIORITY } class INTERACTIVE } interface E1021-0 { description "PL126612 to Joppa, MD" bandwidth 0.1G ip-address 144.227.0.11/24 ip-secondary 199.0.88.11/24 keepalive no out-ip-classifier FILTER1 out-class ROUTINE { bandwidth 0.5% ; priority 4 } out-class PRIORITY { bandwidth 20% ; priority 5 } out-class INTERACTIVE { bandwidth 1M ; priority 7 } ip-peer 144.227.0.12 { out-ip-classifier DEFAULT } ip-peer 144.227.0.50 { mac-address 01.29.00.11.91.21 } } interface X123 { load-share [E1021-0, E1021-1, E777-0] } ------------------------------------------------------------- Are you netgeeks salivating yet? :) --vadim

2 1

Top Level Domain Servers
by Curt Howland 23 May '97

23 May '97

Afternoon, all, After reading the commentaries about top level domain servers and their reality or mythical status, I went on a search of a list of the present "." and top-level servers. Well, no luck. I searched the RFC's, resource pages, IETF.org and IANA.org pages, nada. I tried to RTFM, but couldn't find the FM. I know the list exists, I saw it years ago and someone quoted such a list on this NANOG mailing list a day or two ago. So, if someone would be kind enough to mail me a link to this most essential of services, I would be grateful. I appologize in advance for poluting the NANOG list with yet more actual operational questions. Curt- Howland(a)ConXioN.com

3 2

Re: Top Level Domain Servers
by Carl Oppedahl 23 May '97

23 May '97

At 01:54 PM 05/23/97 -0700, Curt Howland wrote: > >After reading the commentaries about top level domain servers >and their reality or mythical status, I went on a search of a >list of the present "." and top-level servers. > >Well, no luck. I searched the RFC's, resource pages, IETF.org >and IANA.org pages, nada. I tried to RTFM, but couldn't find >the FM. > >I know the list exists, I saw it years ago and someone quoted >such a list on this NANOG mailing list a day or two ago. <http://www.patents.com/nsi/roots.sht>

2 1

RE: Top Level Servers...
by Robert Wilson 23 May '97

23 May '97

Isn't it nice to feel like part of the community?!?!.... > ---------- > From: Curt Howland[SMTP:howland@conxion.com] > Sent: Friday, May 23, 1997 2:13 PM > To: nanog(a)merit.edu > Subject: Top Level Servers... > > > Many thanks to those who replied without the heavy > "fucking moron..." attitude. > > Curt- >

1 0

Top Level Servers...
by Curt Howland 23 May '97

23 May '97

Many thanks to those who replied without the heavy "fucking moron..." attitude. Curt-

1 0

Re: We are not hearing the route to your SNEWS server.
by Joe 23 May '97

23 May '97

The following is a copy of communications we have had with AGIS. I think this extended "outage" at CIX, and unwillingness to peer at other points for the benefit of their own customers, is symptomatic of more things to come. ============================================================================ =============== >Date: Fri, 23 May 1997 12:36:51 -0700 >To: georgey(a)agis.net >From: Joe <joe(a)zippo.com> >Subject: Re: We are not hearing the route to your SNEWS server. >Bcc: ddrex(a)netplus.net, kr(a)crl.com > >Hi George, > >This is not intended to fuel an already aggravated situation, but only to offer some exchange of information. Kendall is obviously frustrated in not being able to resolve this issue with AGIS, but if you look at the substance of his communication, I think there is a pretty clear message. In light of the long term outage of AGIS based CIX equipment, why wouldn't AGIS peer at another point ? > >Once again, if there is more to this story I'd like to know. We communicate via CRL through many peering points to virtually every location on the Internet. AGIS is the only one that is unreachable and forcing peering through CIX. It would seem that even with AGIS CIX equipment up, you're forcing your internal traffic to run through your network to get to CIX rather than peering out at the closest point. The result is more traffic on your own network. > >It's a little difficult to believe a major Internet service provider such as AGIS would have a 4 day outage at a NAP that could not be repaired. > >It seems to me that the service you are selling is suppose to provide full Internet access to your users. Every time you limit access to other Internet locations, you diminish the value of your service by reducing the content your users have access to. You are providing less than full Internet access. Starting to look like you are trying to go to where AOL was two years ago, with your customers relying on intra AGIS services to provide all of the content. > >When you cut connection with CRL, you broke commercial arrangements between your own ISPs and services they have secured for their own customers. I can only request that AGIS works with CRL to establish a more reasonable level of peering. CRL is a quality organization and one that can only add to the value of the service AGIS offers to its customers. > >Joe > > >>Date: Fri, 23 May 1997 11:35:52 -0700 (PDT) >>From: Kendall Holback <kh(a)crl.com> >>To: Joe <joe(a)zippo.com> >>Subject: Re: We are not hearing the route to your SNEWS server. >> >>Joe, >> >>Thanks for the input from your customers. This helps in getting people to >>move on resolving problems like this. For the last several months we have >>made numerous attempts to establish peering with AGIS (other than at the >>CIX) and have had little or no response from them. We actually maintain >>peering at more peering points and NAPs than AGIS and we have full peering >>with every other major network aside from AGIS. Sometimes, it takes >>a barrage of complaints directly from customers to a certain provider in >>order for them to move on an issue like this. I realize this is >>ridiculous and we have made every attempt to put the politics aside >>and get it resolved, but unfortunately this is the way some organizations >>operate. If AGIS is not supporting their connecitvity to the CIX and is not >>making any effort to establish alternative peering, then they are not to be >>considered a first-tier Internet Service Provider and do not have >>connnectivity to the entire Internet. We are currently announcing all of >>our networks at all peering points - AGIS is choosing not to accept >>them. I strongly encourage any person/organization that is affected by >>this to contact AGIS directly (as this customer has done) and voice their >>dissatisfaction. If possible, please Cc me as well. >> >>--Kendall >> >>================================================================== >>Kendall Holback phone: (415) 837-5300 x122 >>CRL Network Services fax: (415) 392-9000 >>kh(a)crl.com >> >>> >Date: Fri, 23 May 1997 10:19:02 -0700 >>> >To: George Yedinak <georgey(a)agis.net> >>> >From: Joe <joe(a)zippo.com> >>> >Subject: Re: We are not hearing the route to your SNEWS server. >>> >Bcc: ddrex(a)squid.netplus.net >>> >In-Reply-To: <3.0.32.19970523080201.0091a9f0(a)agisgate.agis.net> >>> > >>> >Hi George, >>> > >>> >Good to hear from you. We have received a lot of e-mail from retail and >>> commercial accounts in regard to the issue (e-mail is on Netcom) and I >>> wasn't sure who to contact at AGIS. >>> > >>> >Our upstream provider is CRL. In discussions with them they have indicated >>> they only peer with AGIS at CIX and, since there is a hardware outage, AGIS >>> custmers cannot get through. CRL went on to say they have not been able to >>> get AGIS to peer at any of the other NAPs CRL currently connects through. >>> > >>> >I'd really like to take this out of political context and see if we can >>> get this resolved. If there is anything we can do in communicating with our >>> upstream provider, or anything we can do here, just let us know. We only >>> want to restore service to the people that have used the service for a long >>> time. >>> > >>> >Joe >>> > >>> >At 08:02 AM 5/23/97 -0400, you wrote: >>> >>Joe, >>> >> >>> >> I have received an e-mail from a customer of ours who is not able to reach >>> >>your snews site. I tried to see if we heard any routes to the site, and we >>> >>do not. If you could contact your upstream provider and see if they are >>> >>announcing this to us, we would be very appreciative. >>> >> >>> >> George Yedinak >>> >> AGIS Network Operations. >>> >> >>> >>==================================== >>> >>From: David Drexler <ddrex(a)squid.netplus.net> >>> >>Subject: Customer support request >>> >>To: noc(a)agis.net >>> >>Date: Fri, 23 May 1997 06:14:16 -0500 (CDT) >>> >> >>> >>Certain destinations through the chicago router have been unreachable for >>> >>over 24 hours now. For example: >>> >> >>> >>traceroute to snews.zippo.com (207.211.168.98), 30 hops max, 40 byte packets >>> >> 1 irx1 (206.250.192.1) 1.612 ms 1.478 ms 1.412 ms >>> >> 2 agis-netplus.chicago2.agis.net (205.254.172.69) 47.677 ms 44.711 ms >>> >>42.783 ms >>> >> 3 * agis-netplus.chicago2.agis.net (205.254.172.69) 106.251 ms !H * >>> >> >>> >>We know that you know -- there's already been discussion of it in the >>> >>mailing list. >>> >> >>> >>What we want to know is why it's taking so long to fix, and when we can >>> >>expect it will be resolved. This problem is impacting us severely. >>> >> >>> >>Please assign a ticket number and reply. >>> >> >>> >>Thank you. >>> >> >>> >>David >>> >>______________________________________________ >>> >>Technical Support voice: (405) 848-4424 >>> >>Internet Access Plus fax: (405) 840-9604 >>> >>Oklahoma City ddrex(a)netplus.net >>> >> >>> >>====================================== >>> >> >>> >> >>> >>Thank You. >>> >> >>> >>-- >>> >>========================================= >>> >> George Yedinak - NOC Technician >>> >> Apex Global Internet Services, Inc. (AGIS) >>> >> >>> >>Network Operations Center - 24x7 Emergency Line (313) 730-5151 >>> >> Business Office/Sales - (313)730-1130 sales(a)agis.net >>> >>========================================= >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>

1 0