The Cidr Report
This report has been generated at Fri Dec 5 21:47:15 2003 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
28-11-03128347 90330
29-11-03128360 90279
30-11-03128411 90309
01-12-03128392 90290
02-12-03128418 90292
03-12-03128561 90308
04-12-03128539 90397
05-12-03128663 90435
AS Summary
16204 Number of ASes in routing system
6463 Number of ASes announcing only one prefix
1406 Largest number of prefixes announced by an AS
AS701 : ALTERNET-AS UUNET Technologies, Inc.
73591040 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 05Dec03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 128617903953822229.7% All ASes
AS6197 764 265 49965.3% BATI-ATL BellSouth Network
Solutions, Inc
AS4323 678 206 47269.6% TW-COMM Time Warner
Communications, Inc.
AS701 1406 972 43430.9% ALTERNET-AS UUNET
Technologies, Inc.
AS7018 1387 962 42530.6% ATT-INTERNET4 AT&T WorldNet
Services
AS7843 524 122 40276.7% ADELPHIA-AS Adelphia Corp.
AS4134 502 123 37975.5% CHINANET-BACKBONE
No.31,Jin-rong Street
AS6198 610 254 35658.4% BATI-MIA BellSouth Network
Solutions, Inc
AS209859 535 32437.7% ASN-QWEST Qwest
AS22909 317 12 30596.2% DNEO-OSP1 Comcast Cable
Communications, Inc.
AS1239 953 669 28429.8% SPRINTLINK Sprint
AS22773 315 31 28490.2% CCINET-2 Cox Communications
Inc. Atlanta
AS4355 383 101 28273.6% ERMS-EARTHLNK EARTHLINK, INC
AS27364 354 73 28179.4% ACS-INTERNET Armstrong Cable
Services
AS1221 954 677 27729.0% ASN-TELSTRA Telstra Pty Ltd
AS6347 331 85 24674.3% DIAMOND SAVVIS Communications
Corporation
AS17676 283 39 24486.2% GIGAINFRA Softbank BB Corp.
AS25844 243 17 22693.0% SKADDEN1 Skadden, Arps, Slate,
Meagher & Flom LLP
AS6140 346 130 21662.4% IMPSAT-USA ImpSat
AS14654 2062 20499.0% WAYPORT Wayport
AS11305 230 37 19383.9% INTERLAND-NET1 Interland
Incorporated
AS2386 402 218 18445.8% INS-AS AT&T Data
Communications Services
AS4519 194 13 18193.3% MAAS Maas Communications
AS6327 204 28 17686.3% SHAW Shaw Communications Inc.
AS9583 228 58 17074.6% SATYAMNET-AS Satyam Infoway
Ltd.,
AS9929 197 27 17086.3% CNCNET-CN China Netcom Corp.
AS20115 581 413 16828.9% CHARTER-NET-HKY-NC Charter
Communications
AS2048 251 85 16666.1% LANET-1 State of Louisiana
AS15270 203 41 16279.8% AS-PAETEC-NET PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS6478 193 41 15278.8% ATT-INTERNET3 AT&T WorldNet
Services
AS6517 237 87 15063.3% YIPESCOM Yipes Communications,
Inc.
Total 14335 6323 801255.9% Top 30 total
Possible Bogus Routes
24.138.80.0/20 AS11260 ANDARA-HSI Andara High Speed Internet c/o Halifax
Cable Ltd.
61.12.32.0/24AS7545 TPG-INTERNET-AP TPG Internet Pty Ltd
61.12.34.0/24AS7545
Re: MTU path discovery and IPSec
>Is there any discussion on better alternatives to PMTUD such as leaving >off DF and a new ICMP subtype, rate limited, to inform senders that >they've been fragged and at what (call it reverse PMTUD?) ? There is a better alternative that is already used in production. When a router receives packets too big for an outgoing link, it fragments the packets. On the other side of the small MTU link, the receiving router reassembles the packets which are always in the correct order. All you need to do to enable this functionality is to turn on IPv6. Or perhaps you would like to keep on reinventing the same wheel over and over again? >Does IP6 really do away with fragmenting? Is there any current >discussion on all this? What!? Are there still people who haven't at least read one or two IPv6 books? Try Huitema, "IPv6 The New Internet Protocol" or Loshin, "IPv6 Clearly Explained" >I see I have to go do some research. Yes. This http://www.ipv6forum.com/ is the best website to use to find resources. The best slideware I've ever seen on IPv6 comes from the folks at the Technical University of Madrid who presented at the 2002 IPv6 summit. You can get their slides from the agenda page here http://www.ipv6-es.com/02/in/i-agenda.htm --Michael Dillon
Re: Does your Certifying Authority have a clue who you are? Do they care?
>So the long and the short of it is, our CA has *LOST* the >documents showing who we are, and wants new ones. Wow! Have you contacted http://www.geotrust.com about this? I'm sure they would fly people out to Calgary to personally inspect your identity at no charge just for a chance to use your story in the marketing. Check what they're saying about Verisign on their website. The bumbling fools at Verisign are not the only choice for SSL certs. The security ecology demands diversity and competition so that there are always plenty of watchers watching the watchers. --Michael Dillon
Re: Does your Certifying Authority have a clue who you are? Do they care?
While the ssl certificate is meant to verify the owners identity, as a consumer I would never trust a ssl certificate for that purpose. It does provide a reasonable effort to keep information between me and the server confidential. That's worth something, I guess. Adi
Re: Does your Certifying Authority have a clue who you are? Do they care?
>I would never trust a ssl certificate for that purpose. It does >provide a reasonable effort to keep information between me and the server >confidential. That's worth something, I guess. I agree with you, I just don't think this is reasonable. If the CA's aren't going to keep tabs on your stuff (and I'm not just picking on thawte here) and the browsers both don't differentiate between CA's, and make it easy for the user to accept random certificates or bypass the certification mechanism entirely, I don't think it is a reasonable effort. The whole process is flawed. -Bob
Re: Does your Certifying Authority have a clue who you are? Do they care?
Matt Blaze said it well some years ago: "A CA will protect you against anyone from whom it won't take money." --Steve Bellovin, http://www.research.att.com/~smb
Re: Does your Certifying Authority have a clue who you are? Do they care?
On Fri, 05 Dec 2003 09:28:05 CST, Adi Linden said: > While the ssl certificate is meant to verify the owners identity, as a > consumer I would never trust a ssl certificate for that purpose. It does > provide a reasonable effort to keep information between me and the server > confidential. That's worth something, I guess. So what does the PKI actually buy you that using a throwaway self-signed cert doesn't provide? pgp0.pgp Description: PGP signature
Re: Does your Certifying Authority have a clue who you are? Do they care?
> So what does the PKI actually buy you that using a throwaway self-signed cert > doesn't provide? No popup box on the browser asking to accept the certificate. Adi
Re: Does your Certifying Authority have a clue who you are? Do they care?
[EMAIL PROTECTED] writes on 12/5/2003 11:01 AM: So what does the PKI actually buy you that using a throwaway self-signed cert doesn't provide? Less headaches handling hundreds of support tickets that basically say "browser displayed an alert about the cert being self signed", with or without 2 MB bitmap screenshots of the same? srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: Does your Certifying Authority have a clue who you are? Do they care?
On 5 Dec 2003, at 11:01, [EMAIL PROTECTED] wrote: On Fri, 05 Dec 2003 09:28:05 CST, Adi Linden said: While the ssl certificate is meant to verify the owners identity, as a consumer I would never trust a ssl certificate for that purpose. It does provide a reasonable effort to keep information between me and the server confidential. That's worth something, I guess. So what does the PKI actually buy you that using a throwaway self-signed cert doesn't provide? There is an expectation that URLs which do not produce "this certificate is not trusted" messages are safe for people to use to disclose sensitive information like credit card numbers. The average consumer has been educated to this effect at great length by commerce-oriented websites and browser vendors. It doesn't matter whether the expectation is reasonable; what matters is that the expectation exists. If there's a risk that people will be afraid to type credit card details into a merchant's web page, and that risk can be reduced by spending some relatively small number of dollars with a CA, then merchants will spend the dollars, and the myth is perpetuated. You could try and re-educate the market, but since there's no money in teaching people not to trust CAs, it's difficult to see who would do the re-education. Joe
Re: Does your Certifying Authority have a clue who you are? Do they care?
>There is an expectation that URLs which do not produce "this >certificate is not trusted" messages are safe for people to use to >disclose sensitive information like credit card numbers. The average >consumer has been educated to this effect at great length by >commerce-oriented websites and browser vendors. Sorry, this is the night soil of a large and very well fed male ox. Anyone who believes that more than 20% of the users have been educated to do this hasn't gone around spoofing their own https sites on their wireless lans and measuring how many passwords they get. and I'm being *generous* with the 20% - I typically get a valid password 9 out of 10 connections to a spoof site. What lusers have been educated to do is "Oh look, an annoying box has popped up. click the button to make it go away so I can keep going." I seriously doubt they differentiate it too much from popup ads for porn sites or herbal viagra. -Bob
Always renew your domain names
Looks like someone forgot to renew there domain name and another party decided to do it for them, with some slight changes: host 206.108.102.93 93.102.108.206.in-addr.arpa domain name pointer bells-network-has-lots-of-security-holes-to-exploit.bell-nexxia.net
Re: Always renew your domain names
On Fri, Dec 05, 2003 at 11:07:24AM -0600, Mike Hyde wrote: > Looks like someone forgot to renew there domain name and another party > decided to do it for them, with some slight changes: > > host 206.108.102.93 > 93.102.108.206.in-addr.arpa domain name pointer > bells-network-has-lots-of-security-holes-to-exploit.bell-nexxia.net This isn't a lapsed domain registration issue; we're not talking about A records. It doesn't strike you as odd (read 'a security issue') that the PTR records have been changed? -- Luca Filipozzi, ECE Dept. IT Manager, University of British Columbia gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D
Re: Does your Certifying Authority have a clue who you are? Do they care?
On Fri, 05 Dec 2003 10:26:33 CST, Adi Linden said: > > So what does the PKI actually buy you that using a throwaway self-signed cert > > doesn't provide? > > No popup box on the browser asking to accept the certificate. "Pay us $1,000 or we'll annoy your users with popups". Sounds suspiciously like the extortion angle used recently against somebody who was using Windows Messenger pop-op spam to advertise their "stop pop-up spam" product. I'm however missing the actual security angle (remember that the lack of a warning doesn't mean you actually connected securely with who you thought you did). pgp0.pgp Description: PGP signature
New Statistics Format Released
ARIN has been working along with APNIC, LACNIC and RIPE NCC to provide number resource statistics in a unified format and location. The following changes will be made to the existing statistics reporting: - Addition of IPv6 allocations - Report generated daily - Summary lines are included - Reports are signed with GPG key - MD5 hash is provided for verification - Minor changes in format We understand that many researchers have scripts that pull these reports on a regular basis and/or perform analysis based on the current format. To facilitate the change and acceptance of the new format, ARIN will run the old and new format from now until January 5, 2004. We have also included a README file in the directory defining the new format. During this time period the location of the stats will be: Current format: ftp://ftp.arin.net/pub/stats/arin/latest New format: ftp://ftp.arin.net/pub/stats/arin/new/delegated-arin-latest On and after January 5, 2004, the only set of stats will be located at: ftp://ftp.arin.net/pub/stats/arin/latest Comments concerning the publicly released statistics can be addressed on the ARIN DBWG mailing list. A mailing list description and subscription information can be found: http://www.arin.net/mailing_lists/index.html Ginny Listman Director of Engineering ARIN
Re: Always renew your domain names
On Dec 5, 2003, at 12:20 PM, Luca Filipozzi wrote: On Fri, Dec 05, 2003 at 11:07:24AM -0600, Mike Hyde wrote: Looks like someone forgot to renew there domain name and another party decided to do it for them, with some slight changes: host 206.108.102.93 93.102.108.206.in-addr.arpa domain name pointer bells-network-has-lots-of-security-holes-to-exploit.bell-nexxia.net This isn't a lapsed domain registration issue; we're not talking about A records. It doesn't strike you as odd (read 'a security issue') that the PTR records have been changed? It is absolutely a lapsed domain issue. The authoritive (arpa) servers for the netblock in question (and several other bell blocks) are taz and pluto.bell-nexxia.net I registered it last year (after getting sick of waiting for lookups to timeout on traceroutes), created the proper glue records to the original NS's and tried to give it back to bell via all available channels, nobody seemed to care, so I let it expire. -- Luca Filipozzi, ECE Dept. IT Manager, University of British Columbia gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- Matt Levine <[EMAIL PROTECTED]> "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -BIX
Re: Always renew your domain names
On Dec 5, 2003, at 12:20 PM, Luca Filipozzi wrote: On Fri, Dec 05, 2003 at 11:07:24AM -0600, Mike Hyde wrote: Looks like someone forgot to renew there domain name and another party decided to do it for them, with some slight changes: host 206.108.102.93 93.102.108.206.in-addr.arpa domain name pointer bells-network-has-lots-of-security-holes-to-exploit.bell-nexxia.net This isn't a lapsed domain registration issue; we're not talking about A records. It doesn't strike you as odd (read 'a security issue') that the PTR records have been changed? It is absolutely a lapsed domain issue. The authoritive (arpa) servers for the netblock in question (and several other bell blocks) are taz and pluto.bell-nexxia.net I registered it last year (after getting sick of waiting for lookups to timeout on traceroutes), created the proper glue records to the original NS's and tried to give it back to bell via all available channels, nobody seemed to care, so I let it expire. -- Luca Filipozzi, ECE Dept. IT Manager, University of British Columbia gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D -- Matt Levine <[EMAIL PROTECTED]> "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -BIX
Re: Always renew your domain names
On Fri, 05 Dec 2003 09:20:04 PST, Luca Filipozzi <[EMAIL PROTECTED]> said: > > 93.102.108.206.in-addr.arpa domain name pointer > > bells-network-has-lots-of-security-holes-to-exploit.bell-nexxia.net > > This isn't a lapsed domain registration issue; we're not talking about A > records. It doesn't strike you as odd (read 'a security issue') that the > PTR records have been changed? Well, a PTR can point *anywhere* as long as you control the zone. The only thing that made it remotely interesting was this SOA: 102.108.206.in-addr.arpa. 0 IN SOA pluto.bell-nexxia.net. help.bell-nexxia.net. 2003110400 28800 7200 604800 86400 It's interesting that googling for 'bell-nexxia.net' doesnt actually hit anything. Who did you THINK owned that domain and address space? pgp0.pgp Description: PGP signature
Re: Always renew your domain names
On Fri, Dec 05, 2003 at 12:29:49PM -0500, Matt Levine wrote: > It is absolutely a lapsed domain issue. The authoritive (arpa) > servers for the netblock in question (and several other bell blocks) > are taz and pluto.bell-nexxia.net My mistake; replied too hastily. > I registered it last year (after getting sick of waiting for lookups > to timeout on traceroutes), created the proper glue records to the > original NS's and tried to give it back to bell via all available > channels, nobody seemed to care, so I let it expire. I would hope that this would get their attention, but after your attempt, I won't hold my breath. Thanks for clarifying. -- Luca Filipozzi, ECE Dept. IT Manager, University of British Columbia gpgkey 5A827A2D - A149 97BD 188C 7F29 779E 09C1 3573 32C4 5A82 7A2D
Re: Always renew your domain names
On 5 Dec 2003, at 12:20, Luca Filipozzi wrote: On Fri, Dec 05, 2003 at 11:07:24AM -0600, Mike Hyde wrote: Looks like someone forgot to renew there domain name and another party decided to do it for them, with some slight changes: host 206.108.102.93 93.102.108.206.in-addr.arpa domain name pointer bells-network-has-lots-of-security-holes-to-exploit.bell-nexxia.net This isn't a lapsed domain registration issue; we're not talking about A records. It doesn't strike you as odd (read 'a security issue') that the PTR records have been changed? Bell's ARIN records show 102.108.206.in-addr.arpa delegated to nameservers named under bell-nexxia.net, which is a zone that Bell do not currently run. If you believe the dates returned by whois.crsnic.net, "bell-nexxia.net" was only recently registered, while "bellnexxia.net" was registered in 1999. Maybe someone at Bell typo'd nameserver names when they filled out the paperwork for 206.108/20, and someone else got fed up with waiting for them to fix it (and hence the reverse DNS for these blocks). Joe
Re: Does your Certifying Authority have a clue who you are? Do they care?
On 5 Dec 2003, at 11:55, Bob Beck wrote: There is an expectation that URLs which do not produce "this certificate is not trusted" messages are safe for people to use to disclose sensitive information like credit card numbers. The average consumer has been educated to this effect at great length by commerce-oriented websites and browser vendors. Sorry, this is the night soil of a large and very well fed male ox. Anyone who believes that more than 20% of the users have been educated to do this hasn't gone around spoofing their own https sites on their wireless lans and measuring how many passwords they get. 20% of users is more than enough to create a helpdesk nightmare for a web hosting company, and represents sufficient potential lost revenue to make any merchant give money to a CA.
Re: Does your Certifying Authority have a clue who you are? Do they care?
[EMAIL PROTECTED] wrote: On Fri, 05 Dec 2003 10:26:33 CST, Adi Linden said: So what does the PKI actually buy you that using a throwaway self-signed cert doesn't provide? No popup box on the browser asking to accept the certificate. "Pay us $1,000 or we'll annoy your users with popups". The CA does not popup a warning. It is the browser or client application that does this. -- => Mark Foster <[EMAIL PROTECTED]> http://mark.foster.cc/
Re: Does your Certifying Authority have a clue who you are? Do they care?
On Fri, 05 Dec 2003 10:14:48 PST, Mark Foster said: > The CA does not popup a warning. It is the browser or client application > that does this. The three ways to disable the popup: 1) Have the user accept a CA cert for your site. Help Desk Nightmare. 2) Have the user disable the popup. Help Desk Nightmare. 3) Get the top-level-CA cartel to accept your CA cert in the list of ones bundled into IE. Yes, it's a cartel, and yes, actions taken by said cartel are at least partially responsible for the pop-up happening. pgp0.pgp Description: PGP signature
Re: Does your Certifying Authority have a clue who you are? Do they care?
[EMAIL PROTECTED] writes on 12/5/2003 1:28 PM: The three ways to disable the popup: 1) Have the user accept a CA cert for your site. Help Desk Nightmare. 2) Have the user disable the popup. Help Desk Nightmare. 3) Get the top-level-CA cartel to accept your CA cert in the list of ones bundled into IE. 4. For ISPs looking to run SSL sites for their own users - distribute copies of IE and Mozilla / Netscape that have your cert embedded in already. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: Does your Certifying Authority have a clue who you are? Do they care?
Yes, it's a cartel, and yes, actions taken by said cartel are at least partially responsible for the pop-up happening. Is there a documented process for a new CA to get their certs approved/added or is it a clandestine process? Thanks, Deepak Jain AiNET
Re: Does your Certifying Authority have a clue who you are? Do they care?
Deepak Jain wrote: > Is there a documented process for a new CA to get their certs > approved/added or is it a clandestine process? "You are in a twisty little maze of corporate back scratching, all political." Peter
Re: Need Contact at RoadRunner
So, I got an e-mail back from RR after I posted here. They claim to have no specific record of why we were blocked, so they removed it. They said it was probably DOS or a Mailbomb, both of which we would have squelched IMMEDIATELY. Frankly, I think that its pretty poor practice to block someone and not tell them, especially when contact information is clearly available everywhere. We've got e-mail, various phones, and INOC-DBA, so its not that hard to get ahold of us :) --- Tom UnitedLayer Office: 415-294-4111 AS23342
Re: Does your Certifying Authority have a clue who you are? Do they care?
In message <[EMAIL PROTECTED]>, "Peter Galbavy" wr ites: > >Deepak Jain wrote: >> Is there a documented process for a new CA to get their certs >> approved/added or is it a clandestine process? > >"You are in a twisty little maze of corporate back scratching, all >political." > s/political/financial/ I believe. --Steve Bellovin, http://www.research.att.com/~smb
Re: Need Contact at RoadRunner
Tom (UnitedLayer) wrote: Frankly, I think that its pretty poor practice to block someone and not tell them, especially when contact information is clearly available everywhere. We've got e-mail, various phones, and INOC-DBA, so its not that hard to get ahold of us :) When you're introducing thousands of IP blocks per day, it's pretty hard to notify them all.
Re: Does your Certifying Authority have a clue who you are? Do they care?
Thus spake Deepak Jain ([EMAIL PROTECTED]) [05/12/03 15:22]: > Is there a documented process for a new CA to get their certs > approved/added or is it a clandestine process? AFAIK, clandestine. cacert.org has been trying to get their CA included in Mozilla for some time now, but hasn't been able to. It really depends on which browser you're trying to get included in to. - Damian
Re: Need Contact at RoadRunner
: When you're introducing thousands of IP blocks per day, it's pretty hard : to notify them all. I may be reaching here but I think perl scripting can do this. James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Re: Need Contact at RoadRunner
"Tom (UnitedLayer)" wrote: > > So, I got an e-mail back from RR after I posted here. > They claim to have no specific record of why we were blocked, so they > removed it. They said it was probably DOS or a Mailbomb, both of which we > would have squelched IMMEDIATELY. > > Frankly, I think that its pretty poor practice to block someone and not > tell them, especially when contact information is clearly available > everywhere. We've got e-mail, various phones, and INOC-DBA, so its not > that hard to get ahold of us :) I have no idea wahta the facts are here, but as a general statement I'd point out that some of us have recently been in a free-fire zone with more than we can handle coming at us from everywhere. A reasonable reaction to protect own-turf is to plug up holes as you identify the local end of it and wait to see if anybody cares about it after the fire-fight. The likelyhood of being able to contact anybody competent and sympathetic is not worth the time and effort the attempt takes. The usual response back when I thought I should try was "you are not our customer" with the common alternative being "Please reboot and see if that clears it up." YMMV
Re: Need Contact at RoadRunner
On Fri, 5 Dec 2003, Laurence F. Sheldon, Jr. wrote: > A reasonable reaction to protect own-turf is to plug up holes as > you identify the local end of it and wait to see if anybody cares > about it after the fire-fight. So block a /30, not a /24 > The likelyhood of being able to contact anybody competent and > sympathetic is not worth the time and effort the attempt takes. So next time I get portscanned from someone from RR, I should just blackhole their IP space and wait till someone complains about not being able to get to www.apache.org or www.archive.org? Thats totally irresponsible. Unless you like playing whack-a-mole, you need a smarter hammer, not a bigger one.
Evolution of the U.S. Peering Ecosystem v1.1
Hi all - Thanks to those who provided comments to the last white paper draft of "The Evolution of the U.S. Peering Ecosystem". I've made most of the changes and added the data points as suggested, so I am now ready to send out the document more broadly. Lots of acknowledgements in the acknowledgements section now - Thanks!! In a nutshell, the Evolution of the U.S. Peering Ecosystem introduces the notion of the Internet as a set of Regional Peering Ecosystems, each with its own - Tier 1s (who have access to the entire regional routing table solely through peering relationships), - Tier 2s (broadly all other ISPs), and - Content Providers These players are modelled with characteristics (upstream transit links, peering links, etc.) and their motivations (described as Peering Inclinations (Open, Selective, Restrictive, or No Peering) articulated in Peering Policies) that can predict roughly their behavior in the Peering Ecosystem. The "Evolution" of the U.S. Peering Ecosystem is the result of five forces: 1) The so-called dot.bomb - economic collapse of the telecom sector 2) The emergence of a large scale used equipment market 3) The exponential growth of Kazaa traffic costing eyeball networks 4) The failure of @Home - cable companies provide Internet services themselves 5) The rapid decline in transport and transit prices The three major changes roughly are: 1) The Cable companies are peering (with Tier 2s and each other) in a *big* way 2) The Large Network Savvy Content Companies are getting into peering in a *big* way 3) The Large Network Savvy Content Companies are getting their content directly onto the Cable companies eyeball networks by peering relationships. These are significant changes due to the volume of traffic exchanged, the amount of money being saved by avoiding intermediary transit providers, and the performance implications of these direct connections. As promised, if you are interested in this stuff I will gladly send you a copy of the latest draft, v1.1. I'm working on the same exploration for the Asia Pacific Peering Ecosystems (hence the APRICOT Peering Track note I sent out earlier this week). Hope this helps - Bill
Re: Need Contact at RoadRunner
On Fri, 05 Dec 2003 14:30:57 MST, james <[EMAIL PROTECTED]> said: > : When you're introducing thousands of IP blocks per day, it's pretty hard > : to notify them all. > I may be reaching here but I think perl scripting can do this. Yes, a perl script can send thousands of warning e-mails to bogus addresses. If you've got a way for a perl script to get it right, when the WHOIS data is broken, the address block is a /25 sold out of a /22 sold out of a /19 sold out of a /16, and some of the address space is hijacked to boot, please let us know pgp0.pgp Description: PGP signature
Re: Need Contact at RoadRunner
james wrote: : When you're introducing thousands of IP blocks per day, it's pretty hard : to notify them all. I may be reaching here but I think perl scripting can do this. I wish. I've been experimenting with doing exactly that for years. Problems: - WHOIS data is often incomplete, wrong, or deliberately misleading. Heck, I see legitimate IP space which simply isn't registered _anywhere_. - there is no standard way to indicate notification addresses - some use comments, many different potential field names. Why couldn't this have been standardized? - Inadequate delegation - Notifying too far down the chain The experiments I've done got to about 10% accuracy. But it's the 90% that are completely erroneous and potentially cause mailing entirely the wrong person. There's no way you can let one of these things run unattended. I have something running doing this - but the IP -> email address database is compiled by hand. Coverage is abysmal - maybe 20% on good days for spam reports. Probably be 0% on reasonably clean IP ranges. abuse.net maintains a domain -> abuse address database. It's the best data, _if_ the domain owner has registered. There is nothing analogous for IP addresses. Or even AS's. Man it would be nice if there was an IP or AS -> notification address service out there (ie: by DNS, ala DNSBL TXT records).
Peering BOF VII at NANOG 30 in Miami
Hi again -
We have approval to run the Peering BOF again at the upcoming NANOG 30 in
Miami ! Appropriate attire (Hawaiian Shirts) is required ;-)
So, now my job is to draft Peering Coordinators to stand up, introduce
themselves, say a few words about their peering requirements, why you
should peer with them, etc. in order to facilitate peering. While you
introduce yourself I will have a screen behind you that has the answers to
the questions below. At the end of the BOF we break for beers and, if
history is any indication, peering coordinators meet each other, exchange
cards and get some direct peering going.
BTW - This time we may add an agenda topic, perhaps a brief debate
"Tier 1 Peering Policies: Defensible?".
Taking the Affirmative will be ___, taking the Negative will be __.
(Both TBD, debaters being secretly solicited)
Bill
--- For Peering Coordinators participating in Peering Personals
---
The Peering BOF focuses on meeting other Peering Coordinators using a
methodology we call "Peering Personals." We solicit Peering Coordinators
(before the meeting), asking them to characterize their networks and
peering policies in general ways ("content heavy" or "access (eyeball)
-heavy," "Multiple Points Required" or "Will Peer anywhere," "Peering with
Content OK," etc.). From the answers we will select a set of ISP Peering
Coordinators to present a 2-3 minute description of their network, what
they look for in a peer, etc., allowing the audience to put a face with the
name of the ISP.
At the end of the Peering BOF, Peering Coordinators will have time to speak
with Peering Coordinators of ISPs they seek to interconnect with. The
expectation is that these interactions will lead to the Peering
Negotiations stage, the first step towards a more fully meshed and
therefore resilient Internet.
If you are a Peering Coordinator and wish to participate in this BOF,
please fill out the following form and e-mail it to
[EMAIL PROTECTED] with
Subject: Peering BOF VII
We will only be able to accommodate maybe 20 peering coordinators this time
so please RSVP early!
- clip here
--
Name:
Title:
Company:
AS#:
Check each that applies:
___ We are an ISP (sell access to the Internet)
-- OR --
___ We are a Non-ISP (content company, etc.)
___ We are generally more Content-Heavy
-- OR --
___ We are generally more Access-Heavy
___ Peering with Content Players or Content Heavy ISPs is OK by us
___ We generally require peering in multiple locations
___ We will peer with anyone in any single location
___ We have huge volumes of traffic (lots of users and/or lots of content)
(huge: > 1 Gbps total outbound traffic to peers and transit providers)
___ We have a global network
___ We require Contracts for Peering
List all Current Peering Locations:
1)
2)
3)
:
List all Planned (3-6 mos) Peering Locations:
1)
2)
3)
:
Privacy Notice: This information is made available only to me, William B.
Norton, as an individual, and will be used only for facilitating the BOF
and making up the screen behind the speakers. People in the audience are
certainly welcome to jot down information presented at the BOF, but the
information will not be made available in any other form to anyone.
Hopefully this clarifies things and will avoid the controversy of the past.
To give you an idea of previous Peering BOFs please see
---
Peering BOF VI, NANOG 27, Phoenix, February 2003.
http://www.nanog.org/mtg-0302/norton.html
Peering BOF V. NANOG 25, Toronto, June 2002.
http://www.nanog.org/mtg-0206/norton.html
Peering BOF IV. NANOG 23, Oakland, October 2001.
http://www.nanog.org/mtg-0110/norton.html
Peering BOF III. NANOG 20, Washington, DC, October 2000.
http://www.nanog.org/mtg-0010/peering.html
Peering BOF II. . NANOG 19, Albuquerque, June 2000
http://www.nanog.org/mtg-0006/peering.html
Peering BOF I. NANOG 17, Montreal, Oct 1999
http://www.nanog.org/mtg-9910/peering.html
Re: Need Contact at RoadRunner
: > I may be reaching here but I think perl scripting can do this. : : I wish. I've been experimenting with doing exactly that for years. That is what I ment by "reaching", it was not intended to be a smart a** comment. How about mailing to abuse/postmaster@ ? I realize that the postmaster/abuse account is often non-existent but at least you made the effort. To me the important thing is at least trying to notify. So the clueless miss out. Tuff. Those of us that care would like to know there is a problem, so we can solve it. James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Re: Need Contact at RoadRunner
On Fri, 5 Dec 2003, james wrote: > To me the important thing is at least trying to notify. > So the clueless miss out. Tuff. Those of us that care would like to know > there is a problem, so we can solve it. Thank you James, thats my point exactly :) The people who care or have a clue will have what they need, and those who don't will get left behind. When people decide to clean up their act, they will start to care.
Re: Need Contact at RoadRunner
james wrote: > > : > I may be reaching here but I think perl scripting can do this. > : > : I wish. I've been experimenting with doing exactly that for years. > > That is what I ment by "reaching", it was not intended to be a smart a** comment. > How about mailing to abuse/postmaster@ ? I realize that the postmaster/abuse > account is often non-existent but at least you made the effort. To me the important > thing is at least trying to notify. So the clueless miss out. Tuff. Those of us that > care > would like to know there is a problem, so we can solve it. I have been laid off for a while now so I may be out of touch, but for all of the attacks I worked on, the only think we could know (emphasis "could") was which interface the attack vehicle arrived on, as a maximum. Everything else was forged, spoofed, or unintelligble. I was probably not filtering off traffic from you (for any value of "you"), I was filtering off stuff with your IP address in it.
Large Cable ISP Looking for a Roadrunner contact...
Hello, Could someone from Roadrunner please contact me – you have blocked a large ISP’s mail server farm and are not responding to requests to unblock. We received no notification of a block. Thanks --Dan -- Daniel Ellis, CTO, PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay
Re: Large Cable ISP Looking for a Roadrunner contact...
Dan Ellis writes on 12/5/2003 6:05 PM: Could someone from Roadrunner please contact me – you have blocked a large ISP’s mail server farm and are not responding to requests to unblock. We received no notification of a block. Thanks --Dan Doesn't [EMAIL PROTECTED] work? srs -- Daniel Ellis, CTO, PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
RE: Large Cable ISP Looking for a Roadrunner contact...
As per their bounceback instructions, tried [EMAIL PROTECTED], it appears still blocked. -- Daniel Ellis, CTO, PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay -Original Message- From: Suresh Ramasubramanian [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2003 6:13 PM To: Dan Ellis Cc: [EMAIL PROTECTED] Subject: Re: Large Cable ISP Looking for a Roadrunner contact... Dan Ellis writes on 12/5/2003 6:05 PM: > Could someone from Roadrunner please contact me - you have blocked a > large ISP's mail server farm and are not responding to requests to > unblock. We received no notification of a block. > > Thanks > > --Dan > Doesn't [EMAIL PROTECTED] work? srs > -- > > Daniel Ellis, CTO, PenTeleData > > (610)826-9293 > > "The only way to predict the future is to invent it." > > --Alan Kay > -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: Need Contact at RoadRunner
I think part of the problem is not only to notify but provide information for techs at another ISP to know what kind of problem they have (and if you block them, they may not be able to reach you to even ask). I would remind that this thread started from Tom telling us that roadrunner did not even record whey thy blocked him. Not only should they have recorded it but perhaps had a location where Tom could find that: 1. He's being blocked 2. Why he is being blocked with particular example of abuse that caused it 3. How long will block last or what steps he should take if he corrected the problem to notify and get the block removed Since its difficult to maintain tracking system like this for every ISP, perhaps a more centralized abuse clearing house could be developed (by centralized does not mean it should involve in these disputes just provide forum for one ISP to record filtering policies that are being applied to another one). In fact more then one system like this can exist and ISPs may choose which system they use or run their own system, what would be important is to let everyone know what system they are using and how to get information from it, preferably in real time. On Fri, 5 Dec 2003, james wrote: > : > I may be reaching here but I think perl scripting can do this. > : > : I wish. I've been experimenting with doing exactly that for years. > > That is what I ment by "reaching", it was not intended to be a smart a** comment. > How about mailing to abuse/postmaster@ ? I realize that the postmaster/abuse > account is often non-existent but at least you made the effort. To me the important > thing is at least trying to notify. So the clueless miss out. Tuff. Those of us that > care > would like to know there is a problem, so we can solve it. > > James Edwards > Routing and Security > [EMAIL PROTECTED] > At the Santa Fe Office: Internet at Cyber Mesa > Store hours: 9-6 Monday through Friday > 505-988-9200 SIP:1(747)669-1965
Re: Large Cable ISP Looking for a Roadrunner contact...
I have also had some blocking taking place. Mail was sent to spamblock @ rr.com two days ago without any response although we did have ticket generation. /m - Original Message - From: "Suresh Ramasubramanian" <[EMAIL PROTECTED]> To: "Dan Ellis" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, December 05, 2003 3:13 PM Subject: Re: Large Cable ISP Looking for a Roadrunner contact... > > Dan Ellis writes on 12/5/2003 6:05 PM: > > > Could someone from Roadrunner please contact me – you have blocked a > > large ISP’s mail server farm and are not responding to requests to > > unblock. We received no notification of a block. > > > > Thanks > > > > --Dan > > > Doesn't [EMAIL PROTECTED] work? > > srs > > > -- > > > > Daniel Ellis, CTO, PenTeleData > > > > (610)826-9293 > > > > "The only way to predict the future is to invent it." > > > > --Alan Kay > > > > > -- > srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 > manager, outblaze.com security and antispam operations > >
Re: Evolution of the U.S. Peering Ecosystem v1.1
> 1) The Cable companies are peering (with Tier 2s and each other) in a > *big* way That's probably why ATDN depeered ~20 networks over last few months, while Comcast and Charter do not peer at all. > 2) The Large Network Savvy Content Companies are getting into peering in > a *big* way With transit bandwidth at 20k$/GE, and Equinix shared fabric now priced at nearly half that, I don't see that many "content companies" peering all that much. > 3) The Large Network Savvy Content Companies are getting their content > directly onto the Cable companies eyeball networks by peering > relationships. I wish. Out of big eyeball networks, only SBC has reasonably open policy, rest are attempting to force "content networks" into paid peering arrangements using restrictive ratio requirements -- Alex Pilosov| DSL, Colocation, Hosting Services President | [EMAIL PROTECTED](800) 710-7031 Pilosoft, Inc. | http://www.pilosoft.com
Re: Need Contact at RoadRunner
[EMAIL PROTECTED] writes on 12/5/2003 7:24 PM: did not even record whey thy blocked him. Not only should they have recorded it but perhaps had a location where Tom could find that: 1. He's being blocked 2. Why he is being blocked with particular example of abuse that caused it 3. How long will block last or what steps he should take if he corrected the problem to notify and get the block removed Roadrunner bounce messages are quite verbose and explanatory. And http://security.rr.com has a lot more. [micah mcneily] I have also had some blocking taking place. Mail was sent to spamblock @ rr.com two days ago without any response although we did have ticket generation. They say to email [EMAIL PROTECTED] at http://security.rr.com/mail_blocks.htm I do guess they should automate a lot of their unblocking process as well - especially unblocking the open relay / open proxy type blocks, that can be trivially automated (click here to schedule a retest of your IP, etc). That might cut down on a whole lot of their load. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: Evolution of the U.S. Peering Ecosystem v1.1
At 06:23 PM 12/5/2003 -0500, [EMAIL PROTECTED] wrote: > 1) The Cable companies are peering (with Tier 2s and each other) in a > *big* way That's probably why ATDN depeered ~20 networks over last few months, while Comcast and Charter do not peer at all. I had not heard that. As for Comcast and Charter, I would add the word "yet." > 2) The Large Network Savvy Content Companies are getting into peering in > a *big* way With transit bandwidth at 20k$/GE, and Equinix shared fabric now priced at nearly half that, I don't see that many "content companies" peering all that much. The phrase, "You get what you pay for" comes to mind. There is real difference between transit services IMHO. Also, you rarely use the full gigE in these types of arrangements, so you need to be a little careful doing the "simple math." Having said all that, the transit price pressures are certainly there and it does make the peering financial argument a little tougher. I've heard the argument that "Peering is better than transit. It ought to cost more." > 3) The Large Network Savvy Content Companies are getting their content > directly onto the Cable companies eyeball networks by peering > relationships. I wish. Well then you shall receive. The large guys do peer (Yahoo!, MSN, Google, EA, Sony Online, etc.) in a very big way. I expect too these guys are simply leading the charge - those content companies large enough to employ a network engineering staff that can do the math will be following as well. It is not only a financial motivation; peering provides greater control over routing and is often seen as a performance enhancing strategy. Folks like Yahoo! seem to emphasize the end-user performance improvements over the financial savings these days. Out of big eyeball networks, only SBC has reasonably open policy, rest are attempting to force "content networks" into paid peering arrangements using restrictive ratio requirements Hmm. SBC has what I call a "Selective Peering" inclination; they will peer with you if you meet certain criteria. The cable companies are all different of course but generally seem to have migrated from a "No Peering" inclination (when @Home ran things for them the cable companies didn't peer) to an "Open Peering" inclination to reduce costs (and to deal with Kazaa traffic), to a "Selective Peering" inclination. I see this last step as an operations sanity motivation; peer with those who have at least 10M of traffic to exchange on a couple coasts. If you don't have that much traffic it may not be worth the time to configure the session, and when things break it may be more hassle than it is worth. The ones who are a bit different are the "Restrictive Peering Inclination" folks; those who have a peering policy articulated solely so they can say "No" with a reason. Rather than deal with the hassle of peering requests, some of these guys don't articulate their Peering Inclination in the form of a Peering Policy. "We have all the peering that we need" is the attitude, and, not to open a can of worms here, but it is a business rational attitude. Bill -- Alex Pilosov| DSL, Colocation, Hosting Services President | [EMAIL PROTECTED](800) 710-7031 Pilosoft, Inc. | http://www.pilosoft.com
Re: Need Contact at RoadRunner
On Fri, 2003-12-05 at 16:05, Laurence F. Sheldon, Jr. wrote: > Everything else was forged, spoofed, or unintelligble. > > I was probably not filtering off traffic from you (for any value of > "you"), I was filtering off stuff with your IP address in it. I was not aware one can fake everything in the mail headers, including the sending mail server. -- James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa 505-988-9200 SIP:747-669-1965
Re: Need Contact at RoadRunner
On 5 Dec 2003, james wrote: On Fri, 2003-12-05 at 16:05, Laurence F. Sheldon, Jr. wrote: > Everything else was forged, spoofed, or unintelligble. > > I was probably not filtering off traffic from you (for any value of > "you"), I was filtering off stuff with your IP address in it. I was not aware one can fake everything in the mail headers, including the sending mail server. Where have you been for the last year? The sending "mail server" is some chump's infected Windows box on DSL. Boy, tracking that host down is going to do a whole lot of good! Then start working on the other 9,999 hosts the same spammer is abusing as well. gg matto [EMAIL PROTECTED]< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include
Re: Need Contact at RoadRunner
On Fri, 2003-12-05 at 21:20, just me wrote: > On 5 Dec 2003, james wrote: > > On Fri, 2003-12-05 at 16:05, Laurence F. Sheldon, Jr. wrote: > > > Everything else was forged, spoofed, or unintelligble. > > > > I was probably not filtering off traffic from you (for any value of > > "you"), I was filtering off stuff with your IP address in it. > > I was not aware one can fake everything in the mail headers, including > the sending mail server. > > Where have you been for the last year? The sending "mail server" is > some chump's infected Windows box on DSL. Boy, tracking that host down > is going to do a whole lot of good! Then start working on the other > 9,999 hosts the same spammer is abusing as well. > > gg > matto What is your point ? It is still the server that sent it. james
Re: Need Contact at RoadRunner
james wrote: > > On Fri, 2003-12-05 at 16:05, Laurence F. Sheldon, Jr. wrote: > > > Everything else was forged, spoofed, or unintelligble. > > > > I was probably not filtering off traffic from you (for any value of > > "you"), I was filtering off stuff with your IP address in it. > > I was not aware one can fake everything in the mail headers, including > the sending mail server. Just to clarify--I didn't realize we were talking about just email, that is sort of frowned upon here. I was talking about all attack vehicles, I think, including email, spam, worm castings, and viral debris.
