November 2005 - Test - lists.nanog.org

RE: Bay area data center recommendations
by Matt Bazan 30 Nov '05

30 Nov '05

http://www.upsite.com/TUIpages/whitepapers/tuitiers.html > -----Original Message----- > From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Wednesday, November 30, 2005 12:15 PM > To: Matt Bazan > Cc: nanog(a)nanog.org > Subject: Re: Bay area data center recommendations > > On Wed, 30 Nov 2005 11:41:55 PST, Matt Bazan said: > > Looking for recs on bay area California data centers (within 45 > > minutes of San Francisco). Need a class IV facility. Off > list is fine. > > Is "class IV facility" a term any better defined than "tier > 1"? Googling for +"data center" +"class IV" produced some > hits of places that bragged they were class IV, and some NASA > sites talking about class IV supergiants, and other > not-obviously-relevant hits.... > >

1 0

Bay area data center recommendations
by Matt Bazan 30 Nov '05

30 Nov '05

Looking for recs on bay area California data centers (within 45 minutes of San Francisco). Need a class IV facility. Off list is fine. Thanks, Matt

2 1

rbl.cluecentral.net v2.0
by Pim van Pelt 30 Nov '05

30 Nov '05

Hi, Summary: rbl.cluecentral.net moves to ascc.dnsbl.bit.nl per 1/Dec/2005. When Sabri Berisha mailed nanog a couple of weeks ago that he would be stopping his AS and CC DNSBL lists, I'm sure many users were somewhat disappointed. Sabri has received a lot of feedback on the matter, but has decided to stop hosting the lists due to lack of time and other resources. My employer is one of the ISPs that actively use these lists in our antispam setup, so I have conferred with them and we came to the decision that BIT will start hosting the list using the same generating algorithm, but under a new domain. I have finished prototyping and have an implementation ready for production. I worked closely with Sabri to ensure that the data we will publish is compatible with his. BIT will publish new data (800MB, 8M records) on our dnsbl servers on wednesdays at around 02:00 UTC, and on our ftp/rsync server on the following day. I am looking for a couple of US based nameservers (tinydns) to which I can push the compressed data.cdb file (100M per week) and get query statistics from (details to be determined), so if any of you have such gear to share, let me know off-list and maybe we can work something out. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

1 1

Ethernet over SDH tutorial/concepts.
by MARLON BORBA 30 Nov '05

30 Nov '05

Dear NANOGers, We are in process of choosing a new corporate ISP for our company. One of them offered us connection to their backbone using Ethernet over SDH. I'd like to find some introductory texts or prospects about that technology and some advice about its pros/cons when compared to traditional data circuits. Abraços, Marlon Borba, CISSP. -- GTER 20/GTS 02.05 - Participe! http://eng.registro.br/gter20/prog.html --

2 1

Comcast latency Maryland area
by Mark Owen 30 Nov '05

30 Nov '05

Congested router? Tracing route to google.com [72.14.207.99] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.20.1 2 15 ms 6 ms 5 ms 73.138.40.1 3 7 ms 6 ms 26 ms ge-2-3-ur01.lanham.md.bad.comcast.net [68.87.131 .113] 4 6 ms 7 ms 7 ms te-9-1-ur01.bowie.md.bad.comcast.net [68.87.128. 177] 5 7 ms 8 ms 7 ms te-8-2-ar01.capitolhghts.md.bad.comcast.net [68. 87.128.182] 6 17 ms 23 ms 15 ms 68.87.16.153 7 92 ms 92 ms 91 ms pos-0-0-cr01.whitemarsh.md.core.comcast.net [68. 87.16.21] 8 250 ms 253 ms 254 ms 12.118.102.5 9 259 ms 263 ms 257 ms tbr1-p010101.n54ny.ip.att.net [12.123.3.82] 10 255 ms 252 ms 253 ms ggr2-p300.n54ny.ip.att.net [12.123.3.58] 11 294 ms 284 ms 275 ms so-7-1.car3.NewYork1.Level3.net [4.68.127.5] 12 283 ms 286 ms 283 ms ae-1-56.bbr2.NewYork1.Level3.net [4.68.97.161] 13 267 ms * 277 ms as-1-0.bbr1.Chicago1.Level3.net [64.159.0.237] 14 277 ms 286 ms 278 ms ae-12-51.car2.Chicago1.Level3.net [4.68.101.3] 15 253 ms 260 ms 263 ms unknown.Level3.net [209.247.34.26] 16 279 ms 278 ms 288 ms 64.233.175.97 17 274 ms 309 ms 289 ms 66.249.94.69 18 292 ms 272 ms 290 ms 66.249.94.73 19 275 ms 268 ms 293 ms 72.14.207.99 Trace complete. -- Mark Owen

2 2

Re: BGP Security and PKI Hierarchies
by Peter J. Cherny 29 Nov '05

29 Nov '05

On 29-Nov-2005, at 12:16, David Barak wrote: > Maybe my imagination just isn't good enough: could you > toss me an example-type of organization where that > would be problematic? If we consider non-operators e.g. medium sized commercial or NGOs ... APNIC have a mechanism in-place, but most of the denizens of the Swamp are suspicious that if we were to sign an agreement with APNIC, we'd be giving up some of our historical rights and exposing ourselves to the risk of reclamation. Annual account fee (historical resource maintenance) $100.00 http://www.apnic.net/docs/policy/historical-maintain-guide.html http://www.apnic.net/member/feesinfo.html#non_mem_fee Until (and if) an ipv6 multi-homed transition is possible, medium sized organizations here in Oz will continue to use a mixture of PA and PI space to isolate us from dependence on a single carrier. In a country as large as the US, but sparsely populated except for scattered cities, each with millions of people, reliable and cost effective service delivery requires that we retain direct control of routing policy i.e. have our own chunks of PI space, though having one or more ASs is not necessary. Back to lurking, pjc

1 0

Re: QoS for ADSL customers
by Frank Coluccio 29 Nov '05

29 Nov '05

2 1

AW: BGP Security and PKI Hierarchies
by John van Oppen 29 Nov '05

29 Nov '05

While I think $1250/year for a /24 of space seems a bit high, I see no reason that legacy allocations should remain free. Perhaps $100/year (like an ASN is) would be reasonable for small legacy allocations. This is especially important for end users who have these allocations as they would most likely be free from their upstream provider. That being said, if it is larger than a few /24s I see no reason to not have the regular rates apply. If you have a /16 and can't afford the fee, you can't possibly afford to fill it with machines and should simply be allowed to swap down to a smaller allocation. Such a scheme would be in the best interest of all as it would all for some reclamation of numbering resources. Charging something also seems as though it would help with the IP hording problem that is going on with legacy allocations. It would also help to "automatically" expire allocations which are not in use as users would be less willing to pay for resources they are not using. John :) -----Ursprüngliche Nachricht----- Von: Joe Abley [mailto:jabley@isc.org] Gesendet: Tuesday, November 29, 2005 11:20 AM An: David Barak Cc: nanog(a)nanog.org Betreff: Re: BGP Security and PKI Hierarchies On 29-Nov-2005, at 12:16, David Barak wrote: > Maybe my imagination just isn't good enough: could you > toss me an example-type of organization where that > would be problematic? Oh, my mistake -- you're talking about new organisations looking to acquire PI space. I was talking about organisations who have grandfathered (and hence zero-fee) PI space. I don't have any examples of the former, and I tend to agree with your assessment for that. Joe

1 0

Outbound mail filtering on large mail / web server farms - just an idea or two that I have
by Suresh Ramasubramanian 29 Nov '05

29 Nov '05

On 11/20/05, Suresh Ramasubramanian <ops.lists(a)gmail.com> wrote: > When you aggregate all .forward email out through a single box, stuff > that's slipping through your filters starts to stick out like a sore > thumb when you analyze the mail queues on that box, so you can tune > your inbound filters better. Quite a useful thing to do, really. I originally wrote this lot below as boilerplate for large webhosting providers that find themselves with several racks full of pizzabox colos running a web control panel like ensim or cpanel so that the people actually operating the colos may not have too much clue .. and these places are typically riddled with lots and lots of exploitable cgi / php scripts that are broken into and used to send spam using injection / xss etc holes .. Some of the ideas here might well apply to what I was talking about in this thread as well - the two kind of tie in together Comments welcome regards srs ------------------------------------------ First and most important thing to do - Please set your webserver up so that it uses suexec / phpsuexec to make sure perl and php scripts run as the uid/gid of the the user rather than the webserver's uid/gid like nobody or www-data. Never mind if your webhosting software like ensim or plesk inserts headers showing the spammer's uid/gid, path of the calling script etc - serves as a useful backup, and is especially useful when you are searching your logs for cgi scripts that that spammers upload onto your server and then use to proxy their spam from another server through your IP [so your IP shows up in our logs as sending spam, rather than the spammer's actual IP] I'd also strongly suggest something like this if you can manage it 1. Block port 25 outbound on all your webservers. Port 25 inbound as well if you happen to have a mailserver infrastructure for your users thats separate from the webservers they are on, rather than MX'ing your users domains onto the webserver they're hosted on. 2. Set your exim local installs to smarthost through a separate, filtered cluster of servers (spamassassin + bogofilter or something like that - possibly DCC for bulk email detection as well). Smarthosting - see http://www.hserus.net/exim.html For extra points you could do smtp auth on the filtered smarthost as well, to help you jump on issues faster. Set it up so the user's local uid/gid gets used to auth to the remote exim box .. centralized ldap or mysql userdb does the trick for that. That way spammers cant spam out direct through cgis - but peoples normal email and script generated traffic goes out just fine through your filtered gateways. -------------------------------------------

3 6

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
by Sandy Murphy 28 Nov '05

28 Nov '05

>the rir attests to the delegation of the prefix and an asn to the >identified isp. > >the isp signs, using their isp identity to > o originating from the asn > o originating that prefix (in sbgp, toward another isp) Looks to me like: proof of allocation: S(withRIRkey, Prefix_p_key, prefix_p) as Steve pointed out, there could be two of these, one with CA bit set for use in suballocation and one without the CA bit set for use in routing proof of identity S(withRIRkey, AS_A_key, AS_A) or S(withwebofttrustkeys, AS_A_key, AS_A) maybe Randy is saying this is two steps, not an "OR" proof of origination authorization: S(withPrefix_p_key, authr_origin_AS_#, prefix_p) proof of origination authentication: S(withAS_A_key, (AS_A,prefix_p)update) could be S(withAS_A_key, (AS_A,prefix_p)||proofoforiginationauthr) The binding between the proof of origination authorization and the proof of origination authentication is that the AS_A in the proof of identity mapping AS_A to the AS_A_key must be the same as the authr_origin_AS_# in the proof of origination authorization. [Future complication of this would have to decide what to do with ISPs that own more than one AS #. (make "authr_origin_AS_#" a list?)] --Sandy who really should be baking

3 2