From fw at deneb.enyo.de Tue Jan 1 10:56:24 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 01 Jan 2013 11:56:24 +0100 Subject: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: <77455F9F-4ED4-4494-A3BB-679BDA81479B@atrato-ip.com> (Job Snijders's message of "Mon, 31 Dec 2012 17:46:07 +0100") References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> <77455F9F-4ED4-4494-A3BB-679BDA81479B@atrato-ip.com> Message-ID: <87ip7hrx2f.fsf@mid.deneb.enyo.de> * Job Snijders: > In the meantime you could consider setting up an irrd[1], redirect > queries to that instance instead of whois.ripe.net, and keep it kind > of fresh by feeding it ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz on a > daily basis. RIPE NCC strips all contact information from the bulk exports, so this isn't a replacement. But RIPE NCC promised that the bulk exports will include data related to the (new, mandatory) abuse-c field, so that data might be more useful again in the future. From morrowc.lists at gmail.com Tue Jan 1 16:18:38 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 1 Jan 2013 11:18:38 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Mon, Dec 31, 2012 at 9:07 AM, John R. Levine wrote: > Also keep in mind that this particular argument is about the certs used to > submit mail to Gmail, which requires a separate SMTP AUTH within the SSL > session before you can send any mail. This isn't belt and suspenders, this > is belt and a 1/16" inch piece of duct tape. wait, no... this was gmail's pop crawlers gathering mail from remote pop services wasn't it? (or that was my impression at least). so this is, I think, an attempt by gmail/google to protect their users from intermediaries presenting a certificate for 'floof' self-signed instead of iecc.com ... -chris From kmedcalf at dessus.com Tue Jan 1 19:04:16 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 01 Jan 2013 12:04:16 -0700 Subject: Gmail and SSL Message-ID: Perhaps Googles other "harvesters" and the government agents they sell or give user credentials to, don't work against privately (not under the goverment thumb) encryption keys without the surveillance state expending significantly more resources. Perhaps the cheapest way to solve this is to apply thumbscrews and have google require the use of co-option freindly keying material by their victims errr customers errr users. Sent from Samsung Mobile -------- Original message -------- From: Christopher Morrow Date: To: "John R. Levine" Cc: nanog at nanog.org Subject: Re: Gmail and SSL From morrowc.lists at gmail.com Tue Jan 1 22:46:20 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 1 Jan 2013 17:46:20 -0500 Subject: Gmail and SSL In-Reply-To: References: Message-ID: On Tue, Jan 1, 2013 at 2:04 PM, Keith Medcalf wrote: > Perhaps Googles other "harvesters" and the government agents they sell or > give user credentials to, don't work against privately (not under the > goverment thumb) encryption keys without the surveillance state expending > significantly more resources. > > Perhaps the cheapest way to solve this is to apply thumbscrews and have > google require the use of co-option freindly keying material by their > victims errr customers errr users. you lost me in conspiracy theories, can you rephrase? From scott at doc.net.au Wed Jan 2 00:04:11 2013 From: scott at doc.net.au (Scott Howard) Date: Tue, 1 Jan 2013 16:04:11 -0800 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Mon, Dec 31, 2012 at 6:07 AM, John R. Levine wrote: > Really, this isn't hard to understand. Current SSL signers do no more > than tie the identity of the cert to the identity of a domain name. Anyone > who's been following the endless crisis at ICANN about bogus WHOIS knows > that domain names do not reliably identify anyone. > So you're saying that you'd have no problems getting a well-known-CA signed certificate for, say, pop.mail.yahoo.com? If you can't, then it would seem that the current process provides (at least) a better mechanism than just blindly accepting self-signed certificates, no? Also keep in mind that this particular argument is about the certs used to > submit mail to Gmail, which requires a separate SMTP AUTH within the SSL > session before you can send any mail. This isn't belt and suspenders, this > is belt and a 1/16" inch piece of duct tape. > Err.. no it's not. It's about the certs used when Gmail connects to a 3rd-party host to collect mail. ie, Google is the client, not the server. Scott From mpalmer at hezmatt.org Wed Jan 2 01:31:13 2013 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 2 Jan 2013 12:31:13 +1100 Subject: Gmail and SSL In-Reply-To: References: Message-ID: <20130102013113.GY4888@hezmatt.org> On Tue, Jan 01, 2013 at 12:04:16PM -0700, Keith Medcalf wrote: > Perhaps the cheapest way to solve this is to apply thumbscrews and have > google require the use of co-option freindly keying material by their > victims errr customers errr users. ITYM "product". - Matt From mike at mikejones.in Wed Jan 2 01:57:41 2013 From: mike at mikejones.in (Mike Jones) Date: Wed, 2 Jan 2013 01:57:41 +0000 Subject: Gmail and SSL In-Reply-To: References: Message-ID: On 1 January 2013 19:04, Keith Medcalf wrote: > Perhaps Googles other "harvesters" and the government agents they sell or give user credentials to, don't work against privately (not under the goverment thumb) encryption keys without the surveillance state expending significantly more resources. > > Perhaps the cheapest way to solve this is to apply thumbscrews and have google require the use of co-option freindly keying material by their victims errr customers errr users. There is no difference in encryption terms between a certificate signed by an external CA and a certificate signed by itself, in either case only parties with the private key (which you should never send to the CA) can decrypt messages encrypted with that public key. Some CAs will offer to generate a key pair for you instead of managing your own keys, however that merely demonstrates that those CAs (and anyone who uses that service) don't know how the certificates they are issuing are meant to work. If anyone other than the party directly identified by the public key ever gets a copy of the private key then those keys are no longer secure and the certificate should be revoked immediately as it no longer has any meaning*. But if you ignore facts (as most conspiracy theories do) and try to argue it's part of a conspiracy to intercept data - we're talking about hop by hop transport encryption not end to end content encryption, google already have a copy of all the messages going through their service anyway. - Mike * A CA signs to say "we have verified this is google", not "this is either google or their CA or some other random person, well really we don't have a clue who it is but someone gave us money to sign here" - although the latter is probably more accurate in the real world. From kmedcalf at dessus.com Wed Jan 2 02:53:42 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 01 Jan 2013 19:53:42 -0700 Subject: Gmail and SSL Message-ID: Non prime number store certificates are acceptd for SMTP (25) both to and from google. Perhaps this is CYA to prevent compromised gmail accounts from giving credentials from hijacked accounts to unknown servers. I have no idea how credentials for gmails pop pickup work but perhaps having hijacked a gmail account the hijacker can just change the target pop server address without needing to know the target crefentials. ?Changing to a malicious pop server would allow the credentials for that account to be compromised. Of course if this were the case I should think fixing the underlying brokedness in the UI might be a good idea as well. Sent from Samsung Mobile -------- Original message -------- From: Scott Howard Date: To: "John R. Levine" Cc: nanog at nanog.org Subject: Re: Gmail and SSL From Valdis.Kletnieks at vt.edu Wed Jan 2 12:53:28 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Jan 2013 07:53:28 -0500 Subject: Gmail and SSL In-Reply-To: Your message of "Sun, 30 Dec 2012 19:25:04 -0600." References: Message-ID: <46705.1357131208@turing-police.cc.vt.edu> On Sun, 30 Dec 2012 19:25:04 -0600, Jimmy Hess said: > I would say those claiming certificates from a public CA provide no > assurance of authentication of server identity greater than that of a > self-signed one would have the burden of proof to show that it is no > less likely for an attempted forger to be able to obtain a false > "bought" certificate from a public trusted CA that has audited > certification practices statement, a certificate improperly issued > contrary to their CPS, than to have created a self-issued false > self-signed certificate. There's a bit more trust (not much, but a bit) to be attached to a cert signed by a reputable CA over and above that you should attach to a self-signed cert you've never seen before. However, if you trust a CA-signed cert more than you trust a self-signed cert *that you yourself created*, there's probably a problem there someplace. (In other words, you should be able to tell Gmail "yes, you should expect to see a self-signed cert with fingerprint 'foo' - only complain if you see some *other* fingerprint". To the best of my knowledge, there's no currently known attack that allows the forging of a certificate with a pre-specified fingerprint. Though I'm sure Steve Bellovin will correct me if I'm wrong... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From member at linkedin.com Wed Jan 2 12:55:27 2013 From: member at linkedin.com (glauber gabriel via LinkedIn) Date: Wed, 2 Jan 2013 12:55:27 +0000 (UTC) Subject: Join my network on LinkedIn Message-ID: <1390198437.38053838.1357131327108.JavaMail.app@ela4-app2312.prod> LinkedIn ------------ glauber gabriel requested to add you as a connection on LinkedIn: ------------------------------------------ I'd like to add you to my professional network on LinkedIn. Accept invitation from glauber gabriel http://www.linkedin.com/e/-voa23o-hbggy9vf-4c/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I289313318_50/3wOtCVFbmdxnSVFbm8JrnpKqlZJrmZzbmNJpjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfP0RnPwNcPcNcPAUcAALd6AVcPd4i6gLd3kUcPcPcjkOc34LrCBxbOYWrSlI/eml-comm_invm-b-in_ac-inv28/?hs=false&tok=0sxGA2-yjD8BA1 View profile of glauber gabriel http://www.linkedin.com/e/-voa23o-hbggy9vf-4c/rso/83706038/sJhI/name/50054316_I289313318_50/?hs=false&tok=3uUzmVjIjD8BA1 ------------------------------------------ You are receiving Invitation emails. This email was intended for Ted Fischer. Learn why this is included: http://www.linkedin.com/e/-voa23o-hbggy9vf-4c/plh/http%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?hs=false&tok=2KhfbmfCrD8BA1 (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. From member at linkedin.com Wed Jan 2 13:20:20 2013 From: member at linkedin.com (Luis Palma Lopez via LinkedIn) Date: Wed, 2 Jan 2013 13:20:20 +0000 (UTC) Subject: Join my network on LinkedIn Message-ID: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> LinkedIn ------------ Luis Palma Lopez requested to add you as a connection on LinkedIn: ------------------------------------------ I'd like to add you to my professional network on LinkedIn. Accept invitation from Luis Palma Lopez http://www.linkedin.com/e/-voa23o-hbghuaa4-6f/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I289333489_50/3wOtCVFbmdxnSVFbm8JrnpKqlZJrmZzbmNJpjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfP0RnPAUd3cPcPAUcAALs556oRx6mAYLdj4Rcj8RdjAMc34LrCBxbOYWrSlI/eml-comm_invm-b-in_ac-inv28/?hs=false&tok=18q0RW0fU08RA1 View profile of Luis Palma Lopez http://www.linkedin.com/e/-voa23o-hbghuaa4-6f/rso/90277286/KLaW/name/50054316_I289333489_50/?hs=false&tok=1GE8fVDck08RA1 ------------------------------------------ You are receiving Invitation emails. This email was intended for Ted Fischer. Learn why this is included: http://www.linkedin.com/e/-voa23o-hbghuaa4-6f/plh/http%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?hs=false&tok=3_QBrdDt408RA1 (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. From froztbyte at froztbyte.net Wed Jan 2 13:25:35 2013 From: froztbyte at froztbyte.net (JP Viljoen) Date: Wed, 2 Jan 2013 15:25:35 +0200 Subject: Join my network on LinkedIn In-Reply-To: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> Message-ID: <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> On 02 Jan 2013, at 3:20 PM, Luis Palma Lopez via LinkedIn wrote: > This email was intended for ***Ted Fischer*** A whole new year and things are still the same? -J From Dave.Siegel at level3.com Wed Jan 2 15:27:35 2013 From: Dave.Siegel at level3.com (Siegel, David) Date: Wed, 2 Jan 2013 15:27:35 +0000 Subject: looking glass for Level 3 In-Reply-To: References: <50DD6B12.4030106@forthnetgroup.gr> <0c9ee62f4b24abf453152acf8d5a62b8@nurve.com.au> Message-ID: <72A2F9AF18EC024C962A748EA6CF75B90EE418DC@W8USSFJ204.ams.gblxint.com> Hi Folks, The site is offline as a result of some security issues that were discovered. As soon as we've got it patched we'll put it back online. Sorry for any inconvenience this may be causing. Dave -----Original Message----- From: N. Max Pierson [mailto:nmaxpierson at gmail.com] Sent: Friday, December 28, 2012 11:06 AM To: Cameron Daniel Cc: nanog at nanog.org Subject: Re: looking glass for Level 3 Same here. http://lg.level3.net has been down for over a week for me. I know someone in operations I can open a ticket with. On Fri, Dec 28, 2012 at 5:18 AM, Cameron Daniel wrote: > I've had issues getting to it for a week or so. Their NOC was > unresponsive when queried. > > > On 2012-12-28 8:23 pm, Peter Ehiwe wrote: > >> I normally use the 3rd one you mentioned but they seem to be down at >> the moment. >> >> Rgds Peter, >> Sent from my Asus Transformer Pad >> On Dec 28, 2012 1:51 AM, "Tassos Chatzithomaoglou" < >> achatz at forthnetgroup.gr> >> wrote: >> >> Anyone have any looking glass for Level 3? >>> >>> The following seem not to be working >>> >>> http://www.level3.com/**LookingGlass/>> lass/> http://lg.level3.net/bgp/bgp.**cgi >>> >>> http://lookingglass.level3.**net/ >>> >>> -- >>> Tassos >>> >>> >>> >>> > > From smb at cs.columbia.edu Wed Jan 2 16:36:13 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 2 Jan 2013 11:36:13 -0500 Subject: Gmail and SSL In-Reply-To: <46705.1357131208@turing-police.cc.vt.edu> References: <46705.1357131208@turing-police.cc.vt.edu> Message-ID: <055EFC6A-8A83-4881-BEF5-4AB5DDCCAF59@cs.columbia.edu> On Jan 2, 2013, at 7:53 AM, valdis.kletnieks at vt.edu wrote: > On Sun, 30 Dec 2012 19:25:04 -0600, Jimmy Hess said: > >> I would say those claiming certificates from a public CA provide no >> assurance of authentication of server identity greater than that of a >> self-signed one would have the burden of proof to show that it is no >> less likely for an attempted forger to be able to obtain a false >> "bought" certificate from a public trusted CA that has audited >> certification practices statement, a certificate improperly issued >> contrary to their CPS, than to have created a self-issued false >> self-signed certificate. > > There's a bit more trust (not much, but a bit) to be attached to a > cert signed by a reputable CA over and above that you should attach > to a self-signed cert you've never seen before. > > However, if you trust a CA-signed cert more than you trust a self-signed > cert *that you yourself created*, there's probably a problem there someplace. > > (In other words, you should be able to tell Gmail "yes, you should expect > to see a self-signed cert with fingerprint 'foo' - only complain if you > see some *other* fingerprint". To the best of my knowledge, there's no > currently known attack that allows the forging of a certificate with a > pre-specified fingerprint. Though I'm sure Steve Bellovin will correct > me if I'm wrong... :) No, you're quite correct. Depending on what you assume, that would take a preimage or second preimage attack. None are known for any current hash functions, even MD5. I think, though, that that isn't the real issue. We're talking about a feature that would be used by about .0001% of gmail users. Apart from code development and database maintenance by Google -- and even for Google, neither is free -- it requires a UI that is comprehensible, robust, and doesn't confuse the 99.9999% of people who think that a certificate is something you hang on the wall. (Aside: do you remember how Netscape displayed certs -- in a frame with a curlicue border? These are *certificates*; they should look the part, right? I'm just glad that the signature wasn't denoted by 3-D shadowing on a "raised" seal....) Furthermore, the UI has to have a gentle way of telling people that the cert has changed, which may be correct. (Recall that for some of these users, they didn't create the cert; it was done by the admin of a site they use.) Do you run Cert Patrol (a Firefox extension) in your browser? It's amazing how much churn there is among certificates used by big sites (including Google itself). Certificate pinning is a great idea for experts, but it requires expert maintenance. I haven't yet seen a scalable, comprehensible version. I wish Google did support this, but I don't think it's unreasonable of them not to. Recall that they've been targeted by governments around the world, precisely the sort of adversary who can launch active attacks. Now, if you want to say that these adversaries can also corrupt CAs, whether they do it technically, procedurally, financially, or by sending around several large visitors who know where the CEO's kids go to school -- well, I won't argue; I certainly remember the Diginotar case. There may even be a lesser threat from using self-signed certs, since these large individuals operate on a human time frame, so it's more scalable to hit a few large CAs than a few thousand dissidents or other targets of interest. I think, though, that there are arguments on both sides. (The issue of you yourself accepting your own certs is quite different, of course.) --Steve Bellovin, https://www.cs.columbia.edu/~smb From knife at toaster.net Wed Jan 2 17:03:12 2013 From: knife at toaster.net (Sean Lazar) Date: Wed, 02 Jan 2013 09:03:12 -0800 Subject: Join my network on LinkedIn In-Reply-To: <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> Message-ID: <50E46850.5080107@toaster.net> I sent an unsubscribe request. Why Linkedin makes this so difficult, is beyond me. They should just put an unsubscribe link in the email like everyone else does. On 1/2/13 5:25 AM, JP Viljoen wrote: > On 02 Jan 2013, at 3:20 PM, Luis Palma Lopez via LinkedIn wrote: > >> This email was intended for ***Ted Fischer*** > > > A whole new year and things are still the same? > > -J > > > > From bruns at 2mbit.com Wed Jan 2 17:35:00 2013 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 02 Jan 2013 10:35:00 -0700 Subject: Join my network on LinkedIn In-Reply-To: <50E46850.5080107@toaster.net> References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> <50E46850.5080107@toaster.net> Message-ID: <50E46FC4.2060507@2mbit.com> On 1/2/13 10:03 AM, Sean Lazar wrote: > I sent an unsubscribe request. Why Linkedin makes this so difficult, is > beyond me. They should just put an unsubscribe link in the email like > everyone else does. > > On 1/2/13 5:25 AM, JP Viljoen wrote: >> On 02 Jan 2013, at 3:20 PM, Luis Palma Lopez via LinkedIn wrote: >> >>> This email was intended for ***Ted Fischer*** >> >> >> A whole new year and things are still the same? >> I once managed to corner someone at Linked-In about these types of mails, and the short version of their response, "This is how we do it, deal with it." Needless to say, I'm starting to get a little annoyed with this behavior as well. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bill at herrin.us Wed Jan 2 17:57:01 2013 From: bill at herrin.us (William Herrin) Date: Wed, 2 Jan 2013 12:57:01 -0500 Subject: Join my network on LinkedIn In-Reply-To: <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> Message-ID: On Wed, Jan 2, 2013 at 8:25 AM, JP Viljoen wrote: > On 02 Jan 2013, at 3:20 PM, Luis Palma Lopez via LinkedIn wrote: > >> This email was intended for ***Ted Fischer*** > > > A whole new year and things are still the same? Out of curiousity... how did member at linkedin.com get subscribed to nanog and, if it isn't, how did the message from member at linkedin.com make it to the list? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Wed Jan 2 18:08:50 2013 From: bill at herrin.us (William Herrin) Date: Wed, 2 Jan 2013 13:08:50 -0500 Subject: Gmail and SSL In-Reply-To: <20121231034645.11439.qmail@joyce.lan> References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Sun, Dec 30, 2012 at 10:46 PM, John Levine wrote: > So the only assurance a signed cert provides is that the person who > got the cert has some authority over a name that points to the mail > client What other assurance are you looking for? The only point of a signed server certificate, the ONLY point, is to prevent a man-in-the-middle attack where someone who doesn't control the name decrypts the traffic from the server, reads it, and then re-encrypts it with his own self-signed key before sending it to you. If the signature accomplishes that goal, it has done 100% of what it's designed to do. In theory a signature can mean anything the signing authority defines it to mean. In practice, that also requires special handling from the users... behavior web browser users don't engage in. As for Google (and anyone else) it escapes me why you would require a signed certificate for any connection that you're willing to also permit completely unencrypted. Encryption stops nearly every purely passive packet capture attack, with or without a signed certificate. Even without a signed cert an encrypted data flow is much more secure than an unencrypted one. It's not an all-or-nothing deal. Encrypted with a signed or otherwise verified cert is more secure than merely encrypted which is more secure than unencrypted on a switched path which is more secure than unencrypted on a hub. None of these things is wholly insecure and none are 100% secure. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cmadams at hiwaay.net Wed Jan 2 18:11:16 2013 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 2 Jan 2013 12:11:16 -0600 Subject: Join my network on LinkedIn In-Reply-To: <50E46FC4.2060507@2mbit.com> References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> <50E46850.5080107@toaster.net> <50E46FC4.2060507@2mbit.com> Message-ID: <20130102181116.GD19278@hiwaay.net> Once upon a time, Brielle Bruns said: > Needless to say, I'm starting to get a little annoyed with this behavior > as well. Put eBay on the list of "annoying" as well. Somebody put my Gmail address in their eBay account before Christmas, and there is no way for me to stop getting their emails about bids, closed auctions, shipping, etc. There is no unsubscribe or "wrong address" link, I can't log in to the account to change it, and there is no email contact I see for eBay if you don't have an account. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From wbailey at satelliteintelligencegroup.com Wed Jan 2 18:29:50 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 2 Jan 2013 18:29:50 +0000 Subject: Join my network on LinkedIn In-Reply-To: <20130102181116.GD19278@hiwaay.net> References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> <50E46850.5080107@toaster.net> <50E46FC4.2060507@2mbit.com>,<20130102181116.GD19278@hiwaay.net> Message-ID: Isn't this what verification emails are meant to curb? I could have sworn LinkedIn made you verify your email before you can play. >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Chris Adams Date: 01/02/2013 10:13 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: Join my network on LinkedIn Once upon a time, Brielle Bruns said: > Needless to say, I'm starting to get a little annoyed with this behavior > as well. Put eBay on the list of "annoying" as well. Somebody put my Gmail address in their eBay account before Christmas, and there is no way for me to stop getting their emails about bids, closed auctions, shipping, etc. There is no unsubscribe or "wrong address" link, I can't log in to the account to change it, and there is no email contact I see for eBay if you don't have an account. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From morrowc.lists at gmail.com Wed Jan 2 18:39:40 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 2 Jan 2013 13:39:40 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 1:08 PM, William Herrin wrote: > As for Google (and anyone else) it escapes me why you would require a > signed certificate for any connection that you're willing to also > permit completely unencrypted. Encryption stops nearly every purely raising the bar for observers is potentially a goal, no? making it simple for people to get 'more secure' email isn't a bad thing. (admittedly, requiring a signed cert now is more painful, though startssl.com makes it less so). > passive packet capture attack, with or without a signed certificate. > Even without a signed cert an encrypted data flow is much more secure > than an unencrypted one. It's not an all-or-nothing deal. Encrypted > with a signed or otherwise verified cert is more secure than merely > encrypted which is more secure than unencrypted on a switched path > which is more secure than unencrypted on a hub. None of these things > is wholly insecure and none are 100% secure. boiling down the above you mean: goodness-scale (goodness to the left) signed > self-signed > unsigned I don't think there's much disagreement about that... the sticky wicket though is 'how much better is 'signed' vs 'self-signed' ? and I think the feeling is that: 'if we can verify that the cert is proper/signed, we have more assurance that the end user meant for this cert to be presented. A self-signed cert could be any intermediary between me/you... we have no way to verify who is presenting the cert.' -chris (note the use of 'we' here is the 'royal we', I have no idea what the real reason is, but the above makes some sense to me, at least.) From rsk at gsp.org Wed Jan 2 18:40:59 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 2 Jan 2013 13:40:59 -0500 Subject: Join my network on LinkedIn In-Reply-To: <50E46850.5080107@toaster.net> References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> <50E46850.5080107@toaster.net> Message-ID: <20130102184059.GA11179@gsp.org> This isn't new. It's been LinkedIn's practice since approximately forever to get its users to surrender their address books and then to spam [1] every address in them. The fix is simple: block linkedin.com at the MTA. [2] ---rsk [1] It's unsolicited bulk email, therefore spam. We could argue about who's responsible for the spam, and a fair case can be made that those giving up their address books bear some culpability for it...but since it comes from LinkedIn's domain and LinkedIn's mail servers and LinkedIn's network and LinkedIn's software (which is expressly designed to do this very thing), I think it's fair to say that it's LinkedIn's spam. [2] If you don't want to do this on all mail servers, it should definitely be done on those hosting mailing lists, either at the MTA or in the mailing list software's configuration. From nick at foobar.org Wed Jan 2 18:45:09 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 02 Jan 2013 18:45:09 +0000 Subject: Join my network on LinkedIn In-Reply-To: <50E46850.5080107@toaster.net> References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> <50E46850.5080107@toaster.net> Message-ID: <50E48035.407@foobar.org> On 02/01/2013 17:03, Sean Lazar wrote: > I sent an unsubscribe request. Why Linkedin makes this so difficult, is > beyond me. They should just put an unsubscribe link in the email like > everyone else does. If you're not a user of linkedin, you can stop this by sending an email to linkedin_support at cs.linkedin.com and asking them to put you on their "do not contact" list. Nick From bill at herrin.us Wed Jan 2 19:36:30 2013 From: bill at herrin.us (William Herrin) Date: Wed, 2 Jan 2013 14:36:30 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 1:39 PM, Christopher Morrow wrote: > goodness-scale (goodness to the left) > signed > self-signed > unsigned Hi Chris, Self-signed and unsigned are identical. The "goodness" scale is: Encrypted & Verified (signed) > Encrypted Unsigned (or self-signed, same difference) > Unencrypted but physically protected > Unprotected > I don't think there's much disagreement about that... the sticky > wicket though is 'how much better is 'signed' vs 'self-signed' ? and I > think the feeling is that: I don't see how "feeling" plays into it. Communications using an unverified public key are trivially vulnerable to a man-in-the-middle attack where the connection is decrypted, captured in its unencrypted form and then undetectably re-encrypted with a different key. Communications using a key signed by a trusted third party suffer such attacks only with extraordinary difficulty on the part of the attacker. It's purely a technical matter. The information you're trying to protect is either sensitive enough that this risk is unacceptable or it isn't. That's purely a question for the information owner. No one else's opinion matters for squat. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From betty at newnog.org Wed Jan 2 20:04:20 2013 From: betty at newnog.org (Betty Burke ) Date: Wed, 2 Jan 2013 15:04:20 -0500 Subject: [NANOG-announce] NANOG 57 Update Message-ID: Colleagues: Welcome to 2013! NANOG 57, our first meeting of the new year, scheduled for Monday, February 4-6, 2013 in sunny Orlando is well underway. The NANOG Program Committee will be sharing agenda information very soon. As always it will be linked to the NANOG 57 meeting page . I write today, sending along a few reminders regarding registration and hotel information for NANOG 57. The hotel information is as follows: - *Group Name:* NANOG - *Room Rate:* $199 single/double, plus taxes - *Group Rate Expires:* Saturday, January 12, 2013 - *Reservations:* - To call for hotel room reservations, please call 1-888-789-3090 and state that you will be attending NANOG 57. - *Online Reservations:* - Please click here for online reservations directly with the Renaissance Orlando at Seaworld. And lastly do not miss out on Registration savings: If you are not a NANOG member, consider joining by visiting *Join NANOG today ** and receive a $25 discount on standard registration fees for any NANOG conference.* * * *For registration, * - Standard Registration starting December 17, 2012 (non-member $525, member $500, student $100) - Late Registration starting January 11, 2013 (non-member $600, member $575, student $100) - On-Site Registration starting February 1, 2013 (non-member $675, member $650, student $100) Look forward to seeing many of you in Orlando. Should you have any questions, please send email to nanog-support at nanog.org. Sincerely, Betty Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From george.herbert at gmail.com Wed Jan 2 20:10:55 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 2 Jan 2013 12:10:55 -0800 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 11:36 AM, William Herrin wrote: > Communications using a key signed by a trusted > third party suffer such attacks only with extraordinary difficulty on > the part of the attacker. It's purely a technical matter. While I agree with your general characterization of MIIM, the "extraordinary difficulty" here is not supported. As has been demonstrated, the bar for getting certs from some trusted CAs is in some cases low enough that it's not even difficult, much less extraordinarily difficult. Getting certs to a well known domain may be somewhat harder, it might be useful to see how far someone got trying to get a "mail.google.com" cert from all the commonly trusted vendors without resorting to illegal penetrations or layer 8+ hacking / social engineering / threats / intimidation / politics, but even if we exclude those threats the general envelope for not-well-known domains seems risky. Google is setting a higher bar here, which may be sufficient to deter a lot of bots and script kiddies for the next few years, but it's not enough against nation-state or serious professional level attacks. The advantage for the deterrence it can give may well be worth it anyways, for the near future. Every measure in security that does not involve the off switch is a half-measure, at least in the long term, even very large key crypto, but enough incremental steps form a useful cushion. -- -george william herbert george.herbert at gmail.com From morrowc.lists at gmail.com Wed Jan 2 20:24:03 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 2 Jan 2013 15:24:03 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 2:36 PM, William Herrin wrote: > On Wed, Jan 2, 2013 at 1:39 PM, Christopher Morrow > wrote: >> goodness-scale (goodness to the left) >> signed > self-signed > unsigned > > Hi Chris, > > Self-signed and unsigned are identical. The "goodness" scale is: > > Encrypted & Verified (signed) > Encrypted Unsigned (or self-signed, > same difference) > Unencrypted but physically protected > Unprotected > >> I don't think there's much disagreement about that... the sticky >> wicket though is 'how much better is 'signed' vs 'self-signed' ? and I >> think the feeling is that: > > I don't see how "feeling" plays into it. > > Communications using an unverified public key are trivially vulnerable > to a man-in-the-middle attack where the connection is decrypted, > captured in its unencrypted form and then undetectably re-encrypted > with a different key. Communications using a key signed by a trusted > third party suffer such attacks only with extraordinary difficulty on > the part of the attacker. It's purely a technical matter. > > The information you're trying to protect is either sensitive enough > that this risk is unacceptable or it isn't. That's purely a question > for the information owner. No one else's opinion matters for squat. I think we're talking past eachother :( I also think we're mostly saying the same thing... I think though that the 'a question for the information owner' is great, except that I doubt most of them are equipped with enough information to make the judgement themselves. -chris From nick at flhsi.com Wed Jan 2 20:43:45 2013 From: nick at flhsi.com (Nick Olsen) Date: Wed, 2 Jan 2013 15:43:45 -0500 Subject: ATT/Bellsouth Mail Message-ID: <57fe1815$9847ac1$4d990f2$@flhsi.com> Looking for a contact at ATT/Bellsouth regarding email acceptance. (@bellsouth.net) I've been unable to send them mail with a 550 Error (Blocked for abuse) and have requested de-listing no less then 5 times. Not getting anywhere, Normal contact routes have failed. Nick Olsen Network Operations (855) FLSPEED x106 From ripencc-management at ripe.net Wed Jan 2 16:00:14 2013 From: ripencc-management at ripe.net (Axel Pawlik) Date: Wed, 02 Jan 2013 17:00:14 +0100 Subject: RIPE Database Proxy Service Issues Message-ID: <50E4598E.2090508@ripe.net> [Apologies for duplicate emails] Dear colleagues, There has been discussion on various mailing lists regarding the status of the RIPE Database Proxy Service. Before I address the issues that arose, I'd like to give you some background information on the service itself that may help with the discussions. Technical Background -------------------- To prevent the automatic harvesting of personal information (real names, email addresses, phone numbers) from the RIPE Database, there are PERSON and ROLE object query limits defined in the RIPE Database Acceptable Use Policy. This is set at 1,000 PERSON or ROLE objects per IP address per day. Queries that result in more than 1,000 objects with personal data being returned result in that IP address being blocked from carrying out queries for that day. Users of the RIPE Database have unlimited access to Network Information Centre (NIC)-related objects. They can use the -r flag in order to filter out personal objects and query NIC objects without any limitations. The RIPE Database Proxy Service allows websites to provide a third party interface to the RIPE Database. Without the proxy service, the third parties would quickly run into the limits set on RIPE Database queries. With the proxy service, we whitelist the third party IP address and ask them to pass their user's IP address to us, so limits are only set on the user's IP address, not the third party's. There is no technical way to ensure that the user IP addresses passed to us by the third party are valid. Potentially, third party users of the proxy service could harvest all personal data in the RIPE Database (approximately 2 million objects) in a matter of hours. To ensure that the RIPE NCC's Terms and Conditions are followed, we require a contract between the third party and the RIPE NCC. Users of the Proxy Service -------------------------- In the past ten years, the RIPE NCC has had 31 requests for the proxy service and over the past year, there have been only four active users of the service. Of these four, one is already a RIPE NCC member. NIC Information --------------- All NIC information is still available without access to the proxy service. In the normal presentation of whois data, there is a redirect system that allows users with a normal whois client to deal directly with the RIPE Database whois service. There is no need for a proxy service in this scenario. The proxy service is only necessary if the data needs to be presented in alternative forms, such as on a third party's website. The limits imposed on RIPE Database queries only apply to personal data. Users can always access NIC data in any form they like if they are happy not to receive personal data. On 6 March 2012, the RIPE NCC proposed to change the default behaviour of the query system to instead return only "ALLOWED" results if a user had reached their daily personal data query limit, but there was disagreement over this on the mailing list so the change was not implemented. The proposal is available at: http://www.ripe.net/ripe/mail/archives/db-wg/2012-March/003885.html Legal Considerations -------------------- The RIPE NCC operates under European Data Protection laws, so to avoid risk in this area we insist on having a contract with third parties who wish to use the proxy service. The RIPE NCC and its Executive Board believes that the proxy service should become a member service because it tightens the contractual relationship between the RIPE NCC and third parties. Currently, no such agreement that meets the EU Data Protection legislation is in place between the RIPE NCC and the proxy service users. In order to tighten the contractual relationship between the RIPE NCC and the Proxy service users, taking into account the recent approval of the Charging Scheme 2013 that caused a simplification of the contractual agreements between the RIPE NCC and its service users, the RIPE NCC offered to conclude the membership agreement for continuation of the service. Next Steps? ------------ The Executive Board approved changes to the draft version of the Activity Plan and Budget 2013, and the RIPE NCC published the final version on 13 December 2012: http://www.ripe.net/internet-coordination/news/announcements/ripe-ncc-activity-plan-and-budget-2013 We do apologise, however, that the changes regarding the proxy service were not more explicitly communicated to the members and the RIPE community in advance of the final publication of the Activity Plan. The RIPE NCC asks that non-RIPE NCC member proxy service users become members but we propose to waive their membership fee until the discussion of the RIPE NCC Charging Scheme 2014 takes place. This will give the membership and community the opportunity to discuss the best way forward for the proxy service in the coming months while ensuring a strong contractual bond between the RIPE NCC and users of this service. In the meantime, there will be no changes to the proxy service and no loss of functionality for the community. The RIPE NCC and its Executive Board will return to its members with proposals for ways to ensure that their wishes are met with regard to service developments while allowing the RIPE NCC to be operate efficiently and responsively. If you have any comments on this issue, please direct them to the RIPE NCC Services Working Group mailing list . Best regards, Axel Pawlik Managing Director RIPE NCC From bill at herrin.us Wed Jan 2 22:27:06 2013 From: bill at herrin.us (William Herrin) Date: Wed, 2 Jan 2013 17:27:06 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 3:10 PM, George Herbert wrote: > On Wed, Jan 2, 2013 at 11:36 AM, William Herrin wrote: >> Communications using a key signed by a trusted >> third party suffer such attacks only with extraordinary difficulty on >> the part of the attacker. It's purely a technical matter. > > While I agree with your general characterization of MIIM, the > "extraordinary difficulty" here is not supported. AFAICT someone finds a way to get themselves a certificate for a domain they don't control every couple years or so. The hole is promptly plugged (and the certs revoked) before much actually happens as a result. Has your experience been different? Are you, at this moment, able to acquire a falsely signed certificate for www.herrin.us that my web browser will accept? You're right that false certificates have been issued in the past. You're right that false certificates will be issued again in the future. No security apparatus is 100% effective. But if despite your resources you in particular can't make it happen in a timely manner, that's a meaningful barrier to mounting a man-in-the-middle attack against someone using properly signed certificates. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Wed Jan 2 22:27:51 2013 From: bill at herrin.us (William Herrin) Date: Wed, 2 Jan 2013 17:27:51 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 3:24 PM, Christopher Morrow wrote: > I think though that the 'a question for the information owner' is > great, except that I doubt most of them are equipped with enough > information to make the judgement themselves. Much of the evil in the world starts with the presumption that otherwise competent individuals can't make good decisions for themselves. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From johnl at iecc.com Wed Jan 2 22:38:16 2013 From: johnl at iecc.com (John R. Levine) Date: 2 Jan 2013 17:38:16 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: > Are you, at this moment, able to acquire a falsely signed certificate > for www.herrin.us that my web browser will accept? Me, no, although I have read credible reports that otherwise reputable SSL signers have issued MITM certs to governments for their filtering firewalls. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From george.herbert at gmail.com Wed Jan 2 22:43:23 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 2 Jan 2013 14:43:23 -0800 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 2:27 PM, William Herrin wrote: > On Wed, Jan 2, 2013 at 3:10 PM, George Herbert wrote: >> On Wed, Jan 2, 2013 at 11:36 AM, William Herrin wrote: >>> Communications using a key signed by a trusted >>> third party suffer such attacks only with extraordinary difficulty on >>> the part of the attacker. It's purely a technical matter. >> >> While I agree with your general characterization of MIIM, the >> "extraordinary difficulty" here is not supported. > > AFAICT someone finds a way to get themselves a certificate for a > domain they don't control every couple years or so. The hole is > promptly plugged (and the certs revoked) before much actually happens > as a result. Has your experience been different? > > Are you, at this moment, able to acquire a falsely signed certificate > for www.herrin.us that my web browser will accept? > > You're right that false certificates have been issued in the past. > You're right that false certificates will be issued again in the > future. No security apparatus is 100% effective. But if despite your > resources you in particular can't make it happen in a timely manner, > that's a meaningful barrier to mounting a man-in-the-middle attack > against someone using properly signed certificates. > > Regards, > Bill Herrin There are three vectors of attack: One, asking a CA for a cert in someone else's name and it gets issued. As you noted, generally discovered pretty quickly and shut down, but there's no robust external verification for the discovery process. Also, the verifications the CAs perform to validate the user could be subverted, as noted earlier in conversation, so they could receive false assurances that it was the right entity asking for the keys. That subversion could happen via registrar account hacking (known problem) among other places, along with technical measures to monitor unencrypted validation emails sent to proper authoritative domain contact emails. Two, a CA's keys can go walking (either due to technical penetration or human corruption), and then external parties can issue their own certs as if they were the CA. If identified the CA can revoke its own key and re-issue all the client certs from a new one, but someone needs to identify that it happened. This is alleged to have happened at least twice, once of which the CA was shut down over, the other one of which became opaque and ambiguous, and therefore untrustworthy. Three, there may be crypto flaws we don't know about still lingering, or a CA could choose easily factored numbers by bad luck and someone could luck out grinding them. Not a high risk (anyone SHOULD grind their own keys some to check them for that) but nonzero. Can I go get a key for your site right now? I'm not going to spend the afternoon trying (I'm working for a living) but I am reasonably sure I could do so. Lax checks by CAs are well described elsewhere. If push came to shove and minor legalities were not restraining me, I recall (without checking) your domain's emails come to your home, and your DSL or cable line is sniffable, so any of the CA who email URL validators out could be trivially temporarily spoofed (until you read your email and responded) by tapping your data lines. BGP games to snarf your traffic are another venue, possibly not yet even covered by wiretap laws that I know of, though I'm not currently an ISP in a position to personally do that to you. The same is possible but slightly harder for midsized corporate entities. Still possible but much harder for large ones. If you're going to argue that that's cheating, that IS the threat envelope... -- -george william herbert george.herbert at gmail.com From rjoffe at centergate.com Wed Jan 2 22:49:29 2013 From: rjoffe at centergate.com (Rodney Joffe) Date: Wed, 2 Jan 2013 17:49:29 -0500 Subject: RIPE Database Proxy Service Issues In-Reply-To: <50E4598E.2090508@ripe.net> References: <50E4598E.2090508@ripe.net> Message-ID: Hell Axel, On Jan 2, 2013, at 11:00 AM, Axel Pawlik wrote: > [Apologies for duplicate emails] > > Dear colleagues, > > There has been discussion on various mailing lists regarding the status of the RIPE Database Proxy Service. > > We do apologise, however, that the changes regarding the proxy service were not more explicitly communicated to the members and the RIPE community in advance of the final publication of the Activity Plan. Not being members, we obviously were not privy to these discussions or decisions. Not your fault, of course, just a reality. > > The RIPE NCC asks that non-RIPE NCC member proxy service users become members but we propose to waive their membership fee until the discussion of the RIPE NCC Charging Scheme 2014 takes place. This will give the membership and community the opportunity to discuss the best way forward for the proxy service in the coming months while ensuring a strong contractual bond between the RIPE NCC and users of this service. > > In the meantime, there will be no changes to the proxy service and no loss of functionality for the community. I appreciate the decision and accommodation? And I am sure the community appreciates it. As users have no doubt realized, the proxy data continued to be available after Dec 31. We were waiting to see what the "DENIED" output looked like before we implemented our changes, so there was no impact. This too is appreciated. And thank you to the many community and RIPE members who offered and provided assistance and support. Thank you. Rodney Joffe CenterGate Research/GeekTools From wbailey at satelliteintelligencegroup.com Wed Jan 2 22:56:09 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 2 Jan 2013 22:56:09 +0000 Subject: RIPE Database Proxy Service Issues In-Reply-To: References: <50E4598E.2090508@ripe.net>, Message-ID: <8unbqwihiuvwx6k6d51pw9hj.1357167364388@email.android.com> This looks to be a happy ending. I thought we were going to get to see a fight. ;) >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Rodney Joffe Date: 01/02/2013 2:51 PM (GMT-08:00) To: ripencc-management at ripe.net Cc: nanog at nanog.org Subject: Re: RIPE Database Proxy Service Issues Hell Axel, On Jan 2, 2013, at 11:00 AM, Axel Pawlik wrote: > [Apologies for duplicate emails] > > Dear colleagues, > > There has been discussion on various mailing lists regarding the status of the RIPE Database Proxy Service. > > We do apologise, however, that the changes regarding the proxy service were not more explicitly communicated to the members and the RIPE community in advance of the final publication of the Activity Plan. Not being members, we obviously were not privy to these discussions or decisions. Not your fault, of course, just a reality. > > The RIPE NCC asks that non-RIPE NCC member proxy service users become members but we propose to waive their membership fee until the discussion of the RIPE NCC Charging Scheme 2014 takes place. This will give the membership and community the opportunity to discuss the best way forward for the proxy service in the coming months while ensuring a strong contractual bond between the RIPE NCC and users of this service. > > In the meantime, there will be no changes to the proxy service and no loss of functionality for the community. I appreciate the decision and accommodation? And I am sure the community appreciates it. As users have no doubt realized, the proxy data continued to be available after Dec 31. We were waiting to see what the "DENIED" output looked like before we implemented our changes, so there was no impact. This too is appreciated. And thank you to the many community and RIPE members who offered and provided assistance and support. Thank you. Rodney Joffe CenterGate Research/GeekTools From randy at psg.com Thu Jan 3 00:15:25 2013 From: randy at psg.com (Randy Bush) Date: Thu, 03 Jan 2013 09:15:25 +0900 Subject: Gmail and SSL In-Reply-To: <055EFC6A-8A83-4881-BEF5-4AB5DDCCAF59@cs.columbia.edu> References: <46705.1357131208@turing-police.cc.vt.edu> <055EFC6A-8A83-4881-BEF5-4AB5DDCCAF59@cs.columbia.edu> Message-ID: > Do you run Cert Patrol (a Firefox extension) in your browser? yes, but my main browser is chrome (ff does poorly with nine windows and 60+ tabs). there is some sort of pinning, or at least discussion of it. but it is not clear what is actually provided. and i don't see evidence of churn reporting. randy From randy at psg.com Thu Jan 3 00:17:31 2013 From: randy at psg.com (Randy Bush) Date: Thu, 03 Jan 2013 09:17:31 +0900 Subject: Join my network on LinkedIn In-Reply-To: <50E46FC4.2060507@2mbit.com> References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> <50E46850.5080107@toaster.net> <50E46FC4.2060507@2mbit.com> Message-ID: procmail is your friend and what's "linkedin?" From smb at cs.columbia.edu Thu Jan 3 00:29:05 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 2 Jan 2013 19:29:05 -0500 Subject: Gmail and SSL In-Reply-To: References: <46705.1357131208@turing-police.cc.vt.edu> <055EFC6A-8A83-4881-BEF5-4AB5DDCCAF59@cs.columbia.edu> Message-ID: On Jan 2, 2013, at 7:15 PM, Randy Bush wrote: >> Do you run Cert Patrol (a Firefox extension) in your browser? > > yes, but my main browser is chrome (ff does poorly with nine windows and > 60+ tabs). there is some sort of pinning, or at least discussion of it. > but it is not clear what is actually provided. and i don't see evidence > of churn reporting. > Google uses certificate pinning for a very, very few sites. From http://blog.chromium.org/2011/06/new-chromium-security-features-june.html : In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). You can turn it on for other sites but: Advanced users can enable stronger security for some web sites by visiting the network internals page: chrome://net-internals/#hsts You can now force HTTPS for any domain you want, and even ?pin? that domain so that only a more trusted subset of CAs are permitted to identify that domain. _It?s an exciting feature but we?d like to warn that it?s easy to break things! We recommend that only experts experiment with net internals settings._ Emphasis theirs. The only Chrome browser I have lying around right now is on a Nexus 7 tablet; I don't see any way to list the pinned certs from the browser. There is a list at http://www.chromium.org/administrators/policy-list-3, and while I don't know how current it is you'll notice a decided dearth of interesting sites with the exceptions of paypal.com and lastpass.com. --Steve Bellovin, https://www.cs.columbia.edu/~smb From bill at herrin.us Thu Jan 3 00:35:49 2013 From: bill at herrin.us (William Herrin) Date: Wed, 2 Jan 2013 19:35:49 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 5:38 PM, John R. Levine wrote: >> Are you, at this moment, able to acquire a falsely signed certificate >> for www.herrin.us that my web browser will accept? > > Me, no, although I have read credible reports that otherwise reputable SSL > signers have issued MITM certs to governments for their filtering firewalls. The governments in question are watching for exfiltration and they largely use a less risky approach: they issue their own root key and, in most cases, install it in the government employees' browser before handing them the machine. A "reputable" SSL signer would have to get outed just once issuing a government a resigning cert and they'd be kicked out of all the browsers. They'd be awfully easy to catch. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Jan 3 00:42:16 2013 From: bill at herrin.us (William Herrin) Date: Wed, 2 Jan 2013 19:42:16 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 5:43 PM, George Herbert wrote: > If push came to shove and minor legalities were not restraining me, I > recall (without checking) your domain's emails come to your home, and > your DSL or cable line is sniffable, so any of the CA who email URL > validators out could be trivially temporarily spoofed (until you read > your email and responded) by tapping your data lines. BGP games to > snarf your traffic are another venue, possibly not yet even covered by > wiretap laws that I know of, though I'm not currently an ISP in a > position to personally do that to you. And none of this describes an extraordinary effort? The quote you're trying to refute was, "suffer such attacks only with extraordinary difficulty on the part of the attacker." > If you're going to argue that that's cheating, that IS the threat envelope... You're quite right about the scope of the threat envelope. And it's one to two orders of magnitude more difficult to penetrate than man-in-the-middle with an unverified key. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gem at rellim.com Thu Jan 3 00:59:05 2013 From: gem at rellim.com (Gary E. Miller) Date: Wed, 2 Jan 2013 16:59:05 -0800 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: <20130102165905.27a5a5e8.gem@rellim.com> Yo William! On Wed, 2 Jan 2013 19:42:16 -0500 William Herrin wrote: > On Wed, Jan 2, 2013 at 5:43 PM, George Herbert > wrote: > > If push came to shove and minor legalities were not restraining me, > > I recall (without checking) your domain's emails come to your home, > > and your DSL or cable line is sniffable, so any of the CA who email > > URL validators out could be trivially temporarily spoofed (until > > you read your email and responded) by tapping your data lines. BGP > > games to snarf your traffic are another venue, possibly not yet > > even covered by wiretap laws that I know of, though I'm not > > currently an ISP in a position to personally do that to you. > > And none of this describes an extraordinary effort? The quote you're > trying to refute was, "suffer such attacks only with extraordinary > difficulty on the part of the attacker." I would say it is pretty easy, and I have caught people doing it many times. All a hacker needs to do is get a sniffer near your email traffic. Then they can grab any challange emails sent to any of you domain contacts. Pretty trvial to do in a coffee shop environment. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From christopher.morrow at gmail.com Thu Jan 3 01:03:32 2013 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 2 Jan 2013 20:03:32 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Jan 2, 2013 7:36 PM, "William Herrin" wrote: > > > > > Me, no, although I have read credible reports that otherwise reputable SSL > > signers have issued MITM certs to governments for their filtering firewalls. > That's not the case join is referring to. > The governments in question are watching for exfiltration and they No, not really. Some are busy tracking "dissidents" among their populations. > largely use a less risky approach: they issue their own root key and, > in most cases, install it in the government employees' browser before > handing them the machine. > Not just for employees. > A "reputable" SSL signer would have to get outed just once issuing a > government a resigning cert and they'd be kicked out of all the > browsers. They'd be awfully easy to catch. > Oh! You mean like cyber trust and etilisat? Right... That's working just perfectly... > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From schoen at loyalty.org Thu Jan 3 01:25:15 2013 From: schoen at loyalty.org (Seth David Schoen) Date: Wed, 2 Jan 2013 17:25:15 -0800 Subject: Gmail and SSL In-Reply-To: References: <46705.1357131208@turing-police.cc.vt.edu> <055EFC6A-8A83-4881-BEF5-4AB5DDCCAF59@cs.columbia.edu> Message-ID: <20130103012515.GI24733@frotz.zork.net> Steven Bellovin writes: > The only Chrome browser I have lying around right now is on a Nexus 7 tablet; > I don't see any way to list the pinned certs from the browser. There is a > list at http://www.chromium.org/administrators/policy-list-3, and while I > don't know how current it is you'll notice a decided dearth of interesting > sites with the exceptions of paypal.com and lastpass.com. You can see the current list of cert pins and HSTS preloads in the Chromium source tree at https://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state_static.h?view=markup or https://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state_static.json?view=markup -- Seth David Schoen | No haiku patents http://www.loyalty.org/~schoen/ | means I've no incentive to FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150 | -- Don Marti From mpalmer at hezmatt.org Thu Jan 3 01:37:25 2013 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 3 Jan 2013 12:37:25 +1100 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: <20130103013725.GJ4888@hezmatt.org> On Wed, Jan 02, 2013 at 07:35:49PM -0500, William Herrin wrote: > A "reputable" SSL signer would have to get outed just once issuing a > government a resigning cert and they'd be kicked out of all the > browsers. They'd be awfully easy to catch. I believe Honest Achmed said it best: "In any case by the time he's issued enough certificates he'll be regarded as too big to fail by the browser vendors, so an expensive audit doesn't really matter." as well as "Achmed's business plan is to sell a sufficiently large number of certificates as quickly as possible in order to become too big to fail" and "Achmed guarantees that no certificate will be issued without payment having been received, as per the old latin proverb "nil certificati sine lucre"." - Matt From christopher.morrow at gmail.com Thu Jan 3 01:39:52 2013 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 2 Jan 2013 20:39:52 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 8:03 PM, Christopher Morrow wrote: > > On Jan 2, 2013 7:36 PM, "William Herrin" wrote: >> > >> > >> > Me, no, although I have read credible reports that otherwise reputable >> > SSL >> > signers have issued MITM certs to governments for their filtering >> > firewalls. >> > > That's not the case join is referring to. > >> The governments in question are watching for exfiltration and they > > No, not really. Some are busy tracking "dissidents" among their populations. > >> largely use a less risky approach: they issue their own root key and, >> in most cases, install it in the government employees' browser before >> handing them the machine. >> > > Not just for employees. > >> A "reputable" SSL signer would have to get outed just once issuing a >> government a resigning cert and they'd be kicked out of all the >> browsers. They'd be awfully easy to catch. >> > > Oh! You mean like cyber trust and etilisat? Right... That's working just > perfectly... should have included this reference link: From bill at herrin.us Thu Jan 3 01:51:51 2013 From: bill at herrin.us (William Herrin) Date: Wed, 2 Jan 2013 20:51:51 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 8:39 PM, Christopher Morrow wrote: > On Wed, Jan 2, 2013 at 8:03 PM, Christopher Morrow > wrote: >> On Jan 2, 2013 7:36 PM, "William Herrin" wrote: >>> A "reputable" SSL signer would have to get outed just once issuing a >>> government a resigning cert and they'd be kicked out of all the >>> browsers. They'd be awfully easy to catch. >> >> Oh! You mean like cyber trust and etilisat? Right... That's working just >> perfectly... > > should have included this reference link: > Hi Christopher, That was nearly 30 months ago. At the time there were no reports of fake Etilisat certs, merely concern that the UAE's regulatory environment was "institutionally hostile to the existence and use of secure cryptosystems." Has the EFF's SSL Observatory project detected even one case of a fake certificate under Etilisat's trust chain since then? There's a reason Etilisat's cert is still valid and it isn't Honest Achmed's. https://bugzilla.mozilla.org/show_bug.cgi?id=647959 Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Thu Jan 3 02:06:15 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 Jan 2013 20:06:15 -0600 Subject: Gmail and SSL In-Reply-To: References: Message-ID: In resp, On 1/2/13, Valdis.Kletnieks at vt.edu wrote: > There's a bit more trust (not much, but a bit) to be attached to a > cert signed by a reputable CA over and above that you should attach > to a self-signed cert you've never seen before. [snip] Absolutely. A certificate whose fingerprint has personally been validated by a human, and compared to a SHA1 fingerprint learned earlier out of band, is to be trusted with a high level of confidence. It is in a sense may be a more reliable assurance than a CA signature on a certificate, as long as a strong validation process was followed -- it is still stronger if BOTH fingerprint manually validated _and_ signed by a recognized CA. A problem, however, that can come in when designing software - such as browsers -- How do you prove the human actually was properly trained, and followed the correct validation procedure? If the human doesn't actually have to type the expected SHA1 fingerprint, and there is a way the human can just "click OK"; or select an option to "disable checking" -- the average human will likely just spontaneously click that -- not understanding what fingerprint validation is, and simply "Approve" or "Skip" the validation process, and mark as trusted, without manually verifying squat. Therefore: the usefulness of fingerprint validation is often limited, to situations where the operator is specifically trained to follow a reasonable validation procedure, and adherence to the validation procedure is enforced. ---- In resp to, On 1/1/13, Keith Medcalf wrote: > Perhaps Googles other "harvesters" and the government agents they sell or There are plenty of public CAs that will allow you to generate your own private key, and distribute only the CSR to the CA, for their signature attesting to the authenticity of every public attribute of the certificate; a CA signs a certificate based on the public information it claims, based on its signing policy, CAs don't ever actually get to learn the private key of the certificate request. If you are concerned about CA misbehavior on behalf of governments, then it makes sense to have software require manual approval/certificate installation of even CA-validated certs. And the "CA signature" should then simply be a mandatory Pre-Check, before being allowed to install or trust a certificate. [snip] In resp to >On 12/31/12, John R. Levine wrote: > Really, this isn't hard to understand. Current SSL signers do no more > than tie the identity of the cert to the identity of a domain name. Correct, when an organization name is not listed on the certificate; that is not part of what has been authenticated, only domain control was authenticated. This is what CAs do. They only necessarily attest the details actually published on the certificate; their job is not to attest that the certificate will only be used for legitimate purposes, although they may do that as well, through CSP and revokation practices. If you are the legitimate owner of a domain, then a certificate issued to it with a CN or Altname of a hostname within that domain, is legitimate, if you are actually the person that authorized it, you approved acceptance of the certificate request containing that name, and you, and only people authorized by the principal have access to the private key. CAs, could do their job better, if DNSSEC is implemented securely for a domain, and the CA required a DNSSEC validated TXT record with the Certificate Authority's Issuer /CN=..../OU=.../O=... fields and the CSR Certificate Request's public key SHA256 hash code, together with a DNSSEC validatable record published containing the /CN=..../OU=.../O=... fields of the PKCS#10 CSR, for the Common name (hostname) and a DNSSEC signed CNAME for each alt name on every certificate to be issued. I expect browser CA policies to evolve to require stronger validations. > I supose to the extent that 0.2% is greater than 0.1%, perhaps. But not > enough for any sensible person to care. Where do you draw the conclusion it is only 0.1%? Not that 0.1% is a small number 1 time out of 1000... If you anticipate 86400 attacks in a day, 0.2% could be 8640 more attacks succeeding. I don't thinkyou give the CAs enough credit. There are well-known trojans that generate on the fly self-signed certificates (specifically things like Flashback,Flame,Flashback,Tatanarg,ZeuS). It seems to be a much rarer event, that there is any report and then only a small number of improperly issued CA signed certificates. This is likely reflecting greater difficulty and much lower practicality of improperly issued certificates as an effective attack strategy. There have in the past been cases where a CA was compromised or improperly issued certificates, and the certificates were revoked. Self-signed certificates cannot be revoked, except by manually updating software to blacklist them. You may be missing the fact, that it's still _hard enough_ and inefficient enough to apply for and get false SSL certificates en masse, that the possible attack scope is greatly limited. That is, the CA certificates aren't low-hanging fruit (Self signed ones are). And the increase in difficulty, if self-signed certs are blocked: other attacks against parts of the stack besides the certificate are more likely, OR another target may be picked (Such as brute force attempts to guess valid authentication credentials, or a search for vulnerabilities in the SSL implementation itself, such as buffer overflow, authentication bypass, or MD5 weaknesses allowing substitution of certificate signed content with fraudulent certificate content). -- -JH From kmedcalf at dessus.com Thu Jan 3 02:06:56 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 02 Jan 2013 19:06:56 -0700 Subject: Gmail and SSL Message-ID: <97syalxlqariq5b3idvufntg.1357178815245@email.android.com> No more difficult at all. ?A MITM is a MITM. ?The atack is the same and intteger-store-bought certificates make the process ?neither more nor less complicated. Sent from Samsung Mobile -------- Original message -------- From: William Herrin Date: To: George Herbert Cc: John Levine ,nanog at nanog.org Subject: Re: Gmail and SSL From smb at cs.columbia.edu Thu Jan 3 02:12:27 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 2 Jan 2013 21:12:27 -0500 Subject: Gmail and SSL In-Reply-To: <20130103012515.GI24733@frotz.zork.net> References: <46705.1357131208@turing-police.cc.vt.edu> <055EFC6A-8A83-4881-BEF5-4AB5DDCCAF59@cs.columbia.edu> <20130103012515.GI24733@frotz.zork.net> Message-ID: <7C382BB8-D654-4BE6-9922-D22FB5E7EBAC@cs.columbia.edu> On Jan 2, 2013, at 8:25 PM, Seth David Schoen wrote: > Steven Bellovin writes: > >> The only Chrome browser I have lying around right now is on a Nexus 7 tablet; >> I don't see any way to list the pinned certs from the browser. There is a >> list at http://www.chromium.org/administrators/policy-list-3, and while I >> don't know how current it is you'll notice a decided dearth of interesting >> sites with the exceptions of paypal.com and lastpass.com. > > You can see the current list of cert pins and HSTS preloads in the Chromium > source tree at > > https://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state_static.h?view=markup > > or > > https://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state_static.json?view=markup Thanks. The list is longer, but with the exception of Twitter (and possibly intuit -- a subdomain is shown), not a lot more interesting. I don't see major banks, I don't see Facebook or Hotmail, I don't see the big CAs, etc. --Steve Bellovin, https://www.cs.columbia.edu/~smb From mohta at necom830.hpcl.titech.ac.jp Thu Jan 3 02:25:11 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 03 Jan 2013 11:25:11 +0900 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: <50E4EC07.1030002@necom830.hpcl.titech.ac.jp> William Herrin wrote: > The governments in question are watching for exfiltration and they > largely use a less risky approach: they issue their own root key and, That is a trusted first party. Masataka Ohta From mysidia at gmail.com Thu Jan 3 02:35:23 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 Jan 2013 20:35:23 -0600 Subject: Join my network on LinkedIn In-Reply-To: References: <924449023.38129557.1357132820626.JavaMail.app@ela4-app2311.prod> <589AA932-A398-4079-A261-7FA4CA9CBD51@froztbyte.net> Message-ID: On 1/2/13, William Herrin wrote: > Out of curiousity... how did member at linkedin.com get subscribed to > nanog and, if it isn't, how did the message from member at linkedin.com > make it to the list? Whatever happened to ' Only humans who bothered to read the directions and subscribed to intentionally separate NANOG-POST@ mailing list ' can post ? http://www.nanog.org/mailinglist/mailarchives/old_archive/1997-12/msg00012.html Seems like someone's broke something since > Regards, > Bill Herrin -- -JH From mysidia at gmail.com Thu Jan 3 03:02:00 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 Jan 2013 21:02:00 -0600 Subject: Gmail and SSL In-Reply-To: <7C382BB8-D654-4BE6-9922-D22FB5E7EBAC@cs.columbia.edu> References: <46705.1357131208@turing-police.cc.vt.edu> <055EFC6A-8A83-4881-BEF5-4AB5DDCCAF59@cs.columbia.edu> <20130103012515.GI24733@frotz.zork.net> <7C382BB8-D654-4BE6-9922-D22FB5E7EBAC@cs.columbia.edu> Message-ID: On 1/2/13, Steven Bellovin wrote: [snip] It's ashame they've stuck with a hardcoded list of "Acceptable CAs" for certain certificates; that would be very difficult to update. The major banks, Facebook, Hotmail, etc, possibly have not made a promise to anyone, that all their future new renewal certificates will be from a specific CA; would be more interesting, if the Chrome devs provided for a mechanism for making a remote query or receiving a digitally signed "PINned cert list" download, that could be updated dynamically, /and/ provided policy and mechanisms to have sites included in the list. One of the broken things about X500, is a certificate can only have one signature. The trust could be strengthened, if there were a mechanism allowing multiple 3rd party attestations to be made (eg PGP-like multiple signatures), or a browser could be configured to only accept a certificate, if BOTH (i) Signed by a CA, and (ii) The certificate's information, or the CA information for the cert is published in a 3rd party corroborating database, that also requires proof of ID/authorization to publish in that DB. (iii) And the server does the work of querying the 3rd party databases listed by the client, by sending the CA ID, Certificate ID, through a query to some standardized URL format, and returns the timestamped digitally signed result (query answer, or affirmative proof of no entry in the DB), during authentication, together with the certificate. Depending on the authenticating browser's config, a domain not found in the 3rd party corroborating datasources, or listed by the 3rd party source with an attestation level of "Only domain control validated", might result in the CA's signature being ignored. That is: the browser (or the user) should pick how strong the certificate has to be, depending on the kind of business they will be executing over the SSL channel. CA's could later become required to check at least 2 3rd party databases, to ensure any prior certificate issued by another CA was actually revoked or expired, before allowing the signing of a new certificate. > Thanks. The list is longer, but with the exception of Twitter (and possibly > intuit -- a subdomain > is shown), not a lot more interesting. I don't see major banks, I don't see > Facebook or Hotmail, > I don't see the big CAs, etc. > --Steve Bellovin, https://www.cs.columbia.edu/~smb -- -JH From christopher.morrow at gmail.com Thu Jan 3 03:04:26 2013 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 2 Jan 2013 22:04:26 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On Wed, Jan 2, 2013 at 8:51 PM, William Herrin wrote: > secure cryptosystems." Has the EFF's SSL Observatory project detected > even one case of a fake certificate under Etilisat's trust chain since > then? it's possible that the observatory won't see these in the wild, if the observatory is on the wrong side of the connection. According to the code EFF uses: it looks like they simply portscanned 0/0 for tcp/443 listeners, then grabbed certs from the respondents. In the cases we're talking about in this thread EFF's observatory may never be in the middle of the conversation. In the cases of Etisalat (or one use they may have) the scanners may not be behind etisalat's piece of gear which uses the CA cert in question. "not observed in the wild" isn't really a good judge for this particular problem I think :( As to why the Etisalat cert isn't yet removed, I wouldn't know... it seems a bit fishy though. -chris From Valdis.Kletnieks at vt.edu Thu Jan 3 03:31:34 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Jan 2013 22:31:34 -0500 Subject: Gmail and SSL In-Reply-To: Your message of "Wed, 02 Jan 2013 12:10:55 -0800." References: <20121231034645.11439.qmail@joyce.lan> Message-ID: <82858.1357183894@turing-police.cc.vt.edu> On Wed, 02 Jan 2013 12:10:55 -0800, George Herbert said: > Google is setting a higher bar here, which may be sufficient to deter > a lot of bots and script kiddies for the next few years, but it's not > enough against nation-state or serious professional level attacks. To be fair though - if I was sitting on information of sufficient value that I was a legitimate target for nation-state TLAs and similarly well funded criminal organizations, I'd have to think long and hard whether I wanted to vector my e-mails through Google. It isn't even the certificate management issue - it's because if I was in fact the target of such attention, my threat model had better well include "adversary attempts to use legal and extralegal means to get at my data from within Google's infrastructure". "Operation Aurora". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From george.herbert at gmail.com Thu Jan 3 03:38:21 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 2 Jan 2013 19:38:21 -0800 Subject: Gmail and SSL In-Reply-To: <82858.1357183894@turing-police.cc.vt.edu> References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> Message-ID: On Wed, Jan 2, 2013 at 7:31 PM, wrote: > On Wed, 02 Jan 2013 12:10:55 -0800, George Herbert said: > >> Google is setting a higher bar here, which may be sufficient to deter >> a lot of bots and script kiddies for the next few years, but it's not >> enough against nation-state or serious professional level attacks. > > To be fair though - if I was sitting on information of sufficient value that I > was a legitimate target for nation-state TLAs and similarly well funded > criminal organizations, I'd have to think long and hard whether I wanted to > vector my e-mails through Google. It isn't even the certificate management > issue - it's because if I was in fact the target of such attention, my threat > model had better well include "adversary attempts to use legal and extralegal > means to get at my data from within Google's infrastructure". > > "Operation Aurora". I probably fit into that description; while I vector my personal email through Google, the actual sensitive stuff does not touch any wired or wireless network. Because I know. -- -george william herbert george.herbert at gmail.com From jeff-kell at utc.edu Thu Jan 3 03:41:09 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 2 Jan 2013 22:41:09 -0500 Subject: Gmail and SSL In-Reply-To: <82858.1357183894@turing-police.cc.vt.edu> References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> Message-ID: <50E4FDD5.2080304@utc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/2/2013 10:31 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 02 Jan 2013 12:10:55 -0800, George Herbert said: > >> Google is setting a higher bar here, which may be sufficient to deter >> a lot of bots and script kiddies for the next few years, but it's not >> enough against nation-state or serious professional level attacks. > > To be fair though - if I was sitting on information of sufficient value that I > was a legitimate target for nation-state TLAs and similarly well funded > criminal organizations, I'd have to think long and hard whether I wanted to > vector my e-mails through Google. It isn't even the certificate management > issue - it's because if I was in fact the target of such attention, my threat > model had better well include "adversary attempts to use legal and extralegal > means to get at my data from within Google's infrastructure". > > "Operation Aurora". Well, the "bar" started at something as trivial as FireSheep. And I'm sure many more silly (in retrospect) exploits remain to be discovered in any cloud-based infrastructure (the bigger the cloud, the bigger the target, the greater the potential damages/losses). And a lot of infrastructure remains vulnerable to something as trivial as FireSheep. Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDk/dUACgkQiwXJq373XhYS6QCgtUyTSNHg8zXA5JxECi/c1Jd+ oDsAn0sSG3nZXSmKWUz2+wZ/1P3EXsps =B0X3 -----END PGP SIGNATURE----- From damian at google.com Thu Jan 3 03:59:35 2013 From: damian at google.com (Damian Menscher) Date: Wed, 2 Jan 2013 19:59:35 -0800 Subject: Gmail and SSL In-Reply-To: <82858.1357183894@turing-police.cc.vt.edu> References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> Message-ID: On Wed, Jan 2, 2013 at 7:31 PM, wrote: > On Wed, 02 Jan 2013 12:10:55 -0800, George Herbert said: > > > Google is setting a higher bar here, which may be sufficient to deter > > a lot of bots and script kiddies for the next few years, but it's not > > enough against nation-state or serious professional level attacks. > > To be fair though - if I was sitting on information of sufficient value > that I > was a legitimate target for nation-state TLAs and similarly well funded > criminal organizations, I'd have to think long and hard whether I wanted to > vector my e-mails through Google. It isn't even the certificate management > issue - it's because if I was in fact the target of such attention, my > threat > model had better well include "adversary attempts to use legal and > extralegal > means to get at my data from within Google's infrastructure". > > "Operation Aurora". > [Full disclosure: I work at Google, though the opinions stated below are mine alone.] Aurora compromised at least 20 other companies, failed at its assumed objective of seeing user data, and Google was the only organization to notice, let alone have the guts to expose the attack [0]. And you're going to hold that against them? If you're the target of a state-sponsored attacker, Google is by far the best place to host your mail. Good luck finding another provider that enables SSL by default [1], offers 2-factor authentication [2], warns you when you're being targeted by state-sponsored attackers [3], and actually fights overly-broad subpoenas from governments [4]. While I'm writing, I'll also point out that the Diginotar hack which came up in this discussion as an example of why CAs can't be trusted was discovered due to a feature of Google's Chrome browser when a cert was being used to spy on users in Iran [5]. Note that it also provides a good example of the difficulty of getting away with such attacks. [0] http://googleblog.blogspot.com/2010/01/new-approach-to-china.html [1] http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html [2] http://support.google.com/accounts/bin/answer.py?hl=en&answer=180744 [3] http://googleonlinesecurity.blogspot.com/2012/06/security-warnings-for-suspected-state.html [4] http://www.google.com/transparencyreport/userdatarequests/ [5] http://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html Damian From Valdis.Kletnieks at vt.edu Thu Jan 3 04:52:21 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Jan 2013 23:52:21 -0500 Subject: Gmail and SSL In-Reply-To: Your message of "Wed, 02 Jan 2013 19:59:35 -0800." References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> Message-ID: <85830.1357188741@turing-police.cc.vt.edu> On Wed, 02 Jan 2013 19:59:35 -0800, Damian Menscher said: > Aurora compromised at least 20 other companies, failed at its assumed > objective of seeing user data, and Google was the only organization to > notice, let alone have the guts to expose the attack [0]. And you're going > to hold that against them? I didn't say that. What I *said* was "one should *expect* a nation-state adversary to go after your mail hosting company via multiple avenues of attack, because it's already been tried before". Google is indeed one of the better actors. But if you're a target, maybe it's time to reconsider whether the phrase "hosting company" should be included in your environment *at all*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From tvhawaii at shaka.com Thu Jan 3 05:13:49 2013 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 2 Jan 2013 19:13:49 -1000 Subject: Fw: Gmail and SSL Message-ID: <14AA26F65A934B48A5446CC7EC59DAF1@owner59e1f1502> Michael Painter wrote: > Damian Menscher wrote: > [Full disclosure: I work at Google, though the opinions stated below are >> mine alone.] > snip Good luck finding another provider that >> enables SSL by default [1], offers 2-factor authentication [2], warns you >> when you're being targeted by state-sponsored attackers [3], and actually >> fights overly-broad subpoenas from governments [4]. > > > I like the notification when an unusual IP address accesses your account. > > Thanks, > > --Michael From damian at google.com Thu Jan 3 05:14:31 2013 From: damian at google.com (Damian Menscher) Date: Wed, 2 Jan 2013 21:14:31 -0800 Subject: Gmail and SSL In-Reply-To: <85830.1357188741@turing-police.cc.vt.edu> References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> <85830.1357188741@turing-police.cc.vt.edu> Message-ID: On Wed, Jan 2, 2013 at 8:52 PM, wrote: > On Wed, 02 Jan 2013 19:59:35 -0800, Damian Menscher said: > > Aurora compromised at least 20 other companies, failed at its assumed > > objective of seeing user data, and Google was the only organization to > > notice, let alone have the guts to expose the attack [0]. And you're > going > > to hold that against them? > > I didn't say that. What I *said* was "one should *expect* a nation-state > adversary to go after your mail hosting company via multiple avenues of > attack, > because it's already been tried before". Google is indeed one of the > better > actors. But if you're a target, maybe it's time to reconsider whether the > phrase "hosting company" should be included in your environment *at all*. > Thanks for clarifying. We're off-topic, but that decision needs to be weighed against the alternatives. If your alternative is running your own mailserver at home, then your risks are: - They can come into your home and walk off with your machines. Even if your hard drives are encrypted, your backups might not be... or maybe you don't have backups? - If you browse from the server they can get you with a trojan impacting Flash or Java. - Even if you don't browse from your mailserver they can try to compromise it remotely if it's not fully patched. How good are you at keeping your system patched. Does it fall a day or two behind when you're on vacation? - Speaking of vacation, how do you authenticate to your system? Does it support 2-factor? Or maybe you don't think you need 2-factor because you have an SSL cert. Did you self-sign it and tell your browser to ignore all other CAs (to approximate Chrome's certificate pinning)? - How does your email arrive/leave? They could be tapping your line... or they could just DoS you off the net. If you really think you can get all of that right, all the time, then I wish you the best of luck. But remembering that most targets are not cypherpunks, telling them to do it themselves is incredibly bad advice. Back on topic: encryption without knowing who you're talking to is worse than useless (hence no self-signed certs which provide a false sense of security), and there are usability difficulties with exposing strong security to the average user (asking users to generate and upload a self-signed cert would be a customer-support disaster, not to mention all the outages that would occur when those certs expired). Real-world security is all about finding a reasonable balance and adapting to the current threats. Damian From Valdis.Kletnieks at vt.edu Thu Jan 3 06:50:12 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Jan 2013 01:50:12 -0500 Subject: Gmail and SSL In-Reply-To: Your message of "Wed, 02 Jan 2013 21:14:31 -0800." References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> <85830.1357188741@turing-police.cc.vt.edu> Message-ID: <99336.1357195812@turing-police.cc.vt.edu> On Wed, 02 Jan 2013 21:14:31 -0800, Damian Menscher said: > We're off-topic, but that decision needs to be weighed against the > alternatives. If your alternative is running your own mailserver at home, > then your risks are: Let's face it - if a nation-state has you in the crosshairs, digital or real, your life is going to suck. All the rest is implementation details.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mike at mtcc.com Thu Jan 3 13:36:48 2013 From: mike at mtcc.com (Michael Thomas) Date: Thu, 03 Jan 2013 05:36:48 -0800 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> <85830.1357188741@turing-police.cc.vt.edu> Message-ID: <50E58970.4000301@mtcc.com> On 01/02/2013 09:14 PM, Damian Menscher wrote: > Back on topic: encryption without knowing who you're talking to is worse > than useless (hence no self-signed certs which provide a false sense of > security), In fact, it's very useful -- what do you think the initial diffie-hellman exchanges are doing with pfs? Encryption without (strong) authentication is still useful for dealing with passive listening. It's a shame, for example, that wifi security doesn't encrypt everything on an open AP to require attacks be active rather than passive. It's really easy to just scan the airwaves, but I probably don't need to remind you of that. Mike From rsk at gsp.org Thu Jan 3 13:48:15 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 3 Jan 2013 08:48:15 -0500 Subject: RIPE Database Proxy Service Issues In-Reply-To: <50E4598E.2090508@ripe.net> References: <50E4598E.2090508@ripe.net> Message-ID: <20130103134815.GA22332@gsp.org> On Wed, Jan 02, 2013 at 05:00:14PM +0100, Axel Pawlik wrote: > To prevent the automatic harvesting of personal information (real > names, email addresses, phone numbers) from the RIPE Database, there > are PERSON and ROLE object query limits defined in the RIPE Database > Acceptable Use Policy. This is set at 1,000 PERSON or ROLE objects > per IP address per day. Queries that result in more than 1,000 > objects with personal data being returned result in that IP address > being blocked from carrying out queries for that day. 1. The technical measures you've outlined will not prevent, and have not prevented, anyone from automatically harvesting the entire thing. Anyone who owns or rents, for example, a 2M-member botnet, could easily retrieve the entire database using 1 query per IP address, spread out over a day/week/month/whatever. (Obviously more sophisticated approaches immediately suggest themselves.) Of course a simpler approach might be to buy a copy from someone who already has. I'm not picking on you, particularly: all WHOIS operators need to stop pretending that they can protect their public databases via rate-limiting. They can't. The only thing that they're doing is preventing NON-abusers from acquiring and using bulk data. 2. This presumes that the database is actually a target for abusers. I'm sure for some it is. But as a source, for example, of email addresses, it's a poor one: the number of addresses per thousand records is relatively small and those addresses tend to belong to people with clue, making them rather suboptimal choices for spamming/phishing/etc. Far richer targets are available on a daily basis simply by following the dataloss mailing list et.al. and observing what's been posted on pastebin or equivalent. These not only include many more email addresses, but often names, passwords (encrypted or not), and other personal details. And once again, the simpler approach of purchasing data is available. 3. Of course answering all those queries no doubt imposes significant load. Happily, one of the problems that we seem to have pretty much figured out how to solve is "serving up many copies of static content" because we have tools like web servers and rsync. So let me suggest that one way to make this much easier on yourselves is to export a (timestamped) static snapshot of the entire database once a day, and let the rest of the Internet mirror the hell out of it. Spreads out the load, drops the pretense that rate-limiting accomplishes anything useful, makes all the data available to everyone equally, and as long as everyone is aware that it's a snapshot and not a real-time answer, would probably suffice for most uses. (It would also come in handy during network events which render your service unreachable/unusable in whole or part, e.g., from certain parts of the world. Slightly-stale data is way better than no data.) The same thing should be done with all domain WHOIS data, too, BTW. The spammers/phishers/etc. have been getting copies of it for a very long time, whether by mass harvesting, exploiting security holes, paying off insiders, or other means, so it's security theater to pretend that limiting query rates has any value. ---rsk From max at mxcrypt.com Thu Jan 3 14:01:09 2013 From: max at mxcrypt.com (Maxim Khitrov) Date: Thu, 3 Jan 2013 09:01:09 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> <85830.1357188741@turing-police.cc.vt.edu> Message-ID: On Thu, Jan 3, 2013 at 12:14 AM, Damian Menscher wrote: > Back on topic: encryption without knowing who you're talking to is worse > than useless (hence no self-signed certs which provide a false sense of > security), and there are usability difficulties with exposing strong > security to the average user (asking users to generate and upload a > self-signed cert would be a customer-support disaster, not to mention all > the outages that would occur when those certs expired). Real-world > security is all about finding a reasonable balance and adapting to the > current threats. The most recent change to POP3 mail retrieval over SSL is not a reasonable balance. My organization uses Google Apps for mail hosting, but a number of users also have us.army.mil accounts. They used to pull mail from their .mil account into Google Apps via POP3. Army servers do not allow unencrypted connections and their root certificates are not part of the Mozilla Root CA list (and, as you can guess, I have no control over their servers). Google didn't just block the use of self-signed certs; you broke communication with all servers using perfectly legitimate PKIs that are not part of the Mozilla Root CA list. Thus, instead of "self-signed certs = false sense of security," your argument is really "not on some arbitrary root CA list = false sense of security," which is absolute nonsense. I talked to Google Apps support a few weeks ago, sent them a link to this discussion, but all they could do is file a feature request. IMHO, this change should never have been allowed to go into production until there is an interface for uploading our own root certificates. Of course, any root (i.e. self-signed) certificate can be used by the POP3 server directly, so this would also solve the problem for people trying to use self-signed certs not part of any PKI. Finally, "asking users to generate and upload a self-signed cert would be a customer-support disaster," so you just block their access completely? Anyone who doesn't know how to generate and upload a certificate would probably avoid encryption altogether, don't you think? And as for "outages that would occur when those certs expired," what do you think people in my organization are dealing with right now? Only an expired cert can be renewed or replaced, whereas our access has been blocked and there is nothing we can do about it. - Max From carlosm3011 at gmail.com Thu Jan 3 14:12:39 2013 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Thu, 03 Jan 2013 12:12:39 -0200 Subject: Akamai Network Contact Message-ID: <50E591D7.7080801@gmail.com> Hello! I'm looking for a contact in Akamai, preferably someone dwelling in the dark realm of layer 3. I've been contacted by a LACNIC member from Suriname who is having reachability issues specifically with sites hosted in Akamai. Thank you! ~Carlos From jabley at hopcount.ca Thu Jan 3 16:38:44 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 3 Jan 2013 11:38:44 -0500 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: References: <9lnais7c7ei9jielx67hx4be.1355795581892@email.android.com> Message-ID: <437FB07F-A38C-4B01-8091-4B9F722065BA@hopcount.ca> On 2012-12-18, at 11:15, David Conrad wrote: > WRT the root _hints_ change, setting up a cron job to pull, verify, and install the root hints file periodically (once a month should probably be sufficient) would probably be a good idea. This change appears to have been completed, as of root zone serial 2013010300: [krill:~]% host d.root-servers.net d.root-servers.net has address 199.7.91.13 d.root-servers.net has IPv6 address 2001:500:2d::d [krill:~]% [krill:~]% curl -s ftp://rs.internic.net/domain/named.root | fgrep D.ROOT . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13 D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2D::D [krill:~]% The authoritative location of the root hints file is and those who feel like being tidy DNS admins could pull a fresh copy from there so that the next time their nameserver is restarted it will prime optimally. As discussed at some length before, those who prefer to be more hands-off about this will very likely see no negative impact from their laziness. Joe From HSteuart at alliedtelecom.net Thu Jan 3 18:29:00 2013 From: HSteuart at alliedtelecom.net (Henry Steuart) Date: Thu, 3 Jan 2013 18:29:00 +0000 Subject: =?Windows-1252?Q?Re:_Advisory_=97_D-root_is_changing_its_IPv4_address_on_?= =?Windows-1252?Q?the_3rd_of_January.?= In-Reply-To: <437FB07F-A38C-4B01-8091-4B9F722065BA@hopcount.ca> References: <9lnais7c7ei9jielx67hx4be.1355795581892@email.android.com> <437FB07F-A38C-4B01-8091-4B9F722065BA@hopcount.ca> Message-ID: <0751221F-5EE2-4239-BA03-5D87F8846FE5@alliedtelecom.net> On Jan 3, 2013, at 11:38 AM, Joe Abley wrote: On 2012-12-18, at 11:15, David Conrad wrote: > WRT the root _hints_ change, setting up a cron job to pull, verify, and install the root hints file periodically (once a month should probably be sufficient) would probably be a good idea. Perhaps someone at internic.net could explain why the file in the first directory is WRONG but that in the second includes the correct info? [legacy cron jobs pointing at FTP. will obviously not succeed] ; This file is made available by InterNIC ; under anonymous FTP as ; file /domain/named.cache ; on server FTP.INTERNIC.NET ; -OR- RS.INTERNIC.NET Regards -H- From jabley at hopcount.ca Thu Jan 3 18:33:03 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 3 Jan 2013 13:33:03 -0500 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <0751221F-5EE2-4239-BA03-5D87F8846FE5@alliedtelecom.net> References: <9lnais7c7ei9jielx67hx4be.1355795581892@email.android.com> <437FB07F-A38C-4B01-8091-4B9F722065BA@hopcount.ca> <0751221F-5EE2-4239-BA03-5D87F8846FE5@alliedtelecom.net> Message-ID: <30F77A1D-9125-43A9-B663-1D8366594A3C@hopcount.ca> Hi Henry, On 2013-01-03, at 13:29, Henry Steuart wrote: > Perhaps someone at internic.net could explain why the file in the first directory is WRONG but that in the second includes the correct info? > [legacy cron jobs pointing at FTP. will obviously not succeed] > > ; This file is made available by InterNIC > ; under anonymous FTP as > ; file /domain/named.cache > ; on server FTP.INTERNIC.NET > ; -OR- RS.INTERNIC.NET I am not one of the people who works with root zone management, but I understand that: - the normative location of the root hints file is ftp://rs.internic.net/domain/named.root - some of the other mirrors take a few hours to update I appreciate that this is not obviously congruent with the text in the file you cited. I'll pass on this message, and thanks for the feedback. Joe From rmohan at afilias.info Thu Jan 3 19:33:36 2013 From: rmohan at afilias.info (Ram Mohan) Date: Thu, 3 Jan 2013 14:33:36 -0500 Subject: Akamai Network Contact In-Reply-To: <50E591D7.7080801@gmail.com> References: <50E591D7.7080801@gmail.com> Message-ID: <2d5f41c96a5e0359e7384bc888fcc377@mail.gmail.com> I'm looking for a contact in Level3, regarding a client who is having reachability issues with a few sites in the East coast of the US and Asia (sites are reachable via Level3 on the West Coast). Thanks Ram From streiner at cluebyfour.org Thu Jan 3 20:10:08 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 3 Jan 2013 15:10:08 -0500 (EST) Subject: Akamai Network Contact In-Reply-To: <2d5f41c96a5e0359e7384bc888fcc377@mail.gmail.com> References: <50E591D7.7080801@gmail.com> <2d5f41c96a5e0359e7384bc888fcc377@mail.gmail.com> Message-ID: On Thu, 3 Jan 2013, Ram Mohan wrote: > I'm looking for a contact in Level3, regarding a client who is having > reachability issues with a few sites in the East coast of the US and Asia > (sites are reachable via Level3 on the West Coast). Has the client contacted Level3's NOC? That would seem to be the fastest way to get someone from Level3 involved. jms From matthias at leisi.net Thu Jan 3 20:52:13 2013 From: matthias at leisi.net (Matthias Leisi) Date: Thu, 3 Jan 2013 21:52:13 +0100 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> Message-ID: On Thu, Jan 3, 2013 at 4:59 AM, Damian Menscher wrote: > While I'm writing, I'll also point out that the Diginotar hack which came > up in this discussion as an example of why CAs can't be trusted was > discovered due to a feature of Google's Chrome browser when a cert was > Similar to http://googleonlinesecurity.blogspot.ch/2013/01/enhancing-digital-certificate-security.html? -- Matthias From smb at cs.columbia.edu Thu Jan 3 21:25:45 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 3 Jan 2013 16:25:45 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> Message-ID: <7DFEB6F8-67A4-4153-885F-F43799229334@cs.columbia.edu> On Jan 3, 2013, at 3:52 PM, Matthias Leisi wrote: > On Thu, Jan 3, 2013 at 4:59 AM, Damian Menscher wrote: > > >> While I'm writing, I'll also point out that the Diginotar hack which came >> up in this discussion as an example of why CAs can't be trusted was >> discovered due to a feature of Google's Chrome browser when a cert was >> > > Similar to > http://googleonlinesecurity.blogspot.ch/2013/01/enhancing-digital-certificate-security.html? > Thanks; I was just about to post that link to this thread. Certificates don't spread virally, and random browsers don't go looking for whatever interesting certificates they find. They also don't like certs that say "*.google.com" when the user is trying to go somewhere else; that web site would be non-functional unless it was trying to impersonate a Google domain. Taken all together, this sounds to me like deliberate mischief by someone. In fact, were it not for the facts that the blog post says that Google learned of this on December 24 and this thread started on December 14, I'd wonder if there was a connection -- was this the incident that made Google reassess its threat model? Of course, this attack was carried out within the official PKI framework... --Steve Bellovin, https://www.cs.columbia.edu/~smb From kyle.creyts at gmail.com Thu Jan 3 21:30:06 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Thu, 3 Jan 2013 16:30:06 -0500 Subject: Gmail and SSL In-Reply-To: <7DFEB6F8-67A4-4153-885F-F43799229334@cs.columbia.edu> References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> <7DFEB6F8-67A4-4153-885F-F43799229334@cs.columbia.edu> Message-ID: other relevant links for this: http://krebsonsecurity.com/2013/01/turkish-govt-enabled-phishers-to-spoof-google/ http://technet.microsoft.com/en-us/security/advisory/2798897 On Thu, Jan 3, 2013 at 4:25 PM, Steven Bellovin wrote: > > On Jan 3, 2013, at 3:52 PM, Matthias Leisi wrote: > >> On Thu, Jan 3, 2013 at 4:59 AM, Damian Menscher wrote: >> >> >>> While I'm writing, I'll also point out that the Diginotar hack which came >>> up in this discussion as an example of why CAs can't be trusted was >>> discovered due to a feature of Google's Chrome browser when a cert was >>> >> >> Similar to >> http://googleonlinesecurity.blogspot.ch/2013/01/enhancing-digital-certificate-security.html? >> > Thanks; I was just about to post that link to this thread. > > Certificates don't spread virally, and random browsers don't go looking > for whatever interesting certificates they find. They also don't like > certs that say "*.google.com" when the user is trying to go somewhere else; > that web site would be non-functional unless it was trying to impersonate > a Google domain. Taken all together, this sounds to me like deliberate > mischief by someone. In fact, were it not for the facts that the blog > post says that Google learned of this on December 24 and this thread started > on December 14, I'd wonder if there was a connection -- was this the > incident that made Google reassess its threat model? > > Of course, this attack was carried out within the official PKI framework... > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From gem at rellim.com Thu Jan 3 23:31:23 2013 From: gem at rellim.com (Gary E. Miller) Date: Thu, 3 Jan 2013 15:31:23 -0800 Subject: Gmail and SSL Message-ID: <20130103153123.19f39327.gem@rellim.com> Yo All! Apropos the recent discussions: "Google says that someone was caught trying to use an unauthorized digital certificate issued in its name in an attempt to impersonate Google.com for a man-in-the-middle attack." http://www.wired.com/threatlevel/2013/01/google-fraudulent-certificate/ RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mysidia at gmail.com Fri Jan 4 02:08:08 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 3 Jan 2013 20:08:08 -0600 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> <85830.1357188741@turing-police.cc.vt.edu> Message-ID: On 1/3/13, Maxim Khitrov wrote: > On Thu, Jan 3, 2013 at 12:14 AM, Damian Menscher wrote: > I talked to Google Apps support a few weeks ago, sent them a link to > this discussion, but all they could do is file a feature request. I am not sure why this would be classified as a feature request. If it is impacting you, and you had service before, then is an Outage/Defect/Bug, full stop. Describing working service for a previously supported scenario as a "feature request" would be beyond ridiculous :) > - Max -- -JH From alter3d at alter3d.ca Fri Jan 4 02:18:24 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Thu, 03 Jan 2013 21:18:24 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> <82858.1357183894@turing-police.cc.vt.edu> <85830.1357188741@turing-police.cc.vt.edu> Message-ID: <50E63BF0.1020606@alter3d.ca> On 1/3/2013 9:08 PM, Jimmy Hess wrote: > I am not sure why this would be classified as a feature request. If it > is impacting you, and you had service before, then is an > Outage/Defect/Bug, full stop. Describing working service for a > previously supported scenario as a "feature request" would be beyond > ridiculous :) Clouds in the sky tend to look pretty until the day they dump rain on you and then disappear. "Cloud apps" are kind of like that. ;) Not to say that SaaS doesn't have its place in enterprise architecture, but one of the things that should have a huge, gigantic neon sign on it when you're doing your cost-risk-benefit analysis is that you're being put at the whim of your SaaS provider. If they make a change that breaks functionality that only a subset of their clients use, you'd better hope that one of those clients has enough financial clout with the provider to make that functionality come back, otherwise you've just painted yourself into a corner. - Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4431 bytes Desc: S/MIME Cryptographic Signature URL: From ripencc-management at ripe.net Fri Jan 4 11:50:13 2013 From: ripencc-management at ripe.net (Axel Pawlik) Date: Fri, 04 Jan 2013 12:50:13 +0100 Subject: Update - RIPE Database Proxy Service Issues Message-ID: <50E6C1F5.9080902@ripe.net> [Apologies for duplicate emails] Dear colleagues, Thank you for your comments on this issue. I would like to point out that the *DRAFT* Activity Plan and Budget is published around September of each year, allowing members ample time to read it before it is discussed at the Autumn General Meeting. The RIPE NCC Executive Board then takes the outcome of the discussions and any new developments into consideration before finalising and approving the definitive Activity Plan and Budget, which is then published before the end of the year. On 13 December 2012, we informed the membership of the definitive Activity Plan and Budget and listed the changes from the draft plan. Please note that the membership does not vote on either the draft or the final Activity Plan and Budget - this is one of the member-elected Executive Board's functions. One of the modifications that took place from the draft to the final Activity Plan was the addition of the RIPE Database Proxy Service as a member-only service. This was a follow-up on an action point that stemmed from the Data Protection Task Force and a need to strengthen our contractual relationship between the current users of the RIPE Database Proxy Service and the RIPE NCC ensuring compliance with Dutch and EU legislation. Partially based on the membership's vote of approval regarding the new Charging Scheme of "one LIR, one fee" and partially based on the fact that the RIPE Database Proxy Service is only actively used by less than a handful of entities (both members and non-members), the Executive Board made the decision, which they felt was in the members' interest, to ask the users of this service to sign both a specific RIPE Database Proxy Service Agreement and the Standard Service Agreement (Membership Agreement) that adheres to both EU and Dutch legislation, which would entail the users of this service paying the annual membership fee. Based on the recent mailing list discussions it seems apparent that this is a contentious issue that requires further membership and community discussion. Therefore, we will keep the RIPE Database Proxy Service running as it was in 2012 (i.e., no fee and no Membership Agreement) until we have completed these discussions. We will prepare a legal analysis of the options at hand for the contractual documentation required to use this service and gauge whether or not the membership feels that we should charge a fee for this service. Regards, Axel Pawlik Managing Director RIPE NCC From justin.ream at gmail.com Fri Jan 4 17:24:08 2013 From: justin.ream at gmail.com (Justin Ream) Date: Fri, 4 Jan 2013 09:24:08 -0800 Subject: Highwinds / Bandcon tech contact? Message-ID: Hi all - Working on an issue for a very large customer of Bandcon's and they have not been able to flag anyone down from Bandcon since the I believe the Highwinds acquisition and we need some BGP changes to be made. Can anyone contact me offlist? Would be most grateful. -Justin From jra at baylink.com Fri Jan 4 17:27:50 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 4 Jan 2013 12:27:50 -0500 (EST) Subject: Gmail and SSL In-Reply-To: Message-ID: <19528989.1018.1357320470333.JavaMail.root@benjamin.baylink.com> This email, right here? This is Exhibit 1 in my "not all the tradeoffs of outsourcing your $SERVICE are visible or trivial" list. Thanks. Cheers, -- jra ----- Original Message ----- > From: "Maxim Khitrov" > To: "Damian Menscher" > Cc: nanog at nanog.org > Sent: Thursday, January 3, 2013 9:01:09 AM > Subject: Re: Gmail and SSL > On Thu, Jan 3, 2013 at 12:14 AM, Damian Menscher > wrote: > > Back on topic: encryption without knowing who you're talking to is > > worse > > than useless (hence no self-signed certs which provide a false sense > > of > > security), and there are usability difficulties with exposing strong > > security to the average user (asking users to generate and upload a > > self-signed cert would be a customer-support disaster, not to > > mention all > > the outages that would occur when those certs expired). Real-world > > security is all about finding a reasonable balance and adapting to > > the > > current threats. > > The most recent change to POP3 mail retrieval over SSL is not a > reasonable balance. My organization uses Google Apps for mail hosting, > but a number of users also have us.army.mil accounts. They used to > pull mail from their .mil account into Google Apps via POP3. Army > servers do not allow unencrypted connections and their root > certificates are not part of the Mozilla Root CA list (and, as you can > guess, I have no control over their servers). > > Google didn't just block the use of self-signed certs; you broke > communication with all servers using perfectly legitimate PKIs that > are not part of the Mozilla Root CA list. Thus, instead of > "self-signed certs = false sense of security," your argument is really > "not on some arbitrary root CA list = false sense of security," which > is absolute nonsense. > > I talked to Google Apps support a few weeks ago, sent them a link to > this discussion, but all they could do is file a feature request. > IMHO, this change should never have been allowed to go into production > until there is an interface for uploading our own root certificates. > Of course, any root (i.e. self-signed) certificate can be used by the > POP3 server directly, so this would also solve the problem for people > trying to use self-signed certs not part of any PKI. > > Finally, "asking users to generate and upload a self-signed cert would > be a customer-support disaster," so you just block their access > completely? Anyone who doesn't know how to generate and upload a > certificate would probably avoid encryption altogether, don't you > think? And as for "outages that would occur when those certs expired," > what do you think people in my organization are dealing with right > now? Only an expired cert can be renewed or replaced, whereas our > access has been blocked and there is nothing we can do about it. > > - Max -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cscora at apnic.net Fri Jan 4 18:44:28 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Jan 2013 04:44:28 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201301041844.r04IiSQc009455@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 05 Jan, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 438213 Prefixes after maximum aggregation: 181057 Deaggregation factor: 2.42 Unique aggregates announced to Internet: 215491 Total ASes present in the Internet Routing Table: 42975 Prefixes per ASN: 10.20 Origin-only ASes present in the Internet Routing Table: 33999 Origin ASes announcing only one prefix: 15908 Transit ASes present in the Internet Routing Table: 5711 Transit-only ASes present in the Internet Routing Table: 139 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 31 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 374 Unregistered ASNs in the Routing Table: 129 Number of 32-bit ASNs allocated by the RIRs: 3618 Number of 32-bit ASNs visible in the Routing Table: 3265 Prefixes from 32-bit ASNs in the Routing Table: 8876 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 178 Number of addresses announced to Internet: 2622004844 Equivalent to 156 /8s, 72 /16s and 158 /24s Percentage of available address space announced: 70.8 Percentage of allocated address space announced: 70.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.1 Total number of prefixes smaller than registry allocations: 154787 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 105421 Total APNIC prefixes after maximum aggregation: 32827 APNIC Deaggregation factor: 3.21 Prefixes being announced from the APNIC address blocks: 106384 Unique aggregates announced from the APNIC address blocks: 43509 APNIC Region origin ASes present in the Internet Routing Table: 4810 APNIC Prefixes per ASN: 22.12 APNIC Region origin ASes announcing only one prefix: 1246 APNIC Region transit ASes present in the Internet Routing Table: 804 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 404 Number of APNIC addresses announced to Internet: 716927840 Equivalent to 42 /8s, 187 /16s and 115 /24s Percentage of available APNIC address space announced: 83.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 156128 Total ARIN prefixes after maximum aggregation: 78474 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 156813 Unique aggregates announced from the ARIN address blocks: 70729 ARIN Region origin ASes present in the Internet Routing Table: 15368 ARIN Prefixes per ASN: 10.20 ARIN Region origin ASes announcing only one prefix: 5812 ARIN Region transit ASes present in the Internet Routing Table: 1589 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 28 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1090414976 Equivalent to 64 /8s, 254 /16s and 105 /24s Percentage of available ARIN address space announced: 57.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 112772 Total RIPE prefixes after maximum aggregation: 58370 RIPE Deaggregation factor: 1.93 Prefixes being announced from the RIPE address blocks: 115760 Unique aggregates announced from the RIPE address blocks: 74317 RIPE Region origin ASes present in the Internet Routing Table: 17013 RIPE Prefixes per ASN: 6.80 RIPE Region origin ASes announcing only one prefix: 8158 RIPE Region transit ASes present in the Internet Routing Table: 2767 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 31 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2106 Number of RIPE addresses announced to Internet: 650081892 Equivalent to 38 /8s, 191 /16s and 118 /24s Percentage of available RIPE address space announced: 94.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 45236 Total LACNIC prefixes after maximum aggregation: 8993 LACNIC Deaggregation factor: 5.03 Prefixes being announced from the LACNIC address blocks: 48856 Unique aggregates announced from the LACNIC address blocks: 23141 LACNIC Region origin ASes present in the Internet Routing Table: 1764 LACNIC Prefixes per ASN: 27.70 LACNIC Region origin ASes announcing only one prefix: 504 LACNIC Region transit ASes present in the Internet Routing Table: 335 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 732 Number of LACNIC addresses announced to Internet: 121174312 Equivalent to 7 /8s, 56 /16s and 249 /24s Percentage of available LACNIC address space announced: 72.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9660 Total AfriNIC prefixes after maximum aggregation: 2340 AfriNIC Deaggregation factor: 4.13 Prefixes being announced from the AfriNIC address blocks: 10222 Unique aggregates announced from the AfriNIC address blocks: 3636 AfriNIC Region origin ASes present in the Internet Routing Table: 585 AfriNIC Prefixes per ASN: 17.47 AfriNIC Region origin ASes announcing only one prefix: 188 AfriNIC Region transit ASes present in the Internet Routing Table: 127 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 43102208 Equivalent to 2 /8s, 145 /16s and 176 /24s Percentage of available AfriNIC address space announced: 42.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2928 11555 911 Korea Telecom (KIX) 17974 2487 829 54 PT TELEKOMUNIKASI INDONESIA 7545 1815 301 88 TPG Internet Pty Ltd 4755 1664 381 175 TATA Communications formerly 9829 1409 1155 41 BSNL National Internet Backbo 9583 1198 89 501 Sify Limited 7552 1142 1070 12 Vietel Corporation 4808 1124 2040 316 CNCGROUP IP network: China169 9498 1052 309 74 BHARTI Airtel Ltd. 24560 1038 385 161 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3457 1266 216 Windstream Communications Inc 6389 3117 3701 131 bellsouth.net, inc. 18566 2081 382 180 Covad Communications 22773 1952 2932 131 Cox Communications, Inc. 1785 1945 678 124 PaeTec Communications, Inc. 20115 1690 1604 620 Charter Communications 4323 1596 1155 397 Time Warner Telecom 30036 1354 288 708 Mediacom Communications Corp 7018 1293 10549 853 AT&T WorldNet Services 7011 1206 321 685 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1738 544 16 Corbina telecom 2118 1052 97 15 EUnet/RELCOM Autonomous Syste 34984 904 211 232 BILISIM TELEKOM 12479 869 777 64 Uni2 Autonomous System 13188 770 96 117 Educational Network 31148 743 38 15 FreeNet ISP 20940 734 242 572 Akamai Technologies European 6830 714 2313 435 UPC Distribution Services 8551 658 367 39 Bezeq International 58113 633 70 378 LIR DATACENTER TELECOM SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2270 387 207 TVCABLE BOGOTA 28573 2258 1299 70 NET Servicos de Comunicao S.A 7303 1674 1139 202 Telecom Argentina Stet-France 6503 1452 435 67 AVANTEL, S.A. 8151 1417 2913 354 UniNet S.A. de C.V. 18881 747 716 18 Global Village Telecom 27947 745 85 94 Telconet S.A 3816 672 309 71 Empresa Nacional de Telecomun 11172 602 86 66 Servicios Alestra S.A de C.V 7738 587 1242 34 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 878 275 36 LINKdotNET AS number 36998 749 48 3 MOBITEL 8452 543 958 13 TEDATA 6713 499 602 20 Itissalat Al-MAGHRIB 24835 291 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 181 697 88 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3457 1266 216 Windstream Communications Inc 6389 3117 3701 131 bellsouth.net, inc. 4766 2928 11555 911 Korea Telecom (KIX) 17974 2487 829 54 PT TELEKOMUNIKASI INDONESIA 10620 2270 387 207 TVCABLE BOGOTA 28573 2258 1299 70 NET Servicos de Comunicao S.A 18566 2081 382 180 Covad Communications 22773 1952 2932 131 Cox Communications, Inc. 1785 1945 678 124 PaeTec Communications, Inc. 7545 1815 301 88 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3117 2986 bellsouth.net, inc. 17974 2487 2433 PT TELEKOMUNIKASI INDONESIA 28573 2258 2188 NET Servicos de Comunicao S.A 10620 2270 2063 TVCABLE BOGOTA 4766 2928 2017 Korea Telecom (KIX) 18566 2081 1901 Covad Communications 22773 1952 1821 Cox Communications, Inc. 1785 1945 1821 PaeTec Communications, Inc. 7545 1815 1727 TPG Internet Pty Ltd 8402 1738 1722 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 mywire Datentechnik GmbH Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.112.114.0/24 23884 Proimage Engineering and Comm 31.210.16.0/22 15657 Neural Networks ASN 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.66.32.0/20 18864 >>UNKNOWN<< 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:13 /10:29 /11:87 /12:245 /13:478 /14:859 /15:1546 /16:12490 /17:6562 /18:10926 /19:21636 /20:31075 /21:33048 /22:44245 /23:40846 /24:230123 /25:1300 /26:1682 /27:871 /28:41 /29:59 /30:13 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2723 3457 Windstream Communications Inc 18566 2031 2081 Covad Communications 6389 1773 3117 bellsouth.net, inc. 8402 1463 1738 Corbina telecom 22773 1283 1952 Cox Communications, Inc. 30036 1255 1354 Mediacom Communications Corp 11492 1157 1194 Cable One 1785 1027 1945 PaeTec Communications, Inc. 6503 979 1452 AVANTEL, S.A. 7011 954 1206 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:685 2:697 3:3 4:13 5:703 6:3 8:477 12:1938 13:3 14:701 15:11 16:3 17:6 20:27 23:221 24:1793 27:1473 31:1367 32:54 33:2 34:2 36:11 37:1160 38:842 39:2 40:139 41:2599 42:180 44:3 46:1705 47:3 49:531 50:649 52:12 54:28 55:8 57:28 58:1071 59:561 60:236 61:1317 62:1033 63:2021 64:4361 65:2200 66:4499 67:2088 68:1197 69:3334 70:939 71:551 72:1888 74:2619 75:470 76:295 77:1050 78:1034 79:545 80:1214 81:982 82:655 83:532 84:530 85:1165 86:463 87:969 88:360 89:1737 90:304 91:5387 92:610 93:1617 94:1982 95:1618 96:489 97:337 98:983 99:48 100:32 101:298 103:1969 105:501 106:125 107:207 108:508 109:1743 110:839 111:988 112:470 113:742 114:682 115:896 116:900 117:775 118:967 119:1268 120:373 121:707 122:1725 123:1168 124:1315 125:1301 128:810 129:201 130:309 131:641 132:319 133:142 134:255 135:62 136:209 137:232 138:342 139:169 140:182 141:300 142:514 143:355 144:490 145:89 146:520 147:326 148:727 149:335 150:158 151:248 152:398 153:188 154:24 155:413 156:232 157:379 158:256 159:680 160:335 161:422 162:370 163:193 164:587 165:461 166:464 167:569 168:1005 169:131 170:1001 171:164 172:4 173:1590 174:770 175:470 176:950 177:1522 178:1705 180:1361 181:189 182:1148 183:292 184:656 185:155 186:2175 187:1437 188:1910 189:1552 190:6202 192:6103 193:5714 194:4493 195:3607 196:1227 197:287 198:4045 199:5162 200:6024 201:2017 202:8790 203:8730 204:4475 205:2538 206:2799 207:2773 208:4066 209:3665 210:2900 211:1560 212:1995 213:1882 214:873 215:91 216:5136 217:1564 218:596 219:323 220:1259 221:544 222:323 223:395 End of report From cidr-report at potaroo.net Fri Jan 4 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Jan 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201301042200.r04M00Fw074545@wattle.apnic.net> This report has been generated at Fri Jan 4 21:13:10 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-12-12 440905 252741 29-12-12 440921 252832 30-12-12 440920 252878 31-12-12 441045 252978 01-01-13 441252 252919 02-01-13 441130 252917 03-01-13 440943 253050 04-01-13 441064 252781 AS Summary 43079 Number of ASes in routing system 17944 Number of ASes announcing only one prefix 3458 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 115684832 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 04Jan13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 441027 252781 188246 42.7% All ASes AS6389 3117 135 2982 95.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2265 71 2194 96.9% NET Servicos de Comunicao S.A. AS17974 2486 454 2032 81.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2928 928 2000 68.3% KIXS-AS-KR Korea Telecom AS7029 3458 1611 1847 53.4% WINDSTREAM - Windstream Communications Inc AS22773 1952 183 1769 90.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2081 423 1658 79.7% COVAD - Covad Communications Co. AS10620 2270 652 1618 71.3% Telmex Colombia S.A. AS7303 1674 397 1277 76.3% Telecom Argentina S.A. AS4323 1600 402 1198 74.9% TWTC - tw telecom holdings, inc. AS4755 1664 552 1112 66.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1052 53 999 95.0% RELCOM-AS OOO "NPO Relcom" AS7552 1142 163 979 85.7% VIETEL-AS-AP Vietel Corporation AS7545 1819 948 871 47.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 1016 171 845 83.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1424 584 840 59.0% Uninet S.A. de C.V. AS1785 1944 1160 784 40.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1124 351 773 68.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 848 118 730 86.1% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS18881 747 35 712 95.3% Global Village Telecom AS855 715 52 663 92.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS9808 682 32 650 95.3% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS17676 712 92 620 87.1% GIGAINFRA Softbank BB Corp. AS3356 1121 510 611 54.5% LEVEL3 Level 3 Communications AS3549 1036 437 599 57.8% GBLX Global Crossing Ltd. AS22561 1040 442 598 57.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1000 405 595 59.5% VZGNI-TRANSIT - Verizon Online LLC AS24560 1038 444 594 57.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22047 579 30 549 94.8% VTR BANDA ANCHA S.A. AS4804 632 96 536 84.8% MPX-AS Microplex PTY LTD Total 45166 11931 33235 73.6% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 31.210.16.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.64.0.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 194.8.86.0/24 AS25074 MESH-AS MESH GmbH 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.87.96.0/21 AS40638 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 4 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Jan 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201301042200.r04M01vV074561@wattle.apnic.net> BGP Update Report Interval: 27-Dec-12 -to- 03-Jan-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 77618 5.7% 46.2 -- BSNL-NIB National Internet Backbone 2 - AS45271 45100 3.3% 193.6 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road 3 - AS3909 36140 2.6% 12046.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - AS29256 28656 2.1% 434.2 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 5 - AS8402 23204 1.7% 51.6 -- CORBINA-AS OJSC "Vimpelcom" 6 - AS4657 18609 1.4% 72.4 -- STARHUBINTERNET-AS StarHub Internet Exchange 7 - AS7552 16582 1.2% 20.9 -- VIETEL-AS-AP Vietel Corporation 8 - AS48159 16399 1.2% 42.6 -- TIC-AS Telecommunication Infrastructure Company 9 - AS28306 12104 0.9% 356.0 -- TC Net Inform?tica e Telecomunica??es LTDA 10 - AS37113 11706 0.8% 260.1 -- tangerine-ug-as 11 - AS1637 10380 0.8% 324.4 -- DNIC-AS-01637 - Headquarters, USAISC 12 - AS12880 9181 0.7% 64.7 -- DCI-AS Information Technology Company (ITC) 13 - AS2697 7698 0.6% 98.7 -- ERX-ERNET-AS Education and Research Network 14 - AS36915 7667 0.6% 225.5 -- AFOL-KE-AS 15 - AS9756 7591 0.6% 506.1 -- CHEONANVITSSEN-AS-KR Cheonan Broadcast Corporation 16 - AS8151 7342 0.5% 7.8 -- Uninet S.A. de C.V. 17 - AS57044 7007 0.5% 500.5 -- BRYANSK-AS CJSC "ER-Telecom Holding" 18 - AS2033 6792 0.5% 6792.0 -- PANIX - Panix Network Information Center 19 - AS29859 6764 0.5% 32.8 -- WOW-INTERNET-ILL - WideOpenWest Finance LLC 20 - AS4802 6332 0.5% 186.2 -- ASN-IINET iiNet Limited TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3909 36140 2.6% 12046.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - AS2033 6792 0.5% 6792.0 -- PANIX - Panix Network Information Center 3 - AS42705 5440 0.4% 5440.0 -- TALIA Talia provides VSAT network and hosting services worldwide. 4 - AS57918 3677 0.3% 3677.0 -- ACOD-AS ACOD CJSC 5 - AS6174 5692 0.4% 2846.0 -- SPRINTLINK8 - Sprint 6 - AS6629 2598 0.2% 2598.0 -- NOAA-AS - NOAA 7 - AS19406 4399 0.3% 2199.5 -- TWRS-MA - Towerstream I, Inc. 8 - AS37430 2179 0.2% 2179.0 -- vdctelecom 9 - AS6407 2154 0.2% 2154.0 -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 10 - AS9950 4008 0.3% 2004.0 -- PUBNETPLUS2-AS-KR DACOM 11 - AS17293 3939 0.3% 1969.5 -- VTXC - VTX Communications 12 - AS14680 4906 0.4% 1635.3 -- REALE-6 - Auction.com 13 - AS4826 1459 0.1% 1459.0 -- VOCUS-BACKBONE-AS Vocus Connect International Backbone 14 - AS28722 1392 0.1% 1392.0 -- ENERGETYKA-KALISKA-AS ENERGA-OPERATOR SA 15 - AS36529 2476 0.2% 1238.0 -- AXXA-RACKCO - Rackco.com 16 - AS6620 1237 0.1% 1237.0 -- AS-6620 - AMA Communications, LLC 17 - AS40931 1706 0.1% 853.0 -- MOBITV - MobiTV, Inc 18 - AS27594 1605 0.1% 802.5 -- UTSA - University of Texas at San Antonio 19 - AS33976 672 0.1% 672.0 -- AFTONBLADET-SE aftonbladet.se 20 - AS32529 672 0.1% 672.0 -- CGI-FEDERAL-ASN-1 - CGI Federal TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.255.0/24 12070 0.8% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.254.0/24 12070 0.8% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 12000 0.8% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 209.48.168.0/24 6792 0.5% AS2033 -- PANIX - Panix Network Information Center 5 - 109.194.4.0/24 6606 0.5% AS57044 -- BRYANSK-AS CJSC "ER-Telecom Holding" 6 - 203.28.157.0/24 5997 0.4% AS4802 -- ASN-IINET iiNet Limited 7 - 80.251.10.0/24 5440 0.4% AS42705 -- TALIA Talia provides VSAT network and hosting services worldwide. 8 - 69.38.178.0/24 4396 0.3% AS19406 -- TWRS-MA - Towerstream I, Inc. 9 - 194.63.9.0/24 4323 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 10 - 12.139.133.0/24 4162 0.3% AS14680 -- REALE-6 - Auction.com 11 - 58.184.229.0/24 4002 0.3% AS9950 -- PUBNETPLUS2-AS-KR DACOM 12 - 91.236.24.0/24 3677 0.2% AS57918 -- ACOD-AS ACOD CJSC 13 - 206.105.75.0/24 2848 0.2% AS6174 -- SPRINTLINK8 - Sprint 14 - 208.16.110.0/24 2844 0.2% AS6174 -- SPRINTLINK8 - Sprint 15 - 115.170.128.0/17 2843 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange 16 - 192.58.232.0/24 2598 0.2% AS6629 -- NOAA-AS - NOAA 17 - 5.0.32.0/19 2586 0.2% AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment 18 - 31.9.96.0/19 2546 0.2% AS29256 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 19 - 5.0.128.0/19 2518 0.2% AS29256 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 20 - 5.0.160.0/19 2518 0.2% AS29256 -- INT-PDN-STE-AS Syrian Telecommunications Establishment Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From Eric.Sabo at calu.edu Sat Jan 5 18:32:18 2013 From: Eric.Sabo at calu.edu (Sabo, Eric) Date: Sat, 5 Jan 2013 18:32:18 +0000 Subject: Contact Information (yahoo.com or aol.com) Message-ID: <66D9E8F23BC4F04699A6156D3C92556895C965@MLEXMBX2.CALU.LCL> Does anyone have any contact information for yahoo.com or Aol.com? We are having some issues with NDRs coming from these domains. Thanks, Eric Sabo From dave at temk.in Mon Jan 7 19:09:51 2013 From: dave at temk.in (David Temkin) Date: Mon, 7 Jan 2013 11:09:51 -0800 Subject: Preliminary NANOG Topic List Posted - NANOG 57 in Orlando, FL Message-ID: All, The preliminary topic list for NANOG 57 in Orlando, FL has been posted at http://www.nanog.org/meetings/nanog57/agenda.php We will continue to update this as we confirm speakers and presentations for this upcoming conference. Also, as a reminder - standard registration ends on January 10th and the price rises from $525 to $600, so if you intend on coming please register ASAP. Regards, -Dave Temkin Chair, NANOG Program Committee From blair.trosper at gmail.com Mon Jan 7 21:12:34 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Mon, 7 Jan 2013 15:12:34 -0600 Subject: Comcast Business / Miami, FL Message-ID: Can someone from Comcast contact me off list to help diagnose a business class issue to do with the Comcast AS and peering to cloud services and outrageously high latency confined to a few adjacent ASes? From member at linkedin.com Tue Jan 8 09:26:06 2013 From: member at linkedin.com (glauber gabriel via LinkedIn) Date: Tue, 8 Jan 2013 09:26:06 +0000 (UTC) Subject: Join my network on LinkedIn Message-ID: <161362341.61382033.1357637166048.JavaMail.app@ela4-app2311.prod> LinkedIn ------------ glauber gabriel requested to add you as a connection on LinkedIn: ------------------------------------------ I'd like to add you to my professional network on LinkedIn. Accept invitation from glauber gabriel http://www.linkedin.com/e/-voa23o-hbou45ow-6b/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I294101987_50/3wOtCVFbmdxnSVFbm8JrnpKqlZJrmZzbmNJpjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfP0RnPsUej4McjgVcAALd6AVcPd4i6gLd3kUcPcPcjkOc34LrCBxbOYWrSlI/eml-comm_invm-b-in_ac-inv28/?hs=false&tok=0pb-Og-tPmgRA1 View profile of glauber gabriel http://www.linkedin.com/e/-voa23o-hbou45ow-6b/rso/83706038/sJhI/name/50054316_I294101987_50/?hs=false&tok=2w8mzCcH_mgRA1 ------------------------------------------ You are receiving Invitation emails. This email was intended for Ted Fischer. Learn why this is included: http://www.linkedin.com/e/-voa23o-hbou45ow-6b/plh/http%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?hs=false&tok=34iKGZTnzmgRA1 (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. From jason at jasonantman.com Tue Jan 8 13:21:14 2013 From: jason at jasonantman.com (Jason Antman) Date: Tue, 08 Jan 2013 08:21:14 -0500 Subject: Join my network on LinkedIn In-Reply-To: <161362341.61382033.1357637166048.JavaMail.app@ela4-app2311.prod> References: <161362341.61382033.1357637166048.JavaMail.app@ela4-app2311.prod> Message-ID: <50EC1D4A.3080807@jasonantman.com> If you use LinkedIn (a popular business-oriented social networking site), and utilize the feature to import your email contacts and send connection requests to all of them, *please* un-check the mailing list addresses... since apparently this has now been done twice... -j antman On 01/08/2013 04:26 AM, glauber gabriel via LinkedIn wrote: > LinkedIn > ------------ > > > > > glauber gabriel requested to add you as a connection on LinkedIn: > > > ------------------------------------------ > > I'd like to add you to my professional network on LinkedIn. > > Accept invitation from glauber gabriel > http://www.linkedin.com/e/-voa23o-hbou45ow-6b/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I294101987_50/3wOtCVFbmdxnSVFbm8JrnpKqlZJrmZzbmNJpjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfP0RnPsUej4McjgVcAALd6AVcPd4i6gLd3kUcPcPcjkOc34LrCBxbOYWrSlI/eml-comm_invm-b-in_ac-inv28/?hs=false&tok=0pb-Og-tPmgRA1 > > View profile of glauber gabriel > http://www.linkedin.com/e/-voa23o-hbou45ow-6b/rso/83706038/sJhI/name/50054316_I294101987_50/?hs=false&tok=2w8mzCcH_mgRA1 > ------------------------------------------ > You are receiving Invitation emails. > > > This email was intended for Ted Fischer. > Learn why this is included: http://www.linkedin.com/e/-voa23o-hbou45ow-6b/plh/http%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?hs=false&tok=34iKGZTnzmgRA1 > > (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. > > > From paul at paulstewart.org Tue Jan 8 13:51:17 2013 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 8 Jan 2013 08:51:17 -0500 Subject: Postini Exiting ISP Business? Message-ID: <34f601cdeda7$3c96ce90$b5c46bb0$@paulstewart.org> Hey there. We have been using Postini for a number of years as our anti-spam/anti-virus protection for customer email accounts. Mid last year we received a notice from Google that "In 2013, we plan to transition your Postini services to Google Apps for Business." As part of this notice we were also told "You don't need to make any changes to your Postini service or sign up for a Google Apps account. Your Postini service will continue as usual until your migration begins. We will be in touch at least 60 days before your renewal date." In mid November, Google sent us a letter that stated that we had until the end of 2013 to basically get off their service or to contact their preferred partner (Tech Excel) and migrate to Google Apps with them. Recently we have now been told in email by someone at Postini that we "must transition ASAP" and that we really only had til the end of 2012. Geesh, talk about confusing.. Not a great way to treat a long term customer! Anyone else getting the complete "run around" by Postini? We are fine with leaving them, especially now. Having said that, I'm interested in hearing about competitive solutions either in appliances or in cloud based - this is *not* an invitation for sales people to call me please. Thanks, Paul From faisal at snappydsl.net Tue Jan 8 14:07:47 2013 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 8 Jan 2013 09:07:47 -0500 Subject: Postini Exiting ISP Business? In-Reply-To: <34f601cdeda7$3c96ce90$b5c46bb0$@paulstewart.org> References: <34f601cdeda7$3c96ce90$b5c46bb0$@paulstewart.org> Message-ID: <13AFC997-BD8B-4487-A2E4-2CCBA3C26738@snappydsl.net> We got off Postini many years ago, and have never looked back.. We switched to Katharion, today they are known as GFI Max Mail, Let me know if u are interested in switching, I will be more than happy to send u the contact info for them. Regards Faisal On Jan 8, 2013, at 8:51 AM, "Paul Stewart" wrote: > Hey there. > > > > We have been using Postini for a number of years as our anti-spam/anti-virus > protection for customer email accounts. > > > > Mid last year we received a notice from Google that "In 2013, we plan to > transition your Postini services to Google Apps for Business." > > > > As part of this notice we were also told "You don't need to make any changes > to your Postini service or sign up for a Google Apps account. Your Postini > service will continue as usual until your migration begins. We will be in > touch at least 60 days before your renewal date." > > > > In mid November, Google sent us a letter that stated that we had until the > end of 2013 to basically get off their service or to contact their preferred > partner (Tech Excel) and migrate to Google Apps with them. > > > > Recently we have now been told in email by someone at Postini that we "must > transition ASAP" and that we really only had til the end of 2012. Geesh, > talk about confusing.. Not a great way to treat a long term customer! > > > > Anyone else getting the complete "run around" by Postini? We are fine with > leaving them, especially now. Having said that, I'm interested in hearing > about competitive solutions either in appliances or in cloud based - this is > *not* an invitation for sales people to call me please. > > > > Thanks, > > > > Paul > > > > From maillist at webjogger.net Tue Jan 8 14:22:42 2013 From: maillist at webjogger.net (Adam Greene) Date: Tue, 08 Jan 2013 09:22:42 -0500 Subject: Postini Exiting ISP Business? In-Reply-To: <13AFC997-BD8B-4487-A2E4-2CCBA3C26738@snappydsl.net> References: <34f601cdeda7$3c96ce90$b5c46bb0$@paulstewart.org> <13AFC997-BD8B-4487-A2E4-2CCBA3C26738@snappydsl.net> Message-ID: <50EC2BB2.7050107@webjogger.net> We're in the same boat as Paul and have been investigating McAfee Email Protection (used to be MX Logic). A bit more expensive than Postini, but also more full featured. Additional options can be added on as well, like archiving & outbound encryption. We've thought about deploying a virtual appliance in our datacenter like Barracuda but kind of don't want to have to deal with administering it all ourselves in house. Outsourcing is attractive to us for this service. On 1/8/2013 9:07 AM, Faisal Imtiaz wrote: > We got off Postini many years ago, and have never looked back.. > We switched to Katharion, today they are known as GFI Max Mail, > Let me know if u are interested in switching, I will be more than happy to send u the contact info for them. > > Regards > > Faisal > > On Jan 8, 2013, at 8:51 AM, "Paul Stewart" wrote: > >> Hey there. >> >> >> >> We have been using Postini for a number of years as our anti-spam/anti-virus >> protection for customer email accounts. >> >> >> >> Mid last year we received a notice from Google that "In 2013, we plan to >> transition your Postini services to Google Apps for Business." >> >> >> >> As part of this notice we were also told "You don't need to make any changes >> to your Postini service or sign up for a Google Apps account. Your Postini >> service will continue as usual until your migration begins. We will be in >> touch at least 60 days before your renewal date." >> >> >> >> In mid November, Google sent us a letter that stated that we had until the >> end of 2013 to basically get off their service or to contact their preferred >> partner (Tech Excel) and migrate to Google Apps with them. >> >> >> >> Recently we have now been told in email by someone at Postini that we "must >> transition ASAP" and that we really only had til the end of 2012. Geesh, >> talk about confusing.. Not a great way to treat a long term customer! >> >> >> >> Anyone else getting the complete "run around" by Postini? We are fine with >> leaving them, especially now. Having said that, I'm interested in hearing >> about competitive solutions either in appliances or in cloud based - this is >> *not* an invitation for sales people to call me please. >> >> >> >> Thanks, >> >> >> >> Paul >> >> >> >> > > From erik.soosalu at calyxinc.com Tue Jan 8 14:26:34 2013 From: erik.soosalu at calyxinc.com (Erik Soosalu) Date: Tue, 8 Jan 2013 09:26:34 -0500 Subject: Postini Exiting ISP Business? In-Reply-To: <34f601cdeda7$3c96ce90$b5c46bb0$@paulstewart.org> References: <34f601cdeda7$3c96ce90$b5c46bb0$@paulstewart.org> Message-ID: <0B224A2FE01CC54C860290D42474BF6005832510@exchange.nff.local> I am an enterprise guy, but we've been running MS Forefront Online Protection for Exchange for a number of years with very few issues (that aren't determined by flags/polices we've set). The few issues that we have had have been with delayed SMTP handoffs between Hostopia (Bell's backend provider) and FOPE, but I haven't had reports of that for a couple of years. Thanks, Erik -----Original Message----- From: Paul Stewart [mailto:paul at paulstewart.org] Sent: Tuesday, January 08, 2013 8:51 AM To: nanog at nanog.org Subject: Postini Exiting ISP Business? Hey there. We have been using Postini for a number of years as our anti-spam/anti-virus protection for customer email accounts. Mid last year we received a notice from Google that "In 2013, we plan to transition your Postini services to Google Apps for Business." As part of this notice we were also told "You don't need to make any changes to your Postini service or sign up for a Google Apps account. Your Postini service will continue as usual until your migration begins. We will be in touch at least 60 days before your renewal date." In mid November, Google sent us a letter that stated that we had until the end of 2013 to basically get off their service or to contact their preferred partner (Tech Excel) and migrate to Google Apps with them. Recently we have now been told in email by someone at Postini that we "must transition ASAP" and that we really only had til the end of 2012. Geesh, talk about confusing.. Not a great way to treat a long term customer! Anyone else getting the complete "run around" by Postini? We are fine with leaving them, especially now. Having said that, I'm interested in hearing about competitive solutions either in appliances or in cloud based - this is *not* an invitation for sales people to call me please. Thanks, Paul From tim at interworx.nl Tue Jan 8 14:45:10 2013 From: tim at interworx.nl (Tim Vollebregt) Date: Tue, 8 Jan 2013 15:45:10 +0100 Subject: [j-nsp] Krt queue issues In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0C996C97@MUNEXBE1.medline.com> References: <20121001121539.GA10356@pob.ytti.fi> <2A76E400AC84B845AAC35AA19F8E7A5D0C996C97@MUNEXBE1.medline.com> Message-ID: <4B45C5C9-B16C-4DB9-87D9-B1C1E7621929@interworx.nl> Hi, What we do nowadays as some workaround, is configuring a default route towards a core router on 8 x 10G before maintaining an MX box. Which will be installed before BGP sessions come up, this will cause some packet loss during burst hour outages but is fine during maintenance hours. I've seen cases where it took up to 30 minutes before the full table was installed correctly in the PFE's. Currently this issue/bug is holding back our Juniper deployments. As far as I know Juniper created a project group for this bug, and so far they were able to reproduce the issue. Looks like the issue is being taken serious from now. Tim On Oct 3, 2012, at 11:50 PM, Naslund, Steve wrote: > I think route retention might help in the event the table was cleared or > routing process restarted but I don't that it will help with a boot > because the table structures are being built as part of the system > initialization. In reality, I would expect the static routes to get > installed very early as soon as the routing process comes up. Since you > will need a route to your BGP neighbor (even though it may be directly > connected, it is still a route), routing has to be up BEFORE BGP > establishes and by definition your static routes will have to be up > before your BGP routes are ready. How well your router responds to > traffic during an initial boot and during a 300,000 route update is > another story. My experience with very large routers and tables is that > you will have a hard time guaranteeing user traffic will pass with very > much performance during an event like a full table rebuild. Luckily > with the bandwidth we have these days and the CPU power on the routers, > it does not take that long to pull in a full internet table and begin > handling traffic. > > Steven Naslund > > -----Original Message----- > From: Jensen Tyler [mailto:JTyler at fiberutilities.com] > Sent: Wednesday, October 03, 2012 9:45 AM > To: nanog at nanog.org > Subject: RE: [j-nsp] Krt queue issues > > Look into Static route retain. Should keep the route in the forwarding > table. > > From Jniper site > <<< > Route Retention > > By default, static routes are not retained in the forwarding table when > the routing process shuts down. When the routing process starts up > again, any routes configured as static routes must be added to the > forwarding table again. To avoid this latency, routes can be flagged as > retain, so that they are kept in the forwarding table even after the > routing process shuts down. Retention ensures that the routes are always > in the forwarding table, even immediately after a system reboot. >>>> > > Thanks, > > Jensen Tyler > Sr Engineering Manager > Fiberutilities Group, LLC > > > -----Original Message----- > From: juniper-nsp-bounces at puck.nether.net > [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Benny Amorsen > Sent: Wednesday, October 03, 2012 8:32 AM > To: Jared Mauch > Cc: Saku Ytti; juniper-nsp at puck.nether.net > Subject: Re: [j-nsp] Krt queue issues > > Jared Mauch writes: > >> As far as the fallback 'default' route, if you are purchasing transit >> from someone, you could consider a last-resort default pointed at >> them. You can exclude routes like 10/8 etc by routing these to discard >> + install on your devices. > > That only helps if the default gets installed first, though. If the > default has to wait at boot in the krt-queue behind the 300k+ > Internet-routes, I have not really gained anything... > > I suppose it is likely that a static default would be installed before > the BGP sessions even come up. > > > /Benny > _______________________________________________ > juniper-nsp mailing list juniper-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > From rsk at gsp.org Tue Jan 8 16:36:13 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 8 Jan 2013 11:36:13 -0500 Subject: Fwd: Mark Crispin - MRC - Inventor of IMAP and a friend for decades, has died at 56 Message-ID: <20130108163612.GA9798@gsp.org> ----- Forwarded message from Lauren Weinstein ----- > Date: Mon, 7 Jan 2013 10:35:59 -0800 > From: Lauren Weinstein > To: nnsquad at nnsquad.org > Subject: [ NNSquad ] Mark Crispin - MRC - Inventor of IMAP and a friend for > decades, has died at 56 > > Mark Crispin - MRC - Inventor of IMAP and a friend for decades, has > died at 56 Lauren was also kind enough to provide a link to a posting on Google+ which provides more information: https://plus.google.com/114753028665775786510/posts/4YvWfnneTyN Mark did an awful, awful lot for all of us and for huge numbers of people who'll never know his name. Perhaps it would be appropriate to take a moment and send a kind thought to his family/friends via the funeral home guestbook: http://cookfamilyfuneralhome.com/obits/obituaries.asp?Id=1344 ---rsk From rayw at rayw.net Tue Jan 8 17:06:02 2013 From: rayw at rayw.net (Ray Wong) Date: Tue, 8 Jan 2013 09:06:02 -0800 Subject: Postini Exiting ISP Business? In-Reply-To: <0B224A2FE01CC54C860290D42474BF6005832510@exchange.nff.local> References: <34f601cdeda7$3c96ce90$b5c46bb0$@paulstewart.org> <0B224A2FE01CC54C860290D42474BF6005832510@exchange.nff.local> Message-ID: I used to work for Postini, but have long since lost touch with pretty much everyone there. I'm actually surprised this didn't happen sooner. When Google bought them (what, over 5 years now?), it seemed fairly obvious they were going to be integrating them into their own email offerings. The lack of customer service is, somewhat sadly, fairly typical of Google's offerings. Once you get into dealings with Google's actual business units it's a little better, but still always a challenge to reach a human being who can actually give you straight answers and simplify things. Actually, pretty typical IME of almost every company that's run by the Tech people(top execs not withstanding, they've always favored promoting/hiring techier people to oversee pretty much everything... even sales types get the tech screen interviews, just with lower grading standards) to forget how to actually treat customers. -R> On Tue, Jan 8, 2013 at 6:26 AM, Erik Soosalu wrote: > I am an enterprise guy, but we've been running MS Forefront Online > Protection for Exchange for a number of years with very few issues (that > aren't determined by flags/polices we've set). The few issues that we > have had have been with delayed SMTP handoffs between Hostopia (Bell's > backend provider) and FOPE, but I haven't had reports of that for a > couple of years. > > > Thanks, > Erik > -----Original Message----- > From: Paul Stewart [mailto:paul at paulstewart.org] > Sent: Tuesday, January 08, 2013 8:51 AM > To: nanog at nanog.org > Subject: Postini Exiting ISP Business? > > Hey there. > > > > We have been using Postini for a number of years as our > anti-spam/anti-virus > protection for customer email accounts. > > > > Mid last year we received a notice from Google that "In 2013, we plan to > transition your Postini services to Google Apps for Business." > > > > As part of this notice we were also told "You don't need to make any > changes > to your Postini service or sign up for a Google Apps account. Your > Postini > service will continue as usual until your migration begins. We will be > in > touch at least 60 days before your renewal date." > > > > In mid November, Google sent us a letter that stated that we had until > the > end of 2013 to basically get off their service or to contact their > preferred > partner (Tech Excel) and migrate to Google Apps with them. > > > > Recently we have now been told in email by someone at Postini that we > "must > transition ASAP" and that we really only had til the end of 2012. > Geesh, > talk about confusing.. Not a great way to treat a long term customer! > > > > Anyone else getting the complete "run around" by Postini? We are fine > with > leaving them, especially now. Having said that, I'm interested in > hearing > about competitive solutions either in appliances or in cloud based - > this is > *not* an invitation for sales people to call me please. > > > > Thanks, > > > > Paul > > > > > From skhosla at neutraldata.com Tue Jan 8 18:09:30 2013 From: skhosla at neutraldata.com (Sameer Khosla) Date: Tue, 8 Jan 2013 18:09:30 +0000 Subject: Postini Exiting ISP Business? In-Reply-To: <0B224A2FE01CC54C860290D42474BF6005832510@exchange.nff.local> References: <34f601cdeda7$3c96ce90$b5c46bb0$@paulstewart.org> <0B224A2FE01CC54C860290D42474BF6005832510@exchange.nff.local> Message-ID: <49A81EB09F493442B6D259E36251192CE594063E@ndcc-exch1.neutraldata.com> We use mailfoundry internally ourselves, but I have a customer who has been raving about mimecast for years and I am on the verge of switching over to them. Thanks Sameer -----Original Message----- From: Erik Soosalu [mailto:erik.soosalu at calyxinc.com] Sent: Tuesday, January 08, 2013 9:27 AM To: Paul Stewart; nanog at nanog.org Subject: RE: Postini Exiting ISP Business? I am an enterprise guy, but we've been running MS Forefront Online Protection for Exchange for a number of years with very few issues (that aren't determined by flags/polices we've set). The few issues that we have had have been with delayed SMTP handoffs between Hostopia (Bell's backend provider) and FOPE, but I haven't had reports of that for a couple of years. Thanks, Erik -----Original Message----- From: Paul Stewart [mailto:paul at paulstewart.org] Sent: Tuesday, January 08, 2013 8:51 AM To: nanog at nanog.org Subject: Postini Exiting ISP Business? Hey there. We have been using Postini for a number of years as our anti-spam/anti-virus protection for customer email accounts. Mid last year we received a notice from Google that "In 2013, we plan to transition your Postini services to Google Apps for Business." As part of this notice we were also told "You don't need to make any changes to your Postini service or sign up for a Google Apps account. Your Postini service will continue as usual until your migration begins. We will be in touch at least 60 days before your renewal date." In mid November, Google sent us a letter that stated that we had until the end of 2013 to basically get off their service or to contact their preferred partner (Tech Excel) and migrate to Google Apps with them. Recently we have now been told in email by someone at Postini that we "must transition ASAP" and that we really only had til the end of 2012. Geesh, talk about confusing.. Not a great way to treat a long term customer! Anyone else getting the complete "run around" by Postini? We are fine with leaving them, especially now. Having said that, I'm interested in hearing about competitive solutions either in appliances or in cloud based - this is *not* an invitation for sales people to call me please. Thanks, Paul From jeroen at mompl.net Tue Jan 8 18:43:39 2013 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 08 Jan 2013 10:43:39 -0800 Subject: LA locally owned ISP Message-ID: <50EC68DB.4010102@mompl.net> Not exactly a nanog subject but I would like to know if there is a (ideally) locally owned ISP in LA that's knowledgeable, for DSL service. Something like cruzio in Santa Cruz. Trying to avoid the big ones such as AT&T and comcast. Thanks, Jeroen -- Earthquake Magnitude: 4.0 Date: Tuesday, January 8, 2013 14:46:33 UTC Location: Southeastern Alaska Latitude: 56.0080; Longitude: -135.4542 Depth: 10.00 km From itsmemattchung at gmail.com Tue Jan 8 18:48:38 2013 From: itsmemattchung at gmail.com (Matt Chung) Date: Tue, 8 Jan 2013 12:48:38 -0600 Subject: LA locally owned ISP In-Reply-To: <50EC68DB.4010102@mompl.net> References: <50EC68DB.4010102@mompl.net> Message-ID: Hey Jeroen, Hope all is well. I use to work as a network engineer at a regional ISP based out in LA - Bel Air Internet. Feel free to unicast me if you have any questions. On Tue, Jan 8, 2013 at 12:43 PM, Jeroen van Aart wrote: > Not exactly a nanog subject but I would like to know if there is a > (ideally) locally owned ISP in LA that's knowledgeable, for DSL service. > Something like cruzio in Santa Cruz. Trying to avoid the big ones such as > AT&T and comcast. > > Thanks, > Jeroen > > -- > Earthquake Magnitude: 4.0 > Date: Tuesday, January 8, 2013 14:46:33 UTC > Location: Southeastern Alaska > Latitude: 56.0080; Longitude: -135.4542 > Depth: 10.00 km > > -- -Matt Chung From owen at delong.com Tue Jan 8 19:14:09 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Jan 2013 11:14:09 -0800 Subject: Join my network on LinkedIn In-Reply-To: <50EC1D4A.3080807@jasonantman.com> References: <161362341.61382033.1357637166048.JavaMail.app@ela4-app2311.prod> <50EC1D4A.3080807@jasonantman.com> Message-ID: <4DA76F28-85A7-440D-9B1D-6A866E6D4F69@delong.com> I could be wrong, but I'm guessing that there's no legitimate circumstance for member at linkedin.com to be sending to nanog at nanog.org. Couldn't the list be taught to filter these? Owen On Jan 8, 2013, at 05:21 , Jason Antman wrote: > If you use LinkedIn (a popular business-oriented social networking site), and utilize the feature to import your email contacts and send connection requests to all of them, *please* un-check the mailing list addresses... since apparently this has now been done twice... > > -j antman > > On 01/08/2013 04:26 AM, glauber gabriel via LinkedIn wrote: >> LinkedIn >> ------------ >> >> >> >> >> glauber gabriel requested to add you as a connection on LinkedIn: >> >> ------------------------------------------ >> >> I'd like to add you to my professional network on LinkedIn. >> >> Accept invitation from glauber gabriel >> http://www.linkedin.com/e/-voa23o-hbou45ow-6b/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I294101987_50/3wOtCVFbmdxnSVFbm8JrnpKqlZJrmZzbmNJpjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfP0RnPsUej4McjgVcAALd6AVcPd4i6gLd3kUcPcPcjkOc34LrCBxbOYWrSlI/eml-comm_invm-b-in_ac-inv28/?hs=false&tok=0pb-Og-tPmgRA1 >> >> View profile of glauber gabriel >> http://www.linkedin.com/e/-voa23o-hbou45ow-6b/rso/83706038/sJhI/name/50054316_I294101987_50/?hs=false&tok=2w8mzCcH_mgRA1 >> ------------------------------------------ >> You are receiving Invitation emails. >> >> >> This email was intended for Ted Fischer. >> Learn why this is included: http://www.linkedin.com/e/-voa23o-hbou45ow-6b/plh/http%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?hs=false&tok=34iKGZTnzmgRA1 >> >> (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. >> >> >> > From askoorb+nanog at gmail.com Tue Jan 8 19:52:18 2013 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Tue, 8 Jan 2013 19:52:18 +0000 Subject: Join my network on LinkedIn In-Reply-To: <4DA76F28-85A7-440D-9B1D-6A866E6D4F69@delong.com> References: <161362341.61382033.1357637166048.JavaMail.app@ela4-app2311.prod> <50EC1D4A.3080807@jasonantman.com> <4DA76F28-85A7-440D-9B1D-6A866E6D4F69@delong.com> Message-ID: Hello all, On Tue, Jan 8, 2013 at 7:14 PM, Owen DeLong wrote: > I could be wrong, but I'm guessing that there's no legitimate circumstance for member at linkedin.com > to be sending to nanog at nanog.org. > > Couldn't the list be taught to filter these? > > Owen > Since this seems to be causing everyone a lot of stress, I reached out to LinkedIn today. I've just had a reply saying that nanog nanog.org has been added to their "do not contact" list. That means, assuming their processes work, the address will no longer receive any emails from LinkedIn or their members though LinkedIn. If anyone from NANOG management doesn't like this, LinkedIn confirmed that this block can be revered if required. Hopefully that will solve the issue and let everyone go back to running the Intertubes. Alex From rsk at gsp.org Tue Jan 8 20:21:43 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 8 Jan 2013 15:21:43 -0500 Subject: Join my network on LinkedIn In-Reply-To: References: <161362341.61382033.1357637166048.JavaMail.app@ela4-app2311.prod> <50EC1D4A.3080807@jasonantman.com> <4DA76F28-85A7-440D-9B1D-6A866E6D4F69@delong.com> Message-ID: <20130108202143.GA30087@gsp.org> On Tue, Jan 08, 2013 at 07:52:18PM +0000, Alex Brooks wrote: > I've just had a reply saying that nanog > nanog.org has been added to their "do not contact" list. That means, > assuming their processes work, the address will no longer receive any > emails from LinkedIn or their members though LinkedIn. Those "processes" have been noticeably broken in the past. (Note as well that even if they do work in this case, that won't stop spam to other nanog.org mailing lists, current or future.) The best way to stop the spammers at LinkedIn is to block their domain at the MTA, and that's what I've recommended that the keepers of the NANOG mailing lists do. ---rsk From j at 2600hz.com Tue Jan 8 20:22:21 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Tue, 8 Jan 2013 20:22:21 +0000 Subject: Join my network on LinkedIn In-Reply-To: References: <161362341.61382033.1357637166048.JavaMail.app@ela4-app2311.prod> <50EC1D4A.3080807@jasonantman.com> <4DA76F28-85A7-440D-9B1D-6A866E6D4F69@delong.com> Message-ID: But what will we complain about now??? Thanks for doing that Alex. We'll see if it works. Cheers, Joshua On Jan 8, 2013, at 11:52 AM, Alex Brooks > wrote: Hello all, On Tue, Jan 8, 2013 at 7:14 PM, Owen DeLong > wrote: I could be wrong, but I'm guessing that there's no legitimate circumstance for member at linkedin.com to be sending to nanog at nanog.org. Couldn't the list be taught to filter these? Owen Since this seems to be causing everyone a lot of stress, I reached out to LinkedIn today. I've just had a reply saying that nanog nanog.org has been added to their "do not contact" list. That means, assuming their processes work, the address will no longer receive any emails from LinkedIn or their members though LinkedIn. If anyone from NANOG management doesn't like this, LinkedIn confirmed that this block can be revered if required. Hopefully that will solve the issue and let everyone go back to running the Intertubes. Alex From blakjak at blakjak.net Tue Jan 8 20:29:42 2013 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 09 Jan 2013 09:29:42 +1300 Subject: Join my network on LinkedIn In-Reply-To: <20130108202143.GA30087@gsp.org> References: <161362341.61382033.1357637166048.JavaMail.app@ela4-app2311.prod> <50EC1D4A.3080807@jasonantman.com> <4DA76F28-85A7-440D-9B1D-6A866E6D4F69@delong.com> <20130108202143.GA30087@gsp.org> Message-ID: <50EC81B6.3040209@blakjak.net> On 09/01/13 09:21, Rich Kulawiec wrote: > On Tue, Jan 08, 2013 at 07:52:18PM +0000, Alex Brooks wrote: >> I've just had a reply saying that nanog >> nanog.org has been added to their "do not contact" list. That means, >> assuming their processes work, the address will no longer receive any >> emails from LinkedIn or their members though LinkedIn. > Those "processes" have been noticeably broken in the past. (Note as > well that even if they do work in this case, that won't stop spam to > other nanog.org mailing lists, current or future.) The best way to stop > the spammers at LinkedIn is to block their domain at the MTA, and that's > what I've recommended that the keepers of the NANOG mailing lists do. > > And hope that non-mailing-lists on the same host don't need to see mail from that MTA? I'm amazed that the NANOG mailing list doesn't simply reject email from non-subscribed addresses. I didn't realise that this was so difficult, considering it's an out-of-box Mailman feature to be able to arrange exactly that. Mark. From Dave.Siegel at level3.com Tue Jan 8 21:20:09 2013 From: Dave.Siegel at level3.com (Siegel, David) Date: Tue, 8 Jan 2013 21:20:09 +0000 Subject: NANOG education committee is seeking instructors Message-ID: <72A2F9AF18EC024C962A748EA6CF75B90EE5979F@W8USSFJ204.ams.gblxint.com> NANOG community, As those of you who were able to attend one of the last couple of NANOG membership meetings know, the education committee is exploring the idea of adding a professional instructor-led class to the NANOG conference, not unlike you might find with the tutorials available at Interop or similar conferences. If you are an experience instructor in this field or you know of an instructor, please email education at nanog.org with contact information. Thank you for the assistance! Dave David Siegel p: 720.888.0953 c: 520.229.7627 e: Dave.Siegel at level3.com From ras at e-gerbil.net Tue Jan 8 21:20:41 2013 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 8 Jan 2013 15:20:41 -0600 Subject: [j-nsp] Krt queue issues In-Reply-To: <4B45C5C9-B16C-4DB9-87D9-B1C1E7621929@interworx.nl> References: <20121001121539.GA10356@pob.ytti.fi> <2A76E400AC84B845AAC35AA19F8E7A5D0C996C97@MUNEXBE1.medline.com> <4B45C5C9-B16C-4DB9-87D9-B1C1E7621929@interworx.nl> Message-ID: <20130108212041.GV65604@gerbil.cluepon.net> On Tue, Jan 08, 2013 at 03:45:10PM +0100, Tim Vollebregt wrote: > Hi, > > What we do nowadays as some workaround, is configuring a default route > towards a core router on 8 x 10G before maintaining an MX box. Which > will be installed before BGP sessions come up, this will cause some > packet loss during burst hour outages but is fine during maintenance > hours. > > I've seen cases where it took up to 30 minutes before the full table > was installed correctly in the PFE's. > > Currently this issue/bug is holding back our Juniper deployments. As > far as I know Juniper created a project group for this bug, and so far > they were able to reproduce the issue. Looks like the issue is being > taken serious from now. PR 836197 I actually have very good luck reproducing it: http://cluepon.net/ras/rpdstall.png The issue appears to be that when rpd is busy processing incoming BGP updates (such as when you turn up a large number of peers simultaniously), it starves the rest of the process from actually spending any CPU time handling/installing the route. The graph above shows a plot of the total BGP paths, the number of routes in the "pending" state, and the number of routes actually installed into the forwarding hardware. This is a very simplified example (nothing but IBGP sessions with very simple policies here, not even any EBGP neighbors), using the latest top of the line routing engine, so in real life the issue is much worse. As you can see, while rpd is still busy receiving and processing the incoming updates, the number of pending routes rises and doesn't fall, and the number of routes installed in the PFE stays almost non-existant. A few routes actually manage to squeek in before all of the BGP sessions come up, which is why it has any at all for the period between 0 and 330 seconds. After the router finishes receiving the BGP paths, the pending routes clear very quickly, and then the FIB installation process begins. 8 minutes after turning up the BGP sessions, this router finally has a full table installed in hardware. The pending routes actually clear much quicker than this once the BGP routes stop coming int, I need to update this graph with a higher resolution to show it. :) Juniper actually DOES have a fix for this issue, tweaking the scheduler in rpd so that the router still processes BGP routes even when it's spending a lot of time receiving new routes. Unfortunately they haven't yet decided to prioritize implementing this fix, so it's still stuck in development. If this issue drives you as insane as it does me, I highly encourage you to talk to your account team about PR 836197 and why 8-20+ minutes to install routes to the FIB is not acceptable to you. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From kilobit at gmail.com Tue Jan 8 22:10:16 2013 From: kilobit at gmail.com (bas) Date: Tue, 8 Jan 2013 23:10:16 +0100 Subject: [j-nsp] Krt queue issues In-Reply-To: <20130108212041.GV65604@gerbil.cluepon.net> References: <20121001121539.GA10356@pob.ytti.fi> <2A76E400AC84B845AAC35AA19F8E7A5D0C996C97@MUNEXBE1.medline.com> <4B45C5C9-B16C-4DB9-87D9-B1C1E7621929@interworx.nl> <20130108212041.GV65604@gerbil.cluepon.net> Message-ID: Hi, On Tue, Jan 8, 2013 at 10:20 PM, Richard A Steenbergen wrote: > PR 836197 That looks like a spanking new PR number to me. The highest PR number I found in 12.2 release notes was 82xxxx. Rather strange that they didn't have an earlier PR number, while the issue has existed for such a long time. > If this issue drives you as insane as it does me, I highly > encourage you to talk to your account team about PR 836197 Done. I can't read PR836197 online as it is not public. Can you post it without liability? If you would be liable do not post it.. Also do _not_ email me off list with the PR description....... Thanks. From mureninc at gmail.com Wed Jan 9 00:46:25 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Tue, 8 Jan 2013 16:46:25 -0800 Subject: Join my network on LinkedIn In-Reply-To: <50EC81B6.3040209@blakjak.net> References: <161362341.61382033.1357637166048.JavaMail.app@ela4-app2311.prod> <50EC1D4A.3080807@jasonantman.com> <4DA76F28-85A7-440D-9B1D-6A866E6D4F69@delong.com> <20130108202143.GA30087@gsp.org> <50EC81B6.3040209@blakjak.net> Message-ID: On 8 January 2013 12:29, Mark Foster wrote: > I'm amazed that the NANOG mailing list doesn't simply reject email from > non-subscribed addresses. I didn't realise that this was so difficult, > considering it's an out-of-box Mailman feature to be able to arrange > exactly that. I think they're supposed to. I recall my first message to this list a couple of months ago was returned, because I was not subscribed with the same address. Then after getting subscribed with the address from which I wanted to post, my message still did not get posted automatically, and required a moderator approval prior to actually being posted. Has this since changed? Or have the moderators been approving all these LinkedIn invitations? C. From ras at e-gerbil.net Wed Jan 9 00:49:51 2013 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 8 Jan 2013 18:49:51 -0600 Subject: [j-nsp] Krt queue issues In-Reply-To: References: <20121001121539.GA10356@pob.ytti.fi> <2A76E400AC84B845AAC35AA19F8E7A5D0C996C97@MUNEXBE1.medline.com> <4B45C5C9-B16C-4DB9-87D9-B1C1E7621929@interworx.nl> <20130108212041.GV65604@gerbil.cluepon.net> Message-ID: <20130109004951.GA65604@gerbil.cluepon.net> On Tue, Jan 08, 2013 at 11:10:16PM +0100, bas wrote: > Hi, > > On Tue, Jan 8, 2013 at 10:20 PM, Richard A Steenbergen wrote: > > PR 836197 > > That looks like a spanking new PR number to me. > The highest PR number I found in 12.2 release notes was 82xxxx. > Rather strange that they didn't have an earlier PR number, while the > issue has existed for such a long time. Oh I have a pile of PR's about a mile long, including some that I opened on this issue 5+ years ago. But I'm not going to harp on the complete absurdity of how long it has taken to finally figure this thing out, or the number of people who have seen this issue while they've claimed all along that nobody else sees it. I'm just going to focus on fixing it. This is the PR that they've chosen for implementing the actual fix, so that's what I'm going with for the sake of simplicity. :) > I can't read PR836197 online as it is not public. > Can you post it without liability? > If you would be liable do not post it.. Also do _not_ email me off > list with the PR description....... Neither can I, but the basic description of the issue is what I said before. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jra at baylink.com Wed Jan 9 00:54:29 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 8 Jan 2013 19:54:29 -0500 (EST) Subject: Join my network on LinkedIn In-Reply-To: <50EC81B6.3040209@blakjak.net> Message-ID: <15977291.1636.1357692869656.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Foster" > I'm amazed that the NANOG mailing list doesn't simply reject email from > non-subscribed addresses. I didn't realise that this was so difficult, > considering it's an out-of-box Mailman feature to be able to arrange > exactly that. In fact, for many years, you had to be subscribed to nanog-post in order to post to nanog (old timers will remember when I ran afoul of that, after Katrina :-}); I presume it wasn't reimplemented when the lists were rehosted several years ago. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From swmike at swm.pp.se Wed Jan 9 14:37:16 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 9 Jan 2013 15:37:16 +0100 (CET) Subject: OOB core router connectivity wish list Message-ID: I have together with some other people, collected a wish list for OOB support, mainly aimed for core routers. This is to replace the legacy serial port usually present on core routing equipment and to move/collapse all its functionality to an ethernet only port. Some equipment already have an mgmt ethernet port, but usually this can't do "everything", meaning today one has to have OOB ethernet *and* OOB serial which just brings more pain than before. I would like to post it here to solicit feedback on it. Feel free to use it to tell your vendor account teams you want this if you feel it useful. I've already sent it to one vendor. http://swm.pp.se/oob.txt Priorities: [P1] -> must have, otherwise not useful [P2] -> would be very useful, to most operators [P3] -> nice to have, useful to some >From the OOB ethernet port it should be possible to: [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they might be totally dead and I want to cut power to it via the back plane. Also useful for FPGA upgrades). [P1]: Connect to manage the RP(s) and linecards (equivalent of todays "connect" on GSR and ASR9k or connecting to RP serial port). [P2]: It should be possible to connect to the OOB from the RP as well (to diagnose OOB connectivity problems). [P2]: Upload software to the RP or otherwise make information available to the RP (for later re-install/turboboot for example). RP should have access to local storage on the OOB device to transfer configuration or software from the OOB device to the RP). [P2]: Read logs and other state of the components in the chassis (displays and LEDs) plus what kind of card is in each slot. [P1]: The OOB port should support (configurable), telnet, ssh and optionally [P3] https login (with a java applet or equivalent to give CLI access in the browser) with ACLs to limit wherefrom things can be done. OOB should support ssh key based logins to admin account. [P1]: The IP address of the OOB port should be set via DHCP/DHCPv6/SLAAC and should have both IPv4 and IPv6 support. If not both, then IPv6 only. [P1]: It should be possible to transfer data using tftp, ftp and scp (ftp client on the OOB device, scp being used to transfer data *to* the device (OOB being scp server). [P2]: OOB device should have tacacs and radius and [P1] local user/password database support for authentication. [P3] OOB should support ssh-key based authentication. [P3] Chassis should have a character display or LEDs with configurable blink pattern from OOB, to aid remote hands identification. [P3] OOB should have two USB ports, one to use to insert storage to transfer files to/from device. The other should be USB port that presents itself as ether USB serial port, or USB ethernet port, where the OOB device would have built in DHCP/DHCPv6 server to give IPv4v6 access to a laptop connected to the OOB so the onsite engineer can then use ssh/telnet to administrate the OOB. Optionally this port could be ethernet port (compare todays CON and AUX ports). [P2] OOB should have procedure to factory default its configuration, perhaps physical button that can be pressed and held for duration of time. The fact that this is done should be logged to the RP. [P3] OOB should have possibility to show power supply and environmental state. [P3] The factory default configuration should not include an empty or obvious login password. The factory-default login password should be the MAC address (without punctuation) of the OOB ethernet interface, which should be printed on the chassis next to the OOBE port. -- Mikael Abrahamsson email: swmike at swm.pp.se From mailing-lists at brianraaen.com Wed Jan 9 15:51:33 2013 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 9 Jan 2013 10:51:33 -0500 Subject: Multicast over GRE between Linux server and Cisco Router Message-ID: I am trying to set up multicast between a Linux server and Router using GRE. The GRE tunnel is up fine and I can see traffic go across it, but the router is not indicating it is receiving the IGMP joins that the server is sending. I have identical setting with another server attached to fastethernet0/1 and it is joined to the group fine, but I am not able to get the server to link to the router via GRE interface. Note that I have another server behind another router where the two routers do GRE and PIM and that on is working fine. Is there some reason that IGMP joins would not work across the GRE link, but another router using PIM would? -- Brian Christopher Raaen Network Architect Zcorum From saku at ytti.fi Wed Jan 9 15:58:55 2013 From: saku at ytti.fi (Saku Ytti) Date: Wed, 9 Jan 2013 17:58:55 +0200 Subject: OOB core router connectivity wish list In-Reply-To: References: Message-ID: <20130109155855.GA30643@pob.ytti.fi> On (2013-01-09 15:37 +0100), Mikael Abrahamsson wrote: > equipment already have an mgmt ethernet port, but usually this can't > do "everything", meaning today one has to have OOB ethernet *and* > OOB serial which just brings more pain than before. The key difference is, that those are not OOB at all, they are on-band as they fate-share the control-plane. Having real OOB port is demand everyone should put in their RFQ/RFP. > http://swm.pp.se/oob.txt Fully support. In essence, all CSCO needs to do, is bring CMP back that they had in Nexus7k/SUP1 and SUP2T but removed again in Nexus7k/SUP2 citing thermal, pintcount and lack of customer adoption. Other vendors need to check out CMP and copy it. I emailed freescale, since they are the ones who can solve the thermal and pincount problem by implementing mgmt board directly. They replied 'something similar will be implemented in the next generation of our multicore processors' (big kudos to large semi to replies quickly and cluefully to non-customer queries) Once there is hardware for this, getting vendors to implement software should be easy peasy. -- ++ytti From jneiberger at gmail.com Wed Jan 9 16:01:25 2013 From: jneiberger at gmail.com (John Neiberger) Date: Wed, 9 Jan 2013 09:01:25 -0700 Subject: Multicast over GRE between Linux server and Cisco Router In-Reply-To: References: Message-ID: My guess is that this is because IGMP is a host-to-router protocol while PIM is for router-to-router signaling. IGMP joins typically flow from a multicast receiver to its local router. A GRE tunnel emulates a router-to-router connection, so you need PIM running on it for signaling. An IGMP join is really just a first hop host-to-router message and isn't intended to be routed, which is what would be necessary to get it over a GRE tunnel. HTH, John On Wed, Jan 9, 2013 at 8:51 AM, Brian Christopher Raaen < mailing-lists at brianraaen.com> wrote: > I am trying to set up multicast between a Linux server and Router using > GRE. The GRE tunnel is up fine and I can see traffic go across it, but the > router is not indicating it is receiving the IGMP joins that the server is > sending. I have identical setting with another server attached to > fastethernet0/1 and it is joined to the group fine, but I am not able to > get the server to link to the router via GRE interface. Note that I have > another server behind another router where the two routers do GRE and PIM > and that on is working fine. Is there some reason that IGMP joins would > not work across the GRE link, but another router using PIM would? > > -- > Brian Christopher Raaen > Network Architect > Zcorum > From jra at baylink.com Wed Jan 9 16:04:43 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 9 Jan 2013 11:04:43 -0500 (EST) Subject: Who's the hostmaster for .fl.us? Message-ID: <33529498.1658.1357747483737.JavaMail.root@benjamin.baylink.com> This seems much harder to find out than I would have expected. RFC 1480 is, sadly, dated, and it's really hard to google for ".fl.us" usably. And www.fl.us goes nowhere. Off-list is fine; I don't expect this is a high-interest question. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jgreco at ns.sol.net Wed Jan 9 16:11:31 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 9 Jan 2013 10:11:31 -0600 (CST) Subject: Who's the hostmaster for .fl.us? In-Reply-To: <33529498.1658.1357747483737.JavaMail.root@benjamin.baylink.com> Message-ID: <201301091611.r09GBVf0011938@aurora.sol.net> > This seems much harder to find out than I would have expected. > > RFC 1480 is, sadly, dated, and it's really hard to google for ".fl.us" > usably. And www.fl.us goes nowhere. > > Off-list is fine; I don't expect this is a high-interest question. Neustar has been successful in getting RFC1480-style domain names effectively discontinued as of maybe a decade ago (we're responsible for mil.wi.us here) and so any locality stuff under .fl.us is probably legacy stuff. They'd much rather sell people foo.us ... Anyways, whois information is available via www.nic.us which points at www.whois.us, but if your question is about the ".fl.us" zone itself, that's almost certainly handled directly by Neustar. www.whois.us appears to be functional, or, at least, showed me current data for our zones. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From bill at herrin.us Wed Jan 9 16:18:50 2013 From: bill at herrin.us (William Herrin) Date: Wed, 9 Jan 2013 11:18:50 -0500 Subject: OOB core router connectivity wish list In-Reply-To: References: Message-ID: On Wed, Jan 9, 2013 at 9:37 AM, Mikael Abrahamsson wrote: > I have together with some other people, collected a wish list for OOB > support, mainly aimed for core routers. Hi Mikael, I generally agree but have several quibbles: > [P1]: The IP address of the OOB port should be set via DHCP/DHCPv6/SLAAC and > should have both IPv4 and IPv6 support. If not both, then IPv6 only. (a) This is a P2 not a P1. Asking the OOB to be critically dependent on an external network element is dubious to begin with but even if desired it's usable without. About the only time you'd strictly *need* dynamic configuration in an OOB is when directly connecting it to a commodity Internet link. If you're willing to give your poorly secured and rarely updated OOB a public IP address, you're a braver man than I am. If you are that "brave" then you'll need a more robust set of dynamic configuration tools than just the ones you've listed and you'll also need a dynamic dns client or some other mechanism for the the OOB to let you know what addresses it ended up on. (b) IPv6-only in an OOB won't be broadly acceptable for at least another 5 years if then. You'd be foolish not to include IPv6 support in a greenfield design -- the writing is on the wall -- but there are today very few scenarios in which an IPv4 only OOB would not be usable. > [P1]: It should be possible to transfer data using tftp, ftp and scp (ftp > client on the OOB device, scp being used to transfer data *to* the device > (OOB being scp server). For security and performance reasons, FTP has no place in a modern network. If you're still using it anywhere, you're borrowing grief. Replace with an http/https client. TFTP has such a strong legacy of use on routers that its presence remains just barely tolerable. For now. Have a look at how HP iLO3 makes use of http to implement virtual media. You can upload an ISO image to a web server somewhere and then instruct ilo to mount the URL as a virtual dvdrom. Best of all, if your management session disconnects, the virtual media remains mounted via the web server. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From streiner at cluebyfour.org Wed Jan 9 16:20:39 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 9 Jan 2013 11:20:39 -0500 (EST) Subject: OOB core router connectivity wish list In-Reply-To: References: Message-ID: On Wed, 9 Jan 2013, Mikael Abrahamsson wrote: > I would like to post it here to solicit feedback on it. Feel free to use it > to tell your vendor account teams you want this if you feel it useful. I've > already sent it to one vendor. Ethernet/Serial/USB management is useful, but I would not be in favor of eliminating the serial port entirely, because having an OOB serial console connection has saved me more than a few times. Plus, having working connectivity from something like a terminal server or a headless Linux box has proven its value countless times in the past. I would also add the following to your list: If $vendor's device provides an IP-based management interface over an ethernet port, it should provide both a web-based interface and a CLI. The web interface should be as platform-agnostic as possible (not restrict people to specific platforms and browsers), and be as gentle as possible in requiring things like Java. Being forced to deal with Java runtime version dependency hell in a critical situation would not fill my heart with joy. jms From morrowc.lists at gmail.com Wed Jan 9 16:21:49 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 9 Jan 2013 11:21:49 -0500 Subject: OOB core router connectivity wish list In-Reply-To: References: Message-ID: On Wed, Jan 9, 2013 at 11:18 AM, William Herrin wrote: > About the only time you'd strictly *need* dynamic configuration in an > OOB is when directly connecting it to a commodity Internet link. If > you're willing to give your poorly secured and rarely updated OOB a > public IP address, you're a braver man than I am. If you are that > "brave" then you'll need a more robust set of dynamic configuration > tools than just the ones you've listed and you'll also need a dynamic > dns client or some other mechanism for the the OOB to let you know > what addresses it ended up on. it's possible that he's thinking of a world where your dhcp is not 'dynamic' but a management system which can keep all the other bits of information updated (and easily updatable!) for the remote nodes: ip address def-gw dns servers for instance. From bill at herrin.us Wed Jan 9 16:25:47 2013 From: bill at herrin.us (William Herrin) Date: Wed, 9 Jan 2013 11:25:47 -0500 Subject: OOB core router connectivity wish list In-Reply-To: References: Message-ID: On Wed, Jan 9, 2013 at 11:21 AM, Christopher Morrow wrote: > On Wed, Jan 9, 2013 at 11:18 AM, William Herrin wrote: >> About the only time you'd strictly *need* dynamic configuration in an >> OOB is when directly connecting it to a commodity Internet link. If >> you're willing to give your poorly secured and rarely updated OOB a >> public IP address, you're a braver man than I am. If you are that >> "brave" then you'll need a more robust set of dynamic configuration >> tools than just the ones you've listed and you'll also need a dynamic >> dns client or some other mechanism for the the OOB to let you know >> what addresses it ended up on. > > it's possible that he's thinking of a world where your dhcp is not > 'dynamic' but a management system which can keep all the other bits of > information updated (and easily updatable!) for the remote nodes: > ip address > def-gw > dns servers > > for instance. Sure, but in that scenario you don't *need* a dhcp system, it's merely a "nice to have." Hence a P2 not a P1. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From johnl at iecc.com Wed Jan 9 16:30:49 2013 From: johnl at iecc.com (John Levine) Date: 9 Jan 2013 16:30:49 -0000 Subject: Who's the hostmaster for .fl.us? In-Reply-To: <201301091611.r09GBVf0011938@aurora.sol.net> Message-ID: <20130109163049.28969.qmail@joyce.lan> >Neustar has been successful in getting RFC1480-style domain names >effectively discontinued as of maybe a decade ago (we're responsible >for mil.wi.us here) and so any locality stuff under .fl.us is probably >legacy stuff. They'd much rather sell people foo.us ... If you're wondering about something in k12.fl.us, do a WHOIS and you'll find the Florida Dep't of Education. For other fl.us names, do a WHOIS on the name, and you'll find out what Neustar's got. I have a few .ny.us delegations, but there's no new ones. There was a big kerfuffle in which Neustar demanded in the agreement that subregistries provide unlimited indemnification for their legal costs. It turned out that you could just cross out that clause and Neustar would accept it, but that news was not widely disseminated and many local registries just gave up. The .us zone still has some very crufty legacy stuff. The name iecc.cambridge.ma.us is still there as a CNAME, left over from something I registered in about 1991. There's no WHOIS for it, Neustar probably has no idea that I was the original registrant, and I have no idea how I'd even ask them to get rid of it. It's a dandy spamtrap, though. R's, John From swmike at swm.pp.se Wed Jan 9 16:47:25 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 9 Jan 2013 17:47:25 +0100 (CET) Subject: OOB core router connectivity wish list In-Reply-To: References: Message-ID: On Wed, 9 Jan 2013, Christopher Morrow wrote: > On Wed, Jan 9, 2013 at 11:18 AM, William Herrin wrote: >> About the only time you'd strictly *need* dynamic configuration in an >> OOB is when directly connecting it to a commodity Internet link. If >> you're willing to give your poorly secured and rarely updated OOB a >> public IP address, you're a braver man than I am. If you are that >> "brave" then you'll need a more robust set of dynamic configuration >> tools than just the ones you've listed and you'll also need a dynamic >> dns client or some other mechanism for the the OOB to let you know >> what addresses it ended up on. > > it's possible that he's thinking of a world where your dhcp is not > 'dynamic' but a management system which can keep all the other bits of > information updated (and easily updatable!) for the remote nodes: Well, I was actually thinking more about initial factory default configuration. After I can reach the device, I would like to be able to set a static address. I'll consider adding this to the document. My grief with this is that if we're going to go into that kind of level, we need a RFC style document with a lot of detail, and that wasn't what I was initially aiming for. I wanted more to spark the discussion and see what came out of it. If there indeed is a lot of interest in this, I'd gladly like to try to create a more detailed document. I would be very happy if multiple vendors could standardise on a functionality and software though, perhaps even with API. Don't know which standards body would be right for this though. -- Mikael Abrahamsson email: swmike at swm.pp.se From saku at ytti.fi Wed Jan 9 16:48:03 2013 From: saku at ytti.fi (Saku Ytti) Date: Wed, 9 Jan 2013 18:48:03 +0200 Subject: OOB core router connectivity wish list In-Reply-To: References: Message-ID: <20130109164803.GA30676@pob.ytti.fi> On (2013-01-09 11:18 -0500), William Herrin wrote: > (a) This is a P2 not a P1. Asking the OOB to be critically dependent > on an external network element is dubious to begin with but even if > desired it's usable without. Agreed that P2 suffices. Usage scenario is installing fresh router. You order router from vendor to remote location, notsosmarthands plug it to wires, boom you configure it remotely. > About the only time you'd strictly *need* dynamic configuration in an > OOB is when directly connecting it to a commodity Internet link. If > you're willing to give your poorly secured and rarely updated OOB a > public IP address, you're a braver man than I am. If you are that This is not absolute truth, but depends on what hat you wear. If you are DC guy, you have handful of POPs, arranging proper OOB network there is a breeze. If you are incumbent, you can't buy anything externally, as everyone buys from you, so you need to build separate network just for OOB. All other service providers may have hundreds of pops, you're not going to build non-revenue generating network to reach all those hundreds of pops, just to build OOB. You get cheapest connection you can get there, maybe competitor ADSL, cable model, 3G, public WLAN, ISDN what ever is available which is not fate-sharing with your network. Then plug in say cisco CPE to the OOB port, which offers address via DHCP and connect over IPSEC DMVPN to your own network. 0 touch installation of new router. Some might be ghetto and omit the CPE and use IPSEC from the management plane to openswan linux. > (b) IPv6-only in an OOB won't be broadly acceptable for at least > another 5 years if then. You'd be foolish not to include IPv6 support > in a greenfield design -- the writing is on the wall -- but there are > today very few scenarios in which an IPv4 only OOB would not be > usable. Agreed. IPv4 would be priority for most. > For security and performance reasons, FTP has no place in a modern > network. If you're still using it anywhere, you're borrowing grief. > Replace with an http/https client. http(s), scp would be my picks. Hell with FTP. > TFTP has such a strong legacy of use on routers that its presence > remains just barely tolerable. For now. There is no standard way to send arbitrary size files over TFTP, not worth the pain. -- ++ytti From swmike at swm.pp.se Wed Jan 9 16:55:04 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 9 Jan 2013 17:55:04 +0100 (CET) Subject: OOB core router connectivity wish list In-Reply-To: <20130109164803.GA30676@pob.ytti.fi> References: <20130109164803.GA30676@pob.ytti.fi> Message-ID: On Wed, 9 Jan 2013, Saku Ytti wrote: > Agreed. IPv4 would be priority for most. Today yes. In 2-4 years when this might be a reality, I don't want IPv4 only device. I rather go for IPv6 only immediately. -- Mikael Abrahamsson email: swmike at swm.pp.se From bicknell at ufp.org Wed Jan 9 17:12:25 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 9 Jan 2013 09:12:25 -0800 Subject: OOB core router connectivity wish list In-Reply-To: References: Message-ID: <20130109171225.GA91802@ussenterprise.ufp.org> I think this list goes too far, and has a decent chance of introducing other fun failure modes as a result. The goal of OOB is generally to gain control of a "misbehaving" device. Now, misbehaving can take many forms, from the device actually being ok and all of it's circuits going down (fiber cut isolating it), to the device being very much not ok with a bad linecard trying to lock up the bus, core dumps, etc. I'm going to pick on one specific example: In a message written on Wed, Jan 09, 2013 at 03:37:16PM +0100, Mikael Abrahamsson wrote: > [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they > might be totally dead and I want to cut power to it via the back plane. > Also useful for FPGA upgrades). Most Cisco high end devices can do this today from the CLI (test mbus power off on a GSR, for example). Let's consider what it would take to move that functionality from the live software to some sort of "etherent oob" as proposed... The first big step is that some sort of "computer" to operate the ethernet oob is required. I think where you're going with this is some sort of small SoC type thing connected to the mangement buss of the device, not unlike an IPMI device on a server. Using IPMI devices on servers as an example this is now another device that must be secured, upgraded, and has the potential for bugs of its own. Since only a small fraction of high end users will use the OOB at all (inband is fine for many, many networks), there will not be a lot of testing of this code, or demand for features/fixes. So while I agree with the list of features in large part, I'm not sure I agree with the concept of having some sort of ethernet interface that allows all of this out of band. I think it will add cost, complexity, and a lot of new failure modes. The reality is the current situation on high end gear, a serial console plus ethernet "management" port is pretty close to a good situation, and could be a really good situation with a few minor modifications. My list would be much simpler as a result: 1) I would like to see serial consoles replaced with USB consoles. They would still appear to be serial devices to most equipment, but would enable much faster speeds making working on the console a much more reasonable option. For bonus points, an implementation that presents 2-4 serial "terminals" over the same USB cable would allow multiple people to log into the device without the need for any network connectivity. This would also allow USB hubs to be used to connect multiple devices in a colo, rather than the serial terminal servers needed today. 2) I would like to see "manangement" ethernets that live in their own walled off world out of the box. Yes, I know with most boxes you can put them in a VRF or similar, but that should be the default. I should be able to put an IP and default route on a management ethernet and still have a 100% empty (main) routing table. This would allow the management port to be homed to a separate network simply and easily. 3) I would like to see "legacy protocols" dumped. TFTP, bye bye. FTP, bye bye. rcp, bye bye. HTTP, HTTPS, and SCP should be supported for all operations at all levels of the OS. In this ideal world, the deployment model is simple. A small OOB device would be deployed (think like a Cisco 1900, or Juniper SRX 220), connected to a separate network (DSL, cable modem, cell modem, ethernet to some other provider, or gasp, even an old school analog modem). Each large router would get an ethernet port and usb console to that device. SSH to the right port would get the USB console, ideally with the 2-4 consoles exposed where hitting the same port just cycles through them. At that point all of the functionality described in the original post should be available in the normal CLI on the device. File transfer operations should be able to specify the management port "copy [mangement]http://1.2.3.4/newimage.code flash:" to use that interface/routing table. I also think on most boxes this would require no hardware changes. The high end boxes have Ethernet, they have USB...it's just updating the software to make them act in a much more useful way, rather than the half brain-dead ways they act now... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From saku at ytti.fi Wed Jan 9 17:34:13 2013 From: saku at ytti.fi (Saku Ytti) Date: Wed, 9 Jan 2013 19:34:13 +0200 Subject: OOB core router connectivity wish list In-Reply-To: <20130109171225.GA91802@ussenterprise.ufp.org> References: <20130109171225.GA91802@ussenterprise.ufp.org> Message-ID: <20130109173413.GA30693@pob.ytti.fi> On (2013-01-09 09:12 -0800), Leo Bicknell wrote: > So while I agree with the list of features in large part, I'm not sure I > agree with the concept of having some sort of ethernet interface that > allows all of this out of band. I think it will add cost, complexity, > and a lot of new failure modes. It already exists, CMP is its name, and it is great. Server people woke up to this over decade ago, so should networking people. Failure modes are somewhat uninteresting, as long as it does not fate-share with control-plane. Having RS232 or USB console on forwarding-plane is not OOB. And even OOB version of these is of limited value, you can't send images over them, you can't multiplex over them and RS232 OOB 'server' costs more than switch. So you get less and you pay more. HW + SW wise it's extremely simple contraption, all the code and HW needed is proven. RS232 on-band management is case of 'well it's always done like this, so it must be the right way to do it' -- ++ytti From swmike at swm.pp.se Wed Jan 9 17:39:28 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 9 Jan 2013 18:39:28 +0100 (CET) Subject: OOB core router connectivity wish list In-Reply-To: <20130109171225.GA91802@ussenterprise.ufp.org> References: <20130109171225.GA91802@ussenterprise.ufp.org> Message-ID: On Wed, 9 Jan 2013, Leo Bicknell wrote: > of the device, not unlike an IPMI device on a server. Using IPMI IPMI is exactly what we're going for. > In this ideal world, the deployment model is simple. A small OOB > device would be deployed (think like a Cisco 1900, or Juniper SRX > 220), connected to a separate network (DSL, cable modem, cell modem, > ethernet to some other provider, or gasp, even an old school analog > modem). Each large router would get an ethernet port and usb console > to that device. SSH to the right port would get the USB console, > ideally with the 2-4 consoles exposed where hitting the same port just > cycles through them. This is added cost and complexity. Sometimes there is only 1-2 devices in the pop, and now there is need to install a serial console router with DC (limits options) just to connect to the serial console, which might not work anyway because the control plane might be so screwed up that it actually needs power cycling. So I want to retire serial ports in the front to be needed for normal operation. Look at the XR devices from Cisco for instance. For "normal maintenance" you pretty much require both serial console (to do rommon stuff one would imagine shouldn't be needed) and also mgmt ethernet (to use tftp for downloading software when you need to turbo-boot because the system is now screwed up because the XR developer ("install") team messed up the SMUs *again*). For instance, if you have single RP the upgrade instructions for 4.2.1 lists going into rommon and doing "boot -s", *or* power cycling the box, after FPGA upgrade. -- Mikael Abrahamsson email: swmike at swm.pp.se From tglassey at earthlink.net Wed Jan 9 17:54:13 2013 From: tglassey at earthlink.net (tglassey) Date: Wed, 09 Jan 2013 09:54:13 -0800 Subject: OOB core router connectivity wish list In-Reply-To: <20130109171225.GA91802@ussenterprise.ufp.org> References: <20130109171225.GA91802@ussenterprise.ufp.org> Message-ID: <50EDAEC5.8000608@earthlink.net> On 1/9/2013 9:12 AM, Leo Bicknell wrote: > I think this list goes too far, and has a decent chance of introducing > other fun failure modes as a result. The goal of OOB is generally > to gain control of a "misbehaving" device. Now, misbehaving can > take many forms, from the device actually being ok and all of it's > circuits going down (fiber cut isolating it), to the device being > very much not ok with a bad linecard trying to lock up the bus, > core dumps, etc. > > I'm going to pick on one specific example: > > In a message written on Wed, Jan 09, 2013 at 03:37:16PM +0100, Mikael Abrahamsson wrote: >> [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they >> might be totally dead and I want to cut power to it via the back plane. >> Also useful for FPGA upgrades). > Most Cisco high end devices can do this today from the CLI (test > mbus power off on a GSR, for example). Let's consider what it would > take to move that functionality from the live software to some sort > of "etherent oob" as proposed... Install an Embedded Peer (a Bus Level Peering Card like a SlotServer or the Fuji Module and provide console level access through the peer. Then the Peer itself becomes the controller interface. Todd > > The first big step is that some sort of "computer" to operate the > ethernet oob is required. I think where you're going with this is > some sort of small SoC type thing connected to the mangement buss > of the device, not unlike an IPMI device on a server. Using IPMI > devices on servers as an example this is now another device that > must be secured, upgraded, and has the potential for bugs of its > own. Since only a small fraction of high end users will use the > OOB at all (inband is fine for many, many networks), there will not > be a lot of testing of this code, or demand for features/fixes. > > So while I agree with the list of features in large part, I'm not sure I > agree with the concept of having some sort of ethernet interface that > allows all of this out of band. I think it will add cost, complexity, > and a lot of new failure modes. > > The reality is the current situation on high end gear, a serial console > plus ethernet "management" port is pretty close to a good situation, and > could be a really good situation with a few minor modifications. My > list would be much simpler as a result: > > 1) I would like to see serial consoles replaced with USB consoles. They > would still appear to be serial devices to most equipment, but would > enable much faster speeds making working on the console a much more > reasonable option. For bonus points, an implementation that presents > 2-4 serial "terminals" over the same USB cable would allow multiple > people to log into the device without the need for any network > connectivity. > > This would also allow USB hubs to be used to connect multiple devices > in a colo, rather than the serial terminal servers needed today. > > 2) I would like to see "manangement" ethernets that live in their own > walled off world out of the box. Yes, I know with most boxes you can > put them in a VRF or similar, but that should be the default. I > should be able to put an IP and default route on a management ethernet > and still have a 100% empty (main) routing table. This would allow > the management port to be homed to a separate network simply and > easily. > > 3) I would like to see "legacy protocols" dumped. TFTP, bye bye. FTP, > bye bye. rcp, bye bye. HTTP, HTTPS, and SCP should be supported > for all operations at all levels of the OS. > > In this ideal world, the deployment model is simple. A small OOB > device would be deployed (think like a Cisco 1900, or Juniper SRX > 220), connected to a separate network (DSL, cable modem, cell modem, > ethernet to some other provider, or gasp, even an old school analog > modem). Each large router would get an ethernet port and usb console > to that device. SSH to the right port would get the USB console, > ideally with the 2-4 consoles exposed where hitting the same port just > cycles through them. > > At that point all of the functionality described in the original > post should be available in the normal CLI on the device. File > transfer operations should be able to specify the management port > "copy [mangement]http://1.2.3.4/newimage.code flash:" to use that > interface/routing table. > > I also think on most boxes this would require no hardware changes. The > high end boxes have Ethernet, they have USB...it's just updating the > software to make them act in a much more useful way, rather than the > half brain-dead ways they act now... > -- Regards TSG "Ex-Cruce-Leo" //Confidential Mailing - Please destroy this if you are not the intended recipient. From bicknell at ufp.org Wed Jan 9 18:18:22 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 9 Jan 2013 10:18:22 -0800 Subject: OOB core router connectivity wish list In-Reply-To: References: <20130109171225.GA91802@ussenterprise.ufp.org> Message-ID: <20130109181822.GA94721@ussenterprise.ufp.org> In a message written on Wed, Jan 09, 2013 at 06:39:28PM +0100, Mikael Abrahamsson wrote: > IPMI is exactly what we're going for. For Vendors that use a "PC" motherboard, IPMI would probably not be difficult at all! :) I think IPMI is a pretty terrible solution though, so if that's your target I do think it's a step backwards. Most IPMI cards are prime examples of my worries, Linux images years out of date, riddled with security holes and universally not trusted. You're going to need a "firewall" in front of any such solution to deploy it, so you can't really eliminate the extra box I proposed just change its nature. I also still think there's a lot of potential here to take gigantic steps backwards. Replacing a serial console with a Java applet in a browser (a la most IPMI devices) would be a huge step backwards. Today it's trival to script console access, in a Java applet world, not so much. Having a IPMI like device with dedicated ethernet and connection to the management bus would allow it to have a web interface to do things like power cycle individual line cards and may be a win, but I would posit these things are to work around horribly broken upgrade procedures that vendors have not given enough thought. They could be solved with more intelligent software in the ROM and on the main box without needing any add on device. > So I want to retire serial ports in the front to be needed for normal > operation. Look at the XR devices from Cisco for instance. For "normal > maintenance" you pretty much require both serial console (to do rommon > stuff one would imagine shouldn't be needed) and also mgmt ethernet (to > use tftp for downloading software when you need to turbo-boot because the > system is now screwed up because the XR developer ("install") team messed > up the SMUs *again*). Your vendor is going to hire those same developers to write the code for your OOB device. The solution here is not bad developers writing and deploying even more code, it's to demand your vendors uplevel their developers and software. Ever have these problems on Vendor J? No, the upgrade process there is smooth as silk. Not to say that vendor is perfect, they just have different warts. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From saku at ytti.fi Wed Jan 9 18:41:01 2013 From: saku at ytti.fi (Saku Ytti) Date: Wed, 9 Jan 2013 20:41:01 +0200 Subject: OOB core router connectivity wish list In-Reply-To: <20130109181822.GA94721@ussenterprise.ufp.org> References: <20130109171225.GA91802@ussenterprise.ufp.org> <20130109181822.GA94721@ussenterprise.ufp.org> Message-ID: <20130109184101.GA30746@pob.ytti.fi> On (2013-01-09 10:18 -0800), Leo Bicknell wrote: > I also still think there's a lot of potential here to take gigantic > steps backwards. Replacing a serial console with a Java applet in > a browser (a la most IPMI devices) would be a huge step backwards. > Today it's trival to script console access, in a Java applet world, > not so much. P1 requirement was ssh. > Ever have these problems on Vendor J? No, the upgrade process there is > smooth as silk. Not to say that vendor is perfect, they just have > different warts. I'm getting maybe bit too far from topic. We have different opinion of smooth or silk. I hate how in J once you do the upgrade, current config is stored with it, so when you finally boot, you're using that configuration. So this means, you can't install new image to all boxes at once you decide new standard release and then reload then when you get maint window, without having any extra work during expensive maint hours. Also I've seen very poor hit-miss ratio with ISSU, so I can't use it at all. -- ++ytti From hmurray at megapathdsl.net Wed Jan 9 22:35:07 2013 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 09 Jan 2013 14:35:07 -0800 Subject: OOB core router connectivity wish list Message-ID: <20130109223507.25B8B80003B@ip-64-139-1-69.sjc.megapath.net> It might help clarify things if you added two (hopefully) short sections: One discussing how to get off the ground. How do I get my ssh key on a factory-reset box? Another discussing security. There may be conflicting requirements for different usage scenarios. -- These are my opinions. I hate spam. From rdobbins at arbor.net Wed Jan 9 23:17:15 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 9 Jan 2013 23:17:15 +0000 Subject: OOB core router connectivity wish list In-Reply-To: References: Message-ID: On Jan 9, 2013, at 9:37 AM, Mikael Abrahamsson wrote: > http://swm.pp.se/oob.txt Flow telemetry export - many of these so-called 'management' ports can't be used to export flow, oddly enough. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From julian at jdcomputers.com.au Thu Jan 10 02:58:59 2013 From: julian at jdcomputers.com.au (Julian DeMarchi) Date: Thu, 10 Jan 2013 12:58:59 +1000 Subject: [SHAME] Spam Rats Message-ID: <50EE2E73.2060309@jdcomputers.com.au> Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are "mass-listed" the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only From rcarpen at network1.net Thu Jan 10 03:05:11 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 9 Jan 2013 22:05:11 -0500 (EST) Subject: OOB core router connectivity wish list In-Reply-To: Message-ID: <1400592755.31199.1357787111080.JavaMail.root@network1.net> My main requirements would be: 1. Something that is *not* network (ethernet or otherwise) (isn't that the point of OOB?) 2. Something that is standard across everything, and can be aggregated easily onto a "console server" or the like I don't really see what is wrong with with keeping the serial port as the standard. Things like servers and RAID cards and such are coming with "BIOS"es that are graphical and even require a mouse to use. What use is that when I need to get into the BIOS from a remote site that is completely down? Likewise OS vendors are increasingly dropping support for installing OSes via serial port (RHEL, VMWare, etc.) At leaset with RHEL, you can make your own boot image that gets rid of the asinine splash screen (which is the only thing that causes the requirement for a full VGA console) It might be nice to have a "management-only" port of some sort to do more advanced things that serial cannot do, but the serial port is ubiquitous already, and I don't see any reason to remove it as the very low-level access method. thanks, -Randy ----- Original Message ----- > > I have together with some other people, collected a wish list for OOB > support, mainly aimed for core routers. This is to replace the legacy > serial port usually present on core routing equipment and to > move/collapse > all its functionality to an ethernet only port. Some equipment > already > have an mgmt ethernet port, but usually this can't do "everything", > meaning today one has to have OOB ethernet *and* OOB serial which > just > brings more pain than before. > > I would like to post it here to solicit feedback on it. Feel free to > use > it to tell your vendor account teams you want this if you feel it > useful. > I've already sent it to one vendor. > > http://swm.pp.se/oob.txt > > Priorities: > > [P1] -> must have, otherwise not useful > [P2] -> would be very useful, to most operators > [P3] -> nice to have, useful to some > > From the OOB ethernet port it should be possible to: > > [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in > they > might be totally dead and I want to cut power to it via the back > plane. > Also useful for FPGA upgrades). > > [P1]: Connect to manage the RP(s) and linecards (equivalent of todays > "connect" on GSR and ASR9k or connecting to RP serial port). > > [P2]: It should be possible to connect to the OOB from the RP as well > (to > diagnose OOB connectivity problems). > > [P2]: Upload software to the RP or otherwise make information > available to > the RP (for later re-install/turboboot for example). RP should have > access > to local storage on the OOB device to transfer configuration or > software > from the OOB device to the RP). > > [P2]: Read logs and other state of the components in the chassis > (displays > and LEDs) plus what kind of card is in each slot. > > [P1]: The OOB port should support (configurable), telnet, ssh and > optionally [P3] https login (with a java applet or equivalent to give > CLI > access in the browser) with ACLs to limit wherefrom things can be > done. > OOB should support ssh key based logins to admin account. > > [P1]: The IP address of the OOB port should be set via > DHCP/DHCPv6/SLAAC > and should have both IPv4 and IPv6 support. If not both, then IPv6 > only. > > [P1]: It should be possible to transfer data using tftp, ftp and scp > (ftp > client on the OOB device, scp being used to transfer data *to* the > device > (OOB being scp server). > > [P2]: OOB device should have tacacs and radius and [P1] local > user/password database support for authentication. [P3] OOB should > support > ssh-key based authentication. > > [P3] Chassis should have a character display or LEDs with > configurable > blink pattern from OOB, to aid remote hands identification. > > [P3] OOB should have two USB ports, one to use to insert storage to > transfer files to/from device. The other should be USB port that > presents > itself as ether USB serial port, or USB ethernet port, where the OOB > device would have built in DHCP/DHCPv6 server to give IPv4v6 access > to a > laptop connected to the OOB so the onsite engineer can then use > ssh/telnet > to administrate the OOB. Optionally this port could be ethernet port > (compare todays CON and AUX ports). > > [P2] OOB should have procedure to factory default its configuration, > perhaps physical button that can be pressed and held for duration of > time. > The fact that this is done should be logged to the RP. > > [P3] OOB should have possibility to show power supply and > environmental > state. > > [P3] The factory default configuration should not include an empty or > obvious login password. The factory-default login password should be > the > MAC address (without punctuation) of the OOB ethernet interface, > which > should be printed on the chassis next to the OOBE port. > > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > > From ops.lists at gmail.com Thu Jan 10 03:06:48 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 10 Jan 2013 08:36:48 +0530 Subject: [SHAME] Spam Rats In-Reply-To: <50EE2E73.2060309@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing? That said, it is best practice to set ptr records even for your unassigned ip space --srs (htc one x) On 10-Jan-2013 8:30 AM, "Julian DeMarchi" wrote: > Heya, > > I don't like to publicly shame[0] companies or services but today I have > found a need too. There is an anti-spam company called Spam Rats[1]. > They provide an RBL service and today is the first time I've seen them. > So thank god they seem to not be used much. > > I'm emailing this list to advise of their listing pratices. They have > listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of > PTRs in the /24 range. This is for co-lo customers. The range has a > netural score on senderbase. > > This is the first RBL I have seen list a /24 for lack of PTRs. Not for > sending spam, but just PTRs alone. How do you explain this to your > customer? > > Their removal process is also a joke. As we are "mass-listed" the normal > removal process does not apply. I've used their contact form but doubt > I'll get a response. > > Please make 2013 the year you migrate away from Spam Rats if you choose > to use this service[2]. > > Regards, > > Julian > > 0 - is ready to get flamed. > 1 - http://www.spamrats.com > 2 - these are my opinions only > > From julian at jdcomputers.com.au Thu Jan 10 03:10:48 2013 From: julian at jdcomputers.com.au (Julian DeMarchi) Date: Thu, 10 Jan 2013 13:10:48 +1000 Subject: [SHAME] Spam Rats In-Reply-To: References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: <50EE3138.7060903@jdcomputers.com.au> On 01/10/2013 01:06 PM, Suresh Ramasubramanian wrote: > Who uses it? Or did you see your IP listed in one of those multiple dnsbl > query sites and contacted them on general principles even though you didn't > see any actual bounced email that could be traced to a spam rats listing? Customers use the range. They had a complaint to us that the IP was listed by spamrats and thus the issue made it to my queue. > That said, it is best practice to set ptr records even for your unassigned > ip space Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts. --julian From wbailey at satelliteintelligencegroup.com Thu Jan 10 03:12:43 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 10 Jan 2013 03:12:43 +0000 Subject: [SHAME] Spam Rats In-Reply-To: <50EE2E73.2060309@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: <3x7rk4xc3jwi7177xnrqritn.1357787557625@email.android.com> I wouldn't flame you.. I think this forum lacks this kind of discussion. At least we can move on from the LinkedIn email saga earlier this week? >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Julian DeMarchi Date: 01/09/2013 7:00 PM (GMT-08:00) To: NANOG Subject: [SHAME] Spam Rats Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are "mass-listed" the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only From otis at ocosa.com Thu Jan 10 03:14:29 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Wed, 9 Jan 2013 21:14:29 -0600 Subject: [SHAME] Spam Rats In-Reply-To: <50EE2E73.2060309@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B0180E8@ocsbs.ocosa.com> We had issues and similar behavior from SORBS.net and TrendMicro ERS but have never dealt with Spam Rats. It was our second direct allocation from ARIN last year that was apart of a larger block that got split up. Our block was listed in their DUL. It was a pain to remove. They wanted our PTR records to say "static" and provide a longer TTL. Others on this list have shared similar stories. This is crazy but it's their service and seem to be a common practice amongst some RBLs. I hope you get your issue fixed. FYI - I have a PTR for all IPs. Just general practice. Otis -----Original Message----- From: Julian DeMarchi [mailto:julian at jdcomputers.com.au] Sent: Wednesday, January 09, 2013 8:59 PM To: NANOG Subject: [SHAME] Spam Rats Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are "mass-listed" the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only From cmadams at hiwaay.net Thu Jan 10 03:15:47 2013 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 9 Jan 2013 21:15:47 -0600 Subject: OOB core router connectivity wish list In-Reply-To: <1400592755.31199.1357787111080.JavaMail.root@network1.net> References: <1400592755.31199.1357787111080.JavaMail.root@network1.net> Message-ID: <20130110031547.GB2212@hiwaay.net> Once upon a time, Randy Carpenter said: > Likewise OS vendors are increasingly dropping support for installing OSes via serial port (RHEL, VMWare, etc.) > > At leaset with RHEL, you can make your own boot image that gets rid of the asinine splash screen (which is the only thing that causes the requirement for a full VGA console) RHEL installs with a serial console just fine. You also don't have to "make your own boot image" to get a non-graphical boot. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ops.lists at gmail.com Thu Jan 10 03:16:10 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 10 Jan 2013 08:46:10 +0530 Subject: [SHAME] Spam Rats In-Reply-To: <50EE3138.7060903@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> <50EE3138.7060903@jdcomputers.com.au> Message-ID: Ask your customers what I asked you. Are they actually seeing email blocked and bounced because of that spam rats listing. Also it is your choice whether or not to follow best practices, it is spam rats choice to block mail based on whatever they like, and it is the choice of some random email Admin or the other to block mail based on spam rats.. Which is something I wouldn't recommend to people running a production mail system, but we'll.. --srs (htc one x) On 10-Jan-2013 8:40 AM, "Julian DeMarchi" wrote: > On 01/10/2013 01:06 PM, Suresh Ramasubramanian wrote: > > Who uses it? Or did you see your IP listed in one of those multiple dnsbl > > query sites and contacted them on general principles even though you > didn't > > see any actual bounced email that could be traced to a spam rats listing? > > Customers use the range. They had a complaint to us that the IP was > listed by spamrats and thus the issue made it to my queue. > > > That said, it is best practice to set ptr records even for your > unassigned > > ip space > > Mail servers do need to have PTRs, but it is my _choice_ if my hosts > that do not send mail have PTRs or not. I would not expect anyone to > block my /24 for lack of PTRs on non-mail-sending hosts. > > --julian > From cmadams at hiwaay.net Thu Jan 10 03:16:26 2013 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 9 Jan 2013 21:16:26 -0600 Subject: [SHAME] Spam Rats In-Reply-To: References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: <20130110031626.GC2212@hiwaay.net> Once upon a time, Suresh Ramasubramanian said: > That said, it is best practice to set ptr records even for your unassigned > ip space [citation needed] -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From wbailey at satelliteintelligencegroup.com Thu Jan 10 03:16:36 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 10 Jan 2013 03:16:36 +0000 Subject: OOB core router connectivity wish list In-Reply-To: <1400592755.31199.1357787111080.JavaMail.root@network1.net> References: , <1400592755.31199.1357787111080.JavaMail.root@network1.net> Message-ID: Uplogix has a pretty rad solution.. >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Randy Carpenter Date: 01/09/2013 7:07 PM (GMT-08:00) To: Mikael Abrahamsson Cc: nanog at nanog.org Subject: Re: OOB core router connectivity wish list My main requirements would be: 1. Something that is *not* network (ethernet or otherwise) (isn't that the point of OOB?) 2. Something that is standard across everything, and can be aggregated easily onto a "console server" or the like I don't really see what is wrong with with keeping the serial port as the standard. Things like servers and RAID cards and such are coming with "BIOS"es that are graphical and even require a mouse to use. What use is that when I need to get into the BIOS from a remote site that is completely down? Likewise OS vendors are increasingly dropping support for installing OSes via serial port (RHEL, VMWare, etc.) At leaset with RHEL, you can make your own boot image that gets rid of the asinine splash screen (which is the only thing that causes the requirement for a full VGA console) It might be nice to have a "management-only" port of some sort to do more advanced things that serial cannot do, but the serial port is ubiquitous already, and I don't see any reason to remove it as the very low-level access method. thanks, -Randy ----- Original Message ----- > > I have together with some other people, collected a wish list for OOB > support, mainly aimed for core routers. This is to replace the legacy > serial port usually present on core routing equipment and to > move/collapse > all its functionality to an ethernet only port. Some equipment > already > have an mgmt ethernet port, but usually this can't do "everything", > meaning today one has to have OOB ethernet *and* OOB serial which > just > brings more pain than before. > > I would like to post it here to solicit feedback on it. Feel free to > use > it to tell your vendor account teams you want this if you feel it > useful. > I've already sent it to one vendor. > > http://swm.pp.se/oob.txt > > Priorities: > > [P1] -> must have, otherwise not useful > [P2] -> would be very useful, to most operators > [P3] -> nice to have, useful to some > > From the OOB ethernet port it should be possible to: > > [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in > they > might be totally dead and I want to cut power to it via the back > plane. > Also useful for FPGA upgrades). > > [P1]: Connect to manage the RP(s) and linecards (equivalent of todays > "connect" on GSR and ASR9k or connecting to RP serial port). > > [P2]: It should be possible to connect to the OOB from the RP as well > (to > diagnose OOB connectivity problems). > > [P2]: Upload software to the RP or otherwise make information > available to > the RP (for later re-install/turboboot for example). RP should have > access > to local storage on the OOB device to transfer configuration or > software > from the OOB device to the RP). > > [P2]: Read logs and other state of the components in the chassis > (displays > and LEDs) plus what kind of card is in each slot. > > [P1]: The OOB port should support (configurable), telnet, ssh and > optionally [P3] https login (with a java applet or equivalent to give > CLI > access in the browser) with ACLs to limit wherefrom things can be > done. > OOB should support ssh key based logins to admin account. > > [P1]: The IP address of the OOB port should be set via > DHCP/DHCPv6/SLAAC > and should have both IPv4 and IPv6 support. If not both, then IPv6 > only. > > [P1]: It should be possible to transfer data using tftp, ftp and scp > (ftp > client on the OOB device, scp being used to transfer data *to* the > device > (OOB being scp server). > > [P2]: OOB device should have tacacs and radius and [P1] local > user/password database support for authentication. [P3] OOB should > support > ssh-key based authentication. > > [P3] Chassis should have a character display or LEDs with > configurable > blink pattern from OOB, to aid remote hands identification. > > [P3] OOB should have two USB ports, one to use to insert storage to > transfer files to/from device. The other should be USB port that > presents > itself as ether USB serial port, or USB ethernet port, where the OOB > device would have built in DHCP/DHCPv6 server to give IPv4v6 access > to a > laptop connected to the OOB so the onsite engineer can then use > ssh/telnet > to administrate the OOB. Optionally this port could be ethernet port > (compare todays CON and AUX ports). > > [P2] OOB should have procedure to factory default its configuration, > perhaps physical button that can be pressed and held for duration of > time. > The fact that this is done should be logged to the RP. > > [P3] OOB should have possibility to show power supply and > environmental > state. > > [P3] The factory default configuration should not include an empty or > obvious login password. The factory-default login password should be > the > MAC address (without punctuation) of the OOB ethernet interface, > which > should be printed on the chassis next to the OOBE port. > > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > > From julian at jdcomputers.com.au Thu Jan 10 03:19:57 2013 From: julian at jdcomputers.com.au (Julian DeMarchi) Date: Thu, 10 Jan 2013 13:19:57 +1000 Subject: [SHAME] Spam Rats In-Reply-To: References: <50EE2E73.2060309@jdcomputers.com.au> <50EE3138.7060903@jdcomputers.com.au> Message-ID: <50EE335D.5000100@jdcomputers.com.au> On 01/10/2013 01:16 PM, Suresh Ramasubramanian wrote: > Ask your customers what I asked you. Are they actually seeing email blocked > and bounced because of that spam rats listing. They are yes. Emails are being blocked due to the listing on spamrats. For our colo ranges we do not set PTRs by default. I do for the hosts I run. I do beleive in BCP. :) From ops.lists at gmail.com Thu Jan 10 03:24:59 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 10 Jan 2013 08:54:59 +0530 Subject: [SHAME] Spam Rats In-Reply-To: <50EE335D.5000100@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> <50EE3138.7060903@jdcomputers.com.au> <50EE335D.5000100@jdcomputers.com.au> Message-ID: One $GENERATE in bind should take care of that, and save what looks like the usual extra long nanog thread? What does it cost you not to do it? On Thursday, January 10, 2013, Julian DeMarchi wrote: > On 01/10/2013 01:16 PM, Suresh Ramasubramanian wrote: > > Ask your customers what I asked you. Are they actually seeing email > blocked > > and bounced because of that spam rats listing. > > They are yes. Emails are being blocked due to the listing on spamrats. > > For our colo ranges we do not set PTRs by default. I do for the hosts I > run. I do beleive in BCP. :) > > -- --srs (iPad) From cboyd at gizmopartners.com Thu Jan 10 03:27:17 2013 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 9 Jan 2013 21:27:17 -0600 Subject: [SHAME] Spam Rats In-Reply-To: <50EE2E73.2060309@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: On Jan 9, 2013, at 8:58 PM, Julian DeMarchi wrote: > This is the first RBL I have seen list a /24 for lack of PTRs. Not for > sending spam, but just PTRs alone. How do you explain this to your > customer? We're small shop, but our policy is not to accept email from addresses without PTRs. And we have a long list of pool/dhcp/dyn/resnet PTRs we don't accept mail from as well. I tried SpamRats a few years ago, but found them to have too many false positives. Then, they were trying to be early detectors of spam orginiating from static IP cable/DSL customers. Good idea, but poorly executed in operation. --Chris From jlewis at lewis.org Thu Jan 10 03:30:09 2013 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 9 Jan 2013 22:30:09 -0500 (EST) Subject: [SHAME] Spam Rats In-Reply-To: <50EE3138.7060903@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> <50EE3138.7060903@jdcomputers.com.au> Message-ID: On Thu, 10 Jan 2013, Julian DeMarchi wrote: > Customers use the range. They had a complaint to us that the IP was > listed by spamrats and thus the issue made it to my queue. That frequently just means they've subscribed to one of the monitoring services that notifies you if your IPs have turned up on any DNSBL the monitoring service has ever heard of, sometimes including ones that have been shut down, domain snatched up by speculators, and wildcard A record installed pointing at an ads landing page. > Mail servers do need to have PTRs, but it is my _choice_ if my hosts > that do not send mail have PTRs or not. I would not expect anyone to > block my /24 for lack of PTRs on non-mail-sending hosts. If they're not mail servers, how is the DNSBL listing impacting them (assuming anyone even uses spamrats)? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rsk at gsp.org Thu Jan 10 03:40:25 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 9 Jan 2013 22:40:25 -0500 Subject: [SHAME] Spam Rats In-Reply-To: <50EE2E73.2060309@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: <20130110034025.GA32705@gsp.org> On Thu, Jan 10, 2013 at 12:58:59PM +1000, Julian DeMarchi wrote: > This is the first RBL I have seen list a /24 for lack of PTRs. Not for > sending spam, but just PTRs alone. How do you explain this to your > customer? First, this would be better on mailop. Second, they're running a DNSBL, not *the* RBL. Third, anyone may run any DNSBL with any policy they wish: listing IP addresses whose octets are primes, domains with the letter "j" in their names, etc. Provide they comply with RFC 6471, this isn't a problem. What *might* be a problem is how they're used and by whom, but one of the nice features of DNSLs in operational practice is that those with suboptimal listing policies aren't used much. Fourth, one of the hundreds of DNSBLs may be the least of your problems. For roughly a decade now, it's been a very good idea to refuse/defer all mail traffic from anything which doesn't have matching PTR and A records. (The refuse/defer depends on whether the problem appears to be a permanent misconfiguration or the temporary consequence of a DNS oops.) But again: mailop would be better for this. ---rsk From ops.lists at gmail.com Thu Jan 10 03:44:32 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 10 Jan 2013 09:14:32 +0530 Subject: [SHAME] Spam Rats In-Reply-To: <20130110031626.GC2212@hiwaay.net> References: <50EE2E73.2060309@jdcomputers.com.au> <20130110031626.GC2212@hiwaay.net> Message-ID: Personal experience is that I have had a large telco, which I won't name since they immediately unblocked, blocked exactly such a range once, for the exact same reason. RFCs and best practices often aren't a 100 % exact match so sorry, I can't dig up a cite. --srs (htc one x) On 10-Jan-2013 9:00 AM, "Chris Adams" wrote: > Once upon a time, Suresh Ramasubramanian said: > > That said, it is best practice to set ptr records even for your > unassigned > > ip space > > [citation needed] > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From julian at jdcomputers.com.au Thu Jan 10 03:49:57 2013 From: julian at jdcomputers.com.au (Julian DeMarchi) Date: Thu, 10 Jan 2013 13:49:57 +1000 Subject: [SHAME] Spam Rats In-Reply-To: References: <50EE2E73.2060309@jdcomputers.com.au> <50EE3138.7060903@jdcomputers.com.au> Message-ID: <50EE3A65.7070903@jdcomputers.com.au> On 01/10/2013 01:30 PM, Jon Lewis wrote: >> Mail servers do need to have PTRs, but it is my _choice_ if my hosts >> that do not send mail have PTRs or not. I would not expect anyone to >> block my /24 for lack of PTRs on non-mail-sending hosts. > > If they're not mail servers, how is the DNSBL listing impacting them > (assuming anyone even uses spamrats)? Here[0] is the only message they give you. All mail servers have PTRs. At least one company uses spamrats. That's how it got escalated to me. --julian 0 - http://pastebin.com/dBSncSaV From julian at jdcomputers.com.au Thu Jan 10 03:50:44 2013 From: julian at jdcomputers.com.au (Julian DeMarchi) Date: Thu, 10 Jan 2013 13:50:44 +1000 Subject: [SHAME] Spam Rats In-Reply-To: References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: <50EE3A94.8040903@jdcomputers.com.au> On 01/10/2013 01:27 PM, Chris Boyd wrote: > We're small shop, but our policy is not to accept email from addresses without PTRs. And we have a long list of pool/dhcp/dyn/resnet PTRs we don't accept mail from as well. This is the normal pratice. I would never run a mail server without a PTR. --julian From rcarpen at network1.net Thu Jan 10 03:55:29 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 9 Jan 2013 22:55:29 -0500 (EST) Subject: OOB core router connectivity wish list In-Reply-To: <20130110031547.GB2212@hiwaay.net> Message-ID: <872017535.31231.1357790129273.JavaMail.root@network1.net> ----- Original Message ----- > Once upon a time, Randy Carpenter said: > > Likewise OS vendors are increasingly dropping support for > > installing OSes via serial port (RHEL, VMWare, etc.) > > > > At leaset with RHEL, you can make your own boot image that gets rid > > of the asinine splash screen (which is the only thing that causes > > the requirement for a full VGA console) > > RHEL installs with a serial console just fine. You also don't have > to > "make your own boot image" to get a non-graphical boot. Probably a bit off topic for this thread, but... If I boot the default install disc/image on any of my servers (mostly Supermicro), it hangs at a blank screen when isolinux loads. If you get rid of the splash screen, it works fine. This has been an issue since RHEL4, I think. Maybe other server manufacturers handle the video a little differently, and are able to get past the splash screen. -Randy From kauer at biplane.com.au Thu Jan 10 04:15:33 2013 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 10 Jan 2013 15:15:33 +1100 Subject: [SHAME] Spam Rats In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B0180E8@ocsbs.ocosa.com> References: <50EE2E73.2060309@jdcomputers.com.au> <5FE1FB6D43B8A647BBC821840C1AEA8B0180E8@ocsbs.ocosa.com> Message-ID: <1357791333.2912.26.camel@karl> On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote: > FYI - I have a PTR for all IPs. Just general practice. All IPs actually in use, or all possible IPs in a network? If the latter, then it's not gunna fly for IPv6. Not at all. Not unless you synthesise the responses - in which case there is no point to requiring them anyway. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From blakjak at blakjak.net Thu Jan 10 04:18:27 2013 From: blakjak at blakjak.net (Mark Foster) Date: Thu, 10 Jan 2013 17:18:27 +1300 Subject: [SHAME] Spam Rats In-Reply-To: <1357791333.2912.26.camel@karl> References: <50EE2E73.2060309@jdcomputers.com.au> <5FE1FB6D43B8A647BBC821840C1AEA8B0180E8@ocsbs.ocosa.com> <1357791333.2912.26.camel@karl> Message-ID: <50EE4113.2000906@blakjak.net> On 10/01/13 17:15, Karl Auer wrote: > On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote: >> FYI - I have a PTR for all IPs. Just general practice. > All IPs actually in use, or all possible IPs in a network? If the > latter, then it's not gunna fly for IPv6. Not at all. Not unless you > synthesise the responses - in which case there is no point to requiring > them anyway. > > Regards, K. $GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.) I though the point of doing so was to establish with some degree of accuracy that there were 'real people' behind the administration of said IP, and that there was a somewhat increased level of accountability as a result - which suggests there is infact a point. From marka at isc.org Thu Jan 10 04:41:27 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Jan 2013 15:41:27 +1100 Subject: [SHAME] Spam Rats In-Reply-To: Your message of "Thu, 10 Jan 2013 17:18:27 +1300." <50EE4113.2000906@blakjak.net> References: <50EE2E73.2060309@jdcomputers.com.au> <5FE1FB6D43B8A647BBC821840C1AEA8B0180E8@ocsbs.ocosa.com> <1357791333.2912.26.camel@karl> <50EE4113.2000906@blakjak.net> Message-ID: <20130110044127.6CAD32DEE3E2@drugs.dv.isc.org> In message <50EE4113.2000906 at blakjak.net>, Mark Foster writes: > On 10/01/13 17:15, Karl Auer wrote: > > On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote: > >> FYI - I have a PTR for all IPs. Just general practice. > > All IPs actually in use, or all possible IPs in a network? If the > > latter, then it's not gunna fly for IPv6. Not at all. Not unless you > > synthesise the responses - in which case there is no point to requiring > > them anyway. > > > > Regards, K. > > > $GENERATE, as someone else pointed out, solves that problem for you? > (Does it scale for IPv6? I can't recall - but surely this could be > scripted too.) No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you had machines that supported zettabytes of data the zone would never load in human lifetimes. > I though the point of doing so was to establish with some degree of > accuracy that there were 'real people' behind the administration of said > IP, and that there was a somewhat increased level of accountability as a > result - which suggests there is infact a point. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From johnl at iecc.com Thu Jan 10 04:42:13 2013 From: johnl at iecc.com (John Levine) Date: 10 Jan 2013 04:42:13 -0000 Subject: [SHAME] Spam Rats In-Reply-To: <50EE335D.5000100@jdcomputers.com.au> Message-ID: <20130110044213.53734.qmail@joyce.lan> Any moron can run a DNSBL. Many morons do. But that doesn't mean that anyone actually uses them. >They are yes. Emails are being blocked due to the listing on spamrats. Please show us a copy of one of the failure messages. Feel free to redact any private information, but please leave the IP addresses and reject messages visible. R's, John PS: In my experience, customers who think that their mail is being rejected due to a DNSBL we never heard of are almost always mistaken. A message bounces due to some random reason, they look up their IP on one of those bazillion DNSBL lookup pages, find some obscure DNSBL that lists them, and leap to the conclusion that's the problem. From jeff-kell at utc.edu Thu Jan 10 04:44:12 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 9 Jan 2013 23:44:12 -0500 Subject: [SHAME] Spam Rats In-Reply-To: <20130110044127.6CAD32DEE3E2@drugs.dv.isc.org> References: <50EE2E73.2060309@jdcomputers.com.au> <5FE1FB6D43B8A647BBC821840C1AEA8B0180E8@ocsbs.ocosa.com> <1357791333.2912.26.camel@karl> <50EE4113.2000906@blakjak.net> <20130110044127.6CAD32DEE3E2@drugs.dv.isc.org> Message-ID: <50EE471C.7010409@utc.edu> On 1/9/2013 11:41 PM, Mark Andrews wrote: > $GENERATE, as someone else pointed out, solves that problem for you? > (Does it scale for IPv6? I can't recall - but surely this could be > scripted too.) > No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you > had machines that supported zettabytes of data the zone would never > load in human lifetimes. Can you wildcard it? (Still an IPv6 implementation virgin, just curious :) ) Jeff From marka at isc.org Thu Jan 10 04:50:37 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Jan 2013 15:50:37 +1100 Subject: [SHAME] Spam Rats In-Reply-To: Your message of "Wed, 09 Jan 2013 23:44:12 CDT." <50EE471C.7010409@utc.edu> References: <50EE2E73.2060309@jdcomputers.com.au> <5FE1FB6D43B8A647BBC821840C1AEA8B0180E8@ocsbs.ocosa.com> <1357791333.2912.26.camel@karl> <50EE4113.2000906@blakjak.net> <20130110044127.6CAD32DEE3E2@drugs.dv.isc.org> <50EE471C.7010409@utc.edu> Message-ID: <20130110045038.0A3A32DEE599@drugs.dv.isc.org> In message <50EE471C.7010409 at utc.edu>, Jeff Kell writes: > On 1/9/2013 11:41 PM, Mark Andrews wrote: > > $GENERATE, as someone else pointed out, solves that problem for you? > > (Does it scale for IPv6? I can't recall - but surely this could be > > scripted too.) > > No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you > > had machines that supported zettabytes of data the zone would never > > load in human lifetimes. > > Can you wildcard it? No point. address -> name -> address doesn't work with wildcards. > (Still an IPv6 implementation virgin, just curious :) ) > > Jeff -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nicolai-nanog at chocolatine.org Thu Jan 10 04:51:09 2013 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Wed, 9 Jan 2013 22:51:09 -0600 Subject: [SHAME] Spam Rats In-Reply-To: <50EE2E73.2060309@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: <20130110045109.GA14219@vectra.student.iastate.edu> On Thu, Jan 10, 2013 at 12:58:59PM +1000, Julian DeMarchi wrote: > This is the first RBL I have seen list a /24 for lack of PTRs. Maybe because it's redundant: a PTR check should be automatic on any incoming SMTP connection. Just think of all the traffic their survey tool generated in compiling this totally useless list. The humanity! Nicolai From rob at invaluement.com Thu Jan 10 04:55:47 2013 From: rob at invaluement.com (Rob McEwen) Date: Wed, 09 Jan 2013 23:55:47 -0500 Subject: [SHAME] Spam Rats In-Reply-To: <50EE2E73.2060309@jdcomputers.com.au> References: <50EE2E73.2060309@jdcomputers.com.au> Message-ID: <50EE49D3.7020305@invaluement.com> On 1/9/2013 9:58 PM, Julian DeMarchi wrote: > There is an anti-spam company called Spam Rats[1].... > They have listed a /24 of my companies for lack of PTRs in the range I find SpamRats' lists helpful in spam filtering as a low scoring list because it puts some new emitters which haven't had time to build up bad reputation "over the top". Having said that, they actually have 3 lists, and only one of those 3 lists involves listing IPs ONLY based on "no PTR". They also have an "all" list, but they document on their web site how to query the "all" list, but then ignore those return codes indicating the "no PTR" list. That is how I use them because I didn't need their "no PTR" list since it would be redundant for me since I was already checking for "no PTR" myself... and I didn't want to score twice on that one attribute. But if your information is accurate and I understand you correctly, then I agree that they shouldn't list the whole /24 in their PTR list if SOME of those IPs *do* have PTRs. (Actually, I wasn't aware that any of their lists involved /24 blocks. They should probably be more clear about that on their web site.) On their web site, on the http://www.spamrats.com/about.php page, under the heading, "NEW - SpamRats All", they describe this method of querying their "all" list, but ignoring their PTR list's particular return code. I think they made THAT suggestion FOR VERY GOOD REASON. Therefore, you could use this to your advantage by going back to whichever recipient blocked your mail and say... "hey, you're NOT using spamRATS in a manner that they suggested", then point them to the section I referenced and explain that many don't use their "no PTR" list since most spam filters already do that. Maybe that could be a short term solution for you? (probably better than nothing) -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From julian at jdcomputers.com.au Thu Jan 10 05:23:30 2013 From: julian at jdcomputers.com.au (Julian DeMarchi) Date: Thu, 10 Jan 2013 15:23:30 +1000 Subject: [SHAME] Spam Rats In-Reply-To: <50EE49D3.7020305@invaluement.com> References: <50EE2E73.2060309@jdcomputers.com.au> <50EE49D3.7020305@invaluement.com> Message-ID: <50EE5052.8000804@jdcomputers.com.au> On 01/10/2013 02:55 PM, Rob McEwen wrote: > But if your information is accurate and I understand you correctly, then > I agree that they shouldn't list the whole /24 in their PTR list if SOME > of those IPs *do* have PTRs. My information is correct. The /24 is listed _only_ on the no-ptr list. --- List Status RATS-Dyna - Not on the list RATS-NoPtr - On the list. Worst Offender Alert RATS-Spam - Not on the list --- --julian From johnl at iecc.com Thu Jan 10 05:34:29 2013 From: johnl at iecc.com (John Levine) Date: 10 Jan 2013 05:34:29 -0000 Subject: [SHAME] Spam Rats In-Reply-To: <20130110045038.0A3A32DEE599@drugs.dv.isc.org> Message-ID: <20130110053429.55493.qmail@joyce.lan> >No point. address -> name -> address doesn't work with wildcards. > >> (Still an IPv6 implementation virgin, just curious :) ) If you want to do generic IPv6 rDNS for all your hosts, you're stuck with a variety of less than great possibilities. One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.) Another is instrumenting the routers so that when they notice a new host on their network, they somehow send an update to the DNS servers to install rDNS for that host. If I had to guess, I would say that we'll eventually agree than on IPv6 networks, mail servers and other hosts who have reputations that matter will have fixed addresses assigned statically or via DHCP and rDNS, random client hosts won't. Teeth will gnash at how this makes some hosts second class and it violates the end to end principle, but tough noogies. R's, John From marka at isc.org Thu Jan 10 05:49:10 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Jan 2013 16:49:10 +1100 Subject: [SHAME] Spam Rats In-Reply-To: Your message of "10 Jan 2013 05:34:29 -0000." <20130110053429.55493.qmail@joyce.lan> References: <20130110053429.55493.qmail@joyce.lan> Message-ID: <20130110054910.7ED142DEF1AA@drugs.dv.isc.org> In message <20130110053429.55493.qmail at joyce.lan>, "John Levine" writes: > >No point. address -> name -> address doesn't work with wildcards. > > > >> (Still an IPv6 implementation virgin, just curious :) ) > > If you want to do generic IPv6 rDNS for all your hosts, you're > stuck with a variety of less than great possibilities. > > One is a stunt rDNS server that synthesizes the records on demand. > (Bonus points for doing DNSSEC, too. Double bonus points for doing > NSEC3.) NSEC3 is a waste of time in ip6.arpa or any similarly structured zone so -1000000 for doing NEC3 and effectively doing a DoS attack against yourself and the client resolvers. > Another is instrumenting the routers so that when they notice > a new host on their network, they somehow send an update to the DNS > servers to install rDNS for that host. > > If I had to guess, I would say that we'll eventually agree than on > IPv6 networks, mail servers and other hosts who have reputations that > matter will have fixed addresses assigned statically or via DHCP and > rDNS, random client hosts won't. Teeth will gnash at how this makes > some hosts second class and it violates the end to end principle, but > tough noogies. > > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From swmike at swm.pp.se Thu Jan 10 05:50:23 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 10 Jan 2013 06:50:23 +0100 (CET) Subject: OOB core router connectivity wish list In-Reply-To: <1400592755.31199.1357787111080.JavaMail.root@network1.net> References: <1400592755.31199.1357787111080.JavaMail.root@network1.net> Message-ID: On Wed, 9 Jan 2013, Randy Carpenter wrote: > > My main requirements would be: > > 1. Something that is *not* network (ethernet or otherwise) (isn't that the point of OOB?) I don't understand this at all. Why can't an OOB network be ethernet based towards the equipment needing management? > 2. Something that is standard across everything, and can be aggregated > easily onto a "console server" or the like Yes, ethernet is the proposed management standard interface. > I don't really see what is wrong with with keeping the serial port as the standard. Because it's slow and can't be multiplexed, and it's expensive, only does short distance (20 meters or so), uses different cabling, requires separate planning etc. There are lot of reasons to drop serial port support. > Things like servers and RAID cards and such are coming with "BIOS"es > that are graphical and even require a mouse to use. What use is that > when I need to get into the BIOS from a remote site that is completely > down? My email stated https was way down on the priorities, and ssh and telnet was the prime way of managing the OOB part. > It might be nice to have a "management-only" port of some sort to do > more advanced things that serial cannot do, but the serial port is > ubiquitous already, and I don't see any reason to remove it as the very > low-level access method. An ethernet port is generally a lot cheaper compared to a serial port. Your OOB network would consist of a switch or router with ethernet towards the equipment needing management. -- Mikael Abrahamsson email: swmike at swm.pp.se From johnl at iecc.com Thu Jan 10 06:08:03 2013 From: johnl at iecc.com (John R. Levine) Date: 10 Jan 2013 01:08:03 -0500 Subject: [SHAME] Spam Rats In-Reply-To: <20130110054910.7ED142DEF1AA@drugs.dv.isc.org> References: <20130110053429.55493.qmail@joyce.lan> <20130110054910.7ED142DEF1AA@drugs.dv.isc.org> Message-ID: >> One is a stunt rDNS server that synthesizes the records on demand. >> (Bonus points for doing DNSSEC, too. Double bonus points for doing >> NSEC3.) > > NSEC3 is a waste of time in ip6.arpa or any similarly structured > zone so -1000000 for doing NEC3 and effectively doing a DoS attack > against yourself and the client resolvers. I know, but figuring out on the fly what order the hashes are would be quite a coding feat. R's, John From marka at isc.org Thu Jan 10 06:22:31 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Jan 2013 17:22:31 +1100 Subject: [SHAME] Spam Rats In-Reply-To: Your message of "10 Jan 2013 01:08:03 CDT." References: <20130110053429.55493.qmail@joyce.lan> <20130110054910.7ED142DEF1AA@drugs.dv.isc.org> Message-ID: <20130110062232.208452DF0E57@drugs.dv.isc.org> In message , "John R. Levine" wr ites: > >> One is a stunt rDNS server that synthesizes the records on demand. > >> (Bonus points for doing DNSSEC, too. Double bonus points for doing > >> NSEC3.) > > > > NSEC3 is a waste of time in ip6.arpa or any similarly structured > > zone so -1000000 for doing NEC3 and effectively doing a DoS attack > > against yourself and the client resolvers. > > I know, but figuring out on the fly what order the hashes are would > be quite a coding feat. subtract labels until you have one which fits the namespace pattern. that is the closest encloser . hash that name for the closest encloser. hash