RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
Jeff, In a nutshell you're saying do nothing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Ogden Sent: Thursday, August 22, 2002 7:42 AM To: [EMAIL PROTECTED] Subject: RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs? At 10:32 PM -0700 8/21/02, Nigel Clarke wrote: >However, this type of action might not be necessary at all. > >Some of the users on this list think RIAA's recent actions are nothing more >than empty threats. >Why doesn't NANOG make a few of its own? > >A "polite" letter from a NANOG representative should do the trick. Just to state the obvious, no one is authorized to represent NANOG in this fashion, not even folks here at Merit. NANOG isn't a decision making organization. NANOG isn't something that can take actions (other than holding a few meetings each year and managing this e-mail list). Individuals and organizations that participate in NANOG can take actions, but not in NANOG's name. I'm no lawyer, but I suspect that lawyers should be consulted before taking individual or coordinated action of the sort being suggested against another organization. Of course IPSs do take action against individuals or organizations all of the time, but they need to do that based on policies and procedures that take into account their obligations to their customers as well as their obligations under the law. As an end user I really don't want my ISP to make decisions about who is allowed to communicate with me or who I am allowed to communicate with except when those decisions are based on policies designed to protect me or others from serious problems (DDOS attacks and the like), even then I want those policies to be written and available so I can review them, and I want them to be applied fairly. As an ISP I really don't want my upstream ISPs to make decisions about who is allowed to communicate with my network or who my network is allowed to communicate with except under the conditions outlined in my agreements with those ISPs. This is important to me if I am in turn going to be able to meet my obligations to my own end users. So, I really don't want the RIAA to tell me or my upstreams who I can't communicate with, but neither do I want my upstreams to tell me that I can't communicate with the RIAA or the labels if I (or really my customers) want to do so. -Jeff Ogden Merit Network At 10:32 PM -0700 8/21/02, Nigel Clarke wrote: >However, this type of action might not be necessary at all. > >Some of the users on this list think RIAA's recent actions are nothing more >than empty threats. >Why doesn't NANOG make a few of its own? > >A "polite" letter from a NANOG representative should do the trick. > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of >J.A. Terranson >Sent: Wednesday, August 21, 2002 7:01 PM >To: Nigel Clarke >Cc: Richard A Steenbergen; Jerry Eyers; [EMAIL PROTECTED] >Subject: RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs? > >> On Wed, Aug 21, 2002 at 09:08:03PM -0700, Nigel Clarke wrote: >> > >> > Why don't larger ISPs follow through on this? Simply deny RIAA any >> > access... >> >> And what IPs precisely are you planning to deny? So far its all idle >> threats, we have no idea where they plan to launch their scans or hacking >> attempts from, or even if they have any clue how to hack anything. I > > highly doubt they'll be attaching riaa.com to it either. > >The blocking of any an all directly RIAA sites, feeds, etc, would >produce an economic reaction. Cut off their sales websites, their >basic connectivity (how much money do you think it would cost them >to go back to snail mail today?), their [few] subscription sites. > >Let the money do the work. > >Yours, > >J.A. Terranson >[EMAIL PROTECTED] > >* SPEAKING STRICTLY IN A PERSONAL CAPACITY * at this time anyway. >We'll see if we can't change that. Tomorrow. Goddamn right!
Re: sanity check frame question
> > I have a Frame connection between two sites, A and B. If the router > > crashes at B, wouldn't A still see the DLCI for > > B? Is there any scenario where this wouldn't be the case? If > > B gets blown off the map, shouldnt A's frame interface be > > in at least an up/down scenario? > > In theory, when the remote LMI goes down, or any part of the PVC internal to the > carrier goes down, the local LMI should go INACTIVE. In practice, this is > unreliable at best; for some carriers, you will always get ACTIVE status no > matter what. For a real frame relay (not the frame relay on customer end that terminates into the ATM circuit on your end) if you want the interface to go up/down or down/down when there is a problem on a line, you must configure frame relay using sub-interfaces. Works like a charm. Alex
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
At 10:32 PM -0700 8/21/02, Nigel Clarke wrote: >However, this type of action might not be necessary at all. > >Some of the users on this list think RIAA's recent actions are nothing more >than empty threats. >Why doesn't NANOG make a few of its own? > >A "polite" letter from a NANOG representative should do the trick. Just to state the obvious, no one is authorized to represent NANOG in this fashion, not even folks here at Merit. NANOG isn't a decision making organization. NANOG isn't something that can take actions (other than holding a few meetings each year and managing this e-mail list). Individuals and organizations that participate in NANOG can take actions, but not in NANOG's name. I'm no lawyer, but I suspect that lawyers should be consulted before taking individual or coordinated action of the sort being suggested against another organization. Of course IPSs do take action against individuals or organizations all of the time, but they need to do that based on policies and procedures that take into account their obligations to their customers as well as their obligations under the law. As an end user I really don't want my ISP to make decisions about who is allowed to communicate with me or who I am allowed to communicate with except when those decisions are based on policies designed to protect me or others from serious problems (DDOS attacks and the like), even then I want those policies to be written and available so I can review them, and I want them to be applied fairly. As an ISP I really don't want my upstream ISPs to make decisions about who is allowed to communicate with my network or who my network is allowed to communicate with except under the conditions outlined in my agreements with those ISPs. This is important to me if I am in turn going to be able to meet my obligations to my own end users. So, I really don't want the RIAA to tell me or my upstreams who I can't communicate with, but neither do I want my upstreams to tell me that I can't communicate with the RIAA or the labels if I (or really my customers) want to do so. -Jeff Ogden Merit Network At 10:32 PM -0700 8/21/02, Nigel Clarke wrote: >However, this type of action might not be necessary at all. > >Some of the users on this list think RIAA's recent actions are nothing more >than empty threats. >Why doesn't NANOG make a few of its own? > >A "polite" letter from a NANOG representative should do the trick. > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of >J.A. Terranson >Sent: Wednesday, August 21, 2002 7:01 PM >To: Nigel Clarke >Cc: Richard A Steenbergen; Jerry Eyers; [EMAIL PROTECTED] >Subject: RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs? > >> On Wed, Aug 21, 2002 at 09:08:03PM -0700, Nigel Clarke wrote: >> > >> > Why don't larger ISPs follow through on this? Simply deny RIAA any >> > access... >> >> And what IPs precisely are you planning to deny? So far its all idle >> threats, we have no idea where they plan to launch their scans or hacking >> attempts from, or even if they have any clue how to hack anything. I > > highly doubt they'll be attaching riaa.com to it either. > >The blocking of any an all directly RIAA sites, feeds, etc, would >produce an economic reaction. Cut off their sales websites, their >basic connectivity (how much money do you think it would cost them >to go back to snail mail today?), their [few] subscription sites. > >Let the money do the work. > >Yours, > >J.A. Terranson >[EMAIL PROTECTED] > >* SPEAKING STRICTLY IN A PERSONAL CAPACITY * at this time anyway. >We'll see if we can't change that. Tomorrow. Goddamn right!
Re: sanity check frame question
Thus spake <[EMAIL PROTECTED]> > I have a Frame connection between two sites, A and B. If the router > crashes at B, wouldn't A still see the DLCI for > B? Is there any scenario where this wouldn't be the case? If > B gets blown off the map, shouldnt A's frame interface be > in at least an up/down scenario? In theory, when the remote LMI goes down, or any part of the PVC internal to the carrier goes down, the local LMI should go INACTIVE. In practice, this is unreliable at best; for some carriers, you will always get ACTIVE status no matter what. ATM has a similar feature/problem with ILMI. The only solution is to ignore the carrier and do it yourself end-to-end (gosh, where have we heard that before?). End-to-End Keepalives for FR: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/wan_r/wr dfrely.htm#xtocid18 OAM Loopback for ATM: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/wan_r/wro ampvc.htm#xtocid0 > If the DLCI disappeared, doesn't that suggest that someone > deleted the PVC? Distinguish between INACTIVE and DELETED; those represent very different things in LMI. S
Re: IETF SMTP Working Group Proposal at smtpng.org
In my case it would be because my isp's has several of its own smtp server on many black hole lists for bring open relays. Luckily i have another domain i have access to but if i had to i would run a local SMTP server if i had no other opiton. May God Bless you and everything you touch. My "foundation" verse: Isiah 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. - Original Message - From: "Robert Blayzor" <[EMAIL PROTECTED]> To: "'Jeff Shultz'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, August 21, 2002 3:54 PM Subject: RE: IETF SMTP Working Group Proposal at smtpng.org > > > I'm not a company, I'm Joe Blow private citizen - do you expect me to > > pay $100 just to sign up with AOL? > > If you are Joe Blow private citizen, why would you need to run a mail > server? Would you not use your ISP's, at least as a smart relay? If > running a mail server is that important to you, just like registering a > domain, you'll pay it. > > -- > Robert Blayzor, BOFH > INOC, LLC > [EMAIL PROTECTED] > > Profanity is the one language all programmers know best. > >
RE: IETF SMTP Working Group Proposal at smtpng.org
> That's all well and good until said ISP's upstream servers go > slow/break/take an age to deliver a message you can deliver > from your own > host immediately. [It also doesn't scale particularly well] I don't believe this at all. By going with a whitelist type system that can cache or do cached lookups locally, it wouldn't take any more time to deliver mail than it does today. In fact, it would probably be faster since mail systems would be a lot cleaner not dealing with all the crap that's out there now. I'm not saying that people can't run their own mail servers, certainlly your ISP can register your mail server for you, in their IP space, so that it can be tracked. > I thought I was buying *Internet* access anyway... shouldn't > that mean I > have the right to talk which hosts I want on which port I want? Sure it does. But if the remote host says you need to ID yourself as a "trusted source", and they require it, it's not just your right to connect to anyone you want, but the right of the remote server to require that of you. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] A computer program does what you tell it to do, not what you want it to do.
RE: IETF SMTP Working Group Proposal at smtpng.org
> You're assuming that these people aren't permanently online. I expect > most of our users (I hesitate to call them customers, simply because a > lot of them haven't paid anything) are using 24/7 type connections. > Certainly, running your own mail server and being online two > hours a day is foolish. But just the opposite, you're assuming they ARE permanently online. Even if it was a 50/50 mix, that's still quite a few. > that met your static IP standard of approval, and yet was (unless he > wanted to pay extra) only online 1/6th of the time. Now, most of our > users may not have static IPs, but they're most likely online 24/7 or > close enough. > > Which of the two uses more resources on your servers? I'm > willing to bet > the static IP dialup person will, so there goes your argument. The case you state is the norm. Most dialup people who want to run mail servers use backup MX's supplied by their ISP's. If they run a mail server without proper DNS and a static address, they are no better than the untracked rogue spam mail servers that appear from throw away accounts. > Running mail servers on non-permanent dialup connections is foolish, > I'll grant you that any day, but that wasn't the point you > were making. > Your point was that mail servers on dynamic IPs (and you > never answered > my question on how you define dynamic) are bad, no matter the > circumstances surrounding them, and that's just plain not true. You claim that you have 10,000+ users using dynamic DNS to run SMTP services. That being said, every one of them violate the host requirements for SMTP outlined in RFC1123. Sections 5.3.1.2, 5.3.5, 6.1.1 (keyword MUST). > Oh, and BTW, you're not benefiting our users by having your servers > queue mail for our users. You're benefitting YOUR customers who > presumably want to be able to send mail to our users, and who expect > your servers to queue mail. Right, but your promoting your users to run SMTP servers that violate RFC. While you claim that many of them are online all the time, you can't say for sure that they are. That and the fact that by the RFC, they violate the DNS requirements outlined. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] "Unix is simple, but it takes a genius to understand the simplicity." - Dennis Ritchie
introducer trust model, Was: Eat this RIAA (or, the war has begun?)
Steven M. Bellovin([EMAIL PROTECTED])@2002.08.22 02:03:32 +: > I assume you're talking about the Berman bill -- for the full text, see > http://thomas.loc.gov/cgi-bin/query/D?c107:1:./temp/~c107Pidyhy:: > (it's not law yet). Note in particular that although they have to > notify the Attorney-General of the technologies they intend to use, > the bill doesn't say anything about IP addresses. Note also that the > technology list is confidential. > > Actually, the entire text is pretty appalling -- but read it for > yourself. hmmm all of the efforts to block/modify connections via adress based methods (blackholing whole networks, bh based on AS, ...) are up to no avail, IMHO. let their ``hacker'' folks just order a bunch of dsl lines distributed all over the major providers, and those methods don't make any sense. the same problems apply to blocking incoming SMTP connections, or mails from/to specific addresses, SPAM. thinking a little bit more about the issue with networked services in general (including SMTP and the spam/abuse problems, as well as filesharing and many more), the conclusive decision would be to define a bullet proof standard on introducer based trust, deriving a certain trust level or metric from a peer-trust based trust chain. this has several (dis)advantages: - no central authority involved, nobody will charge your creditcard for issuing a certificate - somewhat more unsharp but still pretty restrictive method of applying permissions to use resources - follows the basic paradigm behind TCP/IP, delivering a never-lights-out trust model that cannot be compromised easily, if it is good in design and implementation i am not an expert in this field, but i think that a generic standard for this kind of trust model is long overdue, the only application nowadays out there in the wild using it being pgp's model of the web of trust. creating such a generally applicable model of introducer trust, starting from design over implementation of a portable library that does it all, up to plug-in extensions to existing software (like hooking it up to SMTP greetings of the major flavours of MTAs, adding it to certain protocols, like HTTP, where it could easily replace most HTTP-Basic-Auth style systems of most community sites, like adding it to say gnutella's protocol, etc.) would solve a whole bunch of problems we all got today. with a certain amount of engineering effort, it might be applicable to IPSEC, too. of course there will be new problems that arise, and we need to take them into account. together with a bunch of folks that feel theirselves at home in the networked services, PKCS and protocol areas, there should be an (half)open discussion, to pave the road to get such a thing on track. this won't be an easy or short term project. also, i'm quite sure that there has been done quite some research in this field, being open or closed source/papers already, which should be aggregated to see the big picture. suggestions welcome, tell me what you think, even if you think that it's a moronic idea (in any case, the ``why'' is the important point) regards, /k -- > In protocol design, perfection has been reached not when there is nothing > left to add, but when there is nothing left to take away. > --Networking truth #12, Ross Callon, RFC 1925 WebMonster Community Project -- Reliable and quick since 1998 -- All on BSD http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/ GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6 REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x msg04724/pgp0.pgp Description: PGP signature
sanity check frame question
I have a Frame connection between two sites, A and B. If the router crashes at B, wouldn't A still see the DLCI for B? Is there any scenario where this wouldn't be the case? If B gets blown off the map, shouldnt A's frame interface be in at least an up/down scenario? The only reason I ask is because AT&T has been working on a 17hr outage like this and they are focusing on the CO at site B. When I asked them how clearing up a CO issue would make the DLCI reaappear at site A, they didn't have a straight answer. In my particular case, the remote site B actually has a PVC to A and C and both of those are in a down/downthese are subinterfaces on DS3's with tons of other sites working properly. If the DLCI disappeared, doesn't that suggest that someone deleted the PVC? Any insights would be helpful Thanks, -BM PS It would be reasonable to interpret this *partially* as a rant. I'd really like to confirm the PVC vs CO scope of the problem though.
Re: IETF SMTP Working Group Proposal at smtpng.org
--On 22 August 2002 01:16 +0200 Brad Knowles <[EMAIL PROTECTED]> wrote: > > At 5:35 PM -0500 2002/08/21, Peter E. Fry wrote: > >>Relay through your upstream (hierarchical approach)? i.e. Register >> your server(s) with your provider, who is presumably trusted (registered >> with the global system). > > This is the approach I recommend, and have recommended for years. That's all well and good until said ISP's upstream servers go slow/break/take an age to deliver a message you can deliver from your own host immediately. [It also doesn't scale particularly well] I thought I was buying *Internet* access anyway... shouldn't that mean I have the right to talk which hosts I want on which port I want?
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
> Blackholing the RIAA and hating them is pointless, that is what they are > there for. Blackholing them accomplishes nothing. > If you want to cause change you need to go after the labels. The labels > are > the member organizations which fund the RIAA. It's the labels who need to > be stopped, the RIAA is just their puppet and shield. However, blackholing is effective in regards to anti-piracy bots that rove the Internet like web spiders attempting to discover copyright violations by verifying P2P data that has been collected elsewhere. Since March of 2001, we have used complaints originating from anti-piracy organizations hired by various labels, most notable Sony, to maintain our own BGP blacklists. Since we have a significant xDSL customer base, we frequently received copyright infringement complaints from these organizations. This policy has eliminated those complaints. We were able to reduce legal exposure and reclaim some of the protection once afforded by open carriage by preventing these intrusive verification tests from even occurring. However, we do act on all complaints that we receive. Ben
Re: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
Avleen Vig <[EMAIL PROTECTED]> writes: > On Wed, 21 Aug 2002, Richard A Steenbergen wrote: > > > Ok, start listing IPs... > > If you have them (and can confirm them of course :P), I'm certain a dozen > > people on this list would put up a bgp feed before you can say > > "blackhole". Heck I'm certain people would have something to do if you > > even knew the provider that was planning on giving them service for such > > activities. > > Start here: > avleen@apple:avleen : host -t MX riaa.org > riaa.org mail is handled (pri=50) by mail3.riaa.com > riaa.org mail is handled (pri=10) by list.sparklist.com > riaa.org mail is handled (pri=10) by mail.riaa.com > riaa.org mail is handled (pri=25) by mail2.riaa.com And continue to here: [sgifford@sghome sgifford]$ whois [EMAIL PROTECTED] [whois.arin.net] RECORDING INDUSTRY ASSOC OF AMERICA (NETBLK-RECORDIN50-191) 1330 CONNECTICUT AVENUE NW SUITE 300 WASHINGTON, DC 20036 US Netname: RECORDIN50-191 Netblock: 12.150.191.0 - 12.150.191.255 Coordinator: EGAS, JACK (JE332-ARIN) [EMAIL PROTECTED] (2027750101) - Record last updated on 11-Aug-2001. Database last updated on 21-Aug-2002 20:01:34 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information. -ScottG.
Re: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
OOPS - my typo sorry! (standing in the corner with egg on my face ;-) ## On 2002-08-22 11:10 +0300 Rafi Sadowsky typed: RS> RS> RS> ## On 2002-08-22 08:04 +0100 Avleen Vig typed: RS> RS> AV> RS> AV> Start here: RS> AV> avleen@apple:avleen : host -t MX riaa.org RS> AV> riaa.org mail is handled (pri=50) by mail3.riaa.com RS> AV> riaa.org mail is handled (pri=10) by list.sparklist.com RS> AV> riaa.org mail is handled (pri=10) by mail.riaa.com RS> AV> riaa.org mail is handled (pri=25) by mail2.riaa.com RS> AV> RS> AV> RS> AV> RS> RS> RS> Not quite ;-) RS> RS> (1021)> whois -h whois.networksolutions.com riia.org RS> RS> RS> Registrant: RS> Royal Institute of International Affairs (RIIA-DOM) RS>Chatham House, 10 St James Square RS>London, SW1Y 4YE RS>ENGLAND RS> RS>Domain Name: RIIA.ORG RS> RS> RS> RS> RS> RS>
Re: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
## On 2002-08-22 08:04 +0100 Avleen Vig typed: AV> AV> Start here: AV> avleen@apple:avleen : host -t MX riaa.org AV> riaa.org mail is handled (pri=50) by mail3.riaa.com AV> riaa.org mail is handled (pri=10) by list.sparklist.com AV> riaa.org mail is handled (pri=10) by mail.riaa.com AV> riaa.org mail is handled (pri=25) by mail2.riaa.com AV> AV> AV> Not quite ;-) (1021)> whois -h whois.networksolutions.com riia.org Registrant: Royal Institute of International Affairs (RIIA-DOM) Chatham House, 10 St James Square London, SW1Y 4YE ENGLAND Domain Name: RIIA.ORG
