April 2003 - Test - lists.nanog.org

RE: Curing the BIND pain
by Michael.Dillon＠radianz.com 02 Apr '03

02 Apr '03

>Michael - one of the things that I am sure of is that this >life and in fact things on this earth are moving targets. >And what I see you saying here is "leave us alone - I want >it to stay the way it was"... Am I wrong and if so how? Uhh, do I have to say it again? If you want to change the world, create new protocols or build an working group on some topic or other, you really shouldn't try to do it on NANOG because it just ain't gonna work. What I want is irrelevant. NANOG is what it is and it isn't going to change much unless and until it fails to meet the needs of its "members". --Michael Dillon

1 0

RE: RFC3514
by Tomas Daniska 02 Apr '03

02 Apr '03

now that we have first implementation i think it's time for rob thomas to start monitoring who has deployed it and who not :))))) -- deejay > -----Original Message----- > From: bmanning(a)karoshi.com [mailto:bmanning@karoshi.com] > Sent: 1. apríla 2003 19:40 > To: nanog(a)nanog.org > Subject: Re: RFC3514 > > > > > > > Well, you weren't taking it seriously, I hope. lol > > > > > > -Jack > > ------------------------- > get it while its hot.... > ----------------- > > Subject: cvs commit: src/sbin/ping ping.8 ping.c src/share/man/man4 > inet.4 ip.4 src/sys/netinet in.h in_pcb.h ip.h ip_input.c > ip_output.c ip_var.h src/usr.bin/netstat inet.c > Date: Tue, 1 Apr 2003 00:21:44 -0800 (PST) > To: src-committers(a)FreeBSD.org, cvs-src(a)FreeBSD.org, > cvs-all(a)FreeBSD.org > > mdodd 2003/04/01 00:21:44 PST > > FreeBSD src repository > > Modified files: > sbin/ping ping.8 ping.c > share/man/man4 inet.4 ip.4 > sys/netinet in.h in_pcb.h ip.h ip_input.c ip_output.c > ip_var.h > usr.bin/netstat inet.c > Log: > Implement support for RFC 3514 (The Security Flag in the > IPv4 Header). > (See: ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt) > > This fulfills the host requirements for userland support by > way of the setsockopt() IP_EVIL_INTENT message. > > There are three sysctl tunables provided to govern system behavior. > > net.inet.ip.rfc3514: > > Enables support for rfc3514. As this is an > Informational RFC and support is not yet widespread > this option is disabled by default. > > net.inet.ip.hear_no_evil > > If set the host will discard all received > evil packets. > > net.inet.ip.speak_no_evil > > If set the host will discard all > transmitted evil packets. > > The IP statistics counter 'ips_evil' (available via > 'netstat') provides > information on the number of 'evil' packets recieved. > > For reference, the '-E' option to 'ping' has been provided > to demonstrate > and test the implementation. > > Revision Changes Path > 1.47 +4 -2 src/sbin/ping/ping.8 > 1.92 +13 -1 src/sbin/ping/ping.c > 1.21 +11 -0 src/share/man/man4/inet.4 > 1.29 +9 -0 src/share/man/man4/ip.4 > 1.75 +2 -0 src/sys/netinet/in.h > 1.59 +1 -0 src/sys/netinet/in_pcb.h > 1.22 +1 -0 src/sys/netinet/ip.h > 1.232 +14 -0 src/sys/netinet/ip_input.c > 1.181 +28 -1 src/sys/netinet/ip_output.c > 1.72 +1 -0 src/sys/netinet/ip_var.h > 1.57 +1 -0 src/usr.bin/netstat/inet.c > > > ----- End forwarded message: >

2 1

Global Crossing right now
by Peter Salus 02 Apr '03

02 Apr '03

Is anyone seeing peering problem with GBLX? We've seen peering problems on GBLX across NA. It's being felt by many of their peering partners and, in turn, being felt by many of our customers. We're sending a generic report to the effected customers and will try to get more info on the problem. The perf. losses started at approx 16:00 GMT and are ongoing. Peter --- "There is no way to peace, peace is the way." -- A.J. Muste ----------------------------------------------------------- Peter H. Salus Chief Knowledge Officer, Matrix NetSystems Ste. 300 5001 Plaza on the Lake Austin, TX 78746 +1 512 697-0613 -----------------------------------------------------------

4 3

Cogent?
by Deepak Jain 01 Apr '03

01 Apr '03

I haven't seen anyone mention this today, and I don't remember if this discussion was considered taboo, but oh well. Flame away. http://www.carrierhotels.com/news/April2003/cogent0401.shtml DJ

1 0

RFC3514
by Scott Francis 01 Apr '03

01 Apr '03

Comments? (Nice to see Mr. Bellovin keeping up the holiday tradition ... :)) -- Scott Francis || darkuncle (at) darkuncle (dot) net illum oportet crescere me autem minui

8 10

More Gifts for a CTO who has everything ...
by Eric Brunner-Williams in Portland Maine 01 Apr '03

01 Apr '03

This week's puzzle ... What is symmetry? The mail relay for a defunct ISP with some 20k users has between 100k and 200k instances of sendmail journaled per day. At any point in time, there are about 1k entries in the host's proctable, 80% are the MTA, and a few connections/sec to port 25, with default MTA rules for open-relays, blacklists, etc. The host is an E250, running Solaris 2.6, with historically problematic roll-your-own-RAID. The load average is nearly zero. iostat and vmstat show nominal load, only 700 users are actually "getting mail", and with a multi-day delay observed anectdotally. ... Asymetric dns (forward and reverse paths with differing SOAs), plus rate limiting at the access router for all forward maps, can result in serious disfunction. Fixing the CTO's dns brought the proctable count down to sub-100. For what it is worth, this is the most horked machine I've ever seen. I decided not to try and explain this one. >From the post to nanog of the 25th, "Gifts for a CTO who has everything ..." (nmap 10.0.0.0/8 has side effects) "Does life get any better than this" Best humor reply: Setup peering with a new provider that PROXY ARPs all your destinations. Second place (tie): LART the sucker, and the perenial foam bat. Best psychology reply: ... find a high-intensity clueino source? But clueinos interact very weakly with that sort of matter... The CTO's actual reply was "Do we have load that high? Were we being attacked by some script kiddies?? Very, very weak interaction. Cheers, Eric

1 1

FC: Colorado state senate delays vote on "mini-DMCA" bill
by Gregory Hicks 01 Apr '03

01 Apr '03

FYI... ------------- Begin Forwarded Message ------------- Date: Tue, 01 Apr 2003 10:15:36 -0500 To: politech(a)politechbot.com From: Declan McCullagh <declan(a)well.com> Subject: FC: Colorado state senate delays vote on "mini-DMCA" bill ---- Date: Mon, 31 Mar 2003 15:39:14 -0700 To: Declan McCullagh <declan(a)well.com> From: Charles Oriez <coriez(a)oriez.org> Subject: state DMCA - delayed in Colorado Thanks to the publicity on the politech list over the weekend, a couple of state senators heard from their constituents yesterday, and the Colorado version of the legislation (HB1303) was laid over for a week. It had been scheduled for final passage in the State Senate today. Of course now the folks who raised the issue in the first place have to finish the job. It isn't dead, merely delayed. http://www.leg.state.co.us/2003a/inetcbill.nsf/fsbillcont/A2F0DA113DF2BFC08… charles oriez coriez(a)oriez.org 39 34' 34.4"N / 105 00' 06.3"W ** --- Date: Mon, 31 Mar 2003 00:10:40 -0500 From: Peter Olsen <pcolsen(a)comcast.net> Subject: RE: An analysis of Michigan and Colorado "mini-DMCA" bills In-reply-to: <5.1.1.6.0.20030330100203.01f1db70(a)mail.well.com> To: declan(a)well.com Cc: balunis(a)buffnet.net, Charles Loukus <cloukus(a)earthlink.net>, Jon Christopher Olsen <joncolsen(a)bigfoot.com>, Eric Carl Olsen <olsenec(a)valero.com>, Seth Olsen <solsen(a)students.uiuc.edu>, Jeff Olsen <jolsen(a)c-hmfg.com>, Randy Olsen <rolsen(a)c-hmfg.com>, James Beaupre <beaupre(a)mit.edu>, Lou Marinelli <lmm1442(a)yahoo.com>, Ruben William Duran <duranr(a)umich.edu> Message-id: <000a01c2f743$df899340$0301a8c0@waldo> Declan, Although I'm not (and never have been) a lawyer, I think there is a danger of these laws becoming "charges of opportunity" Suppose someone is accused of another crime for which there is not sufficient evidence to sustain a charge, but law enforcement finds evidence of a VPN or a router employing network address translation. Would this evidence be enough to sustain a further search warrant? Suppose law enforcement authorities gain access to a computer for another purpose and find encrypted files. Could those files be construed as an attempt to conceal the "origin or destination of a communication service"? This last example brings up the problem of "If you're not guilty, prove your innocence. Just decrypt the files for us." I understand that this is a common tactic, even though it seems to fly in the face of my (engineering) understanding of the Fifth Amendment Take these comments for what they're worth. I have an agreement with some of my lawyer friends: I don't practice law and they don't practice engineering. We all believe the public is safer for both sides of the understanding. Peter Olsen, P.E. pc_olsen(a)yahoo.com --- Date: Sun, 30 Mar 2003 15:13:04 -0800 To: declan(a)well.com From: "A.Lizard" <alizard(a)ecis.com> Subject: Re: FC: An analysis of Michigan and Colorado "mini-DMCA" bills At 10:02 AM 3/30/03 -0500, you wrote: Sounds like making sure that this law is rigorously enforced against its biggest violators would be the fastest way to get it off the books and to make sure it doesn't get reintroduced anywhere else. The options for the organizations in violation would be either to close down or move to somewhere where they can do business. The biggest violators would be large corporations and the Michigan state government. Are there any IT shops of substantial size that *don't* violate this law? Collecting proof should be easy enough, but some organization to systematically tell the rest of us what to look for and where to send it would be helpful. Forcing government to act on this might be more difficult. Perhaps the EFF or one of the other activist organizations might have some ideas about that. A.Lizard --- Date: Sun, 30 Mar 2003 22:44:55 -0500 From: Dave Emery <die(a)die.com> To: Declan McCullagh <declan(a)well.com> Cc: cypherpunks(a)lne.com Subject: Re: FC: An analysis of Michigan and Colorado "mini-DMCA" bills On Sun, Mar 30, 2003 at 10:02:12AM -0500, Declan McCullagh wrote: There is another side to the MPAA's super-DMCA state legislation. In addition to its impact on use of encryption, vpns, firewalls and so forth it also sets forth new non-federal restrictions on possession and used of radio receiving equipment. While some of your readership may have different perspectives on this, it appears that several of these mini=DMCA bills might well be read to ban ownership or use of Big Ugle Dish (BUD) type TVRO satellite dish setups, or at least those used for private viewing of unscrambled sports backhauls and newsfeeds as opposed to being subscribed to scrambled programming services. This private viewing has been generally legal under federal law (Satellite Viewers Rights Act), but very few of the program providers have actually given any kind of express consent for the public to watch and thus the mini-DMCA provisions requiring such consent would possibly render even possession of such dishes illegal in states where such laws are in effect. And while the argument is more stretched, it also seems that someone might argue that police scanners used to monitor public safety communications (expressly permitted under federal law) might fall under this rubric too, as the public safety agencies may not have give express consent. Under the Mass. bill this would criminalize mere possession of such radio equipment. -- Dave Emery N1PRE, die(a)die.com DIE Consulting, Weston, Mass 02493 PGP fingerprint 1024D/8074C7AB 094B E58B 4F74 00C2 D8A6 B987 FB7D F8BA 8074 C7AB ------------------------------------------------------------------------- POLITECH evening reception in New York City at 7 pm, April 1, 2003 at CFP: http://www.politechbot.com/events/cfp2003/ ------------------------------------------------------------------------- POLITECH -- Declan McCullagh's politics and technology mailing list You may redistribute this message freely if you include this notice. To subscribe to Politech: http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ Declan McCullagh's photographs are at http://www.mccullagh.org/ Like Politech? Make a donation here: http://www.politechbot.com/donate/ ------------------------------------------------------------------------- ------------- End Forwarded Message ------------- ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks(a)cadence.com "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. Just because "We've always done it that way" is not necessarily a good reason to continue to do so... Grace Hopper, Rear Admiral, United States Navy

1 0

RE: State Super-DMCA Too True
by Kuhtz, Christian 01 Apr '03

01 Apr '03

> > In other words, you reasoning is quite flawed the way I see it, and > > blocking DoS is indeed legitimate and legally supportable. Excesses > > are rarely protected by any legal statutes. > > To the extent a customer attacks or defrauds the carrier itself, protection > measures are allowed. But you cannot "protect" the public at large without > a court order to do so. I think that's what I said. "excesses are rarely protected by any legal statutes." Any response must be measured by a given cause. ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."

1 0

RE: Curing the BIND pain
by Michael.Dillon＠radianz.com 01 Apr '03

01 Apr '03

> and then send it to the IETF's DNS WG's as a request. >Tell them what you need to accomplish and not how to do it, >and they will build a protocol to satisfy this request Really!? "They" will build a protocol for us!?!?!? And just who do you think the IETF are, hmmm? Reminds me of the Pogo cartoonist Walt Kelly who said, "We have met the enemy and he is us!". May I suggest that all this advice about what "we" should be doing is rather out of place on the NANOG list. This list is to discuss Internet operational stuff that impacts North American Network Operators. Operational stuff is usually technical and it usually is here and now rather than some indeterminate point in the future. This isn't the rules of NANOG, it's just the way things are around here. Anything that falls too far outside of this core focus just doesn't get the list fired up enough to do anything beyond talk and complaining. If you want to change the world, create new protocols or build an working group on some topic or other, you really shouldn't try to do it on NANOG because it just ain't gonna work. You may think that NANOG is in a rut and that's quite true but it is a comfortable rut and one that provides enough benefit to the NANOG participants to keep it going more or less the same way as it has for years. There definitely is room in the world for all of the things that have been discussed recently, it's just that NANOG isn't a particularly fruitful place to discuss them because you won't find enough recruits here to form a critical mass. If you truly are serious about some of these things then you will take the discussion off the NANOG list and make a serious effort to create a working group with a real action plan. Anything else is just posturing and we've seen it all before. It does not impress us. Thanks, --Michael Dillon P.S. No, I'm not the NANOG police; I'm just stating my opinion.

2 1

RE: State Super-DMCA Too True
by Kuhtz, Christian 01 Apr '03

01 Apr '03

> From: Stephen Sprunk [mailto:stephen@sprunk.org] [..] > Common carrier status exists for this very reason. Unfortunately, it > probably means we'll have to stop filtering things like spam and DoS, since > filtering on content inherently violates common carrier protection -- see > the smut suit against AOL a few years ago. Come on, don't go lumping DoS and smut into the same basket. You can't be possibly serious about considering the two to be equals. In other words, you reasoning is quite flawed the way I see it, and blocking DoS is indeed legitimate and legally supportable. Excesses are rarely protected by any legal statutes. Thanks, Christian ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."

5 9