- Test - lists.nanog.org

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

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

01 Apr '03

Let's assume that BIND has a way to know when it is dangerously out of date. The mechanism used would be up to ISC and I'll admit that it would probably involve some sort of DNS records in an ISC-run domain because that's the only way that has a high likelihood of working given the number of firewalls and caching nameservers that may be between a given BIND box and ISC. Seems to me that ISC has always maintained that there are two version numbers, one 4.x and one 8.x, that are always the oldest ones you can run and still be secure against known exploits. So the info stored in the ISC DNS server really doesn't need to be more than those two version numbers. OK, now assume that we have a BIND server which has detected that it is out of date and at risk of attack. What should it do? Well, first of all, what would a human being do if if realised that it was at risk of attack and they had no means of contacting their friends or the police. A child might cry out and an adult might yell for help in case someone was near enough to hear. BIND is in a similar situation. It doesn't know if there is anyone looking after it but it is hurting, so let's make it cry out. I suggest that an appropriate technique would be for the BIND server to originate traffic on it's local subnet that would look suspicious and possibly trigger intrusion alarms. Send out some packets to the broadcast address. Do some portscanning of all addresses on the subnet. Find any open port 80 and retrieve a URL containing BIND/server/at/10.7.7.1/has/security/vulnerability, find any open port 25 and send email to postmaster containing the same message, etc. Not enough traffic to be a DoS but enough to show up in various logs in case someone is looking at some of them. Even then, this is still a string and sealing wax solution. It's situations like this that demonstrate just how primitive our supposedly high technology really is. --Michael Dillon

4 3

Re: [internet.com]
by Joshua Smith 01 Apr '03

01 Apr '03

"Michael Painter" <tvhawaii(a)shaka.com> wrote: > > Anyone else having trouble with reaching internet.com via genuity? > i've heard that level3 is doing some work to re-AS genuity - didn't really pay attention to when it started or how long it would be going on, but it may be part of the reason > Pinging 63.236.73.147 with 32 bytes of data: > > Reply from 4.25.112.2: TTL expired in transit. > Reply from 4.25.112.2: TTL expired in transit. > Reply from 4.25.112.2: TTL expired in transit. > Reply from 4.25.112.2: TTL expired in transit. > > Ping statistics for 63.236.73.147: > Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), > Approximate round trip times in milli-seconds: > Minimum = 0ms, Maximum = 0ms, Average = 0ms > > "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

internet.com
by Michael Painter 01 Apr '03

01 Apr '03

Anyone else having trouble with reaching internet.com via genuity? Pinging 63.236.73.147 with 32 bytes of data: Reply from 4.25.112.2: TTL expired in transit. Reply from 4.25.112.2: TTL expired in transit. Reply from 4.25.112.2: TTL expired in transit. Reply from 4.25.112.2: TTL expired in transit. Ping statistics for 63.236.73.147: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

5 6

Evil Intent
by Baldwin, James 01 Apr '03

01 Apr '03

ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt Have a merry April NANOG.

1 0

Re: internet.com
by Michael Painter 01 Apr '03

01 Apr '03

Tracing route to 63.236.73.147 over a maximum of 30 hops 1 31 ms 47 ms 32 ms adsl-linking.flex.com [10.20.124.1] 2 32 ms 31 ms 47 ms s5-9.hnllhi1-cr3.bbnplanet.net [4.25.157.41] 3 78 ms 94 ms 78 ms p3-0.lsanca2-cr3.bbnplanet.net [4.0.7.69] 4 78 ms 94 ms 78 ms p1-0.lsanca2-br1.bbnplanet.net [4.0.7.58] 5 93 ms 78 ms 79 ms p1-0.lsanca2-cr2.bbnplanet.net [4.25.112.1] 6 94 ms 78 ms 94 ms p0-0.lsanca2-br1.bbnplanet.net [4.25.112.2] 7 78 ms 79 ms 93 ms p1-0.lsanca2-cr2.bbnplanet.net [4.25.112.1] 8 93 ms 78 ms 79 ms p0-0.lsanca2-br1.bbnplanet.net [4.25.112.2] 9 94 ms 78 ms 78 ms p1-0.lsanca2-cr2.bbnplanet.net [4.25.112.1] [snip] 28 78 ms 93 ms 94 ms p0-0.lsanca2-br1.bbnplanet.net [4.25.112.2] 29 79 ms 93 ms 94 ms p1-0.lsanca2-cr2.bbnplanet.net [4.25.112.1] 30 78 ms 94 ms 78 ms p0-0.lsanca2-br1.bbnplanet.net [4.25.112.2] ----- Original Message ----- From: "Joe" <joej(a)rocknyou.com> To: "Michael Painter" <tvhawaii(a)shaka.com> Sent: Monday, March 31, 2003 5:38 PM Subject: Re: internet.com > Don't know about Genuity, but from ATT no expires but an unusual response: > ping internet.com > PING internet.com (63.236.73.147) from 192.168.1.2 : 56(84) bytes of data. > >From 63.236.93.180 icmp_seq=1 Packet filtered > > --- internet.com ping statistics --- > 16 packets transmitted, 0 received, +1 errors, 100% loss, time 15005ms > > Traceroute dies too: > 6 tbr1-p013401.cb1ma.ip.att.net (12.122.11.193) 13.934 ms 14.451 ms > 13.535 > ms > 7 tbr2-p013701.n54ny.ip.att.net (12.122.10.22) 17.536 ms 18.327 ms > 19.759 m > s > 8 gar4-p390.n54ny.ip.att.net (12.123.3.6) 22.599 ms 17.816 ms 18.772 ms > 9 att-gw.ny.qwest.net (192.205.32.170) 18.239 ms 19.638 ms 18.117 ms > 10 jfk-core-02.inet.qwest.net (205.171.230.22) 18.086 ms 18.516 ms > 18.724 ms > 11 ewr-core-01.inet.qwest.net (205.171.8.245) 17.110 ms 18.815 ms 22.078 > ms > 12 ewr-cntr-01.inet.qwest.net (205.171.17.146) 21.773 ms 20.730 ms > 17.912 ms > 13 msfc-22.ewr.qwest.net (63.146.100.34) 19.377 ms 17.880 ms 20.138 ms > 14 63.236.93.180 (63.236.93.180) 24.246 ms !X * * > 15 * > > Odd > -Joe > > ----- Original Message ----- > From: "Michael Painter" <tvhawaii(a)shaka.com> > To: <nanog(a)merit.edu> > Sent: Monday, March 31, 2003 10:21 PM > Subject: internet.com > > > > > > Anyone else having trouble with reaching internet.com via genuity? > > > > Pinging 63.236.73.147 with 32 bytes of data: > > > > Reply from 4.25.112.2: TTL expired in transit. > > Reply from 4.25.112.2: TTL expired in transit. > > Reply from 4.25.112.2: TTL expired in transit. > > Reply from 4.25.112.2: TTL expired in transit. > > > > Ping statistics for 63.236.73.147: > > Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), > > Approximate round trip times in milli-seconds: > > Minimum = 0ms, Maximum = 0ms, Average = 0ms > > >

1 0

Re: [RE: State Super-DMCA Too True]
by Joshua Smith 01 Apr '03

01 Apr '03

"todd glassey" <todd.glassey(a)worldnet.att.net> wrote: > [cut] > > If you ship pot via FedEx, does the delivery guy go to jail > too? > > THIS IS A REALLY BAD EXAMPLE - not really, did the us postal service get in trouble for delivering anthrax laden letters? no. if someone at the post office bypassed the postal inspectors to 'hand deliver' those letters, then that person will be in trouble, not the entire office. > > No. > If you make obscene phone calls, does the operator go to > jail too? > > DEPENDS ON WHETHER THEY DIALED THE PHONE FOR YOU. > operator - "what city and state please" you - mumble mumble mumble operator - "here is the number, thank you for using $telco" i suppose there is a slight chance here, provided that same operator connected all of your repeated calls and then listened and knew you were being obscene, but kept connecting you anyway. > No. > > BUT IF YOUR AGENT OPENS THE PACKAGE TO INSURE THAT IT HAD A > CORRECT ADDRESS ON IT AND FINDS IT CONTAINS CONTRABAND - > THEN ARE THEY RESPONSIBLE? - BETTER YET - IF THEY OPENED THE > PACKAGE TO INSPECT THE DELIVERY ADDRESS AND THEN REFUSED TO > APPLY ANY DILIGENCE ON THE PACKAGES PAYLOAD OR OTHER ADDRESS > DATA BEYOND THAT OF A LOCAL DELIVERY ADDRESS, MY TAKE IS > THAT THIS IS WHY THERE WILL BE SO MANY ADMIN'S IN JAIL IN > THE COMING YEAR OR TWO - WITH THEIR ATTITUDES, THEY MAY > OUT-NUMBER THE DRUNK DRIVERS IN CALIFORNIA PRISONS SOON. > if my 'agent' takes delivery of the 'package', that is essentially the same as if i signed for the package. if they don't know what is in it, and don't look, then they will probably not be charged with anything harsher than ignorance - if they look and participate, then yes, they will get in trouble too. > ANYWAY - THE OPENING OF THE MAIL TO DO ANYTHING INCLUDING > DELIVER IT OBLIGATES YOU TO MAKE SURE THAT ANY AND ALL THE > DATA REPRESENTED IN THE HEADER IS REAL AS WELL. IF YOU PARSE > THE RFC822 DATA TO PROCESS IT THEM PROCESS IT. THAT'S THE > POINT AND THAT THIS IS NOT AN OPTION UNDER THESE LAWS - ITS > JUST THAT TO DATE THE TIER-2/3 ISP'S HAVE NEVER BEFORE BEEN > THREATENED WITH JAIL FOR NOT GOING THE WHOLE ROUTE... > since when did a tier 2/3 carrier become the 'nanny' for naughty customers? just because they don't move quite as much data as a 'tier 1' means that they have the extra time and resources to read all of my mail to ensure that i am not doing anything naughty... > Common carrier status exists for this very reason. > > I WOULD ARGUE THAT THE ISP'S ARE BY DEFINITION NOT COMMON > CARRIERS. ONLY THE TIER-1 PROVIDERS WOULD BE CLASSIFIED AS > CC'S UNDER INTERNET DEFINITIONS, AND ANYONE THAT OPERATES > MORE THAN ONE TIER-1 SERVICE, AS IN A TIER-2 OR TIER-3 > OPERATION TOO, HAS A LARGER ISSUE THAT ALL OF THEIR > INFRASTRUCTURE LIKELY HAS TO COMPLY - > so what is a tier 1/2/3/4 carrier again? if these laws do not define each one explicitly, then the definition is arbitrary. if said definitions are published as operational requirements, then you might have a case... > Unfortunately, it > probably means we'll have to stop filtering things like spam > and DoS, since > filtering on content inherently violates common carrier > protection -- > > NO - QUITE THE OPPOSITE - ACTUALLY WHAT IT MEANS IS THAT FOR > ANY SERVICE FOR WHICH YOU ARE THE ORIGINATING OR TERMINATION > ENTITY, THAT "THE DATA REPRESENTED IN ANYTHING YOU PROCESS > MUST BE RELIABLE AND TRUE". THAT MEANS IF YOU ACCEPT EMAIL > FROM SOMEWHERE AND PROFFER IT ONWARD TO YOUR CLIENT'S, AND > YOU DON'T BOTHER TO FILTER AND PROOF IT - THAT YOU STAND A > GOOD CHANCE TO "GET YOUR PEE-PEE WHACKED BY THE BAILIFF" - > TO QUOTE FROM CHEECH AND CHONG. > so i must now proof-read my customer's emails? i didn't realize that i was a secretary too (guess i should be charging more) - should i charge to spell-check by the word, sentence, or email? > see > the smut suit against AOL a few years ago. > > I KNOW - I WAS AN EXPERT WITNESS IN ONE OF THEM. I ALSO AM > THE INDUSTRY LIAISON TO THE AMERICAN BAR ASSOCIATION'S > INFORMATION SECURITY COMMITTEE, BUT I AM NOT AN ATTORNEY SO > IGNORE THIS IF YOU WANT. > yep, this is smut... ;-) > S > > Stephen Sprunk "God does not play dice." --Albert > Einstein > CCIE #3723 "God is an inveterate gambler, and He > throws the > K5SSS dice at every possible opportunity." --Stephen > Hawking > "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

2 1

RE: State Super-DMCA Too True
by todd glassey 01 Apr '03

01 Apr '03

Yes but this is specific to the argument on whether an ISP should be accountable for what people do with its bandwidth and what I think is ultimately going to happen is that these laws are going to be put in place and as part of enforcing these there will be some arrests. Now beyond that I don't know, but I am sure that being a co-conspirator to any number of illegal acts by facilitating them through what is set as the standard of "operational negligence", i.e. that what is generally expected of you, is still prosecutable. And when the first round of Network Admin's go to jail for being complicit in these frauds, the tunes regarding "hey you cant do this to us" will all vanish as your individual lawyers tell you to shut-up before contempt citations cost you more jail time. I wish this was different or that the general class of Admin's wasn't willing to fight this out - but after a few people wind up in jail, the general tune will change - I assure you. My one embedded comment in caps below "TSG -->" Todd Glassey -----Original Message----- From: Michael Loftis [mailto:mloftis@wgops.com] Sent: Monday, March 31, 2003 10:04 AM To: todd glassey; Robert A. Hayden; nanog(a)merit.edu Subject: RE: State Super-DMCA Too True Yah but that's all akin to asking hte telephone company to make a log of each and every phone conversation above and beyond billing records. Unless you get billed per-piece of e-mail, or per HTTP connection an ISP should have to nor need ot keep a log of that data and be legally compelled to divulge any of that. TSG --> EXCEPT THAT THEY BECOME A PARTNER TO THE DECEPTION BY THEIR FACILITIES CONTINUING TO FACILITATE THE FRAUD. LOOK - IT MAY NOT BE RIGHT - BUT IT IS WHAT'S COMING - SO DO YOU WANT TO BE READY FOR IT OR SLAMMED BY IT? TAKE YOUR PICK. TSG --> THE WORST PART IS IF SOMEONE IN ANOTHER STATE SENDS THIS ILLEGAL DATA GRAM TO YOU AND YOU FORWARD IT, YOU TECHNICALLY BECOME A CO-CONSPIRATOR IN WHAT CAN ONLY BE DESCRIBED AS "INTERSTATE FRAUD BY WIRE" AND THAT BRINGS THE FBI INTO IT POST HASTE. Just my $.02 TSG --> JUST MY $2. TSG --> Todd --On Monday, March 31, 2003 9:50 AM -0800 todd glassey <todd.glassey(a)worldnet.att.net> wrote: > > How about this - The issue is really one of the commission > of fraud and preventing it. So is NAT really an issue? I > think not. I think it may be part of the legislation but > that is because that the writers didn't have our input... > > So if you as an ISP have a good operating process model and > you log and sort your log data. What is the difference > between a log that shows a bunch of stuff moving to a DHCP > lease that was assigned to "xxx-yyyy" at "zz:zz" time on > "dd-mm-yyyy" day. And that this lease was issued to account > "blah" - then you have the most evidence that is available > over a TCP connection anyway. And its as good as the > testimony of the logs regarding that there was only one > address at the end of that pipe serviced. > > What I am saying is that any legislation preventing NAT is > ludicrous and in fact counter productive. What it needs to > be is legislation regarding how well ISP's have to audit > what their customers do. That's it. Nothing more. > > Look - what is the difference between the log data shown in > a scenario where I don't use NAT but instead use Microsoft's > Internet Sharing Feature in the Win2000 Servers? the answer > is simple. Poof NAT gateway. And so now it is illegal to use > a facility already distributed in every copy of MS Server > deployed in these states.... > > Look what this law-shtick is all about is the mandating that > ISP's know what their customers are doing data wise, on > their wires (the ISP's) and that's it. > > Todd Glassey > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On > Behalf Of > Robert A. Hayden > Sent: Sunday, March 30, 2003 7:34 AM > To: nanog(a)merit.edu > Subject: Re: State Super-DMCA Too True > > > > Can't NAT-like devices be just as viable as a security > device as well? > Is the ISP willing to take responsiblity for security > breaches on my home > network because they banned my firewall? From a > political/public-perception standpoint, treat those ISPs > that are > complaining about NAT as being soft on security and > encouraging hacking. > In todays paranoid political climate, there might even be > some milage > here. > > I have Charter pipeline in Madison, WI, and they've been > very open about > people using NAT devices to the point that they are > recommended in some > cases as security devices as well as being sold by Charter's > professional-services group as inexpensive firewalls. About > six months > ago I got a 1-page flier from Charter offering a 4-port > Linksys and an > on-site installation. > > Since a "NAT device" could include virtually any operating > system and any > PC with two or more ethernet ports, it might be better to > push the > "firewall" aspects of them rather than try to defend or > justify the > MANY-to-1 routing aspects of NAT. > >

4 5