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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 21 November 2018 18:25 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 893C9130DDC; Wed, 21 Nov 2018 10:25:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 OdoEksXDZboR; Wed, 21 Nov 2018 10:25:32 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F11A1294D0; Wed, 21 Nov 2018 10:25:30 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 676B720089; Wed, 21 Nov 2018 13:25:25 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id D20A6BD3; Wed, 21 Nov 2018 13:25:29 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CFC5218B; Wed, 21 Nov 2018 13:25:29 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Paul Wouters <paul@nohats.ca>
cc: Warren Kumari <warren@kumari.net>, ipsec@ietf.org, The IESG <iesg@ietf.org>
In-Reply-To: <3A9700FB-EF0B-415B-9338-72070DE8A335@nohats.ca>
References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <25704.1542816043@localhost> <3A9700FB-EF0B-415B-9338-72070DE8A335@nohats.ca>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 21 Nov 2018 13:25:29 -0500
Message-ID: <31884.1542824729@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/hH9hueE445_Vb3dTkIXYgZ0nSZA>
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 18:25:33 -0000

Paul Wouters <paul@nohats.ca> wrote:
    >> Sadly, very few regular users use IPsec/IKEv2 for this kind of access.

    > This is very incorrect.

    > Almost all VPN providers for apple (OSX and iOS) use IKEv2 with
    > CP. Based on numbers of concurrent users I have seen from some vendors
    > using libreswan, we are talking in the orders of 100’s of thousands of
    > users.

That's awesome news to learn!!!
I haven't seen this in the wild myself, and it's not the case in Android as
you point out.

    > One of the main reasons: MOBIKE with phones using wifi and 4/5G and
    > network switching.

So that's a good really good result.  Kudos.
Sometimes the tortoise does win the race with better technology.

    > For Android, the situation is bad. Due to the OS not properly
    > supporting IKEv2, most VPN services bundle openvpn apps for android and
    > very few bundle strongswan with its userland ESP that can do IKEv2.

I'm aware that they (Android) were thinking about fixing this, but nothing
has happened yet to my knowledge.

    >> In almost all cases the VPN provider is in control of the software that is
    >> installed on the client system, so they can hijack paypal already.

    > This is also incorrect. All OSX and iOS provisioning happens via
    > .mobileconfig profiles or apps using apple API’s that are

I'm talking here about people using VPNConnect, OpenConnect, some .MSI that
actually installs OpenVPN on windows, etc.

    >> But, this seems terribly unlikely since just getting two VPNs installed
    >> (and compatible) and running at the same time is such deep VPN-fu, that it's
    >> like only half the IPsec WG members that could ever make this work anyway.

    > It is currently uncommon indeed but I think and hope we will see more
    > of this, especially when we all want a continuous VPN link up to our
    > home network.

I also want it to be easier.

I see IPv6 for the Enterprise remote-access VPN as instrumental to making
this happen.  Each Enterprise can embed their IPv4 RFC1918 address space into
a unique IPv6 prefix, and can NAT64 to get to actual internal legacy services
if they have to.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [




--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-