Re: Internet Exchange Questions
you know who to yell at. Until MFN sells them in coming months in their attempts to pay off billions of dollars of debt... No change is expected in who you yell at if PAIX isn't doing a good job. (That is, me.) -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc. (NASD:MFNX)
Re: MAE-Phoenix info request
The MAE in Phoenix was originally constructed by Dave Siegel and it ran from 1996 through 1998/9. and if anybody thinks phoenix still/again needs an exchange point, i'd thank you very much for contacting me about it off-list. -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc. (NASD:MFNX)
packet reordering at exchange points
packet reordering at MAE East was extremely common a few years ago. Does anyone have information whether this is still happening? more to the point, does anybody still care about packet reordering at exchange points? we (paix) go through significant effort to prevent it, and interswitch trunking with round robin would be a lot easier. are we chasing an urban legend here, or would reordering still cause pain?
Re: packet reordering at exchange points
H. You're right. I lost sight of the original thread...
GigE inter-switch trunking at PAIX. In that case, congestion
_should_ be low, and there shouldn't be much queue depth.
indeed, this is the case. we keep a lot of headroom on those trunks.
But this _does_ bank on current real world behavior. If
endpoints ever approach GigE speeds (of course requiring low
enough latency and big enough windows)...
Then again, last mile is so slow that we're probably a ways away
from that happening.
my expectation is that when the last mile goes to 622Mb/s or 1000Mb/s,
exchange points will all be operating at 10Gb/s, and interswitch trunks
at exchange points will be multiples of 10Gb/s.
Of course, I'd hope that individual heavy pairs would establish
private interconnects instead of using public switch fabric, but
I know that's not always { an option | done | ... }.
individual heavy pairs do this, but as a long term response to growth,
not as a short term response to congestion. in the short term, the
exchange point switch can't present congestion. it's just not on the
table at all.
Re: Links between cabinets at commercial datacentre
While acknowledging that a data center may make any rules it likes, I am asking nanog how common this practice is. data center is too amorphous a term to be used here. private data centers owned by banks or insurance companies aren't relevant at all. telco motels aren't really data centers but the issue does come up there. someone like exodus or qwest or att or uunet or abovenet would be very likely to prevent their customers from directly cross-connecting. mae-west (55 s market) won't allow it either. paix, equinix, switch and data, and other neutral colos won't allow it to occur without a fee but the fees are reasonable (unlike, say, the cross connect fees at mae-west.) there's no answer to the question, as posed. can you be more specific?
Re: Links between cabinets at commercial datacentre
there's no answer to the question, as posed. can you be more specific? I think the poster was inquiring as to common practice. Yes, but there isn't going to be a common practice for data centers as a whole. There's going to be a common practice for telco/fiber hotels, and a common practice for hosting centers, and a common practice for exchange points, and a common practice for shellcore, and so on. Each kind of data center drives toward its own common practice, and asking about common practices for data centers is therefore a nonquestion.
Re: Links between cabinets at commercial datacentre
... So - that is the larger picture, but was not my question to NANOG. We wish to be able to provide this peering, but we find that UUnets cross-connect policy interferes with our aims - as it requires potential peers in the data center to separately purchase connectivity to us (in the same building) instead of hopping onto our link by cross-connecting to another cabinet in the data center, which (of course) they waive for connections to the CINX cabinet. My question was if this was common practice. yes, it's common for a hosting facility (which uunet cape town is.) it would not be common in a carrier/fiber hotel. if there is one of those in town you'd be well served to talk to the landlord about supporting a peering exchange there, since it will drive other sales, and the openness of it will ultimately pull business away from the necessarily-more-closed peering exchange over in the hosting center.
Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
now as to who's responsible, first off you have to understand that we block rfc1918-sourced packets at our AS boundary. (otherwise these numbers would be Much Higher are you sure? i suspect they are windows 2000 systems behind NATs. so the dynamic update is for the 1918 address, but the packet source address has been natted into real space. according to our border flow stats, not all of them get nat'd on the way here.
Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
according to http://root-servers.org/, dns transactions concerning rfc1918 address space are now being served by an anycast device near you ... And right you are. However, pray tell, why doesn't bind feature a simple way to not log these spurious updates? As far as I can tell lots of people want to just ignore these messages but can only do so by turning off all security logging. that question belongs on [EMAIL PROTECTED], i suspect. but i'll answer: if you redirect the update and security categories to channel null then it works like you want. if there was demand, ISC would make a specific category called failed-updates so that other security related events wouldn't have to be nulled at the same time. Please note that PowerDNS is just as silly in this respect up to 1.99.9. The next version features --log-failed-updates which defaults to off. not all failed updates are spurious. i recommend against this as a default.
Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
(received privately, answering publically) any AS owner who wants to localize these updates can do so by simply anycasting the 192.175.48/24 netblock and serving dns on .1,=20 .6, and .42. Will it be a _bad_ thing if I just null-route those addresses in a controlled/documented/restorable manner in the ASes and other sub-AS networks that I administer? not at all. Will it break anything valuable to you or to end-users inside those ASes? nope. Is there is a certain reason I should run a real DNS server on 1, 6 and 42 (besides, of course, collecting statistics and chasing ab|users) ? nope. Is there a centralised place with information on the blackhole-X anycast addresses and AS112 or a document with the proposal and implementation besides www.root-servers.org ? um, nope. if you think it should say more than it does, let us know and we'll plump it up.
Re: Selective DNS replies
[EMAIL PROTECTED] (Eric A. Hall) writes: Clayton Fiske wrote: [bind question] [bind answer] this is nanog, you probably want bind-users[-request]@isc.org.
anybody else been spammed by no-ip.com yet?
as a coauthor of rfc2136, my curiousity is always piqued when spammers use the technology. can i get private forwards of other similar messages? (see below.) (and yes, i'll also be in touch with level3, who serves 166.90.15.236, from whence this message came.) (time was, anyone who could use postfix and php would also know better than to spam, or at least, to spam *me*. grump grumble.) re: --- Forwarded Message Return-Path: [EMAIL PROTECTED] Delivery-Date: Fri May 3 07:44:25 2002 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from isrv3.isc.org (isrv3.isc.org [204.152.184.30]) by as.vix.com (Postfix) with ESMTP id 2360D28B6B for [EMAIL PROTECTED]; Fri, 3 May 2002 07:44:25 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: from www.no-ip.com (yoka.vitalwerks.com [166.90.15.236]) by isrv3.isc.org (8.11.2/8.9.1) via ESMTP id g43EiOT08718 for [EMAIL PROTECTED]; Fri, 3 May 2002 14:44:25 GMT env-from ([EMAIL PROTECTED]) Received: by www.no-ip.com (Postfix, from userid 99) id 4A10F833A4; Fri, 3 May 2002 07:54:40 -0700 (PDT) To: [EMAIL PROTECTED] Subject: Your password for no-ip.com From: No-IP Registration [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-Mailer: PHP/4.1.2 Message-Id: [EMAIL PROTECTED] Date: Fri, 3 May 2002 07:54:40 -0700 (PDT) Hello, Welcome to No-IP.com. Your number one stop for dynamic dns services. Your password is: jnMgta To logon to no-ip.com go to http://www.no-ip.com/ and enter your email address and the password above. Once you logon you may change your password by clicking the Change Password link. Remember that you can use our dynamic update client to keep our system is sync with your IP address. These clients are available at http://www.no-ip.com/downloads.php Also, keep in mind that No-IP offers services for use with personal domain names. This service, No-IP Plus, allows you to use YOUR domain name with our dynamic dns, and other facilities. More information on this and other services is at http://www.no-ip.com/services.php. If you have any further questions about this service, please refer to our FAQ at http://www.no-ip.com/faq.php. If the FAQ doesn't answer your question(s) contact us at [EMAIL PROTECTED] Enjoy! The No-IP Team [EMAIL PROTECTED] http://www.no-ip.com/ --- End of Forwarded Message
Re: anybody else been spammed by no-ip.com yet?
... I'm not sure entirely what the big deal with spam is. Honestly sure I get it like everyone else, in some of my accounts more than others ... I have a delete key ... in the time between when you sent the above, and when i read it, the following messages were added to my mailbox: 1+ 05/03 stay5hard@hotmail The Harder you are The More She Will Come .. Vi 2 05/03 stayhdard@hotmail An Investment that will Rise with out a Doubt.. 3 05/03 sta4yhard@hotmail The Harder you are The More She Will Come.. Via 4 05/03 stayharud@hotmail The Harder you are The More She Will Come.. Via 5 05/03 henning@mercadob Nasty Japanese Whores! 14918Have you ever won 6 05/03 Cindy_W0887w08@ho fw.$25 Investment - Massive Return=== 7 05/03 Cindy_W5276c01@ms fw..$25 Investment - Massive Return== 8 05/03 Joke-of-the-Day! Patients taking Tri-Phetamine for 30 days, lost 9 05/03 istayhard@hotmail The best Hard-on you have ever hadVIAGRA (and 10 05/03 sjtayhard@hotmail Be Hard as a Rock.. Make her come and come../ 11 05/03 AEMI ADV: A low cost professional 800 number is fina 12 05/03 AEMI ADV: A low cost professional 800 number is fina 13 05/03 stayhayrd@hotmail Be Hard as a Rock.. Make her come and come .. V 14 05/03 sxtayhard@hotmail Vaniqa .. Order today You Unwanted Hair Will be 15 05/03 zstayhard@hotmail The Harder you are The More She Will Come.. Via 16 05/03 stayrhard@hotmail Take the Blue Pill.. and show her how far the R 17 05/03 sthayhard@hotmail Better for Him Better for Her.. . Order Viagra 18 05/03 [EMAIL PROTECTED] Quality Affordable Hunts!html head title 19 05/03 mailing@revistatr Especial 100 edi esA TRIP deste m s j est na 20 05/03 AEMI ADV: A low cost professional 800 number is fina 21 05/03 stadyhard@hotmail Take the Blue Pill.. and show her how far the R 22 05/03 Kitty Dials Record Low MORTGAGE rates! *Act Fast* 11551h 23 05/03 AEMI ADV: A low cost professional 800 number is fina 24 05/03 AEMI ADV: A low cost professional 800 number is fina 25 05/03 stayhnard@hotmail Online Pharmacy..Any Medication you Need Lowest 26 05/03 Val (~) You only THINK you're a U.S. citizen! %8t it comes in 24 hours a day, 365.24 days per year, at about that rate. and that's after subscribing to several source-address-based rejection filters, and rejecting some additional sources. (otherwise it would be 4X worse, at least according to my syslog.) here's a short term histogram: lartomatic=# SELECT DATE(entered),COUNT(*) FROM spam WHERE DATE(entered) = '2002-04-01'::DATE GROUP BY DATE(entered) ORDER BY DATE(entered) DESC; date| count +--- 2002-05-03 |78 -- (partial) 2002-05-02 | 111 2002-05-01 | 176 2002-04-30 | 122 2002-04-29 |99 2002-04-28 |65 2002-04-27 | 128 2002-04-26 | 143 2002-04-25 | 107 2002-04-24 | 107 2002-04-23 |73 2002-04-22 | 121 2002-04-21 |72 2002-04-20 | 101 2002-04-19 | 104 2002-04-18 |89 2002-04-17 | 100 2002-04-16 |78 2002-04-15 | 119 2002-04-14 | 113 2002-04-13 | 116 2002-04-12 | 167 2002-04-11 | 167 2002-04-10 | 100 2002-04-09 | 166 2002-04-08 |81 2002-04-07 | 105 2002-04-06 | 115 2002-04-05 | 116 2002-04-04 | 125 2002-04-03 |91 2002-04-02 |88 2002-04-01 |97 (33 rows) go ahead and Just Hit Delete if you want.
Re: anybody else been spammed by no-ip.com yet?
... not only does it cost usually very little to receive these messages ... even if i granted to a third party the right to determine the value of my time, which i don't, the fact is that an hour or more of my time per day is too high a price to pay to receive these messages, by _any_ standard. to understand the scale, here's what came in during my trip home tonight. 456 05/03 Big Brother Protect your family on the InternetHTML BOD 457 05/03 Big Brother Protect your family on the InternetHTML BOD 458 05/03 Big Brother Protect your family on the InternetHTML BOD 459 05/03 Big Brother Protect your family on the InternetHTML BOD 460 05/04 FreeSampleCenter Win $20,000! Win $20,000 to RENOVATE your Home! 463 05/04 my_own_business20 If a 15 year old boy can earn $71,000 in just a 464 05/03 mikeYOUR HEALTH zNAUiqxgExThis is a multi-part mes 465 05/03 National Financia InvestorFacts: NasdaqNM: DSSI -Data Systems and 466 05/02 Pamila Binkley don't Pay another monthly Bill until you read th 469 05/04 [EMAIL PROTECTED] Large Annual Tax Savings!html head title remember, it would be ~4X higher without filtering, according to my syslogs.
Re: DEC AS33 NOC Contact
Anyone have a good NOC contact for DEC, AS33? I checked Jared's NOC page and I don't see them listed. when you find it, send it to me :) you need number 6. in order, as33 was maintained by: 1. brian reid 2. richard johnsson 3. me 4. stephen stuart 5. drew kramer number six is [EMAIL PROTECTED]
Re: anybody else been spammed by no-ip.com yet?
trollishly What do you guess for the amortized cost/spam? /trollishly a cost that you are forced to pay in order to enrich somebody else is theft, no matter how microscopic the payment might be. we all know what (they) are, now we're just arguing about the price. I do find it amusing that nobody responded to my more relevant and intended thrust, about how putting a 'sender pays receiver for email' could cause a variety of new abuses of the email system. on the one hand, you're right that any micropayment system would have to be very carefully thought out and even more carefully implemented, lest it open the door to many and varied forms of microabuse. on the other hand, that doesn't disprove the case, since even in your example it would merely cause people to become a LOT more careful about they mail they sent. that CAN'T be a bad thing. bill washburn's XNS effort, while nowhere near ready for critical review, shows some of the throught that needs to occur to make micropayments not be a bad deal for one or both parties. www.xns.org has an overview and www.onename.com goes so far as to say With an OneName solution, you control and manage all relevant identity data, with no need to involve a third party in your business relationships. You can customize authentication and permission structures for every business relationship and automate specific types of data exchange, both within and across the corporate firewall. These same permission structures provide an easy way for customers to provide consent for the usage of their personal data. note that i'm not advocating the approach, but rather, holding it up as one example of how personal messaging will have to work at full scale.
Re: anybody else been spammed by no-ip.com yet?
There will be a day when folks will need to pay to transit email (Paul Vixie, 1998). Still working on that better mouse trap? well, other than that i wish i could charge _you_ for the spam i get that's due to the several MAILTO:[EMAIL PROTECTED]'s on your www.dotcomeon.com site, no. it's not my mouse of choice.
Re: Interconnects
There are some relatively small regionals like NYIIX where you won't find many large carriers, but they still have their own little nitch markets. There's been rumors of NYIIX and PAIX-NY linking up like SIX and PAIX-seattle. It's not a rumour. PAIX is interconnecting with NYIIX as soon as the fiber engineering people say that the photons will travel end to end. * Price - In these times of cost conciousness (and transit available for less than the price of peering), many people are taking a step back and realizing that PAIX services are OUTRAGEOUSLY priced vs the competition. Some big carriers are turning down their PAIX switch ports, even at Palo Alto. Which is why I was surprised that Paul offered PAIX-seattle connectivity for a $300 one-time charge for those who are already connected to SIX. We aren't silly, and since it would be silly to fail to recognize that some peers want/need different service levels than others, we recognized it and are acting on it.
Re: Interconnects
It's not a rumour. PAIX is interconnecting with NYIIX as soon as the fiber engineering people say that the photons will travel end to end. Will PAIX be around as an entity capable of providing any services in 3 month? PAIX is modestly profitable and has been for years. We are quite healthy. (I cannot answer questions or respond to rumours about the parent company, MFN. PAIX is an arm's length subsidiary.) When a company makes such business decisions, would this company be around to make that $300 one time charge worth more than a dinner at Sagami in next 3 month? If you're not happy with the service we provide, please let me know or talk to your client services rep.
Re: Interconnects
It's not a rumour. PAIX is interconnecting with NYIIX as soon as the fiber engineering people say that the photons will travel end to end. Listen, I am not trying to be antagonistic, but: Why does this take so long? PAIX-NY is a MFN facility, so, presumably, there is MFN fiber there and ready to go. 25 Broadway is a MFN building, and has been for some time (as in, many people have MFN fiber there). I can't comprehend how this can take so long. I had the same thought. However, it turns out to light a path there's all kinds of climbing down into manholes that has to happen. I'm no fiber expert, but the parent company (MFN) does employ such experts, so let's remain calm. -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc. (NASD:MFNXE)
PAIX (was Re: Interconnects)
Mitch what has MFN's financial problems have to do with the quality of the agreements that are in place for peering. Easy. It fills, and then no one wants to pay to increase it. If I am not mistaken, this has happened already. Actually, only the Palo Alto location was ever in this situation, and the parent at the time was Digital Equipment Corporation. MFN did pay to increase it when their time came. Six PAIX locations are open today and there is active peering occuring at all of them and there is room for more peers at all of them. Here's the list in case anybody was curious. site |shipto --+-- atl1 | 56 Marrieta St, Floor 5 and 7, Atlanta GA 30303-2885 dfw1 | 1950 Stemmons Fwy, 1st Floor, Dallas TX 75207-3107 jfk1 | 76 9th Ave, #734, New York NY 19911-5201 sea1 | 2001 6th St, 12th Floor, Seattle WA 98121-2855 pao1 | 529 Bryant St, Palo Alto, CA 95301 USA iad1 | 7990 Science Applications Ct, Vienna VA 0- (6 rows) We are also providing port only services at several Abovenet locations, several Switch and Data locations, Dataplex (in Hungary), and e-exchange at 200 Paul St in San Francisco. With more to come. We have exchange agreements in place with SIX (active) and NYIIX (pending), with more to come. I welcome any further questions about PAIX's health or future. When we started this as a DEC business unit in ~1995 we had a 100 year business plan in mind. Looks to me like we're not quite finished, but that we've made an excellent beginning. There's much, much, much more to come. I can't answer questions about PAIX's current parent (MFN) other than to say that there was a press release a month or so back wherein PAIX was called a nonstrategic asset and that they intended to sell us. -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc. (NASD:MFNXE)
Re: Interconnects
Actually, doesn't MFN usually outsource this to Bechtel, Keyspan Communications and others? :) I don't know. It wouldn't change my position on the subject, which is that it's their fiber, and in NYC it's a large and complex plant, and they've got people working on the PAIX/NYIIX path who know a lot more about fiber in general AND this plant in particular than I do. -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc. (NASD:MFNX)
Re: PAIX (was Re: Interconnects)
I welcome any further questions about PAIX's health or future. [...] Why no optional MLPA like AADS? [...] we had one at first. after a few years of approximately no signatories, we stopped trying. my own experience is that bilaterals are more useful for engineering purposes and that multilaterals are kind of swampy. but if there's interest, we'll find the old paperwork and shuffle it anew. -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc. (NASD:MFNXE)
Re: EBITDA [was Re: Interconnects]
EBITDA positive does not mean profitable, or even necessarily financially stable. Right you are. So please let me clarify my earlier statement (that PAIX has been modestly profitable for years). If we were not a wholly owned subsidiary we would owe income taxes. When we have been wholly owned by companies who were paying income taxes, some of the taxes they had to pay were because of PAIX. (Presumably this positive our income situation will make it easy for MFN to sell us.) Let's have a look at Extreme Networks' recently published financials. (Bring up http://biz.yahoo.com/fin/l/e/extr.html to follow along.) These folks showed a net loss this quarter yet the analysts applauded them and their stock shot up a bit because they had a nonrecurring charge larger than their net loss. This tells analysts that the company would have taxable income if not for the nonrecurring event, which gives them hope for the next quarter. On http://biz.yahoo.com/fin/l/e/extr_ai.html we even see that in the year ending July 2000 they paid $10M in income taxes, which tells us that maybe they know how that feels and want to do it again some day. I like EBITDA as a yardstick for measuring one company against another if they are otherwise similar and I'm looking for a differentiator. But I don't personally buy stock based on EBITDA numbers -- I want to see actual net income and, paradoxically, I love a company who has to pay income tax because it means they had INCOME to pay taxes on. -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc. (NASD:MFNX)
Re: Interconnects
[EMAIL PROTECTED] (Daniel Golding) writes: PAIX shares MFN/Abovenet's peering agreements? That's quite a trick. ... No. PAIX has no peering agreements of any kind. This is not to slam PAIX or Paul Vixie - I'm a big PAIX fan, and Paul has done a superb job. However, MFN adds no value, and only hurts PAIX's credibility with it's massive financial problem. PAIX without MFN will, once again, be a great thing. Hopefully this will be soon. To the best of my knowledge, our parent company's woes have not been noticed by PAIX's customers (unless such a customer has its own separate relationship to the parent company, which PAIX would have no knowledge of.) And, thanks for your kind words. -- Paul Vixie [EMAIL PROTECTED] President, PAIX.Net Inc.
Re: proposed government regulation of .za namespace
[EMAIL PROTECTED] (Randy Bush) writes: well, za and some of its principal subdomains are the highest error rate zones i secondary or use. but i can imagine a different part of the government doing an even funkier job. the contest is likely keen. ISC has had very little in the way of problems as a .ZA slave, fwiw. [phred.isc:alpha] ls -l *.[a-z][a-z] ?? -rw-r--r-- 1 root system 282852 May 25 08:41 bg -rw-r--r-- 1 root system 284449 May 25 08:04 br -rw-r--r-- 1 root system5149177 May 25 07:59 cl -rw-r--r-- 1 root system 69640307 May 25 07:28 com.br -rw-r--r-- 1 root system7722812 May 25 06:55 cz -rw-r--r-- 1 root system 15684581 May 25 04:33 fr -rw-r--r-- 1 root system393 May 25 08:53 kailua-kona.hi.us -rw-r--r-- 1 root system 9585 May 25 08:38 palo-alto.ca.us -rw-r--r-- 1 root system 9409 May 25 04:57 za (btw, more are welcome if anybody else needs a feeless TLD/SLD slave.) but semi-clued governments and semi-clued folk in general seem to be attracted to the domain name space. i suspect it is one of those areas that appear simpler, more powerful, and more lucrative than they actually are. running a cctld well is a major pita with no thanks and thin rewards. brother, you just said a mouthful.
Re: GigEth regenerators
is anybody aware of an optical long-haul gigabit ethernet regenerator box? anything like=20 Cisco Optical Regenerator (COR) OC-48 STM-16 Bi-directional Regenerator http://www.cisco.com/univercd/cc/td/doc/pcat/oc48__l2.htm but for gigeth in this case - we need to connect two sites about 200km apart over dark fiber I don't know if you can use more than one of these on a path, but http://www.extremenetworks.com/products/datasheets/gbx.asp ...might be something like what you want for this. Seems very similar to... http://www.jdsu.com/site/images/products/pdf/Model1280GbX_092101.pdf ...which Pac*Bell SBC is using for its new GigaMan product. -- Paul Vixie
Re: statistics.
I am looking for a ballpark count concerning amount of current internet nodes. ( obviously not exact ) With data relevant to this year. Feel free to contact off-list. http://www.isc.org/ds/ -- Paul Vixie
Re: GigEth regenerators
[EMAIL PROTECTED] (Daniska Tomas) writes: a brief summary of responses up to now: in response to my earlier reply on this topic, i was also pointed at http://www.nbase-xyplex.com/products.html which indeed shows how to do 65Km regen points. pretty cool other stuff too.
Re: Any opinions regarding Telehouse ?
That's 611 6th st., aka ATT Center. PAIX-LA is in that building. Note that when MFN's financial picture changed, the opening date for PAIX-LA was indefinitely postponed. I'll second Woody's remarks about LA Telehouse -- a fine place run by fine people. There're also Equinix and SD facilities within a quarter mile of that intersection. -- Paul Vixie
Re: Sprint peering policy
: when this situation has existed in other industries, gov't intervention : has always resulted. even when the scope is international. i've not : been able to puzzle out the reason why the world's gov'ts have not : stepped in with some basic interconnection requirements for IP carriers. Let's hope they don't decide to do that. i won't take a position on this, other than that dense peering, and high path splay, are good for global internet performance and reliability. wrt the basic likelihood, though, it comes down to the consumer (citizen). if the following are all true, then the world's gov'ts have usually acted: 1. availability of the service is fundamental to quality of life ( economy) 2. cost, availability, or reliability depend on competition (vs monopoly) 3. local economies will benefit more from competition than from monopoly 4. predatory or monopoly practices appear to be in effect so, the reason i am puzzled is that while some of those could be argued by some people, they _are_not_being_argued_about_. there's a blind eye here. none of the following industries would be allowed the kind of self regulation currently practiced in the IP carriage field: air travel, commercial fishing, leased line telco, or switched voice telco. we're treated in a hands-off fashion that absolutely boggles the mind.
Re: Vixie puts his finger squarely on the key issue Re: Sprint
i just want to clarify that... Oh, no. If anyone has illusions that politicos can somehow fix the situation, he ought to do serious reality check. ... ...while my name does appear in the Subject: header, i have no illusions that the world's gov'ts can do a better job on peering architecture than is being done now. when i added my comments to the parent thread, i only meant to indicate my surprise that such isn't being tried -- NOT any disappointment. -- Paul Vixie
Re: Paix-NY and NYIIX -- link stil going to happen?
Anyone know if the link-up is still going to happen? everyone i've talked to still wants it to happen. does that count? I've heard from a few people that given the financial issues at MFN, this is highly unlikely to still happen. Anyone know any different? it seems to me that it's more likely to happen after paix has been sold, or after mfn has completed its chapter 11 restructuring, or after both. Paul? note that i'm a victim of the new economy. mfn axed the president of paix job about a month ago, and so i am presently just a consultant, so my words here are not nec'ily representative of mfn's or paix's actual plans/desires. -- Paul Vixie
Re: Sprint peering policy
What is the connection between unregulated peering and the financial difficulties we have seen? The problems have been caused by: - Bad business models - Greed - Corporate officers who have shirked their fudiciary responsibilities to the stockholders If you can somehow tie peering into this, please be my guest, but it would be a bit of a stretch. you've asked and answered your own question, though. remember, wcom tried to buy sprint and it was only the EU's antitrust folks who stopped them. when peering was an engineering issue rather than a sales/equity/PR issue, there was a lot of it, and there were fewer single points of failure at ISO-L8 than we see today. i completely understand that acquisition is a common and valid means to grow a business. however, with closed peering as a way of life for our industry, a lot of deals are done which only make money for the investment bankers and don't actually grow business. closed peering is all about greed and not about service levels, competitive pricing, or overall sector health. closed peering is a bad business model. it shirks fiduciary duty to long-term equity holders in order to give periodic quick hits to short-term holders. closed peering proceeds from a Highlander-like premise there can be only one when in fact there could be many, and if there were many then the industry overall would be healthier.
Re: Internet vulnerabilities
[EMAIL PROTECTED] (Mike Tancsa) writes:
... Still, I think the softest targets are the root name servers. I was
glad to hear at the Toronto NANOG meeting that this was being looked into
from a routing perspective. Not sure what is being done from a DoS
perspective.
Now that we've seen enough years of experience from Genuity.orig, UltraDNS,
Nominum, AS112, and {F,K}.root-servers.net, we're seriously talking about using
anycast for the root server system. This is because a DDoS isn't just against
the servers, but against the networks leading to them. Even if we provision
for a trillion packets per second per root server, there is no way to get
the whole Internet, which is full of Other People's Networks, provisioned at
that level. Wide area anycast, dangerous though it can be, works around that.
See www.as112.net for an example of how this might work. More later.
--
Paul Vixie
Re: fractional gigabit ethernet links?
one small note, in passing: In other words..intermittent intergap delay? when PAIX sells what it calls Fractional Gig E, it's just Gig E with rate limiting. nothing special at the link level.
Re: AS286 effectively no more..
The KPNQwest Network Operations Center was CLOSED on 19/07/2002 As everybody knew they did have a really proactive and responsive NOC. It is sad to see things like thi happen. :-( indeed. it's rare these days that a noc is given enough budget and authority to do a good job. as286 predated the dotcom boom (and bust) by a lot of years and was a fine bunch of folks from the earliest days to the final days. it's really sad to see a successful enterprise swept up by a boom/bust cycle. (i guess anybody who was able to cash out their equity from the kpn/qwest deal saw it as a good thing, but older customers probably wish it hadn't happened.) -- Paul Vixie
Re: If you have nothing to hide
[EMAIL PROTECTED] (Sean Donelan) writes: ISPs to step up Internet service providers also have to be more security conscious, Clarke said. By selling broadband connectivity to home users without making security a priority, telecommunications companies, cable providers and ISPs have not only opened the nation's homes to attack, but also created a host of computers with fast connections that have hardly any security. Public network operators are very security conscious, about the public network operators network. Should public network operators do things, common in private corporate networks, such as block access to Hotmail, Instant Messenger, Peer-to-peer file sharing, and other potentially risky activities? Should it be official government policy for public network operators to prohibit customers from running their own servers by blocking access with firewalls? Don't dismiss this concern. We know why multipath (core) RPF is hard and why most BGP speakers don't do it yet. But unipath (edge) RPF has been easy for five years and possible for ten, and yet it is in use almost nowhere. The blame for that lays squarely, 100%, no excuses, with the edge ISP's. Whether Microsoft or the rest of the people CERT has named over the years with various buffer overflows are also to blame for making hosts vulnerable is debatable. But whether edge ISP's are grossly negligent for not doing edge RPF since at least 1996 is not debatable. Cut Mr. Clark *that* slack, even if you must (righteously, I might add) blast him on other issues. -- Paul Vixie
Re: Do ATM-based Exchange Points make sense anymore?
What functionality does PVC give you that the ethernet VLAN does not? That´s quite easy. Endpoint liveness. A IPv4 host on a VLAN has no idea if the guy on the other end died until the BGP timer expires. FR has LMI, ATM has OAM. (and ILMI) Adding complexity to a system increases its cost but not nec'ily its value. Consider the question: how often do you expect endpoint liveness to matter? If the connection fabric between your routers has an MTBF best measured in hours or days, then you've got bigger problems than you'll solve with LMI. If on the other hand the MTBF is best measured in months or years, then when it does fail the failure is likely to be *in* the extra complexity you added. -- Paul Vixie
Re: Do ATM-based Exchange Points make sense anymore?
warning: i've had one high gravity steel reserve over my quota. hit D now. The issue I'm trying to address is to figure out how to extend the robustness that can be achieved with tuned IGP's with subsecond convergence across an exchange point without suffering a one to five minute delay blackholing packets. why on god's earth would subsecond anything matter in a nonmilitary situation? are you willing to pay a cell tax AND a protocol complexity tax AND a device complexity tax to make this happen? do you know what that will do do your TCO and therefore your ROI? you want to pay this tax 100% of the time even though your error states will account for less than 0.001% of the time? you want to have the complexity as your most likely source of (false positive) error? As far as I understand, this complexity just got added with Neighbor Discovery on IPv6. if so, then, you misunderstand. -- Paul Vixie
Re: Do ATM-based Exchange Points make sense anymore?
I suppose the discussion is what do you want from your exchange pt operator and what do you NOT want. At the IXP level, bits per month always trumps bits per second, and usually trumps pennies per bit as well. There are now a number of companies trying to sell wide area ethernet -- even some transoceanic but most just intracontinental. It doesn't work well for peering, though, just like SMDS and NetEdge didn't work well for peering. Too many moving parts and too little transparency. Many people would not feel comfortable that circuit operators have visibility and maintain stats on even NUMBER of packets passed That's one of several important reasons why neutrality matters.
gentlemen, stop your engines
after six reports that 192.5.5.241's address has been forged as the source of a tcp fragmented scan probe, i'm ready to have it stop. but just in case it doesn't, this is fair warning to the community: F's address is in unlawful use by as-yet-unidentified third parties. re: --- Forwarded Message From: ... To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: Unauthorized Fragmented Scan Date: Mon, 12 Aug 2002 06:56:08 -0700 To whom it may concern, The Security Information Analysis Center has detected an unauthorized scan against one of our networks that has a possible origin at 192.5.5.241. Please review the following initial information: IPHalfScan 08-11-2002 17:34:02 UTC 192.5.5.241:53 xxx.xxx.xxx.xxx:53 TCP IPHalfScan 08-11-2002 17:28:00 UTC 192.5.5.241:53 xxx.xxx.xxx.xxx:53 TCP Please take action to verify this address on your network and it's intent to scan our networks. Thank you for your assistance. SECURITY INFORMATION AND ANALYSIS CENTER 1-877-... --- End of Forwarded Message
Re: Microslosh vision of the future
How about [EMAIL PROTECTED]? Wasn't this set up for this very purpose? Nobody goes there any more, it's too crowded. -- Paul Vixie
Re: Dave Farber comments on Re: Major Labels v. Backbones
[EMAIL PROTECTED] (Sean Donelan) writes: The record labels don't want to give you that choice. If you read the complaint you'll notice the record companies never attempted to contact the immediate upstream ISP in China. ... Am I the only one who finds it odd that it's illegal to export crypto or supercomputers to certain nations or to sell such goods with prior knowledge that the goods are going to be resold in those nations... or even to travel to certain nations... yet no law prohibits establishing a link and a BGP session to ISP's within those nations, or to ISP's who are known to have links and BGP sessions to ISP's within those nations? How long, in this new era of homeland security, can we expect it to last? How long before someone has to say I'm sorry, I can't peer with you or sell you transit because you have downstreams or peers inside the axis of evil? I'm not sure I'd be opposed to it, since economic blockades do appear to have some effect, and since data is a valuable import/export commodity. I think homeland security is a good thing if it means a mandate for IPsec, DNSSEC, edge RPF, etc... but if we *mean* it, then why are US packets able to reach ISP's in hostile nations? (My bet is that within 6.5 minutes of this message going out, there will be at least one public flame on the topic of how freedom of information is the only way to bring down a totalitarian regime. Save it, please -- I can write, have written, and will write that whitepaper myself. This is not the same topic. I want to know what the homeland security department is likely to do about all this, not what is good/bad for the citizens of hostile nations or even nonhostile nations.) -- Paul Vixie
Re: your mail
Speakig of paix's and locations, I know the mfn filings have held up progress but I wondered and maybe others on this list wonder what the status of the paix nyiix interconnection might be? until mfn finishes selling paix, there will likely be no progress on this.
Re: [Fwd: Re: IETF SMTP Working Group Proposal at smtpng.org]
I agree with getting personal mail servers registered, as far as paying $100 for a mail server registration (as mentioned in previous messages)...that's no good. As a user with a personal mail server, it is bad enough to have pay for connectivity and a domain name. Having to pay for the privilege of running a mail server is too much. e-mail isn't free. in my own experience, i can pay a high price by just hitting delete a couple hundred times a day, or a medium price by turning on all kinds of anti-spam features in my MTA and sending complaints out to network owners on whatever sneaks through the blockade, or a low price by only accepting e-mail from people who have paid to register their servers with some certifier whom i am willing to trust. we'll be seeing this kind of require signed-by-trusted certificates before permitting use logic in the personal certificate field soon. why not do it at the mail server level, where there are fewer certificates and more total lifetime value per signature? the secret is in correctly answering the question who gets the money. i would love to see a bona fide nonprofit use this as a fundraising method. (any organized religion's church comes to mind here as an ideal candidate.) server-level openpgp is also an option, and would more closely reflect the social realities: (1) introducers i'm willing to trust may not be at the top of any virtual certification hierarchy other than my own; and (2) there's no compelling technical reason to keep the number of ultimately trusted keys small. (verisign/thawte may feel that there are compelling business reasons, however.) -- Paul Vixie
Re: IETF SMTP Working Group Proposal at smtpng.org
Lets not forget that you need an SSL cert for every server with a different host name, and you need to go through companies like Verisign to get them. (yes, there are lesser evils I know). But using SSL certs could be more expensive then just registering your company, netblock or whatever with a management account. i won't glock up this already busy list with a full copy of the proposal, but before y'all go off and invent something, here's some prior art that's been resoundingly pooh-pooh'd by the smtp community. http://www.vix.com/~vixie/mailfrom.txt Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. -- Paul Vixie
Re: IETF SMTP Working Group Proposal at smtpng.org
[EMAIL PROTECTED] (Martin Cooper) writes: OK - but unconditionally permitting null-return paths means that spammers can drive a coach and horses through the hole it leaves. :-( that's how the proposal is optional. spammers who lie about their source/return addresses using nonexistent domain names are not the subject of http://www.vix.com/~vixie/mailfrom.txt; rather, i'm trying to address the issue of spammers who lie about _existing_ source/return domain names. -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
As a user, I pay my ISP to forward IP packets. If there happen to be TCP segments in those packets, that's something between me and the person the packet is addressed to, ... ...and, occasionally, your ISP's abuse desk. If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. If they want to do some simple things to keep the slacker cutoff point at those numbers rather than other numbers which are 90% smaller, you'll understand the economics. If one of those simple things is blocking outbound TCP/25, then I hope you have alternatives including changing ISP's... ...but if you don't, then it's between you and your ISP, and best of luck. -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
Every single purely technical approach to stopping spam has been a complete loser. In the fullness of time, the universe itself will die of heat. So what? What matters more is what use is made of time before it gets so full. A number of purely technical approaches to stopping spam have been quite successful... in the short term... which not the same as being a complete loser in the long term. (Everything's a complete loser if you measure it right.) There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing. Someone else already quoted an RFC from geektools that contains such a definition. http://www.mail-abuse.org/standard.html, on the other hand, is something I cowrote back when I still had an operational role at MAPS, and still seems pretty careful and pretty professional (and pretty public.) -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. ... you're offering very definitive figures/labeling, and I'm curious as to what you are basing your calculations/labels on, and what the linearity of the scaling is in your opinion. Your own experience at MAPS? At MFN? Wishful thinking? those numbers are very round. i've seen folks do 1 FTE per 50,000 dialup users and get away with it, but that person was VERY busy. that ratio only works if the rest of the system is designed to repel the professional spammers, i.e., full ANI with filtering, full verification of credit cards (charge and refund before opening the account), nonrefundable deposit if terminated for spamming, and instant termination even at 4AM on sunday morning, ~30 hours or more before the account manager or any other manager could give approval. Personally, I'd much rather try to justify a FTE for 1000 T-1s than I would for 10,000 dialup users. like i said, the numbers were very round. as long as you understand that there IS a ratio and that the cost of dealing with outbound traffic does not end at the demarc point where it's handed to a peer or transit, then what the actual nonzero abuse desk costs actually are is a detail. this seems like something isp/c or cix should do a survey on.
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
as joe pointed out to me privately RFC 2782 specifies SRV RRs which could be used to point an MX.SRV at a port other then 25. anyone got any examples of MTAs or MUAs that implement said RFC? actually it would be _smtp._tcp.$DOMAIN but it's not in use for e-mail. or web, even though that's the example that appears in the rfc. the only users i'm aware of are Microsoft and Apple for their respective service discovery systems, and MIT Kerberos iff your domain name and your realm name are the same. -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
...and, occasionally, your ISP's abuse desk. If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. Not to try to undercut the general point, but that would imply that Earthlink, AOL, and MSN (for examples) should have a combined abuse department of roughly 1500 employees. Well, perhaps those were poor examples then. as i told patrick, the numbers are round, and a survey is needed. it's definitely going to be the case that scale will lead to economy, and AOL could most likely get by with only 100 full time abuse desk staffers as long as the rest of their service model were optimized to make abuse difficult to propagate. i doubt they will comment in detail here, since the actual numbers are likely to be some kind of internal secret. i know i get far less spam from AOL than i used to, and i've assumed that this is because they decided to address the costs at the front end (in their service model) rather than the back end (in endless cleanup.) It would be wonderful if it were the case, and while it seems like laziness when we talk about the big guys, most middle sized providers just don't have the operating budgets to not slack at least a little bit. whenever you get spammed, it's because some isp somewhere is a slacker, and is letting you pay the price for their lack of investment in this critical area. (spam is not unlike route flaps in this way, i suppose.) But this debate (I'm not debating with *you*) keeps coming around full circle. Perhaps the real social problem is convincing whatever standards bodies and vendors necessary that it is a technical problem. i think it's clear that everybody wants it to be somebody else's problem. There seems to be far too much apathy (FUD?) rather than just designing a partial solution, however imperfect, and implementing it. as the designer of several partial solutions which have been implemented, i agree from experience. spam's assymetric cost:benefit ratio (between a spammer and a victim) really institutionalizes apathy. the benefit to one spammer in being able to outwit a defense is a measurable success in that day's events. the benefit to one victim in being able to erect a defense which stops one kind of spam or spam from one source or what have you is immeasurably small compared to the deluge of other crap that'll come over the gunwales in the same diurnal period. no solution which does not progressively leverage the combined small efforts of millions of spam victims will ever be measurably effective other than in some small locality and/or for some brief instant. see the DCC for an example (http://dcc.rhyolite.com/) of how to build and apply that leverage. (i'm not giving the reference to vipul's razor because i said millions.) -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
I still think that it causes problems for mailing lists. I understand the proposal to be based on the envelope sender, not the sender in the body. Hence, mailing lists work, because they are the envelope sender, not the person who submitted the mail to the mailing list. numerically speaking, most mailing lists are simple exploding forwarders on par with a sendmail aliases entry. in this case the envelope sender won't change at forwarding time, and this would cause a problem if it were possible to repudiate mail sources. such mailing lists would have to change from list: person1, person2, ... to list: |sendmail -flist-request person1 person2 ... list-request: postmaster and that's what http://www.vix.com/~vixie/mailfrom.txt means when it says This could scale poorly and may add pressure toward transport remailing (with a new envelope) rather than transport forwarding (reusing the old envelope.) If that is not the case, then Paul needs to be hassled until the wording is clear that mailing lists will continue to work. i don't think sendmail.cf code fragments are equivilent to IOS command line fragments. in other words nothing from this thread can be cut and pasted into mr. bush's router (or anybody else's router). there are other lists which are way more appropriate than nanog for discussion of spam, and even the mailfrom proposal. i mentioned it not because it needed a hearing -- it had already been heard on those very other lists i mentioned -- but to demonstrate that the most powerful force on the internet is someone who says something won't work. thank y'all for your help in the demonstration. -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
[EMAIL PROTECTED] (Paul Vixie) writes: whenever you get spammed, it's because some isp somewhere is a slacker, what i meant to say was whenever you're getting repeat spam from the same place, day after week after month, it's because some isp somewhere is a slacker. any given isp can be attacked and used to send outbound spam. but not every isp can be used in this way over and over by the same bunch of people. to the second group, i say: please shift the cost of dealing with spam from your network, back inside your network. -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
In the fullness of time, the universe itself will die of heat. So what? How come this makes me want to raise the issue of our immortal souls? spammers have souls? So for example saying this or that filter appears to have repelled 1M spam msgs per day doesn't really prove much unless one can say with some (preferably mathematical) confidence that it's actually reduced spam not just caused it to flow around the filter. Put another way it'd be nice to know that a technical approach was statistically superior to just shutting off SMTP for an hour per day which would also block some amount of spam. Look! Not one single piece of spam from 1AM-2AM (while we had our machinery all turned off.) i measure success by the fraction: rejected_spam / total_spam thus if i can reject 6000/1 that may not seem better than rejecting 1000/4000 since i ended up dealing with 4000 received spams rather than 3000, but it actually does mean that my situation got better _compared_to_having_done_nothing_. (those are weekly figures for my own personal server; hotmail sees the same numbers in less than one second, which helps understand the importance of total rational impact rather than simple absolute unrejected volume.) (once postfix supports dcc i expect to see it change to 8000/1, btw.) Maybe there is no technical solution, of any value, possible (at the system / DoS level, not talking about individual approaches like whitelisting.) I'm quite serious. i know you are, but i think the better statement would be there is not going to be a single long term solution, either technical or nontechnical. we're going to see a lot of point solutions, as each participant seeks to shift the costs of handling unwanted e-mail away from themselves. My point is that I think we really need to start focusing on solutions which aren't primarily or solely technical. the folks at http://spam.abuse.net/ and http://www.cauce.org/ and even http://www.spamcon.org/ would be alarmed to hear you say that they've been focused on purely technical solutions all these years.
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
... (http://dcc.rhyolite.com/) ... Indeed, that is a cool idea. I definitely want to look into that a lot more closely. Perhaps we can combine this with deep blacklist checking (beyond just the first hop), tagging, and Bayesian content filtering. Perhaps then we will have a temporary pass at a semi-decent anti-spam filter. be careful when you gang things together. spamassassin seems to be a considered approach, but that doesn't mean more is always better. as has oft been said of PRNG's, adding complexity usually subtracts from the quality. if you combine too many kinds of spam filtering together then you'll have that much more trouble figuring out what to tune when you get a false positive.
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
http://catless.ncl.ac.uk/Risks/22.19.html#subj7 http://catless.ncl.ac.uk/Risks/22.21.html#subj4 There must be a balance. Mistakes happen. How overzealous do you want ISP's to be be at shutting off spam sites or accounts? Some might consider the costs of mistakes acceptable, but are they the majority? Or a minority? zeal must become the norm. there are too many legitimate sources of error to make any loose assumptions about probable illegitimacy when faced with a report. under a high zeal regime, errors will be made until training and policy and toolworks all catches up to the need. -- Paul Vixie
Re: ospf problems?
[EMAIL PROTECTED] writes: Why do we let RIchard Sexton get away with posting this kind of insulting drivel to the list? in my specific case, it's because i've configured my user interface in a way that allows me to live on an internet that does not have certain people in it. (no, my .procmailrc is not for sale, so go make your own.) in the general case, we let this happen because there is no procedure for excluding folks from the list on any basis, including insulting. -- Paul Vixie
Re: How do you stop outgoing spam?
One of the basic problems with discussions about spam control is that it focuses entirely on spam. Blocking output SMTP from individual dial-ups has a serious negative consequence: Laptop mobile users cannot use their home SMTP server. in the business, we call this tough noogies. At best, they must reconfigure for each venue -- goodbye wireless hotspot convenience -- and that is IF they know the SMTP server address for the local access. i've gotten very good mileage out of ssl-smtp, and out of port forwarding so that my laptop uses 127.0.0.1:25 for outbound mail, which is actually a (ssh-borne) tunnel to my home smtp server. In other words, by blocking output SMTP, mobile users are hurt badly. I know that *I* certainly am. Constantly and serously. yes. let me take this opportunity to thank you for your significant contributions to smtp and of course rfc822. i'm sorry that you have to be hurt now. but the design calls for a polite population, and while that was true of the internet in 1983, it is absolutely not true today. the nonpolite nature of the overall population means that you will have to be hurt and you will have to change how you use mail in order to make the pain stop. there's a slight choice on the pain menu -- you can have (A) an unusable mail system clogged with unwanted traffic such as spam and viruses, or (B) a barely-usable mail system where everything you want to do is less convenient because you have to use ssl-smtp and ssh tunnels. either way you have to be hurt now. and that saddens me, it really does.
Re: How do you stop outgoing spam?
[EMAIL PROTECTED] (Barton F Bruce) writes: A twist we saw spammers using on dialup accounts in Miami could come to cyber cafes and could be ugly. They were dialing in and then using the IP address to send spam out some other connection elsewhere where RPF wasn't in use. The return packets all came back on their dialup into us, but bypassed our filters that were then only on outbound packets. this has been going on for some time. the example you gave of an OC3 used for outbound-only tcp streams is noncontrived and has been seen more than twice. it's been a year or so, so i'll renew my question. is anybody, anywhere, including as a term of their peering agreement things like must have a responsive abuse@ mailbox and act credibly to prevent spammers from becoming or remaining customers or must filter both bgp advertisements and ip source addresses from all customers, and require them to do likewise? and if not, why not, and how long do you think it's going to take before we use economic methods to solve this scourge? -- Paul Vixie
Re: Cogent service
Does anyone have any comments (good or bad) about Cognet as a transit provider in New York? No. But we (ISC) are using them in San Francisco (at 200 Paul Street) and they've been fine. -- Paul Vixie
Re: AP IX locations
I would confirm GM's assertion. Also, if you have the luxury of caring more about a smaller set of large-capacity Tier1 private peers, there is some presence of AsiaPac providers doing this at Equinix SJ. Actually Equinix-Los Angeles has more Asian based Networks coming in for turn-up in October than any other region from details gathered this week. Chunghwa is in as of this week. SingTel, Japan Telecom, Hanaro, are on track for peer-ready in October. DACOM is considering, etc. so what does that make telehouse-la after all these years... chopped liver? there have been Plenty of asian isp's in los angeles for Quite a while now. there also seems to be a PAIX switch inside 1 Wilshire now. (mfn's chap.11 filing having sawn off any hope we had of opening PAIX-LA.) -- Paul Vixie
Re: AP IX locations
I have heard that the new paix switch will be attached [to laap] as well. But only rumored not sure if its true. it's true. there was a launch party recently when the paix switch was announced for 1 wilshire, and laap was absolutely mentioned along with the words just like seattle with regard to ix interconnect. paix is late with interconnect to nyiix and ames due to fiber delays, but there ought to be no such delays for a 1 wilshire switch.
Re: Equinix to join role of chapter 11's?
reports of equinix's demise appear to have been grossly premature. see http://biz.yahoo.com/bw/021002/20088_1.html, whose title is something like: Equinix Gains Strategic Investment From Singapore Technologies Telemedia and Creates the Largest Global Network Neutral Internet Exchange Services Company Equinix to Merge i-STT and Pihana Pacific into its Internet Exchange Services Business; Equinix to Retire Approximately 80% of its Outstanding Bonds and Receive New Cash Investments of $30 Million i'd like to publically congradulate equinix on getting this deal made. it will be good for them and their shareholders, but even more importantly it will be good for their customers and even their competitors. neutral data centers that aren't just shellcore, once thought to be a waste of capital because of the lack of upsell, are going to be the biggest survivors after the dot-bomb mess. re: From: [EMAIL PROTECTED] (Pawlukiewicz Jane) Date: 12 Sep 2002 15:08:45 - ... I just got word of this last night. Here's the publication and the story for any who are interested: http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2002/08/30/BU117189.DTLtype=business I certainly hope this doesn't happen.
Re: Who does source address validation? (was Re: what's that smell?)
[EMAIL PROTECTED] (Sean Donelan) writes: If there is a magic solution, I would love to hear about it. Unfortunately, the only solutions I've seen involve considerable work and resources to implement and maintain all the exceptions needed to do 100% source address validation. I had no idea this was so hard. I guess the people who maintain AS3557 (or AS6461 for that matter) do such a job of making this _look_ easy that I just naturally thought it _was_ easy. Forgive my simple minded approach, if it really is simple minded, but... any given interface or peering session or whatever is either customer facing, peer/transit facing, or a trunk which leads ultimately to more customer AND more peer/transit facing interfaces elsewhere in the network. On customer-facing connections, there's a short list of things they should be allowed to say as IP source addresses. (They might be multihomed but chances are low that you want them giving transit to other parts of the network through you, no matter whether you do usage sensitive billing or not.) On transit/peer facing connections, there's a short list of things they should NOT be allowed to send from (your own customers, chiefly) and a short list of things you should NOT be allowed to send them from (RFC1918 being the big example.) Because F-root's network operator was filtering out inbound RFC1918-sourced packets, I could only see them at C-root. Now, F-root can also see them, so I can once again collect stats from (and complain about stats from) both. RFC1918 routes are allowed to float around inside AS3557, by the way, since customers use them for VPN purposes. So we don't filter out ingress 1918 from customer-facing interfaces; instead we filter out egress 1918 toward our peers/transits. Like I said, I had no idea this was generally thought to be so complicated. -- Paul Vixie
Re: Who does source address validation? (was Re: what's that smell?)
[EMAIL PROTECTED] (Sean Donelan) writes: If c.root-servers.net provider did this, they wouldn't see any RFC1918 traffic because it would be dropped at their provider's border routers. Right. But then I wouldn't be able to measure it, which would be bad. If c.root-servers.net provider's peer did this, again c.root-servers.net provider wouldn't see the rfc1918 packets. This is the single case where not being able to measure/complain would be OK, because the problem wouldn't be in the core, it would be (correctly) stopped at the source-AS. So why doesn't c.root-servers.net provider or its peers implement this simple solution? Its not a rhetorical question. If it was so simple, I assume they would have done it already. C-root's provider is also C-root's owner, and they have offerred to shut this traffic off further upstream, as F-root's network operators were doing until yesterday, but I asked that it not be filtered anywhere except C-root itself (where I can measure it) or distant source-AS's (which is where it makes sense.) -- Paul Vixie
Re: Who does source address validation? (was Re: what's that smell?)
Just out of interest how do you co-ordinate use of RFC 1918 addresses and routes amongst your customers? Do you run a registry for them, or do you just let them fight it out and the one with the biggest packets wins or something like that? there's a registry. we also maintain IN-ADDR zones for them and encourage the use of stub zones in customer name servers in order to direct their queries toward the local RFC1918 registry. now, i'll admit that it took almost two hours to get this working initially, and almost a week for it to settle down, and that the network is small -- only about 50 customers. but for the last few years no RFC1918-sourced traffic, nor any RFC1918-IN-ADDR DNS query, has egressed from this network. it can't be THAT hard.
Re: sprint passes uu?
[EMAIL PROTECTED] (Shawn Solomon) writes: I'm curious to know how many of those UU customers are just waiting for their contracts to expire before giving them the big F.U. transit prices have been in free fall, and worldcom has not been following them downward. however, after the cleansing ritual of chapter 11, i think they will be in a fine position to reset their per-megabit charges in ways that make them a compelling transit provider. their network's been great. -- Paul Vixie
Re: sprint passes uu?
i wrote: transit prices have been in free fall, and worldcom has not been following them downward. however, after the cleansing ritual of chapter 11, i think they will be in a fine position to reset their per-megabit charges in ways that make them a compelling transit provider. their network's been great. several people answered me, privately. i'm going to respond publically but preserve anonymity: But WorldCon billing is a nightmare. We'd really like to stay connected to UUNet, but WorldCon's inability to bill us in accordance with our contract and insistance that we pay bills they know are complete works of fiction make it really difficult. there is a curious mixture of fact and fiction in the general response to a uunet bill. in their version of banded rates, you don't know what rate you will owe until the end of the month, but you pay your commit at the start of the month (or at least that's what MIBH was doing, since the overall costs were lower in that case). i usually found that if i read my uunet bill by candlelight during a new moon, i was able to figure out what it all meant and tie it all back to some kind of reality. i know that there are also just plain errors in some of the bills i've been a third party to. however, these errors are no wierder than the ones on my SBC/PacBell frame relay bills. remember as you read these things that IP providers are resisting commodotization, and that means they have to give out quotes, contracts, and invoices that do not map apples to apples against a competitor's quotes, contracts, or invoices. this is creativity for the sake of creativity, and i'd like to see it end, but i don't know how or when that can happen. the real debate is about actual measured cost per bit or per bit-kilometer, and to that end, this next anonymized reply attempts to go there: I got Worldcom to quote me $170/meg for a 100Mb commitment about a month ago. If that's not freefall, I don't know what is. that's not freefall. get yourself a quote from cogent or level(3), for examples. at $170/Mbit for 100Mbit/sec commit you are either paying for name brand or you're paying for quality of on-net service to their other customers or you're just plain getting brutalized. note that $170/Mbit is actually below cost for any network smaller than sprint's or uunet's, once you figure in the people, the routes, the rent, and the depreciation, and then fuzz it based on economies of scale. however, the market hasn't bottomed yet, and most people still don't know what their costs are. once we bottom out and start regenerating, $200/Mbit to $300/Mbit for wholesale high-commit transit is going to be just about right, given the single-digit NPM that you get from high capital long term commodity plays. let's talk about network quality, though: their network's been great. modulo a couple of recent multi-hour meltdowns (one nationwide one regional), yes. i can remember similar meltdowns in sprint, teleglobe, abovenet, mci, cw, psi, qwest, and att (both voice and data for att). most of these networks were grown immaturely, without offline simulation of either current or proposed changed topologies. indeed, most of them are too large to simulate offline, so the only system level testing they get is the live kind. equipment vendors and routing protocols have been in continuous flux. periodic meltdowns do not indicate either incompetence or lack of investment, merely that there's been more growth than was sane. (in other words, the dotcom overshoot in networking was technical, not just fiscal.) uunet's network is still as good as they come, and the people who keep it running are still near the top of the field. (though i understand there's been some personnel runoff during the chapter 11.)
Re: future transit prices
someone wrote, in response to my piece this morning... Can you explain more about why you think transit prices will return to the $200-$300/mbps. I've been quoted $40/mbps on a 50mbps commit (95th%) ... which I think is pretty much as low as it's going to get. I can understand prices going back up near $100/mbps over time, but $200 is much more than I'm expecting. the way i think about this is that somebody has to carry the traffic to wherever it's got to go. with a top tier of huge networks, the pricing model gets smoother in two ways: (1) the distance insensitivity in sales has a larger set of costs to average against; and (2) cost per bit-kilom goes down as pipe size goes up. however, the cost per bit per second of switching these is relatively constant over time (people, rent, depreciation or lease of equipment). a non-top tier provider who wants to get into the game will not be able to make money at market prices until they fill their network to a certain crossover point. (and if you buy your pipes too small you can't get there at all, and if you buy them too large then you can never fill the whole thing.) a lot of networks, both top-tier and non-top-tier, have been selling transit without being able to determine their costs other than at a very gross level. the thought seems to have been, we have to charge what the market will bear, and hope we're the last ones standing. but i think we, as an industry, have pretty much burned all the cash we'll be able to burn in that way. when i look at the ingredients: worldwide presence (peering points, pops, whatever) worldwide L1/L2 costs between pops staff (engineering, operations, management, sales, marketing, etc) capital (for all those pops) rent (of things that aren't pops, like HQ offices) marketing, legal, travel, other goo and so on it looks to me like you could run an OC48 backbone at 60% capacity and make a sustained single digit NPM selling at $250/Mbit average, or you could do an OC192 backbone at 60% capacity and single digit margins at maybe $175/Mbit. perhaps an OC768 backbone running at 60% will be able to make single digit NPM at $100/Mbit, but i'm really reaching on that one. doing it for less involves either (a) not knowing your costs yet, or (b) buying market share, or (c) cost containment strategies like using assets that have been recently through the cleansing ritual of bankruptcy, or (d) selling ahead of usage like getting 100Mbit/sec commits from a lot of 20Mbit/sec customers. none of those things lasts forever. Regardless of which of us is right, I guess I'm still pretty safe if I lock in todays rates for multiple years. oh yeah, oh yeah, oh yeah.
Re: future transit prices
How do you compute CGS on a network that is 25% utilized? bad Is it expenses/current utilization or expenses/maximum capacity? i want to be in a situation where i owe income taxes. so it's all about costs vs. sales. I think a lot of the low-ball pricing that is in the market is the result of networks selling off underutilized capacity at discounted pricing just to get some additional cash flow. in other words, people don't know what their costs are, so any sales are good. this is one of the situations that can't last. This pricing probably doesn't take into account the necessary capex that will be required to upgrade the network when it approaches saturation. actually it assumes that equity funding will be available for step functions in capacity as long as the underlying business is returning high single digit NPM. (that's how large-capex commodity plays work, since share price will be a function of P:E.)
Re: root servers DDoS
[EMAIL PROTECTED] (Sean Donelan) writes: Best guess, its a smurf attack. Networks which still have ip directed-broadcast (or your vendor's equivalent) enabled on interfaces. Its still amazing how much traffic it can generate. however, this attack was icmp request, not icmp reply. -- Paul Vixie
Re: WP: Attack On Internet Called Largest Ever
(Okay Paul - here's your chance to rant about how badly they misquoted you! Grin) I think it's clear that editors were involved. -- Paul Vixie
Re: How to secure the Internet in three easy steps
Assuming no time, money, people, etc resource constraints; securing the Internet is pretty simple. 1. Require all providers install and manage firewalls on all subscriber connections enforcing source address validation. 2. Prohibit subscribers from running services on their own machines. Only approved provider managed servers should provide services to users. 3. Prohibit direct subscriber-to-subscriber communication, except through approved NSP protocol gateways. Only approved NSP-to-NSP proxied traffic should be exchanged between network providers. Are there some down-sides? Sure. But who really needs the end-to-end principle or uncontrolled innovation. i can see how the end to end principle applies in cases 2 and 3, but not 1. -- Paul Vixie
Re: How to secure the Internet in three easy steps
1. Require all providers install and manage firewalls on all subscriber connections enforcing source address validation. i can see how the end to end principle applies in cases 2 and 3, but not 1. I didn't make any of these up. They've all been proposed by serious, well-meaning people. i recommend caution with your choice of words. apparently not everyone treats well meaning as the compliement that it is. If you have 2 and 3, why do you need to waste global addresses on 1. i don't believe that 2 or 3 will ever happen, for simple market reasons -- it is harder to make money if you do 2 or 3. however, 1 only costs a small bit of ops expense, and has no market impact at all, so it's practical in simple economic terms. Its a mis-understanding of what source address validation is. Some folks think it should work like ANI, where the telephone company writes the correct number on the call at the switch. ouch. i guess you're right. perhaps a copy of BCP38 should come with every router sold?
Re: How to secure the Internet in three easy steps
not just the bad people. all the people. a network with 2 or 3 in place is useless. there is no way to make 2 or 3 happen. As part of their anti-spam efforts, several providers block SMTP port 25, and force their subscribers to only use that provider's SMTP relay/proxy to send mail. Why not extend those same restrictions to other (all) protocols? each protocol that becomes as widely abused as smtp has been, will be blocked, since blocking will save the ISP money. you also mentioned proxying of web traffic, which due to banner ads often makes the ISP money. this whole thing is really about money. but 1 isn't getting done because the money that could be saved is by ISP B whereas the money which must be spent is by ISP A. so, the nondeployment of BCP38 is all about money, too. the thing i'm trying to work my way back to is that 2 and 3 can be argued to restrict desireable freedoms (like reaching SMTP or WWW servers without being forced to use a local proxies) whereas 1 has no arguments against it, or at least no arguers here on nanog today. why lump them all three together? PS. you mentioned AOL, which uses IP framing in order to leverage off of the IP stack already present in their customer's computers, but other than that it's a captive application. what addresses are used doesn't really matter there in any global sense, nor proxies or nats or whatever.
Re: How to secure the Internet in three easy steps
Source address validation, or more generally anti-spoofing filters, do not require providers maintain logs, perform content inspection or install firewalls. But source address validation won't stop attacks, viruses, child porn, terrorists, gambling, music sharing or any other evil that exists in the world. So the proposal 1 gets extended to include other stuff. It gives better ROI when more than SAV is included. i can see how this could happen. however, i do not think that it is the reason why SAV is not gettign deployed.
Re: who are the root server operators?
If the roots are once again under attack - how will the root server operators be contacted by a frustrated isp who can't resolve. as valdis points out, 12 operators getting e-mail from 12,000 frustrated isp's is probably not the best way to do this kind of notification. as to who the root server operators are, http://root-servers.org/ has a list. valdis writes: And remember - Paul Vixie has shown that 10% of the inbound traffic at c.root-server.net is bogus rfc1918 sourced. Making the addresses public will serve as a DDoS vector against the root operators moreover, duane wessels came to eugene last week to tell us that only 2.1% of the queries hitting F-root were valid. there's got to be a way to make that better. here's a question. is your authoritative name server set up properly? by that i mean: (1) is recursion disabled, and is it listed only in NS RR's, never in resolv.conf or dhcpd.conf files? (2) is fetch-glue disabled (or if not, does your firewall permit F-root to answer your sysqueries?) -- Paul Vixie
Re: Fw: Where is the edge of the Internet?
Where is the edge of the Internet? here's what i came up with while trying to explain the edge elsewhere. 1 - Connection Taxonomy 1.1. The Internet is a network of networks, where the component networks are called Autonomous Systems (AS), each having a unique AS Number (ASN). 1.2. Connections inside an AS are called Interior (or sometimes backbone), and their security policies are set according to local needs, usually based on business or technical requirements. 1.3. Connections between ASs are called Border (or sometimes peering), and their security policies are set bilaterally according to the joint needs of the interconnecting parties. 1.4. Connections between an AS and its traffic sources (generators) and traffic sinks (consumers) are called Edge (or sometimes customer), and their security policies are generally, by long standing tradition, nonexistent. -- Paul Vixie
Re: Fw: Where is the edge of the Internet?
1 - Connection Taxonomy 1.1. The Internet is a network of networks, where the component networks are called Autonomous Systems (AS), each having a unique AS Number (ASN). Even if this reflects the original intent of ASNs, it certainly does not fit current reality. it is (a) accurate to the original definition, and (b) relevant to finding the edge. everything else you added: Let's call any set of networks under a unified administrative control an Autonomous Routing Domain (ARD). ARDs should not be confused with ASes (an implementation detail). They are distinct for these reasons: 1) Most ARDs do not have an ASN -- they are statically routed at the edge. 2) Many networks at the edge use private ASNs. 3) Many ARDs share a provider provided ASN -- RFC 2270. 4) Many ARDs are implemented with multiple ASNs. Internap is probably an extreme example. But even UUNet's global ARD (AS701, 702, 705 ...) reflects an implementation choice (one that Sprint does not seem to follow with 1239, for example). ...is also completely true, and points to a possible need to upgrade the terminology in general use. however, for the purpose of finding the edge, the original (and still officially current) definition of ASN will serve.
Re: PAIX
Equinix and SD (PAIX) will be the new peering exchanges. I hate to think how many exchange points that leaves out. Telehouse and Terramark come to mind. Even if there are some dominant players, domestic neutral exchange points are still a diverse, vibrant market. Question is, outside of 6 exchanges domestically, what scenario would force a move to doubling that to 12. Long haul circuits rising again, or perhaps some new killer app. Right now seems domestically 6 may be all we need. I'm putting the number closer to 40 (the NFL cities) right now, and 150 by the end of the decade, and ultimately any metro with population greater than 50K in a 100 sq Km area will need a neutral exchange point (even if it's 1500 sqft in the bottom of a bank building.) -- Paul Vixie
Re: PAIX
I'm putting the number closer to 40 (the NFL cities) right now, and 150 by the end of the decade, and ultimately any metro with population greater than 50K in a 100 sq Km area will need a neutral exchange point (even if it's 1500 sqft in the bottom of a bank building.) What application will require this dense peering? today, we need this dense peering to keep local traffic local just with apps that folks already run. kazaa and gaming are examples where isochrony or high volume bidirectional peer-to-peer traffic are already present, but the fact is that hub spoke is a better topology for a metro than for a region, even where http/smtp/ftp are still the primary applications. going forward, movies on demand and other things that we currently use satellites or cable TV systems for. voip. internet-delivered radio, using things like 802.11 and bluetooth as the last mile. i want a Dick Tracy wristwatch and i know that thousands of other people will want it too and i can do the arithmetic to see that there will be more than one (probably more than several) providers per metro, even in small metros, and that if their closest exchange point is in some other metro, it can't take off. someone mentioned SIX. but a peering switch does not an exchange point make. without a PNI upgrade path, which means a certain amount of hard colo, the ceiling is too low. (that's one reason why ATM-based metro exchanges are not growing very fast, and why nobody is building new ones any more.)
Re: PAIX
speaking of paix, for those of you in atlanta (ietf) this week, i'm going to do a couple of site walkthroughs. send me e-mail if interested. -- Paul Vixie
Internet Software Consortium expands DNS ''Root Server'' Footprint
http://www.businesswire.com/cgi-bin/f_headline.cgi?day0/223210010ticker=
Re: PAIX
daniel wrote: With the impending SD buyout of some of PAIX's assets, do you see PAIX Atlanta as a going concern? I know SD owns an adjacent floor at 56 Marieta. Do you think they will hold on to both? until the bankruptcy court's auction runs its course, we don't know who the new owner of PAIX will be. in any case, i can't speak for SD at this time. I am curious, as my company has a POP in PAIX Atlanta, and we are starting to do some contigency planning. it's very likely that SD would like to talk you about those plans, and that with appropriate NDA's in place, they would tell you more about PAIX-ATL1's likely future under their ownership. paul re: speaking of paix, for those of you in atlanta (ietf) this week, i'm going to do a couple of site walkthroughs. send me e-mail if interested. -- Paul Vixie
some of these are worse than others
in the last few months since i most recently cleared out the database, my test network (a defunct /16) has received 3.8M http transactions containing 460K distinct worm bodies sent from 137K source addresses. the top 8, by quantity, are: srcaddr | count |first|last -++-+- 61.137.107.137 | 300772 | 2002-11-05 13:29:26 | 2002-11-14 03:19:42 210.82.7.205| 72755 | 2002-11-13 14:12:00 | 2002-11-14 11:23:07 210.12.30.12| 32450 | 2002-11-01 08:34:09 | 2002-11-01 09:04:10 24.193.82.174 | 31996 | 2002-10-30 11:56:58 | 2002-10-30 13:07:11 131.204.108.181 | 22524 | 2002-11-18 17:33:04 | 2002-11-18 18:05:13 24.76.78.204| 22305 | 2002-10-30 12:13:39 | 2002-10-30 13:26:52 80.11.57.19 | 11379 | 2002-11-01 09:34:01 | 2002-11-01 10:49:20 63.142.226.235 | 10178 | 2002-11-08 12:51:44 | 2002-11-08 13:42:06 if you see one of your own up there, please put your hands on some lineman's shears and Do The Right Thing.
Re: Suggestions for ASP colo space that will be around in 3 years?
Should have mentioned - West Coast. Currently in San Jose area. LA would be OK, too. PAIX has a switch at 200 Paul Street, San Francisco (which is excellent for dogs and ponies, since there's no wasted money on man traps but there's a huge investment and obvious attention to detail everywhere else.) There's also Telehouse, in Santa Clara and Los Angeles. (I'm not suggesting PAIX Palo Alto because if you're an ASP you probably want more than 10 racks and you're probably planning to generate host-level heat from all of them.) None of those places will be kicking anybody out, within three years, or likely ever. (The qualification you should be looking for is cash positive.) Elsewhere in San Francisco, the landlord of Abovenet's old 365 Main facility is planning to reopen it -- see www.365inc.com for some details. (The meet-me room there was originally built to be a PAIX, and we were very proud of it.) -- Paul Vixie
Re: latest variety of Nigeria scam
+00 2002-11-19 15:36:16.225663+00 2002-11-19 17:17:01.467071+00 2002-11-19 19:23:00.98376+00 2002-11-19 22:44:00.711835+00 2002-11-20 16:16:01.493607+00 2002-11-21 10:22:00.546075+00 2002-11-22 17:56:20.813854+00 2002-11-23 18:01:00.899021+00 2002-11-23 19:20:09.851698+00 2002-11-24 03:01:03.83128+00 2002-11-26 01:45:00.453031+00 2002-11-26 16:48:35.607394+00 2002-11-26 21:53:00.577529+00 2002-11-26 22:04:01.48337+00 2002-11-27 03:01:00.788446+00 2002-11-27 09:13:01.014489+00 2002-11-27 14:20:01.481803+00 2002-11-27 16:54:00.894385+00 2002-11-28 17:20:06.519182+00 2002-11-28 18:15:00.012437+00 2002-11-28 20:26:05.306043+00 2002-11-29 18:42:54.376971+00 2002-11-29 19:16:40.72875+00 2002-11-29 20:48:00.96248+00 2002-11-30 01:29:56.306843+00 2002-11-30 01:39:28.335664+00 2002-11-30 16:51:56.698874+00 2002-12-01 00:40:30.625981+00 2002-12-02 05:40:01.141171+00 2002-12-03 15:28:20.540452+00 2002-12-04 01:51:23.235295+00 2002-12-04 01:52:18.631874+00 2002-12-04 03:48:01.543832+00 2002-12-04 15:19:01.29778+00 2002-12-04 16:56:01.398744+00 2002-12-05 02:04:28.731864+00 2002-12-05 02:39:01.039261+00 2002-12-06 13:34:01.304566+00 2002-12-06 19:18:16.930703+00 2002-12-06 19:27:04.795367+00 2002-12-06 19:36:18.116943+00 2002-12-06 20:13:11.24717+00 2002-12-06 20:21:55.262627+00 2002-12-07 16:22:00.914884+00 (398 rows) -- Paul Vixie
Re: AOL Cogent
... trying to even out a perceived inequity ... peering is a business decision. if it's possible to force another network into the role of customer, then that's seen by many as good business since revenue increases. paid peering or even settlements are not about inequity, perceived or otherwise; rather, it's about not leaving money on the table. -- Paul Vixie
Re: AOL Cogent
The perceived money on the table frequently doesn't exist and attempts to get it may produce the opposite result. well, yeah, sure, but... * Who they shift the traffic to may be your competitor. ...at least you know they are paying SOMEBODY, thus supporting the market you want to be in. you can then compete in that market. if everybody who could peer in N places worldwide could just get peering, then all kinds of per-bit revenue for high tier network owners would turn into per-port revenue for exchange point operators. where's the market in that? how could a high tier even exist in those conditions? If you assume the above three cases are costs and you add that to the cost of the decreased efficiency of traffic to the target network you can compare it to the probability that you can sell service to the former peer. Depending on the relationship, you can guess the likelyhood. well, that's a technical consideration, and as such won't matter until we've burned through some of the overcapacity from the dot-bomb era. right now it's possible to do gaming and voip and other isochronous applications via a transit provider who can backhaul your traffic 1500 miles (or 6000 miles) to some centralised peering point and still have reasonable performance. we will need to 1000X the traffic volume again before this stops working again. which should take about a year.
Re: AOL Cogent
... if everybody who could peer in N places worldwide could just get peering, then all kinds of per-bit revenue for high tier network owners would turn into per-port revenue for exchange point operators. ... Well, I think as a local operator you can not expect to be able to peer with everyone to receive global routes but theres no reason not to exchange local routes comparable to the area your own network covers, this wont affect transit sales and wont cost you in backhaul either. Thats a slightly different perspective than assuming you can get a providers to exchange all their network with you in a settlement free bilateral. there we go again, talking technology and making the technological kind of sense. peering isn't a technology decision, it's a business decision. as a local operator myself (ISC), i know that i should not expect peering other than if someone wants their customers to have better access to the f-root server or the kernel.org ftp server or whatever. it's actually easier for me, as a nonprofit, to attract what mr. bill calls 'content peering' relationships, since i don't compete with the folks i peer with. however, in a former job, i took the reins of abovenet and used a lot of mfn fiber and mfn resources (back when they had resources to use, that is) and built a network that touched down in more places with more gigawhuppas and more bit-miles and so on than about half of the current so called top tier networks had then (or indeed have now). i surrounded PSI on all sides, with a network that carried more actual traffic and had more provable headroom, and more endpoints. yet they still insisted on playing peering games. (perhaps if they'd won those games they would still exist today?) peering is not about equity, or ratios, or technology. it's about money. sadly, too many people are focusing on their share of the current market rather than on the size of the eventual market, so, short-term thinking pervades the space, and the actual customers who source and sink all this traffic don't ride a curve that looks anything like moore's law. try a thought experiment. take about $450M in vee cee money, buy up a lot of bankrupt capital and routes, hire a bunch of starving backbone engineers and sales/marketing/finance/etc people at downsized salaries, and build a network that attends about 40 major carrier interconnect locations (some internet exchanges, some carrier motels). document the hell out of it, so that when you enter peering negotiations with the current top tier networks you've got attachment A already done and audited. now ask yourself the chances of becoming defaultless and settlement free before you run out of cash. (now, does anybody still think peering is a technology issue?) And definitely to your gamers and possibly your VoIP folks to (depending on details) they will be very fickle on your network connectivity and the quality of local peerings is crucial to these applications, gaming is growing very quickly as more people get flat fee broadband and to a residential access provider I wouldnt underestimate how much it could hurt to increase the path to the servers by a couple of hops. like i said, we're living in the shadow of bankrupt overcapacity, and until we burn it off, cost per bit-mile is going to be too low to measure when compared with cost per peering edge. the next six to twelve months will favour the small number of large peering edges model. once the capital and routes are rightpriced, and transit contracts are rightpriced, and we reach some kind of equilibrium between the value and cost of traffic, then some kind of technological argument about peering might hold some sway.
Re: AOL Cogent
Similarly to peering, a base amount is required to make this crazy thing we all run work. As we've seen with companies like PSI, those who terminate, or loose significant peering generally end up dead. no part of worldcom's failure traces to uunet's decision to restrict their peering back in 1993/1994. in fact, that decision was has been spectacularly successful from a business standpoint. unfortunately, one example does not a trend make. also unfortunately, one example can be terrifically inspiring to others. so while i accept your use of the word generally, i have to say it doesn't look that way to the business people who have quarterly numbers to make and are willing looking at their fellow network operators as possible meat. oh and while i considered PSI's vision faulty, i do not believe that their peering games had anything to do with their failure. (nor do i believe that winning those games would have saved them.) now, let's resolve a point of confusion: ...at least you know they are paying SOMEBODY, thus supporting the market you want to be in. you can then compete in that market. if everybody who could peer in N places worldwide could just get peering, then all kinds of per-bit revenue for high tier network owners would turn into per-port revenue for exchange point operators. where's the market in that? how could a high tier even exist in those conditions? Argument #1, don't peer with the little guy because it takes revenue away from ISP's in general. as a local operator myself (ISC), i know that i should not expect peering other than if someone wants their customers to have better access to the f-root server or the kernel.org ftp server or whatever. it's actually easier for me, as a nonprofit, to attract what mr. bill calls 'content peering' relationships, since i don't compete with the folks i peer with. Argument #2, it's easy for me, a little guy to get peering because I don't compete with the ISP's, I just buy from them. So which is it? Do you peer with the little guys who don't run networks because content peering is good, or do you not peer with them because it forces them to buy from somebody, and if everyone does that it's good for ISP's in general? as a business decision, peering with someone like ISC is a no-op. it neither costs nor makes any money, doesn't shift cost or revenue toward anybody, etc. the two reasons for this are (a) the potential peer is not going to be selling transit (therefore there's no revenue stream to want a cut of) and (b) the potential peer isn't making any porno or other revenue, and so is an unlikely transit customer for its own traffic. It seems to me you want to have your cake and eat it too. actually i'm trying to explain rather than defend. my arm is still cramped from signing 500 peering agreements at a time back at AS6461, and when i next run an international IP backbone i hope to sign 10X as many. peering is good for business, but only if one has no natural monopoly or first mover advantage (like uunet had) that makes alternatives viable, and only if one's vision extends beyond the next quarterly SEC filing.
Re: AOL Cogent
Is it just me or does all this make Internap's Business model look really good? i think it's just you.
Re: DDos syn attack
wow, break bind in a new and horrid way to accomplish this task :) Nice... perhaps mr. vixie will add this functionality for us? patches welcomed. -- Paul Vixie
Re: US-Asia Peering
[EMAIL PROTECTED] (Simon Lockhart) writes: But, given that peering costs are more than just the circuit cost (once you include Exchange Point costs, and colo, etc), why would anyone do this when you can just buy transit for $100/Mbps or less? Because peering is better. There's no way to become DDoS attack-resistant if you buy transit, since no matter how strong you are, your provider will ultimately be weaker. Whether that's because high splay is required to be strong, or because your provider's security team isn't on a two-minute call back, or because your provider has a larger set of things to invest their capital in than your particular path out, doesn't matter. The fact is, no cost-effective transit will ever be as good as the best high-splay peering. I'm going through this at work at the moment, and am having problems justifying staying at the West Coast, having only just justified the East Coast, so going to AP (although it's what I'd want to do), is just way out of the question... OPN (other people's networks) are the second most frequent root cause of connectivity failure. (Network engineers are the most frequent cause, per Vijay's excellent talk in Eugene.) The most reliable access you can get is when you connect to other networks directly rather than using intermediaries. Naturally, with a high number of other networks and of places to meet them, it's only cost effective to peer globally if you have enough traffic and if that traffic's reliability bears directly on your top-line revenue. -- Paul Vixie
Re: PowerDNS open source since 25th of November
[EMAIL PROTECTED] (Pete Ehlke) writes: Many do not know this yet, probably in part due to the helpful moderators of comp.protocols.dns.bind, the DNS operators newsgroup on usenet, who drop messages about PowerDNS. c.p.d.b is not the DNS operator newsgroup, it's the BIND users newsgroup. If promotional material for other implementations is rejected by moderators, that's appropriate, imho. actually, since it has a BIND-compatible mode, it's perfectly appropriate, and in any case the only moderation which occurs is for spam rejection, not content policing. in any case i remember seeing the announcement, so it must have been published somewhere. You want comp.protocols.tcp-ip.domains. sometimes the moderator of that forum tells us that BIND-specific issues do not belong there. it's possible that c.p.d.b is actually the right place for powerdns-related discussions. -- Paul Vixie
Re: Scaled Back Cybersecuruty
[EMAIL PROTECTED] (Pete Kruckenberg) writes: Is there anything happening with collaborative security policy and remediation in the industry? Has any effort showed progress towards an effective ISAC or similar? Can networks realistically collaborate on security, or do the political and operational barriers not justify the effort? i think that kelly cooper's ISP ISAC was doomed in spite of kelly's excellent efforts, simply because the ISP community is too large. an IP Broadband ISAC, and an IP Longhaul ISAC, and an IP Hosting ISAC, and other small/focused isacs, could yet fly. to that end :-), something is happening with a DNS ISAC. (more later.) -- Paul Vixie
Re: US-Asia Peering
what a morass of confusion. on the one hand we have a metro peering fabric, which as linx, exchangepoint, paix, and lots of others have shown, is good. on another hand we have a metro peering fabric, which as mfs and ames showed, can be really bad. because we have a lot of hands we also have exchange-level peering, which as paix and six has shown, can be done safely. there's also a hand containing multiple instances of exchange level peering which was not done safely (and i'm not double counting ames and mfs here.) finally we have intermetro (wide area) peering, which has been shown to be a complete joke for peering for any number of reasons. before any of you argue further, please carefully define your terminology so the rest of us will know how to fill out our scorecards. -- Paul Vixie
Re: US-Asia Peering
[EMAIL PROTECTED] (Kurt Erik Lindqvist) writes: Bill, How do you see the failed AMS-IX expansion fit into this? My (very simplified) summary of what happened was that : ... At the time of the origin of the discussion I was peering co-ordinator at KPNQwest, and would have pulled-out of AMS-IX if the plans (and KQ..:) ) would have moved on. well of course i'm not bill, but (naturally) i will comment anyway. was AMS-IX planning to expand beyond its original metro and bridge all the XP switches together? if so then i understand exactly why KQ and other ISP's would have pulled out of AMS-IX in protest (and in fear). however, if the expansion was intra-metro, then i must be confused, because KQ's major source of bandwidth revenue should have been inter-metro not intra-metro. -- Paul Vixie
