Re: Netflix VPN detection - actual engineer needed
On Mon, Jun 6, 2016, at 13:09, Brandon Jackson wrote:
Looking up your tunnels block in ARIN will only show HE's Info.
Using HE's rwhois http://rwhois.he.net/whois.php
Shows the information provided by the tunnel user at time of signup or as modified in account settings.
Ahh, correct. This way is showing it for me. I should have known to use their rwhois. -- Mark Felder feld@feld.me
Maybe HE's IPv6 tunnel packets could be flagged with a destination option (extension header field) that records the end-user's IPv4 tunnel endpoint so geolocation could be done in the "old fashioned" way on that address. Similar to the way that edns-client-subnet records the end user's address for geolocation purposes. I have to say though, how many Netflix customers are using HE IPv6 tunnels, really? zero percent (to two decimal places)? Aled
It's obviously a nontrivial number otherwise why would Netflix block it? :) Aled Morris wrote:
Maybe HE's IPv6 tunnel packets could be flagged with a destination option (extension header field) that records the end-user's IPv4 tunnel endpoint so geolocation could be done in the "old fashioned" way on that address.
Similar to the way that edns-client-subnet records the end user's address for geolocation purposes.
I have to say though, how many Netflix customers are using HE IPv6 tunnels, really? zero percent (to two decimal places)?
Aled
On Mon, Jun 6, 2016 at 3:30 PM, Aled Morris <aledm@qix.co.uk> wrote:
Maybe HE's IPv6 tunnel packets could be flagged with a destination option (extension header field) that records the end-user's IPv4 tunnel endpoint so geolocation could be done in the "old fashioned" way on that address.
Similar to the way that edns-client-subnet records the end user's address for geolocation purposes.
why is this any problem at all for HE to solve? why is this any problem at all for NetFlix to solve? HE just provides transport Netflix is just complying (I suspect) with the wishes of the content owners. complain to your local content owner about this? show the content owners that this sort of restriction in a global economy is silly/counter-productive? explain that: "while I'm a Citizen of locale X, I may often travel around to A, B, C and I'd like for my NetFlix to work in all locations, since I pay good pesos for that access?" Doing any sort of 'authentication' or 'authorization' on src-IP is just .. broken.
I have to say though, how many Netflix customers are using HE IPv6 tunnels, really? zero percent (to two decimal places)?
Aled
None of this is a problem with actual network engineering, HE's tunnels work fine. It goes in the category of political/economic/contractual , not "this is a technical problem we need to solve". The problem exists with business/contractual relationship Netflix has with its content providers, which barring a miraculous data leak from a disgruntled sysadmin at Netflix, will remain completely opaque to everyone on the outside looking in. Due to the large sums of money involved, my best guess is that the recent crackdown on VPN and VPN-like tunnels is a result of major content providers staff that have been provided with greatly increased visibility into Netflix's internal processes for identifying and blocking VPNs. Undoubtedly there are dozens of pages in the contracts defining metrics for geolocation and acceptable vs unacceptable levels of "leakage" of content. On Mon, Jun 6, 2016 at 12:39 PM, Christopher Morrow <morrowc.lists@gmail.com
wrote:
On Mon, Jun 6, 2016 at 3:30 PM, Aled Morris <aledm@qix.co.uk> wrote:
Maybe HE's IPv6 tunnel packets could be flagged with a destination option (extension header field) that records the end-user's IPv4 tunnel endpoint so geolocation could be done in the "old fashioned" way on that address.
Similar to the way that edns-client-subnet records the end user's address for geolocation purposes.
why is this any problem at all for HE to solve? why is this any problem at all for NetFlix to solve?
HE just provides transport Netflix is just complying (I suspect) with the wishes of the content owners.
complain to your local content owner about this? show the content owners that this sort of restriction in a global economy is silly/counter-productive? explain that: "while I'm a Citizen of locale X, I may often travel around to A, B, C and I'd like for my NetFlix to work in all locations, since I pay good pesos for that access?"
Doing any sort of 'authentication' or 'authorization' on src-IP is just .. broken.
I have to say though, how many Netflix customers are using HE IPv6 tunnels, really? zero percent (to two decimal places)?
Aled
In message <CAB69EHhOr7fUvEMT9GsNDNtb7n7d3YmSh4QG426a3yD7DK_bOA@mail.gmail.com> , Eric Kuhnke writes:
None of this is a problem with actual network engineering, HE's tunnels work fine. It goes in the category of political/economic/contractual , not "this is a technical problem we need to solve".
The problem exists with business/contractual relationship Netflix has with its content providers, which barring a miraculous data leak from a disgruntled sysadmin at Netflix, will remain completely opaque to everyone on the outside looking in.
Due to the large sums of money involved, my best guess is that the recent crackdown on VPN and VPN-like tunnels is a result of major content providers staff that have been provided with greatly increased visibility into Netflix's internal processes for identifying and blocking VPNs. Undoubtedly there are dozens of pages in the contracts defining metrics for geolocation and acceptable vs unacceptable levels of "leakage" of content.
And they could easily redirect HE IPv6 addresses to a IPv4 only service. This would satify both the content providers and the customers. It's not like there tunneled traffic is IPv6 only as there has to be a IPv4 endpoint for the tunnel. You can't argue that HE is too small to do this for as they are targeting HE tunnels. Mark
On Mon, Jun 6, 2016 at 12:39 PM, Christopher Morrow <morrowc.lists@gmail.co= m
wrote:
On Mon, Jun 6, 2016 at 3:30 PM, Aled Morris <aledm@qix.co.uk> wrote:
Maybe HE's IPv6 tunnel packets could be flagged with a destination opti= on (extension header field) that records the end-user's IPv4 tunnel endpoi= nt so geolocation could be done in the "old fashioned" way on that address= .
Similar to the way that edns-client-subnet records the end user's addre= ss for geolocation purposes.
=E2=80=8Bwhy is this any problem at all for HE to solve? why is this any problem at all for NetFlix to solve?
HE just provides transport Netflix is just complying (I suspect) with the wishes of the content owners.
complain to your local content owner about this? show the content owners that this sort of restriction in a global economy is silly/counter-productive? explain that: "while I'm a Citizen of locale X,= I may often travel around to A, B, C and I'd like for my NetFlix to work in all locations, since I pay good pesos for that access?"=E2=80=8B
=E2=80=8BDoing any sort of 'authentication' or 'authorization' on src-IP = is just .. broken.=E2=80=8B
I have to say though, how many Netflix customers are using HE IPv6 tunnels, really? zero percent (to two decimal places)?
Aled
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 2016-06-06 19:39, Christopher Morrow wrote:
Doing any sort of 'authentication' or 'authorization' on src-IP is just .. broken.
This. Netflix is pretending to have a capability (geolocation by src ip) that doesn't exist and there is collateral damage from the application of their half baked solution. Those who end up getting dropped as collateral damage are rightly upset about the discrimination. -Laszlo
Geolocation by IP is even funnier as an idea for those who have worked in network engineering for commercial, geostationary two-way satellite services... Some examples: 1. C-band teleport in Singapore with SingTel IPs, remote terminals in Afghanistan. 2. Ku-band teleport in Germany with IP space in an Intelsat /20, remote terminal on the roof of a US government diplomatic facility in $DEVELOPING_COUNTRY 3. Teleports in Miami with IP space that looks indistinguishable (in terms of BGP-adjacency and traceroutes) from any other ISP in the metro Miami area, providing services to small TDMA VSAT terminals in west Africa. 4. Things in Antarctica that are on the other end of a C-band SCPC pipe from a large earth station in southern California. 5. Maritime Ku and C-band VSAT services with 2.5 meter size 3-axis tracking antennas on top of cruise ships that could be literally anywhere in the Mediterranean or Caribbean oceans, with the terrestrial end of the connection in Switzerland, Italy, Maryland or Georgia. 6. Small pacific island nations that have no submarine fiber connectivity and are now using o3b for IP backhaul, or C-band connectivity to teleports in Australia. On Mon, Jun 6, 2016 at 2:33 PM, Laszlo Hanyecz <laszlo@heliacal.net> wrote:
On 2016-06-06 19:39, Christopher Morrow wrote:
Doing any sort of 'authentication' or 'authorization' on src-IP is just .. broken.
This.
Netflix is pretending to have a capability (geolocation by src ip) that doesn't exist and there is collateral damage from the application of their half baked solution. Those who end up getting dropped as collateral damage are rightly upset about the discrimination.
-Laszlo
1. C-band teleport in Singapore with SingTel IPs, remote terminals in Afghanistan.
2. Ku-band teleport in Germany with IP space in an Intelsat /20, remote terminal on the roof of a US government diplomatic facility in $DEVELOPING_COUNTRY
3. Teleports in Miami with IP space that looks indistinguishable (in terms of BGP-adjacency and traceroutes) from any other ISP in the metro Miami area, providing services to small TDMA VSAT terminals in west Africa.
4. Things in Antarctica that are on the other end of a C-band SCPC pipe from a large earth station in southern California.
5. Maritime Ku and C-band VSAT services with 2.5 meter size 3-axis tracking antennas on top of cruise ships that could be literally anywhere in the Mediterranean or Caribbean oceans, with the terrestrial end of the connection in Switzerland, Italy, Maryland or Georgia.
6. Small pacific island nations that have no submarine fiber connectivity and are now using o3b for IP backhaul, or C-band connectivity to teleports in Australia.
Yes. All big Netflix customers.
On Mon, 06 Jun 2016 20:30:02 +0100, Aled Morris said:
Maybe HE's IPv6 tunnel packets could be flagged with a destination option (extension header field) that records the end-user's IPv4 tunnel endpoint so geolocation could be done in the "old fashioned" way on that address.
Similar to the way that edns-client-subnet records the end user's address for geolocation purposes.
First, you'd need buy-in from other tunnel providers. Doing it one-off for HE isn't a scalable answer. And if Netflix can't be bothered to consult rwhois for the ownership (which could be used for other use cases as well), they certainly aren't going to do *new* code as a one-off. Second, you'd need to make sure the extension header didn't get molested or dropped by anything on its way to Netflix. (edns-client-subnet leaves its cookie crumbs a few levels higher in the stack, so is less likely to be mangled by recalcitrant routers)
On Mon, 06 Jun 2016 15:44:14 -0400, <Valdis.Kletnieks@vt.edu> wrote:
And if Netflix can't be bothered to consult rwhois for the ownership (which could be used for other use cases as well), they certainly aren't going to do *new* code as a one-off.
Said by someone who's never written (r)whois parsers. There's no standard, you don't know who's running one, and God knows what it's going to spit out. It's hard enough to simply know who to ask. (see also: jwhois) Parsing whatever junk gets sent back almost requires an AI. Yes, ARIN and RIPE have REST APIs, but they're completely different interfaces with different schemas (and different capabilities.) I have independent applications for talking to each. And those are the only two I'm going to bother with. HE doesn't do a GeoIP lookup for the location of your v4 address and update their rwhois information every time your tunnel endpoint changes. Even if they did, Netflix would have to query that for every connection attempt to make sure you haven't moved it. That's never going to happen. --Ricky
RDAP is same across RIRs. Yes old REST API was PITA On 07/06/2016 02:08, Ricky Beam wrote:
Yes, ARIN and RIPE have REST APIs, but they're completely different interfaces with different schemas (and different capabilities.) I have independent applications for talking to each. And those are the only two I'm going to bother with.
participants (11)
-
Aled Morris -
Christopher Morrow -
Eric Kuhnke -
Laszlo Hanyecz -
Lyndon Nerenberg -
Mark Andrews -
Mark Felder -
Nikolay Shopik -
Ricky Beam -
Steven Noble -
Valdis.Kletnieks＠vt.edu