Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT)

[Warren Kumari <[e-mail]>]

On Wed, Nov 21, 2018 at 10:20 AM Paul Wouters <[e-mail]> wrote:

> 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.


So, what my (OpenVPN) client seems to do is send:
193.111.157.66 <-> 0.0.0.0/1
193.111.157.66 <-> 128.0.0.0/1

This "overrides" my default of 0.0.0.0/0, and (depending on how you read
things) could be considered a split tunnel, but with both sides routed
through the tunnel.
You could also do silly things like:
193.111.157.66 <-> 0.0.0.0/1
193.111.157.66 <-> 128.0.0.0/2
193.111.157.66 <-> 192.0.0.0/3
193.111.157.66 <-> 224.0.0.0/4
(I think that this covers basically all space except 240.0.0.0, but I
haven't had any coffee yet).


> 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.


Well, if you removed the DNSSEC_TA bit, and expected enterprise tools to do
this through "normal" enterprise tools methods this would work.
(It started writing that the zone could also be unsigned, but that
obviously doesn't work in the case of non-delegated "TLDs"...)

W



> But in the end, it all depends on
> how badly you want your VPN service to see cute kittens.
>
> Paul
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf