Re: Netflix transit preference?
Hi all, We (Netflix) reached out to Randal off-list to explain how our transit/peering methodology works. Feel free to reach out to peer...@netflix.com for questions like this in the future. -Dave On Thu, Dec 27, 2012 at 6:00 PM, Robert E. Seastrom r...@seastrom.com wrote: Jeff Kell jeff-k...@utc.edu writes: On 12/27/2012 1:26 PM, Patrick W. Gilmore wrote: On Dec 27, 2012, at 13:19 , randal k na...@data102.com wrote: (We move ~1.4gbps to Netflix, and are thus not a candidate for peering. And they have no POP close.) Why don't you ask Netflix? And why not ask them for kit to put on-net? https://signup.netflix.com/openconnect The last time we asked, their criteria was ~2.0gbps, so he doesn't have enough qualifying traffic. Has anyone looked at a Qwilt? http://www.qwilt.com/ MiM-ing streaming media providers is filed under encourage my competitors to do this. It's likely to make your phone ring. -r
Re: Netflix transit preference?
Hurricane electric has a very open peering policy , can peer with them at any major Equinix with pretty much no push or pull requirements , which is why Netflix prefers them cause it costs them almost nothing , why pay hurricane for transit when most of there connectivity can be accessed by peer routes pretty much for free through Equinix exchange or any2... On Thursday, December 27, 2012, randal k wrote: Hey NANOG! I work at a datacenter in southern Colorado that is the upstream bandwidth provider for several regional ISPs. We have been investigating our ever-growing bandwidth usage and have found that out of transits (Level3,Cogent,HE) that Netflix always seems to come in via Hurricane Electric. (We move ~1.4gbps to Netflix, and are thus not a candidate for peering. And they have no POP close.) I tested this by advertising a /24 across all providers, then selectively removed the advertisement to certain carriers to see where the bandwidth goes. In order, it appears that if there is a HE route, Netflix uses it, period. If there isn't, it prefers Level3, and Cogent comes last. Since Netflix is a big hunk of our bandwidth (and obviously makes our customers happy), we are included to buy some more HE. However, if Netflix decides that they want to randomly switch to, say, Cogent, we may be under a year-long bandwidth contract that isn't particularly valuable anymore. With all of that, I am interested in finding out of any knowledge about Netflix transit preferences, be it inside information, anecdotal, or otherwise. I did email peering@ but haven't heard back, thus the public question. Thanks! Randal
Re: really facebook?
Very common. Most Verizon Wireless data traffic on modern phones is backhauled to one or more mobile IP home agents based in a few cities. You'll typically see similar geolocation difficulties on their network for IPv4 too. They have another one in Texas, and another one in a different location I can't remember. This behavior plus related IP assignment practices has resulted in ineffective geolocation, often even on a regional level. Many mobile phone apps use more than just IP for geolocation though, which is much more effective. It's also worth noting that IPV6 geolocation support is quite primitive at this moment, but in this particular case its not what the problem is. On Thu, Dec 27, 2012 at 11:40 AM, joel jaeggli joe...@bogus.com wrote: On 12/27/12 10:29 AM, mike wrote: On 12/27/12 9:25 AM, joel jaeggli wrote: On 12/27/12 9:04 AM, mike wrote: I reloaded their app (yes, I know... sew me) and got this warning: IP address: 2600:100f:b119:c6bc:bd6f:fabb:**ff30:2a3d Estimated location: Livingston, NJ, US That's a rather good estimation of where many verizon wireless customers appear to come from. This can't mean that all of their v6 traffic is backhauled to NJ, right? Wireless carriers have a limited number of PDN gateways in their networks. it is entirely plausible that your packets visited new jersey. Which seems pretty bizarre. I'm guessing they must be getting it from whois or something based on the address block for Verizon. The reverse map according to host 2600:100f:b119:c6bc:bd6f:fabb:**ff30:2a3d one assumes they have a an geoip database like they have for ipv4 comes back with NXDOMAIN. I suppose the real issue here is with Vz and why they don't have v6 reverse maps, but it did throw me thinking that somebody in New Jersey might have hacked my account. Well could certainly wildcard their responses, not sure that dynamic dns updates would be either scalable or appropiate. Right, brain fart on my part. Reverse map has nothing to do with a geoip database. It's still strange that it has no reverse map though. I wonder what might break because of that assumption :) Mike Mike
Re: Gmail and SSL
On 12/29/2012 7:41 PM, Mark - Syminet wrote: On Dec 14, 2012, at 7:52 AM, Peter Kristolaitis alte...@alter3d.ca wrote: On 12/14/2012 10:47 AM, Randy wrote: I don't have hundreds of dollars to get my ssl certificates signed You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. So I guess the question really, is this: Is it bad, therefore - to *force* every holder of a self-signed certificate - to transmit in the clear? There are plenty of good reasons for self-signed certs -- people stuck running a Microsoft environment might find it might difficult without it, since it's a fundamental feature of Active Directory. ;) Various F/OSS projects, like OpenVPN, generally recommend self-signed certs as a standard deployment scenario, because it actually provides an extra layer of security -- as the CA, you determine who gets a cert and who doesn't. The difficulty you'll run into is defining self-signed. If you generate your own CA and put the certs in your /etc/ssl directory, it's still self-signed (as in you're the one signing the end-use certs), the only difference is that your browser, etc, won't pop up a warning because it's now trusted. It's also important to not conflate encryption with chain of trust validation. There are good reasons to encrypt without really caring who you're talking to. There are also good reasons to not necessarily trust an arbitrary list of CAs as provided by your SSL stack vendor and provide your own list, as mentioned above. Two entirely separate issues, IMHO. - Pete
Re: Gmail and SSL
On 12/14/12, Randy na...@afxr.net wrote: [snip] It explained that google is no longer accepting self signed ssl certificates. It claims that this change will offer[s] a higher level of security to better protect your information. Hm... Self-signed certificates, or (worse) the use of hostnames not on the certificate, are very common with POP/SMTP/IMAP over SSL/TLS servers; when setting up POP software, it is common that the user of an e-mail service will have instructions to check and install the certificate in the e-mail client, instead of requiring a unique IP address for every POP server mail domain, and a user purchased SSL certificate for each IP. The major CAs are not an authoritative list of CAs that may be used to sign POP, IMAP, or SMTP server certificates for various POP servers' on the internet; so Google's choices would seem poorly conceived in that regard. If Google should wish to enforce a validation of SSL certificates, the PKI authority required, should be specified by the user, not Google, or there should be a provision to accept any certificate whatsoever, by fingerprint, for a specific hostname; defined by the user. Google should go back to definitions. What is security: security is the assurance that the Confidentiality, Integrity, and Availability of data and systems are protected. How does this change apparently impact the assurances against risk? Availability: This change breaks availability, for users accessing servers already using self-signed certificates. (In other words, the change itself is a compromise of security; the risk that you lose availability of access to your mail that you expect to be downloaded via POP3 is 100%, if you have a self-signed cert in place) Confidentiality: The change prevents any transfer of data at all, unless the user of a self-signed certificate makes one of three changes: (1)Stop using gmail POP download altogether, in this case, confidentiality assurance may be improved, because no email can be downloaded and used with the service.In general, this may not be much of an improvement, when email has already been transmitted in cleartext, before it was placed on the remote POP server. (That might be their intended result -- discourage use of POP downloads) (2)Stop using SSL, and use regular POP3 instead. In this case, confidentiality will be no better than before, and may be significantly worse. A new risk of breach by 'passive sniffing' is created. When using SSL with a self-signed certificate; passive sniffing, or Deep packet inspection was not a risk: an active attack was a requirement. Therefore, being forced to never use SSL, even without a CA signed cert, is not an improvement, and a potential increase in risk. (3) Users may buy an official certificate, from a 3rd party CA that Google trusts. In this case, the SSL encrypted POP3 connections from Google to the POP server, will have strong protection against possible exposure of data in transit due to active Man-in-the-middle attack. * In other words: If you deem Man-in-the-Middle attack more likely than Passive sniffing exposure attacks to discover users' passwords, and the majority of users' POP servers likely to have or get certificates from a CA that Google trusts,then forced rejection of any other certificates may be an improvement in assurance against these risks; forcing the remaining users to not use SSL, and risk their password being exposed is OK, because you deemed MITM the greater risk. If you do not make that assumption, then it is not clear at all, whether assurance of confidentiality has been improved or not; it may be improved slightly for some users, and terribly harmed for many others. Integrity: The change prevents any transfer of data at all, unless the user of a self-signed certificate makes one of three changes: (1)Stop using POP download altogether, in this case, data cannot be altered by an unauthorized user as it transits the network, data that wasn't downloaded couldn't have been tampered with. (2)Stop using SSL, and use regular POP3 instead. In this case, a new risk of transparent inline tampering is created, without encryption, a full blown MITM attack is not required, a passive interceptor can flip random bits, as long as they update the corresponding IP checksums; so there are new significant risks to integrity. (3) Users may buy an official certificate; in this case, the risk of interception by inline Man-in-the-middle attack is reduced. I
