On Wed, 21 Nov 2018, Warren Kumari wrote:
Yes, I get that the *intended* audience is Enterprises, and that usage doesn't really scare me (most enterprise admins already have their fingers sufficiently deep inside their employees machines that they can do $whatever anyway). My concerns is that this will also be used for the "Buy our VPN for secure browsing of the torrentz - only $2.99 per month. Punch the monkey for a discount!!!!!!!!!!" type people -- I trust my enterprise admins to not DNSSEC / DANE poison me, but I don't necessarily trust (to pick at random) CyberGhostVPN - https://offer.cyberghostvpn.com/en_US/trnt/rocket?aff_id=1392&coupon=FlashSale2&aff_sub4=FlashSale2&; (I know nothing about this org!)
These VPN services need to take ALL your network traffic. We now more explicitly state INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA MUST be ignored when the VPN configuration is not a split tunnel one. This can still be abused by VPN service providers but it would require some serious hacking since most remote access profiles will only offer to set a source/dest IP tunnel for YourTempAssignedIP/32 <-> 0.0.0/0 That is, if you connect to vpn.nohats.ca, it will give you 193.111.157.66 as INTERNAL_IP4_ADDRESS and the IPsec policy will cover 193.111.157.66/32 <-> 0.0.0.0/0 only. In which case our new attributes are ignored. They could do something like: 193.111.157.66/32 <-> 0.0.0.0/128 to get their attribute accepted, but the VPN would not work for half the internet. Of course, if their only goal is to screw you over and get your gmail.com traffic on 172.217.1.165, then giving you 172.217.0.0/16 would work and all your other traffic would simply go out in the clear. And if you accept their provisioning profile, they could also override TLSA records. We tried to close all of this as much as possible so that you can still use enterprise split tunnel with DNS while making it as hard as possible for VPN services to not abuse this. But in the end, it all depends on how badly you want your VPN service to see cute kittens. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
