October 2001 - Test - lists.nanog.org

Re: Fwd: Re: Digital Island sponsors DoS attempt
by Paul Vixie 29 Oct '01

29 Oct '01

> > I am sure, Digital Island gets the necessary permissions from network > > owners before hammering them with those requests, right? > The same "permissions" that allow seamless end-to-end connectivity across > the entire Internet. The same "permissions" you granted to others when > you signed the connectivity agreement. "everything not expressly forbidden is allowed" is a workable model for peering relationships and even transit relationships, but it only works within the context of a direct relationship of some kind. in the case where the sender and receiver are communicating between one or many third parties, there is no direct relationship and thus no apriori terms of service to which the traffic must conform. for this, we reverse the model: "everything not welcomed is forbidden" and thus create a prior restraint problem which goes by the name "what, then, is implicitly welcome or unwelcome?" generally any traffic which unequally benefits the sender isn't welcome. ping traffic, even ping traffic which helps one network figure out how to best route traffic to another, still unequally benefits the sender. one ought not, in my opinion, ever have to ask that such pings be stopped. another test for "welcome" is "if everybody did this, would the recipient be injured?" clearly this is the same profile as "unequal benefit to the sender" and the answer in the case of these pings is "yes, ouch." smurf, ddos in general, and spam also classify well by this criteria. it *is* possible to know before initiating communication whether it's implicitly "welcome" by this standard, even if you have no direct relationship to the recipient whose terms and conditions would explicitly tell you the answer.

8 7

Re: FBI is at it again
by Steven M. Bellovin 29 Oct '01

29 Oct '01

In message <GKEFKKIKGCMICPKBAEIMKENECDAA.dgolding(a)sockeye.com>, "Daniel Golding " writes: > > >Are you kidding? The problems with this are numerous. First, the source is >Fox News, which is about a half step up from the Drudge Report. I tried posting this before, but I don't think my note got out. Basically, from what I've heard this report is indeed inaccurate. The FBI is holding a meeting on Thursday of this week where they will explain their new desires, and the legal justification for them; let's see what they say. (Btw -- this is apparently work that's been going on for two years; it's not in reaction to September 11.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

3 2

Hello, route filters?
by Adam Rothschild 29 Oct '01

29 Oct '01

I guess I see the rationale behind passing this cruft along to EXDS transit customers who haven't yet read the filtering section of Halabi (remember: more specifics == more outbound traffic from customer == more revenue). But exchange points? -a ----- Forwarded message from stats(a)merit.edu ----- Date: Sun, 28 Oct 2001 10:00:08 -0500 (EST) From: stats(a)merit.edu Subject: 10/27/01 Internet Routing Problems To: routing-problems(a)merit.edu See http://www.merit.edu/ipma for a more detailed report on routing problems and recommendations on ways service providers can limit the spread of invalid routing information. Send comments and questions to ipma(a)merit.edu [...] Reserved Network and Host Announcements (includes prefixes longer than /27 bits) ---------------------------------------- 202.0.73.32/27 at Paix from AS2516 ASPATH=2516 2500 IGP 202.139.168.232/29 at Paix from Exodus (AS3967) ASPATH=3967 9328 10097 17738 IGP 202.139.172.64/27 at Paix from Exodus (AS3967) ASPATH=3967 9328 10097 17738 IGP 203.236.98.224/27 at Paix from Exodus (AS3967) ASPATH=3967 4766 9522 IGP 203.239.51.128/28 at Paix from Exodus (AS3967) ASPATH=3967 4766 IGP 203.89.225.64/27 at Paix from Exodus (AS3967) ASPATH=3967 9328 6992 IGP 204.71.176.0/27 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 204.71.184.128/27 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 205.216.146.128/27 at Paix from Exodus (AS3967) ASPATH=3967 15870 IGP 206.132.131.160/27 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.142.224/27 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.160.0/27 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.160.32/27 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.187.64/28 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.187.80/30 at Paix from Exodus (AS3967) ASPATH=3967 15870 IGP 206.132.187.84/30 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.187.88/29 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.188.112/28 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.188.32/28 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.194.192/27 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.254.248/29 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.254.36/30 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.29.128/27 at Paix from Exodus (AS3967) ASPATH=3967 IGP 206.132.34.104/30 at Paix from Exodus (AS3967) ASPATH=3967 18997 IGP 206.132.34.112/28 at Paix from Exodus (AS3967) ASPATH=3967 18997 IGP 206.132.34.192/27 at Paix from Exodus (AS3967) ASPATH=3967 18997 IGP 206.132.34.224/27 at Paix from Exodus (AS3967) ASPATH=3967 IGP 206.132.34.64/27 at Paix from Exodus (AS3967) ASPATH=3967 18997 IGP 206.132.34.96/29 at Paix from Exodus (AS3967) ASPATH=3967 18997 IGP 206.132.42.0/27 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.42.48/29 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.42.56/30 at Paix from Exodus (AS3967) ASPATH=3967 15870 IGP 206.132.42.60/30 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.44.128/28 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.44.144/28 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.44.160/27 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.56.0/29 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.56.12/30 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.56.16/28 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.56.32/27 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP 206.132.56.8/30 at Paix from Exodus (AS3967) ASPATH=3967 15878 IGP 206.132.58.136/30 at Paix from Exodus (AS3967) ASPATH=3967 18993 IGP ***** Too many entries. List Truncated! ***** [...] ----- End forwarded message -----

5 6

Re: RBL & Broadband (WAS: Digital Island sponsors DoS attempt?)
by Paul Vixie 29 Oct '01

29 Oct '01

> ... If you do not filter spamers, how do you stop them? If you do > filter spamers, how to do stop from occasionally hurting people in > Christopher's situation? I dunno. Suggestions? That depends. If you want to filter abusive senders you have a different problem than if you want to filter abusive traffic. Abusive senders have ways of avoiding your filters; abusive traffic has other ways. Generally a high volume receiver (such as a busy e-commerce web site) has no way to differentiate an attack from a bump in traffic load. Whereas the number of possible sources of abuse ("launch points") is finite. These sources are not necessarily evil but from the reciever's point of view there's not a lot of difference between evil and laziness on the part of a source-owner. In the specific case of e-mail abuse ("spam"), has everybody checked out http://www.rhyolite.com/dcc/ yet? There ARE ways to raise the bar on the sender's pattern selections, at least for e-mail.

1 0

Re: Hello, route filters?
by Patrick W. Gilmore 29 Oct '01

29 Oct '01

At 01:40 PM 10/29/2001 -0500, Todd Romero wrote: > > >if you were my neighbor, and you had a gangly tree overgrown into my >yard that i took an issue to, i think i would most likely call or talk to >you personally about the issue, rather than carry out some agenda by >sending pictures of it to the community newsletter, saying "hey everyone >look what this guy is doing" Or just cut the branches that were on my property (i.e. filter incoming). -- TTFN, patrick

1 0

Peering BOF IV Meeting Notes
by William B. Norton 29 Oct '01

29 Oct '01

Hi all - Here are my notes from the Peering BOF IV - NANOG 23 ( http://www.nanog.org/mtg-0110/norton.html ) We started at 7:30 PM Monday evening with the intention of pulling the peering community together through introductions. We had about 20 Peering Coordinators step up to the mike, introduce themselves, say a word or two about their network, peering policy and what they are looking for in a peer network. This allowed the audience to put a face to a name for conversations afterwards. Another 10 that didn't pre-register for this stepped up and chimed in as well. From about 8:30 til almost 10PM the community stuck around to talk and I'm told that *dozens* of peering sessions (Yahoo!, Akamai, Carrier1, SBC, etc.) will be set up as a result. Highly successful NANOG for this segment of the population. Several folks asked for a list of those who stood up to talk about their peering policy, and here is what I have: BBC Internet Simon Lockhart simonl(a)rd.bbc.co.uk Digital Island Mitchell Rose mrose(a)digisle.net DoubleClick Alex Ng ngluck(a)bb.directv.com TELUS Clinton Work Clinton.Work(a)telus.com France Telecom/Open Transit Vincent Gillet vgi(a)utopia.opentransit.net Globix Steven J. Schecter sjs(a)globix.net WINFirst Hansel Lee Hansel.Lee(a)corp.winfirst.com 4CNet Brian Court bac(a)csu.net Akamai Rachel Warren rachel(a)plur.net / Patrick Gilmore patrick(a)ianai.net Hostcentric Charlene Wang Charlene.Wang(a)hostcentric.com Japan Telecom Seiji Kuroda kuroda(a)gw.odn.ad.jp Adelphia Joe Klein jtk(a)adelphiacom.net Earthlink Jeb Linton/Josh Fleishman Yahoo! Jeffrey Papen jpapen(a)yahoo-inc.com SBC Ren Nowlin ln1875(a)sbc.com Carrier1 Eric Troyer eric.troyer(a)carrier1.com ESNet Joe Metzger metzger(a)es.net Velocita Brian Dickson brian.dickson(a)velocita.com I want to thank these folks for volunteering to share their info and hopefully this led to some sessions coming up. <a bunch of folks came up to the mike but I don't remember the names except for Paul Vixie. I remember there were people in this group that included e-bay, Microsoft, Comcast.> Speaking of which, if Peering Coordinators would like to participate in the Peering Contact Database and receive a copy once a month or so of the Peering Contact Database, send e-mail to wbn(a)wbnorton.org and I'll return the template to fill out. So far we have about 150 Peering Coordinators listed. Several suggestions were made for the next time: - Include a "Peering Contracts Required" icon and - "Make it easy for folks to step up later along with Icons" and - "Include e-mail addresses" We're going to try and factor in these suggestions for the Peering Personals at the next Gigabit Peering Forum which is held Dec 3rd in San Jose. If you are a Peering Coordinator and would like an invite to this let me know. For those who could not attend due to travel restrictions or whatever I'd be happy to e-mail the slides with the peering icons and ISP names etc. Hope this helped - Bill ---------------------------------------------------------------------------- ------------------------------------------------- William B. Norton Co-Founder and Chief Technical Liaison Equinix wbn(a)equinix.com 650.315.8635

1 0

Re: Fwd: Re: Digital Island sponsors DoS attempt?
by Paul Vixie 29 Oct '01

29 Oct '01

> I was using legitimate in the sense of 'e-mail that the receiver > wanted to receive'. ... So this now boils down to "if the sender and receiver of a packet/session/etc are both interested in having it take place, then noone in the middle shall be allowed to deliberately prevent this from occuring." What would you mean by "deliberate" in this case? If "e-mail between consenting adults" was blocked because some NOC person was trying to stop a DDoS attack that happened to use the same source or destination address as the "consenting" e-mail was coming from or going to? Should that be illegal? If not, then why wouldn't a mailserver operator trying to block spam be allowed to do the same thing? > I also think it's very important to get past the 'who pays' argument. > It's a good argument from a technology point of view, or from the > individual's point of view, but it doesn't work in the abstract. On the contrary this argument is at its best in the abstract. > Worst case is someone will develop and popularize (or legislate) a > settlement system where the sender can pay for the entire transaction. A law allowing someone to make micropayments to the telco I get my T1 from, and to the vendor I buy replacement drives for my RAID box from, and so on, and which further _required_ me to have my costs offset in this manner, is beyond rational consideration and I refuse to even discuss it. Requiring that my inbox have a determinate bank account attached to it so that these micropayments can be made to me without any explicit contract between myself and potential senders is on the borderline of irrationality: we could discuss it but I don't think we'd get anywhere in finite time. This leaves the requirement that I enter into an agreement before costs are shifted in my direction. That's where we are right now. And that's why the "who pays" argument is at its _best_ in the abstract.

4 3

the group
by Brian Whalen 29 Oct '01

29 Oct '01

Any chance of there being a newsgroup format made available, so I can skip past all the philosophy, religion, politics and other non NOG messages? Brian "Sonic" Whalen Success = Preparation + Opportunity

6 5

Thursday Hawaii telephone mishap
by Sean Donelan 28 Oct '01

28 Oct '01

http://the.honoluluadvertiser.com/article/2001/Oct/26/ln/ln01a.html A Verizon telephone worker accidentally cut a fiber cable in Kalihi yesterday, setting off a chain reaction that resulted in the most widespread phone failure in the Islands in recent years.

7 9

Re: Fwd: Re: Digital Island sponsors DoS attempt?
by Paul Vixie 28 Oct '01

28 Oct '01

> > That way lies madness. Senders have no such rights, and the > > determination of a message's legitimacy lies with recipients (and > > perhaps infrastructure owners) NOT senders. > > How is the recipient of a message that has been blocked before he sees it to > decide whether it was legitimate? Why would you care, unless you are the receiver? If I decide that all ICMP traffic from IP addresses that have an odd number of "1" bits in it is not legitimate and shall not be allowed to reach my web server, then that seems to be a matter between me and my psychotherapist. I'm not sure why it would matter to anyone else, including rebuffed senders or NANOG's philosophers. What this all begs for is a reference standard for "presumed legitimacy" so that senders can know without waiting for complaints nor seeking explicit permission, just what kind of traffic they ought or ought not send. As I said in another note here, such a standard would have to be written in terms of assertions rather than negations. A peering or transit agreement is quite explicit since the parties and their specific concerns are known: it can therefore be of the form "All is permitted except X, Y, and Z." Presumptive traffic legitimacy or "implicit welcome" is between unspecified parties who can by definition have no specific concerns and so the standard must take the form "All is prohibited, except A, B, and C."

2 1