Re: Project Fi and the Great Firewall

[Yucong Sun]

This is what roaming data means, Your data packet is simply trunked to
your original operator to process.  So you will be having a US ip on
the web.

On Sun, Nov 15, 2015 at 12:02 PM, Yury Shefer  wrote:
> My team mate was traveling to China with his Nexus 6 (with Project Fi
> SIM-card) and was able to access Google services. The phone uses roaming
> data to access Google and your phone gets IP assigned by your home mobile
> network packet gateway (P-GW). There is no local data break-out.
>
> On Sat, Nov 14, 2015 at 6:00 PM, Sean Hunter  wrote:
>
>> Hello everyone,
>>
>> I come to you to humbly request your assistance, on or off list. This not
>> an urgent technical matter, but something I'm rather fascinated by at the
>> moment.
>>
>> While in China recently, I noticed that my Project Fi phone was accessing
>> Google. Not only Google, but Facebook, YouTube, Gmail, Twitter, and many
>> other normally perma-blocked websites. It's taken me a few days of sleep
>> deprived thinking to realize this, but I'm seeing the same or similar
>> 26.x.x.x addresses across countries I've visited, including China, Spain,
>> Malaysia, and Hong Kong.
>>
>> I'm not a cellular guy and I know even less about MVNO's, but I'm curious
>> if I'm inferring the technical operations of the network correctly. It
>> sounds like the local cellular companies are provisioning access upon
>> arrival, then packing up the packets and shipping them off at layer 2 or
>> below to Google, who's then handling the IP stack and up internet access.
>> I'm also assuming the Great Firewall then acts above these layers since
>> it's not blocking access on my phone.
>>
>> If my inference is correct, I'd be curious to see if those responsible for
>> the Great Firewall are aware of this deal Google has with a Chinese
>> cellular provider and the technical specifics of how it works. Might we be
>> seeing a softening of Great Firewall policies for foreigners, or just
>> another soon to be inspected or blocked flow of traffic?
>>
>> Anyway, I'd just love to hear from a knowledgeable engineer about how this
>> works.
>>
>> If you've read this far, thanks for your time and have a great day!
>>
>
>
>
> --
> Best regards,
> Yury.

Re: Project Fi and the Great Firewall

[Roland Dobbins]

On 15 Nov 2015, at 11:02, Yury Shefer wrote:

The phone uses roaming data to access Google and your phone gets IP 
assigned by your home mobile

network packet gateway (P-GW).


This is what I thought, as well - thanks for confirming!

---
Roland Dobbins 

Re: Project Fi and the Great Firewall

[Yury Shefer]

My team mate was traveling to China with his Nexus 6 (with Project Fi
SIM-card) and was able to access Google services. The phone uses roaming
data to access Google and your phone gets IP assigned by your home mobile
network packet gateway (P-GW). There is no local data break-out.

On Sat, Nov 14, 2015 at 6:00 PM, Sean Hunter  wrote:

> Hello everyone,
>
> I come to you to humbly request your assistance, on or off list. This not
> an urgent technical matter, but something I'm rather fascinated by at the
> moment.
>
> While in China recently, I noticed that my Project Fi phone was accessing
> Google. Not only Google, but Facebook, YouTube, Gmail, Twitter, and many
> other normally perma-blocked websites. It's taken me a few days of sleep
> deprived thinking to realize this, but I'm seeing the same or similar
> 26.x.x.x addresses across countries I've visited, including China, Spain,
> Malaysia, and Hong Kong.
>
> I'm not a cellular guy and I know even less about MVNO's, but I'm curious
> if I'm inferring the technical operations of the network correctly. It
> sounds like the local cellular companies are provisioning access upon
> arrival, then packing up the packets and shipping them off at layer 2 or
> below to Google, who's then handling the IP stack and up internet access.
> I'm also assuming the Great Firewall then acts above these layers since
> it's not blocking access on my phone.
>
> If my inference is correct, I'd be curious to see if those responsible for
> the Great Firewall are aware of this deal Google has with a Chinese
> cellular provider and the technical specifics of how it works. Might we be
> seeing a softening of Great Firewall policies for foreigners, or just
> another soon to be inspected or blocked flow of traffic?
>
> Anyway, I'd just love to hear from a knowledgeable engineer about how this
> works.
>
> If you've read this far, thanks for your time and have a great day!
>



-- 
Best regards,
Yury.

Re: Project Fi and the Great Firewall

[Jake Mertel]

I know the service/device uses VPN if you are using "wifi assist" to
connect to an open WAP -- it automatically tunnels the traffic so it can't
be read by nearby snoopers. Perhaps they employ a similar technology or are
using something like PPP to take all of the traffic back to one (or many)
"access servers" before sending it off to the Internet. I have no
experience whatsoever in cellular network operations, but I know many
providers employ similar methodologies to assist in meeting their CALEA
requirements.

On Saturday, November 14, 2015, Roland Dobbins  wrote:

> On 15 Nov 2015, at 9:00, Sean Hunter wrote:
>
> While in China recently, I noticed that my Project Fi phone was accessing
>> Google.
>>
>
> Accessing, or attempting to access?
>
> Were you using a local SIM card, or roaming w/data?  What about WiFi?
>
> ---
> Roland Dobbins 
>


-- 


--
Regards,

Jake Mertel
Ubiquity Hosting



*Web: *https://www.ubiquityhosting.com
*Phone (direct): *1-480-478-1510
*Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054

Re: Project Fi and the Great Firewall

[Joel Jaeggli]

Sent from my iPhone

> On Nov 14, 2015, at 18:00, Sean Hunter  wrote:
> 
> Hello everyone,
> 
> I come to you to humbly request your assistance, on or off list. This not
> an urgent technical matter, but something I'm rather fascinated by at the
> moment.
> 
> While in China recently, I noticed that my Project Fi phone was accessing
> Google. Not only Google, but Facebook, YouTube, Gmail, Twitter, and many
> other normally perma-blocked websites. It's taken me a few days of sleep
> deprived thinking to realize this, but I'm seeing the same or similar
> 26.x.x.x addresses across countries I've visited, including China, Spain,
> Malaysia, and Hong Kong.

26/8 is T-Mobile using DOD space for their internal addressing.

Irrespective of where you are your connected to the Same APN and traffic from 
your UE is indeed tunneled through the PGW

https://en.m.wikipedia.org/wiki/System_Architecture_Evolution#

> 
> I'm not a cellular guy and I know even less about MVNO's, but I'm curious
> if I'm inferring the technical operations of the network correctly. It
> sounds like the local cellular companies are provisioning access upon
> arrival, then packing up the packets and shipping them off at layer 2 or
> below to Google, who's then handling the IP stack and up internet access.
> I'm also assuming the Great Firewall then acts above these layers since
> it's not blocking access on my phone.
> 
> If my inference is correct, I'd be curious to see if those responsible for
> the Great Firewall are aware of this deal Google has with a Chinese
> cellular provider and the technical specifics of how it works. Might we be
> seeing a softening of Great Firewall policies for foreigners, or just
> another soon to be inspected or blocked flow of traffic?
> 
> Anyway, I'd just love to hear from a knowledgeable engineer about how this
> works.
> 
> If you've read this far, thanks for your time and have a great day!
> 

Re: Project Fi and the Great Firewall

[Roland Dobbins]

On 15 Nov 2015, at 9:00, Sean Hunter wrote:

While in China recently, I noticed that my Project Fi phone was 
accessing Google.


Accessing, or attempting to access?

Were you using a local SIM card, or roaming w/data?  What about WiFi?

---
Roland Dobbins 

Re: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15

[Jonas Bjork]

Thank you Jeff, I'll check it out on the HP side since Cisco seems to not care:

Known Fixed Releases:   (0)
No release planned to fix this bug

Best regards,
Jonas Bjork


> On 15 Nov 2015, at 2:54, Jeff Tantsura  wrote:
> 
> Jonas,
> 
> As expected - the problem is related to vc type negotiation.
> 
> You have hit CSCuq28998 :)
> talk to your cisco rep
> 
> Workaround:
> - configure VC type 5 between the routers (configured on HP side)
> - configuring no-control-word 
> 
> 
> The bug has been reported in 15.2(4)S4a, perhaps there’s an image with the 
> problem fixed.
> 
> Cheers,
> Jeff
> 
> 
> 
> 
> On 11/14/15, 17:31, "Jonas Bjork"  wrote:
> 
>> Dear Mr. Jeff,
>> 
>> Thank you for your reply. Below is the complete output in question (l2 is 
>> short for l2transport).
>> You are mentioning platform capabilities and that the default might have 
>> changed. How do I alter this?
>> 
>> pe#sh mpls l2 vc 42 d
>> Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up
>> Destination address: X.X.1.89, VC ID: 42, VC status: down
>>   Last error: Imposition VLAN rewrite capability mismatch with peer
>>   Output interface: none, imposed label stack {}
>>   Preferred path: not configured
>>   Default path: no route
>>   No adjacency
>> Create time: 00:00:59, last status change time: 00:31:40
>>   Last label FSM state change time: 00:00:18
>>   Last peer autosense occurred at: 00:00:18
>> Signaling protocol: LDP, peer X.X.1.89:0 up
>>   Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP
>>   Graceful restart: not configured and not enabled
>>   Non stop routing: not configured and not enabled
>>   Status TLV support (local/remote)   : enabled/not supported
>> LDP route watch   : enabled
>> Label/status state machine: remote invalid, LruRnd
>> Last local dataplane   status rcvd: No fault
>> Last BFD dataplane status rcvd: Not sent
>> Last BFD peer monitor  status rcvd: No fault
>> Last local AC  circuit status rcvd: No fault
>> Last local AC  circuit status sent: DOWN PW(rx/tx faults)
>> Last local PW i/f circ status rcvd: No fault
>> Last local LDP TLV status sent: No fault
>> Last remote LDP TLVstatus rcvd: Not sent
>> Last remote LDP ADJstatus rcvd: No fault
>>   MPLS VC labels: local 242, remote 1199
>>   Group ID: local 0, remote 0
>>   MTU: local 9216, remote 9216
>>   Remote interface description:
>>   Remote VLAN id: 42
>> Sequencing: receive disabled, send disabled
>> Control Word: Off (configured: autosense)
>> SSO Descriptor: X.X.1.89/42, local label: 242
>> Dataplane:
>>   SSM segment/switch IDs: 0/0 (used), PWID: 142
>> VC statistics:
>>   transit packet totals: receive 0, send 0
>>   transit byte totals:   receive 0, send 0
>>   transit packet drops:  receive 0, seq error 0, send 0
>> pe#
>> 
>> Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching.
>> 
>> Best regards,
>> Jonas Bjork
>> 
>> 
>>> On 15 Nov 2015, at 1:26, Jeff Tantsura  wrote:
>>> 
>>> Been forever since i looked at cisco, however sounds like vc type mismatch. 
>>> They used to have it as a platform capability, perhaps SW upgrade changed 
>>> the default.
>>> 
>>> to my memory "show mpls l2 transport" should provide enough details.
>>> 
>>> Hope this helps
>>> 
>>> Regards,
>>> Jeff
>>> 
 On Nov 14, 2015, at 4:50 AM, Jonas Bjork  wrote:
 
 Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer 
 voice and data traffic across our IP/MPLS core, and it is currently 
 working just fine. The first side consists of a Cisco 7600 router (rsp) 
 and the other one is an HP A5500-HI routing switch with full LER/E-LSR 
 capability. At the HP site, the tunnels are facing the access ports 
 towards our premium end-customers; and on the Cisco PE I terminate the 
 tunnels on one of the 2x10GE portchannel backbone links. There is vlan X 
 on the HP side and vlan Y on the Cisco side - vlan rewrite is working 
 perfectly - as long as I use IOS 12.
 
 After upgrading the Cisco router software to IOS 15 the tunnels won't come 
 up. sh mpls l2 vc Y d says:
 ...
 Last error: Imposition VLAN rewrite capability mismatch with peer
 ...
 
 I use almost exactly the same Cisco configuration before and after the 
 upgrade (only minor changes and nothing related to this) and I havn't 
 touched the HP. Apparently they don't talk the same L2PW language. I 
 wonder though, why now? We use service instances on the HP switchport as 
 endpoint, we initiate the targetted LDP session in addition to the 
 pseudowire handshake from a sub interface MPLS crossconnect. There is no 
 MTU mismatch; not here - not anywhere.
 
 Anyone heard of this issue or experienced it?
 
 Best regards,
 
 Jonas Björk
 SNE, Europe/Sweden (hope you guys will help me anyway:)
>> 

Project Fi and the Great Firewall

[Sean Hunter]

Hello everyone,

I come to you to humbly request your assistance, on or off list. This not
an urgent technical matter, but something I'm rather fascinated by at the
moment.

While in China recently, I noticed that my Project Fi phone was accessing
Google. Not only Google, but Facebook, YouTube, Gmail, Twitter, and many
other normally perma-blocked websites. It's taken me a few days of sleep
deprived thinking to realize this, but I'm seeing the same or similar
26.x.x.x addresses across countries I've visited, including China, Spain,
Malaysia, and Hong Kong.

I'm not a cellular guy and I know even less about MVNO's, but I'm curious
if I'm inferring the technical operations of the network correctly. It
sounds like the local cellular companies are provisioning access upon
arrival, then packing up the packets and shipping them off at layer 2 or
below to Google, who's then handling the IP stack and up internet access.
I'm also assuming the Great Firewall then acts above these layers since
it's not blocking access on my phone.

If my inference is correct, I'd be curious to see if those responsible for
the Great Firewall are aware of this deal Google has with a Chinese
cellular provider and the technical specifics of how it works. Might we be
seeing a softening of Great Firewall policies for foreigners, or just
another soon to be inspected or blocked flow of traffic?

Anyway, I'd just love to hear from a knowledgeable engineer about how this
works.

If you've read this far, thanks for your time and have a great day!

Re: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15

[Jeff Tantsura]

Jonas,

As expected - the problem is related to vc type negotiation.

You have hit CSCuq28998 :)
talk to your cisco rep  

Workaround:
- configure VC type 5 between the routers (configured on HP side)
- configuring no-control-word 


The bug has been reported in 15.2(4)S4a, perhaps there’s an image with the 
problem fixed.

Cheers,
Jeff




On 11/14/15, 17:31, "Jonas Bjork"  wrote:

>Dear Mr. Jeff,
>
>Thank you for your reply. Below is the complete output in question (l2 is 
>short for l2transport).
>You are mentioning platform capabilities and that the default might have 
>changed. How do I alter this?
>
>pe#sh mpls l2 vc 42 d
>Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up
>  Destination address: X.X.1.89, VC ID: 42, VC status: down
>Last error: Imposition VLAN rewrite capability mismatch with peer
>Output interface: none, imposed label stack {}
>Preferred path: not configured
>Default path: no route
>No adjacency
>  Create time: 00:00:59, last status change time: 00:31:40
>Last label FSM state change time: 00:00:18
>Last peer autosense occurred at: 00:00:18
>  Signaling protocol: LDP, peer X.X.1.89:0 up
>Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP
>Graceful restart: not configured and not enabled
>Non stop routing: not configured and not enabled
>Status TLV support (local/remote)   : enabled/not supported
>  LDP route watch   : enabled
>  Label/status state machine: remote invalid, LruRnd
>  Last local dataplane   status rcvd: No fault
>  Last BFD dataplane status rcvd: Not sent
>  Last BFD peer monitor  status rcvd: No fault
>  Last local AC  circuit status rcvd: No fault
>  Last local AC  circuit status sent: DOWN PW(rx/tx faults)
>  Last local PW i/f circ status rcvd: No fault
>  Last local LDP TLV status sent: No fault
>  Last remote LDP TLVstatus rcvd: Not sent
>  Last remote LDP ADJstatus rcvd: No fault
>MPLS VC labels: local 242, remote 1199
>Group ID: local 0, remote 0
>MTU: local 9216, remote 9216
>Remote interface description:
>Remote VLAN id: 42
>  Sequencing: receive disabled, send disabled
>  Control Word: Off (configured: autosense)
>  SSO Descriptor: X.X.1.89/42, local label: 242
>  Dataplane:
>SSM segment/switch IDs: 0/0 (used), PWID: 142
>  VC statistics:
>transit packet totals: receive 0, send 0
>transit byte totals:   receive 0, send 0
>transit packet drops:  receive 0, seq error 0, send 0
>pe#
>
>Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching.
>
>Best regards,
>Jonas Bjork
>
>
>> On 15 Nov 2015, at 1:26, Jeff Tantsura  wrote:
>> 
>> Been forever since i looked at cisco, however sounds like vc type mismatch. 
>> They used to have it as a platform capability, perhaps SW upgrade changed 
>> the default.
>> 
>> to my memory "show mpls l2 transport" should provide enough details.
>> 
>> Hope this helps
>> 
>> Regards,
>> Jeff
>> 
>>> On Nov 14, 2015, at 4:50 AM, Jonas Bjork  wrote:
>>> 
>>> Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer 
>>> voice and data traffic across our IP/MPLS core, and it is currently working 
>>> just fine. The first side consists of a Cisco 7600 router (rsp) and the 
>>> other one is an HP A5500-HI routing switch with full LER/E-LSR capability. 
>>> At the HP site, the tunnels are facing the access ports towards our premium 
>>> end-customers; and on the Cisco PE I terminate the tunnels on one of the 
>>> 2x10GE portchannel backbone links. There is vlan X on the HP side and vlan 
>>> Y on the Cisco side - vlan rewrite is working perfectly - as long as I use 
>>> IOS 12.
>>> 
>>> After upgrading the Cisco router software to IOS 15 the tunnels won't come 
>>> up. sh mpls l2 vc Y d says:
>>> ...
>>> Last error: Imposition VLAN rewrite capability mismatch with peer
>>> ...
>>> 
>>> I use almost exactly the same Cisco configuration before and after the 
>>> upgrade (only minor changes and nothing related to this) and I havn't 
>>> touched the HP. Apparently they don't talk the same L2PW language. I wonder 
>>> though, why now? We use service instances on the HP switchport as endpoint, 
>>> we initiate the targetted LDP session in addition to the pseudowire 
>>> handshake from a sub interface MPLS crossconnect. There is no MTU mismatch; 
>>> not here - not anywhere.
>>> 
>>> Anyone heard of this issue or experienced it?
>>> 
>>> Best regards,
>>> 
>>> Jonas Björk
>>> SNE, Europe/Sweden (hope you guys will help me anyway:)
>

Re: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15

[Jonas Bjork]

Dear Mr. Jeff,

Thank you for your reply. Below is the complete output in question (l2 is short 
for l2transport).
You are mentioning platform capabilities and that the default might have 
changed. How do I alter this?

pe#sh mpls l2 vc 42 d
Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up
  Destination address: X.X.1.89, VC ID: 42, VC status: down
Last error: Imposition VLAN rewrite capability mismatch with peer
Output interface: none, imposed label stack {}
Preferred path: not configured
Default path: no route
No adjacency
  Create time: 00:00:59, last status change time: 00:31:40
Last label FSM state change time: 00:00:18
Last peer autosense occurred at: 00:00:18
  Signaling protocol: LDP, peer X.X.1.89:0 up
Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP
Graceful restart: not configured and not enabled
Non stop routing: not configured and not enabled
Status TLV support (local/remote)   : enabled/not supported
  LDP route watch   : enabled
  Label/status state machine: remote invalid, LruRnd
  Last local dataplane   status rcvd: No fault
  Last BFD dataplane status rcvd: Not sent
  Last BFD peer monitor  status rcvd: No fault
  Last local AC  circuit status rcvd: No fault
  Last local AC  circuit status sent: DOWN PW(rx/tx faults)
  Last local PW i/f circ status rcvd: No fault
  Last local LDP TLV status sent: No fault
  Last remote LDP TLVstatus rcvd: Not sent
  Last remote LDP ADJstatus rcvd: No fault
MPLS VC labels: local 242, remote 1199
Group ID: local 0, remote 0
MTU: local 9216, remote 9216
Remote interface description:
Remote VLAN id: 42
  Sequencing: receive disabled, send disabled
  Control Word: Off (configured: autosense)
  SSO Descriptor: X.X.1.89/42, local label: 242
  Dataplane:
SSM segment/switch IDs: 0/0 (used), PWID: 142
  VC statistics:
transit packet totals: receive 0, send 0
transit byte totals:   receive 0, send 0
transit packet drops:  receive 0, seq error 0, send 0
pe#

Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching.

Best regards,
Jonas Bjork


> On 15 Nov 2015, at 1:26, Jeff Tantsura  wrote:
> 
> Been forever since i looked at cisco, however sounds like vc type mismatch. 
> They used to have it as a platform capability, perhaps SW upgrade changed the 
> default.
> 
> to my memory "show mpls l2 transport" should provide enough details.
> 
> Hope this helps
> 
> Regards,
> Jeff
> 
>> On Nov 14, 2015, at 4:50 AM, Jonas Bjork  wrote:
>> 
>> Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer 
>> voice and data traffic across our IP/MPLS core, and it is currently working 
>> just fine. The first side consists of a Cisco 7600 router (rsp) and the 
>> other one is an HP A5500-HI routing switch with full LER/E-LSR capability. 
>> At the HP site, the tunnels are facing the access ports towards our premium 
>> end-customers; and on the Cisco PE I terminate the tunnels on one of the 
>> 2x10GE portchannel backbone links. There is vlan X on the HP side and vlan Y 
>> on the Cisco side - vlan rewrite is working perfectly - as long as I use IOS 
>> 12.
>> 
>> After upgrading the Cisco router software to IOS 15 the tunnels won't come 
>> up. sh mpls l2 vc Y d says:
>> ...
>> Last error: Imposition VLAN rewrite capability mismatch with peer
>> ...
>> 
>> I use almost exactly the same Cisco configuration before and after the 
>> upgrade (only minor changes and nothing related to this) and I havn't 
>> touched the HP. Apparently they don't talk the same L2PW language. I wonder 
>> though, why now? We use service instances on the HP switchport as endpoint, 
>> we initiate the targetted LDP session in addition to the pseudowire 
>> handshake from a sub interface MPLS crossconnect. There is no MTU mismatch; 
>> not here - not anywhere.
>> 
>> Anyone heard of this issue or experienced it?
>> 
>> Best regards,
>> 
>> Jonas Björk
>> SNE, Europe/Sweden (hope you guys will help me anyway:)

Re: DNSSEC and ISPs faking DNS responses

[Owen DeLong]

> 
> And it may only take a secondary use case to reach critical mass.  People I
> know who use WhatsApp seem to have started using it to avoid per-text
> charges, not to get end-to-end encrypted messaging.  But now, even if
> Facebook's estimate [2] of 450 million WhatsApp users is 90% inflated,
> there are 45 million people using encrypted texting, which I would not have
> predicted.

I think the number is much higher than that due to Messsages+iCloud usage
by iPhone and other Apple products also constituting end-to-end encrypted
text.

Yep… Just a few years ago, nobody cared about end-to-end encrypted text,
today, still most people don’t know or care what it is, but I bet there are 
enough
people using it without even realizing to constitute “most” or something very
close to it. (Between Skype, WhatsApp, Messages/iMessage, and others).


Owen

Re: DNSSEC and ISPs faking DNS responses

[Owen DeLong]

> On Nov 14, 2015, at 04:34 , Roland Dobbins  wrote:
> 
> On 14 Nov 2015, at 19:07, Owen DeLong wrote:
> 
>> The point you seem to be missing is that your “until…” is already met.
> 
> Not AFAICT.  It isn't a default in the OS and on the window manager/home 
> screen.
> 
>> I know of at least one ISP that is providing CPE with VPN pre-configured and 
>> built in.
> 
> That makes one.
> 
>> I know of several other software/service solutions that are literally 
>> download-launch-subscribe. (download client software, launch installer, 
>> supply payment information for subscription).
> 
> The 'download' part is the main barrier to entry.

Trust me, this is not a significant barrier to entry. If it were, Chrome would 
be virtually unused except on Droid.

> 
>> You’re not looking at the right VPN software.
> 
> I look at VPN software all the time, from many providers.
> 
>> The built-in stuff is crap that is years behind the current state of the art.
> 
> My point is that it's in the OS.

Who cares?

That’s like saying that Nobody uses a different preference of web browser, they 
almost all stick to the one that comes with the OS.

If that were true, Firefox would only run on Linux and Chrome would only run on 
Chromebooks and Droids.

> 
>> More likely this is going to be iterations of what is already being more 
>> widely accepted. Downloadable pre-configured client software that works with 
>> a particular VPN service.
> 
> Again, downloading is a barrier to entry.  Don't you remember the browser 
> wars and the Microsoft anti-trust case?

I do. I also note that the issue there wasn’t merely that IE shipped with the 
OS, but the fact that you could _NOT_ extricate it from the OS and beyond just 
downloading another browser, it took significant knowledge to make that other 
browser the preferred browser on the system with any meaningful persistence.

>> Point-click-subscribe model seems to receive fairly wide adoption among 
>> people sufficiently interested in bypassing {insert network damage here} to 
>> pay a monthly fee for a service that will do it.
> 
> 'Sufficiently interested' is a limiting factor.  'Sufficiently interested' to 
> learn that such a thing is possible, and to figure out how to go about doing 
> it.

Among a given community it seems to only take a couple of individuals who 
figure it out once and if it is sufficiently easy to “show a friend” such that 
that friend finds it sufficientlly easy to teach others, adoption spreads quite 
rapidly through said community.

> Of course, the other concern is that governments which don't already 
> interfere with VPNs will outlaw VPNs in the name of 'national security'.  
> Answering my own question, the OS/device vendors won't get into the VPN 
> business due to this issue.

Sure, which is why FLOSS or off-shore subscription services will be the likely 
successful models here and so far, they are succeeding though not to the extent 
you might consider main stream as yet.

Owen

Re: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15

[Jeff Tantsura]

Been forever since i looked at cisco, however sounds like vc type mismatch. 
They used to have it as a platform capability, perhaps SW upgrade changed the 
default.

to my memory "show mpls l2 transport" should provide enough details.

Hope this helps

Regards,
Jeff

> On Nov 14, 2015, at 4:50 AM, Jonas Bjork  wrote:
> 
> Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer 
> voice and data traffic across our IP/MPLS core, and it is currently working 
> just fine. The first side consists of a Cisco 7600 router (rsp) and the other 
> one is an HP A5500-HI routing switch with full LER/E-LSR capability. At the 
> HP site, the tunnels are facing the access ports towards our premium 
> end-customers; and on the Cisco PE I terminate the tunnels on one of the 
> 2x10GE portchannel backbone links. There is vlan X on the HP side and vlan Y 
> on the Cisco side - vlan rewrite is working perfectly - as long as I use IOS 
> 12.
> 
> After upgrading the Cisco router software to IOS 15 the tunnels won't come 
> up. sh mpls l2 vc Y d says:
> ...
> Last error: Imposition VLAN rewrite capability mismatch with peer
> ...
> 
> I use almost exactly the same Cisco configuration before and after the 
> upgrade (only minor changes and nothing related to this) and I havn't touched 
> the HP. Apparently they don't talk the same L2PW language. I wonder though, 
> why now? We use service instances on the HP switchport as endpoint, we 
> initiate the targetted LDP session in addition to the pseudowire handshake 
> from a sub interface MPLS crossconnect. There is no MTU mismatch; not here - 
> not anywhere.
> 
> Anyone heard of this issue or experienced it?
> 
> Best regards,
> 
> Jonas Björk
> SNE, Europe/Sweden (hope you guys will help me anyway:)

Re: DNSSEC and ISPs faking DNS responses

[Sven-Haegar Koch]

On Sun, 15 Nov 2015, Roland Dobbins wrote:

> On 15 Nov 2015, at 2:25, John Levine wrote:
> 
> > They have point'n'click apps for all the usual platforms.
> 
> They are not defaults.
> 
> I think that many people on this list don't understand that the vast majority
> of users around the world do not know what a VPN is, do not know why they
> might need one, and aren't especially adept at installing applications, even
> from 'apps stores'.

Will everyone use VPN? For sure not.

But everyone that really wants to access something that he "should not" 
by local definition.

Like the kids in the neighbourhood - the firsts parents gets an invoice 
("Abmahnung" in German) for an illegal download of something done by 
the kid, and watch how fast it goes around all of them that you can 
avoid such costs (and more important the trouble with the parents) by 
just installing this "app".

Technical details do not matter, a big enough incentive to do 
something about it matters.

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

Re: DNSSEC and ISPs faking DNS responses

[Roland Dobbins]

On 15 Nov 2015, at 6:01, Larry Sheldon wrote:


in spite of your best attempts to prevent it.


My 'best attempts to prevent it'?

You're obviously addressing someone else.  I'm not trying to prevent 
anyone accessing anything.  On the contrary, I'm very much in favor of 
making applications and data and services available to people, and 
keeping them that way.


---
Roland Dobbins 

Re: DNSSEC and ISPs faking DNS responses

[Roland Dobbins]

On 14 Nov 2015, at 23:39, Royce Williams wrote:

Downloading is now much more common 2than during the age of the 
browser wars.


Sure, I understand that.



As of October 2014, 64% of American adults owned a smartphone [1].  
Phones

don't usually come with Candy Crush, but somehow, 93 *million* people
played it daily at one point.  They many not understand that when they
installed the app, they were "downloading" it.  But the end result is 
the

same.


Yes, because that leads to them doing something they want to be able to 
do, that is very tangible.  The same motivations spur VPN use (e.g., 
watching Netflix out-of-region, your example of the Olympics, and so 
forth).


To put that 93 million in context, the most recent estimates I can find 
of Internet users put their number at about 3.2 billion:




It sounds like we're arguing about the definition of the word "most".  
Your

thesis appears to be that most people won't use a VPN -- and you're
probably right.


Yes, we're in agreement.


But what everyone else is saying is that the value of
"most" is likely to shrink rapidly.


I don't know about that.  It seems to me that most people who're 
inclined to use a VPN are already using one.  Unless one believes that a 
relatively high percentage of people who don't yet have Internet access 
will become VPN users once they gain Internet access.


But now, even if Facebook's estimate [2] of 450 million WhatsApp users 
is 90% inflated,
there are 45 million people using encrypted texting, which I would not 
have

predicted.


Sure, and Apple iMessage is somewhat similar in that regard, though it's 
more susceptible to MITM.


Again, as compared to 3.2 billion.

Most of those users probably don't know what "encryption" is.  But 
they're

using it.


Sure, via http/s.  But VPNs used in the sense of this discussion tend to 
imply topological masking, as well.


---
Roland Dobbins 

Re: DNSSEC and ISPs faking DNS responses

[John Levine]

>Do you believe that percentage is going to significantly increase over 
>time?

What relevance does that have to gamblers using VPNs to circumvent
blocks?

R's,
John

Re: DNSSEC and ISPs faking DNS responses

[John Levine]

In article <339de9d9-f459-48e3-8d27-94eb76c90...@arbor.net> you write:
>On 15 Nov 2015, at 2:25, John Levine wrote:
>
>> They have point'n'click apps for all the usual platforms.
>
>They are not defaults.

The question at hand is whether gamblers faced with government
blocking would use VPNS to cirvumvent it.  Given that we have ample
evidence that gamblers elsewhere do exactly that, it's hard to imagine
why anyone would care that it's not the default.

R's,
John

Re: DNSSEC and ISPs faking DNS responses

[Roland Dobbins]

On 15 Nov 2015, at 2:08, Niels Bakker wrote:

When will there be enough 'corner cases' to convince you it's business 
as usual?


The majority of people who use the Internet in Turkey do not in fact use 
Google DNS.  It is an informed and motivated minority.


The most recent statistics I can find on estimation of global VPN use 
put the number at ~25% of Internet users.  That number seems high to me, 
and I've no confidence that the study in question was in fact conducted 
in a rigorous and scientific manner, so I won't link to it here.


But let's assume for the sake of discussion that it's reasonably 
accurate.


Do you believe that percentage is going to significantly increase over 
time?


---
Roland Dobbins 

Re: DNSSEC and ISPs faking DNS responses

[Larry Sheldon]

On 11/14/2015 16:56, Larry Sheldon wrote:

On 11/14/2015 16:48, Roland Dobbins wrote:

On 15 Nov 2015, at 2:25, John Levine wrote:


They have point'n'click apps for all the usual platforms.


They are not defaults.

I think that many people on this list don't understand that the vast
majority of users around the world do not know what a VPN is, do not
know why they might need one, and aren't especially adept at installing
applications, even from 'apps stores'.


It would be interesting to see a credible, referred study of this.

_I_ think the IT world continues to minimize and denigrate the abilities
and interests of its customers at its own, great peril.



Even if the mythical "where is the 'any' key" calls happen at a rate, 
globally, of one a minute, there are still tens of thousands of 
customers unheard-from who are devising ways to get their work done in 
spite of your best attempts to prevent it.


--
sed quis custodiet ipsos custodes? (Juvenal)

Re: DNSSEC and ISPs faking DNS responses

[Larry Sheldon]

On 11/14/2015 16:48, Roland Dobbins wrote:

On 15 Nov 2015, at 2:25, John Levine wrote:


They have point'n'click apps for all the usual platforms.


They are not defaults.

I think that many people on this list don't understand that the vast
majority of users around the world do not know what a VPN is, do not
know why they might need one, and aren't especially adept at installing
applications, even from 'apps stores'.


It would be interesting to see a credible, referred study of this.

_I_ think the IT world continues to minimize and denigrate the abilities 
and interests of its customers at its own, great peril.

--
sed quis custodiet ipsos custodes? (Juvenal)

Re: DNSSEC and ISPs faking DNS responses

[Roland Dobbins]

On 15 Nov 2015, at 2:25, John Levine wrote:


They have point'n'click apps for all the usual platforms.


They are not defaults.

I think that many people on this list don't understand that the vast 
majority of users around the world do not know what a VPN is, do not 
know why they might need one, and aren't especially adept at installing 
applications, even from 'apps stores'.


---
Roland Dobbins 

Re: DNSSEC and ISPs faking DNS responses

[Matt Palmer]

On Sat, Nov 14, 2015 at 05:32:41PM +1100, Mark Andrews wrote:
> In message <20151114044614.ga4...@hezmatt.org>, Matt Palmer writes:
> > On Fri, Nov 13, 2015 at 10:51:52AM +0100, Bj�rn Mork wrote:
> > > So what do we do? We currently point the blocked domains to addresses of
> > > a web server with a short explanation.  But what if the domains were
> > > signed?  We could let validating servers return SERVFAIL.  But I'd
> > > really prefer avoiding that for the simple reason that there is no way
> > > to distinguish that SERVFAIL from one caused by e.g. a domain owner
> > > configuration error.
> > 
> > Perhaps we need to expand RCODE to be the full octet, and indicate "blocked
> > for legal reasons" with RCODE value 25.
> 
> Rcode's were expanded to 12 bits back in 1999.  See RFC 2671.

I didn't feel it was worth looking beyond RFC1035 for an off-the-cuff joke.

- Matt

Re: DNSSEC and ISPs faking DNS responses

[John Levine]

In article  
you write:
>So when will we see CPE routers with built-in secure resolver and VPN
>client? Log in to 192.168.1.1 and select your country of the day from a
>drop down.

VyprVPN has a plug in for Tomato.

R's,
John

Re: DNSSEC and ISPs faking DNS responses

[John Levine]

>Until the setup and functionality are automagic, we're not going to see 
>broad use of VPNs by non-specialists.

I'm getting the impression you haven't yet gotten around to looking at
VPN applications intended for non-specialists.  Here's a good one to
start with:

https://www.goldenfrog.com/vyprvpn

They have point'n'click apps for all the usual platforms.  The free
level of service provides 500MB/mo, plenty for gambling.

If you haven't heard of Golden Frog, it is better known as Giganews.

R's,
John

Re: DNSSEC and ISPs faking DNS responses

[Niels Bakker]

* rdobb...@arbor.net (Roland Dobbins) [Sat 14 Nov 2015, 04:13 CET]:

On 14 Nov 2015, at 10:02, John Levine wrote:


People in New Zealand said differently.


This is a corner-case, however.


We can continue citing corner cases, like the % of people in Turkey 
who use Google DNS since their government started censoring web 
services like Twitter.  When will there be enough 'corner cases' 
to convince you it's business as usual?



-- Niels.

Re: Colo space at Cermak

[Nicholas Suan]

They made an announcement about it a while back:

http://boards.na.leagueoflegends.com/en/c/help-support/2uTrAyy8-na-server-roadmap-update-chicago-server-move-complete

On Sat, Nov 14, 2015 at 11:58 AM, Josh Reynolds  wrote:
> That's interesting news, how did you hear about that?
> On Nov 14, 2015 1:46 AM, "Ishmael Rufus"  wrote:
>
>> The company who has the worlds most played online multiplayer game moved
>> their servers to Chicago back in late August. Maybe that affected prices?
>>
>> On Fri, Nov 13, 2015, 12:45 PM Greg Sowell  wrote:
>>
>> > I would guess it has to do with competing with your landlord now.  I know
>> > it's starting to happen more and more.
>> >
>> > On Thu, Nov 12, 2015 at 8:32 PM, Mike Hammett  wrote:
>> >
>> > > Has something happened the past couple months to cause a quick shortage
>> > of
>> > > space at Cermak? I had an offer sent a few months ago (when I didn't
>> need
>> > > it) where a cab and five cross connects were cheaper than what five
>> cross
>> > > connects normally are, much less the cabinet value as well. Around that
>> > > time I think cabinets were going for $700 or so for basic
>> > primary\redundant
>> > > 20A. Now the cabinet is going for $1,800. It went from being the
>> cheapest
>> > > I've seen at Cermak to the most I've seen at Cermak in a matter of a
>> few
>> > > months. Two people with space in that building are citing an uptick in
>> > > demand. Really? That much of a demand increase with hundreds of
>> thousands
>> > > of square feet coming online in the Chicago metro?
>> > >
>> > > Can anyone corroborate that story or are they just making stuff up
>> hoping
>> > > I agree to inflated cabinet prices?
>> > >
>> > >
>> > >
>> > >
>> > > -
>> > > Mike Hammett
>> > > Intelligent Computing Solutions
>> > > http://www.ics-il.com
>> > >
>> > >
>> > >
>> > > Midwest Internet Exchange
>> > > http://www.midwest-ix.com
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> > --
>> >
>> > GregSowell.com
>> > TheBrothersWISP.com
>> >
>>

Re: DNSSEC and ISPs faking DNS responses

[Baldur Norddahl]

So when will we see CPE routers with built-in secure resolver and VPN
client? Log in to 192.168.1.1 and select your country of the day from a
drop down.

Regards

Baldur

Re: DNSSEC and ISPs faking DNS responses

[Stephane Bortzmeyer]

On Sat, Nov 14, 2015 at 01:36:06AM -0500,
 Jean-Francois Mezei  wrote 
 a message of 71 lines which said:

> Loto Québec is supposed to be testing for compliance, and I am not
> sure how they will do that short of having a subscription to every
> ISP that sells services in Québec.

They will simply use RIPE Atlas probes, as we all do to test our
networks from the outside.

Here, Bulgaria, where the mandatory blocking of gambling Web sites is
far from perfect (the right IP address is 5.226.176.16):

% python resolve-name.py --requested=500 --country=BG www.bet365.com 
Measurement #2930308 for www.bet365.com/A uses 94 probes

[] : 1 occurrences 
[193.24.240.122] : 1 occurrences 
[84.54.148.18] : 1 occurrences 
[212.73.128.166] : 1 occurrences 
[212.39.93.34] : 3 occurrences 
[ERROR: SERVFAIL] : 1 occurrences 
[5.226.176.16] : 75 occurrences 
[127.0.0.1] : 4 occurrences 
Test done at 2015-11-14T17:14:20Z

A few lying DNS resolvers but not much. 

> (Maybe they think they only have to test 3 ISPs, (telcos and
> cablecos) and don't realise they have over 100 ISPs to test for
> compliance).

My experience with these sort of organisations is that they don't care
about 100 % compliance. They're only interested in "good enough" (the
three largest ISPs...)

Re: Colo space at Cermak

[Josh Reynolds]

That's interesting news, how did you hear about that?
On Nov 14, 2015 1:46 AM, "Ishmael Rufus"  wrote:

> The company who has the worlds most played online multiplayer game moved
> their servers to Chicago back in late August. Maybe that affected prices?
>
> On Fri, Nov 13, 2015, 12:45 PM Greg Sowell  wrote:
>
> > I would guess it has to do with competing with your landlord now.  I know
> > it's starting to happen more and more.
> >
> > On Thu, Nov 12, 2015 at 8:32 PM, Mike Hammett  wrote:
> >
> > > Has something happened the past couple months to cause a quick shortage
> > of
> > > space at Cermak? I had an offer sent a few months ago (when I didn't
> need
> > > it) where a cab and five cross connects were cheaper than what five
> cross
> > > connects normally are, much less the cabinet value as well. Around that
> > > time I think cabinets were going for $700 or so for basic
> > primary\redundant
> > > 20A. Now the cabinet is going for $1,800. It went from being the
> cheapest
> > > I've seen at Cermak to the most I've seen at Cermak in a matter of a
> few
> > > months. Two people with space in that building are citing an uptick in
> > > demand. Really? That much of a demand increase with hundreds of
> thousands
> > > of square feet coming online in the Chicago metro?
> > >
> > > Can anyone corroborate that story or are they just making stuff up
> hoping
> > > I agree to inflated cabinet prices?
> > >
> > >
> > >
> > >
> > > -
> > > Mike Hammett
> > > Intelligent Computing Solutions
> > > http://www.ics-il.com
> > >
> > >
> > >
> > > Midwest Internet Exchange
> > > http://www.midwest-ix.com
> > >
> > >
> > >
> > >
> >
> >
> > --
> >
> > GregSowell.com
> > TheBrothersWISP.com
> >
>

Re: DNSSEC and ISPs faking DNS responses

[Royce Williams]

On Sat, Nov 14, 2015 at 3:34 AM, Roland Dobbins  wrote:
>>
>> More likely this is going to be iterations of what is already being more
widely accepted. Downloadable pre-configured client software that works
with a particular VPN service.
>
>
> Again, downloading is a barrier to entry.  Don't you remember the browser
wars and the Microsoft anti-trust case?

That was before the rise of the app.  Downloading is now much more common
than during the age of the browser wars.

As of October 2014, 64% of American adults owned a smartphone [1].  Phones
don't usually come with Candy Crush, but somehow, 93 *million* people
played it daily at one point.  They many not understand that when they
installed the app, they were "downloading" it.  But the end result is the
same.

Downloading is now a way of life -- and there are easily downloaded VPN
apps.  You don't have to know what a VPN is in order to use one.  Anecdote
!= data, but during the 2014 Olympics, Googling for "how to watch the
Olympics on the Internet" led many people I know to install one, without
asking me for advice like they usually do. :)

It sounds like we're arguing about the definition of the word "most".  Your
thesis appears to be that most people won't use a VPN -- and you're
probably right.  But what everyone else is saying is that the value of
"most" is likely to shrink rapidly.

And it may only take a secondary use case to reach critical mass.  People I
know who use WhatsApp seem to have started using it to avoid per-text
charges, not to get end-to-end encrypted messaging.  But now, even if
Facebook's estimate [2] of 450 million WhatsApp users is 90% inflated,
there are 45 million people using encrypted texting, which I would not have
predicted.

Most of those users probably don't know what "encryption" is.  But they're
using it.

Royce

1. http://www.pewinternet.org/fact-sheets/mobile-technology-fact-sheet/
2.
http://www.forbes.com/sites/georgeanders/2014/02/19/facebook-justifies-19-billion-by-awe-at-whatsapp-growth/

comcast metro-e questions

[Mike]

Hi,

Anyone here using comcast metro-e? I'd like to hear the good, bad 
and the ugly. I have a call in to sales but it being the weekend I won't 
be expecting a response, but I'm also wondering off the top of my head 
on general ballpark pricing for gigE?


Thanks.

Mike-

EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15

[Jonas Bjork]

Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer voice 
and data traffic across our IP/MPLS core, and it is currently working just 
fine. The first side consists of a Cisco 7600 router (rsp) and the other one is 
an HP A5500-HI routing switch with full LER/E-LSR capability. At the HP site, 
the tunnels are facing the access ports towards our premium end-customers; and 
on the Cisco PE I terminate the tunnels on one of the 2x10GE portchannel 
backbone links. There is vlan X on the HP side and vlan Y on the Cisco side - 
vlan rewrite is working perfectly - as long as I use IOS 12.

After upgrading the Cisco router software to IOS 15 the tunnels won't come up. 
sh mpls l2 vc Y d says:
...
Last error: Imposition VLAN rewrite capability mismatch with peer
...

I use almost exactly the same Cisco configuration before and after the upgrade 
(only minor changes and nothing related to this) and I havn't touched the HP. 
Apparently they don't talk the same L2PW language. I wonder though, why now? We 
use service instances on the HP switchport as endpoint, we initiate the 
targetted LDP session in addition to the pseudowire handshake from a sub 
interface MPLS crossconnect. There is no MTU mismatch; not here - not anywhere.

Anyone heard of this issue or experienced it?

Best regards,

Jonas Björk
SNE, Europe/Sweden (hope you guys will help me anyway:)

Re: DNSSEC and ISPs faking DNS responses

[Roland Dobbins]

On 14 Nov 2015, at 19:07, Owen DeLong wrote:

The point you seem to be missing is that your “until…” is 
already met.


Not AFAICT.  It isn't a default in the OS and on the window manager/home 
screen.


I know of at least one ISP that is providing CPE with VPN 
pre-configured and built in.


That makes one.

I know of several other software/service solutions that are literally 
download-launch-subscribe. (download client software, launch 
installer, supply payment information for subscription).


The 'download' part is the main barrier to entry.


You’re not looking at the right VPN software.


I look at VPN software all the time, from many providers.

The built-in stuff is crap that is years behind the current state of 
the art.


My point is that it's in the OS.

More likely this is going to be iterations of what is already being 
more widely accepted. Downloadable pre-configured client software that 
works with a particular VPN service.


Again, downloading is a barrier to entry.  Don't you remember the 
browser wars and the Microsoft anti-trust case?


Point-click-subscribe model seems to receive fairly wide adoption 
among people sufficiently interested in bypassing {insert network 
damage here} to pay a monthly fee for a service that will do it.


'Sufficiently interested' is a limiting factor.  'Sufficiently 
interested' to learn that such a thing is possible, and to figure out 
how to go about doing it.


Of course, the other concern is that governments which don't already 
interfere with VPNs will outlaw VPNs in the name of 'national security'. 
 Answering my own question, the OS/device vendors won't get into the 
VPN business due to this issue.


---
Roland Dobbins 

Re: DNSSEC and ISPs faking DNS responses

[Roland Dobbins]

On 14 Nov 2015, at 16:27, Owen DeLong wrote:


Today.


Yes, today, and tomorrow, and next week, and next month, and next year, 
etc.


Why on earth do you assume that this will not continue to expand 
and/or accelerate its rate of expansion as word spreads that it is 
possible?


Because it isn't a simple default.

If it ever becomes a simple default, we'll start to see greater 
adoption.  And probably not in the form of 'tunneling-everything' VPNs, 
but 'application VPNs' which automagically utilize SSL/TLS


---
Roland Dobbins 

Re: DNSSEC and ISPs faking DNS responses

[Owen DeLong]

> On Nov 14, 2015, at 03:11 , Roland Dobbins  wrote:
> 
> On 14 Nov 2015, at 16:05, Owen DeLong wrote:
> 
>> Lots of VPN services out there like the ones mentioned earlier in the thread 
>> have made it nearly as simple to install and operate a VPN.
> 
> Until the setup and functionality are automagic, we're not going to see broad 
> use of VPNs by non-specialists.

The point you seem to be missing is that your “until…” is already met.

I know of at least one ISP that is providing CPE with VPN pre-configured and 
built in.

I know of several other software/service solutions that are literally 
download-launch-subscribe. (download client software, launch installer, supply 
payment information for subscription).

> VPN functionality is built into pretty much every mainstream (and many 
> non-mainstream) OS out there, including mobile devices.  But it isn't 
> something that's simple; users have to at a minimum install and accept a VPN 
> profile, which means they have to go looking for a service in the first place.

You’re not looking at the right VPN software. The built-in stuff is crap that 
is years behind the current state of the art.

> I'm wondering if perhaps major OS vendors/developers may start 
> offering/OEMing VPN services, or at least distributing profiles in the same 
> way as browser vendors/developers distribute CA certs?

More likely this is going to be iterations of what is already being more widely 
accepted. Downloadable pre-configured client software that works with a 
particular VPN service.

Point-click-subscribe model seems to receive fairly wide adoption among people 
sufficiently interested in bypassing {insert network damage here} to pay a 
monthly fee for a service that will do it.

I think the going rate is something like $5/month for US VPNs last time I 
looked.

Owen

Re: DNSSEC and ISPs faking DNS responses

[Roland Dobbins]

On 14 Nov 2015, at 16:05, Owen DeLong wrote:

Lots of VPN services out there like the ones mentioned earlier in the 
thread have made it nearly as simple to install and operate a VPN.


Until the setup and functionality are automagic, we're not going to see 
broad use of VPNs by non-specialists.


VPN functionality is built into pretty much every mainstream (and many 
non-mainstream) OS out there, including mobile devices.  But it isn't 
something that's simple; users have to at a minimum install and accept a 
VPN profile, which means they have to go looking for a service in the 
first place.


I'm wondering if perhaps major OS vendors/developers may start 
offering/OEMing VPN services, or at least distributing profiles in the 
same way as browser vendors/developers distribute CA certs?


---
Roland Dobbins 

Re: DNSSEC and ISPs faking DNS responses

[Owen DeLong]

> On Nov 14, 2015, at 00:21 , Roland Dobbins  wrote:
> 
> On 14 Nov 2015, at 13:36, Jean-Francois Mezei wrote:
> 
>> With regards to VPNs: while they may not be very well known in the USA, they 
>> are outside the USA where many people need VPNs to access foreign content 
>> that is geoblocked in their home country.
> 
> I do not live in the United States; I live outside the United States, where 
> many expats and others want to access content from their home countries that 
> is 'geoblocked'.
> 
> The percentage of the Internet user population who use VPNs is tiny.  It is 
> growing a bit, but it isn't even a sizable minority.

Today.

Why on earth do you assume that this will not continue to expand and/or 
accelerate its rate of expansion as word spreads that it is possible?

There was a time when on-line download or streaming was dwarfed by DVDs and 
Blu-Ray sales.
There was a time when DVD/Blu-Ray/other digital formats didn’t represent even 
1% of the market vs. VHS.

This is a typical adoption rate issue.

If people want a functionality that is not currently available to them, they 
will adopt and adapt technology to meet that desire over time.

The adapt part is already mostly done with VPNs as has been pointed out. There 
are now GeoBlock Bypass services readily available and easily installable.

The next step will be growth in adoption. We’ve already seen this occur in NZ. 
Likely it will spread fairly quickly to other geographies subject to 
geoblocking.

It is unlikely to spread rapidly in the US because the US suffers from very 
little geoblocking or censorship in general. Likely the first major market 
where it will see very rapid adoption will be someplace like China where it can 
be used to circumvent a wide variety of government network restrictions.

However, if Quebec and/or NY manage to block gambling as they are currently 
attempting to do, it’s very likely that such services will also catch on 
quickly in those localities.

Owen

Re: DNSSEC and ISPs faking DNS responses

[Owen DeLong]

> On Nov 13, 2015, at 21:28 , Roland Dobbins  wrote:
> 
> On 14 Nov 2015, at 11:32, Owen DeLong wrote:
> 
>> Go out onto the street and ask a random number of people over 30 if they 
>> know what a URL is  and how to enter one into a browser.
> 
> They don't know what URIs are, nor do they enter them into browsers.  They 
> type words into a search engine and then click on the resulting links.

If that were true, billboards wouldn’t look like this:

http://worthwhileadvertising.com/wp-content/uploads/2010/11/Sandstone-billboard.jpg
 


(Note randomly chosen billboard image from google image search, not at all tech 
related and not in silicon valley.)

> 
> [I was shocked when I realized this is how non-specialists access Web sites, 
> about 15 years or so ago.]

I’m not surprised… It’s how I access about 30% of the websites I visit. Another 
50% or so come from bookmarks/browser history completion.
The remaining 20% are URLs I type.

> 
>> Today, the average 6 year old can operate a DirectTV satellite system with a 
>> relatively high degree of facility.
> 
> And has no idea how it actually works, and can't do anything with it beyond 
> the obvious.

Sure, but that’s also true of lots of VPNs that people use every day too.

The marketing people at Akamai use VPNs routinely. IT has it boiled down to 
Clicking an ICON in the menu bar and selecting “Akamai->Connect”.

Lots of VPN services out there like the ones mentioned earlier in the thread 
have made it nearly as simple to install and operate a VPN.

> 
>> What the average person knows changes over time.
> 
> Yes, but not in the way you're thinking.  If anything, specialized technical 
> knowledge tends to decrease over time, as technology goes from being used by 
> a relatively few self-selected enthusiasts to becoming more mainstream and 
> accessible to the masses.
> 
> Auto mechanics is one example from the physical world.  Cooking is another.  
> Handwriting is yet another.

Sure, but it used to be that setting up an internet connection on the average 
computer was a complex technical process that only a few could handle.

Today, we take having an internet connection on a system for granted.

Why couldn’t things get to a point where we take using VPNs for granted? It’s 
just a combination of software development and user acceptance.

I’m not saying everyone is going to learn how to configure an IPSEC SA set with 
tunnels on a Juniper. I’m saying that people will learn to use point-click-VPN 
software which already exists for the most part.

> 
>> Assuming that it does not strikes me as either (1) ignoring history
> 
> See above.

Most people know how to operate a microwave while few are gourmet chefs. 

I would argue that VPN technology is evolving (has evolved) to a point where it 
can be more like a microwave.

> 
>> or (2) underestimating the general public even more than I do, which is 
>> saying something.
> 
> Among the population of Internet users, the knowledge of how the Internet 
> actually works has decreased tremendously in the last 20 years, as that 
> population has expanded to include non-specialists - e.g., the majority.

Sure… Not particularly relevant to the discussion at hand, however.

> Most computer users have no idea how computers actually work.  They certainly 
> don't know what a VPN is, or how (or why) to set one up.  This state of 
> affairs will continue until VPN technology becomes subsumed into applications 
> and is enabled as a default, if it ever does.

Or until users discover that they can achieve something they want by installing 
a VPN application and using that, such as happened in New Zealand.

Will the understand how said VPN application works or why it makes what they 
want possible? No. Nor will they care. But they will care that it solves the 
problem of reaching their gambling sites despite the government interference or 
that they can use it to get to the Netflix version they want rather than no 
service in their locality or…

Many ways to skin a cat.

Owen

Re: DNSSEC and ISPs faking DNS responses

[Roland Dobbins]

On 14 Nov 2015, at 13:36, Jean-Francois Mezei wrote:

With regards to VPNs: while they may not be very well known in the 
USA, they are outside the USA where many people need VPNs to access 
foreign content that is geoblocked in their home country.


I do not live in the United States; I live outside the United States, 
where many expats and others want to access content from their home 
countries that is 'geoblocked'.


The percentage of the Internet user population who use VPNs is tiny.  It 
is growing a bit, but it isn't even a sizable minority.


---
Roland Dobbins 

Re: DNSSEC and ISPs faking DNS responses

[Roland Dobbins]

On 14 Nov 2015, at 13:38, Royce Williams wrote:

> They don't have to know what a VPN is in order to to use it -- and to pass
> it on to their friends.

That's still a very small proportion of the user base.

---
Roland Dobbins