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

Warren Kumari <warren@kumari.net> Wed, 21 November 2018 16:05 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5C8130DEE for <ipsec@ietfa.amsl.com>; Wed, 21 Nov 2018 08:05:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.458
X-Spam-Level:
X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRz1mhOH7pDV for <ipsec@ietfa.amsl.com>; Wed, 21 Nov 2018 08:05:17 -0800 (PST)
Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325D21277CC for <ipsec@ietf.org>; Wed, 21 Nov 2018 08:05:14 -0800 (PST)
Received: by mail-wr1-x441.google.com with SMTP id z5so1963371wrt.11 for <ipsec@ietf.org>; Wed, 21 Nov 2018 08:05:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0GyFhOuGjS7KFSZ2wNV9YOrTNxHFl01TWZ8f57XROGg=; b=qi4a/NswDb+qy1S/4GCAgu9JB/zX12HGZHAkjaaD0hlenxdf+TMGv6SFyYqeiF+ZLH j/34OANtTxYxVrtY2jPJP250B8iLPvi2vPRYPf2rVw+D6J/JHEbcwD6RlvidOiIX6rzR rglOXvDahwCfeqysennXtxmTkGvSgrgjd5VmUPLgUaWNiKVYE/af9pURxpWXBcLykrj9 Q5jyCshn4VkLIzCVCilkc50Fpa7Hc3WpaorWMXEjQz2+tbeRa16pGxR/F7SoLra5Nt+5 jWDpRVT5lZRUS5P8saZV1+4SUr3gh1kN4qjxcSsnJQWIz5zE29suCHRWdtsuYd6IOOt2 bKJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0GyFhOuGjS7KFSZ2wNV9YOrTNxHFl01TWZ8f57XROGg=; b=AUhgZk+zOH1nSxqlWHJc8jZz/rTA/fCgqh7sRgQpr1wwWH0LtCa1dH5Yt3q+r5t9Ju nxxHnLnefl/+m8TKOMRpQpyIHGexJTLAEPaMJcIQtC5OQpo3ybH1vVS6pX2Cq+g83+uy in+EeLW2KGzVhGOYoYvsI/OvBuSUT+0ZGmIxHuOjAGKQ4kSCznWn+SBeb9h6cleT25bK djSH34TUrt+gtHUMsxjBmoNN97422iFBFDOiSlOcOnDf9KFTrtTMRJ6/h9dHYZc7cqzR belMqS8Cd4ryVlYBWeCDaCrMe9u0vWz4Gx4yki3AP3DJWkOcHBmA4j/2mEnIbrZiuVwM WgeA==
X-Gm-Message-State: AA+aEWboeJ54GgiJnUlJ0k2NQsGFlSeVdHNvMAv6AgaNdxhZOKd2hjWE mANxPZ9tmFy5FS8f4XNIqxt2j/94WBy82ANLSuF3zA==
X-Google-Smtp-Source: AFSGD/XlzmO/XePEYV06omF03o/lEkwdZFk6/wG1tQZqBvM4nUeU1i9788LpBi1eZTm1wqkjukmOm2C8dpLVxXYd7C4=
X-Received: by 2002:a5d:4e82:: with SMTP id e2mr6208863wru.291.1542816312051; Wed, 21 Nov 2018 08:05:12 -0800 (PST)
MIME-Version: 1.0
References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <alpine.LRH.2.21.1811210006170.29140@bofh.nohats.ca> <CAHw9_iKyBpOa1ktYvDDvuHnN+nLN7GnP49PwdT6-FWqNzDrUgg@mail.gmail.com> <alpine.LRH.2.21.1811211012160.24767@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1811211012160.24767@bofh.nohats.ca>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 21 Nov 2018 11:04:34 -0500
Message-ID: <CAHw9_i+j92j4-DZHrL21CNkUFdheOO6z5+wfsG8Lrq1WorwnCw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: The IESG <iesg@ietf.org>, ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, "Waltermire, David A." <david.waltermire@nist.gov>
Content-Type: multipart/alternative; boundary="0000000000003bde3d057b2eea3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/ZIZC2QX3Uhmrq9DzVD_nFfON8M8>
Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2018 16:05:19 -0000

On Wed, Nov 21, 2018 at 10:20 AM Paul Wouters <paul@nohats.ca>; 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