Re: [IPsec] draft-pauly-ipsecme-split-dns
Paul Wouters <paul@nohats.ca> Wed, 20 June 2018 04:38 UTC
Return-Path: <paul@nohats.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 8440E130EBA; Tue, 19 Jun 2018 21:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 BjeO3UBsrR_R; Tue, 19 Jun 2018 21:38:28 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614F1130EA1; Tue, 19 Jun 2018 21:38:28 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419XC425mbz1rR; Wed, 20 Jun 2018 06:38:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529469504; bh=U/gQv2FLM2Pkcp2gSqUTjM1UX1p3N3LI3UKAUpWxRRI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZCc3/G0o1dzzv8b/tHcjwMVYGVFPY81VSg2jckFbWUDZR1ylOEf2jXFkgBfS2Qcru hSD6kePEOd62DLJ9+P3JrqQgc44PaUE5h0Ps7Yd203/a4l+GvZvLLAYqZaym/eJK1Z pEv9ZtvKTjoYvveh+qDgPomkEUtOh/j46Ts+yT/0=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KScRue7nWyLV; Wed, 20 Jun 2018 06:38:22 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Jun 2018 06:38:21 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 92C1F4FB769; Wed, 20 Jun 2018 00:38:20 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 92C1F4FB769
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8C41E4023307; Wed, 20 Jun 2018 00:38:20 -0400 (EDT)
Date: Wed, 20 Jun 2018 00:38:20 -0400
From: Paul Wouters <paul@nohats.ca>
To: Eric Rescorla <ekr@rtfm.com>
cc: Nico Williams <nico@cryptonector.com>, IPsecME WG <ipsec@ietf.org>, "draft-ietf-ipsecme-split-dns.all@ietf.org" <draft-ietf-ipsecme-split-dns.all@ietf.org>, "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>, Tero Kivinen <kivinen@iki.fi>
In-Reply-To: <CABcZeBNmavpZvzNRZBdOTKQYZ=yW=y2poaoVtsOeESNyRrG15Q@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1806200002340.18235@bofh.nohats.ca>
References: <alpine.LRH.2.21.1806181702230.13143@bofh.nohats.ca> <CABcZeBOa8qMhDyCMzPTAtUBZTYPGehrhPrr6h4cVCjP4QZ1+Ew@mail.gmail.com> <alpine.LRH.2.21.1806191109300.16269@bofh.nohats.ca> <CABcZeBPFw1iuHXV+_sEuMaRCYRSk1nH_FujeimOb=ViEAtvkVA@mail.gmail.com> <alpine.LRH.2.21.1806191159310.26059@bofh.nohats.ca> <CABcZeBN2HwiwVzAUjyZU+Q+toFM2jOKHD9xmKwM1V5qhUoULEQ@mail.gmail.com> <20180619183459.GC4218@localhost> <CABcZeBPh33RMWy=pWVSWPp9cDrzrRrVQXgw1BKPLy_W0_Wrdgg@mail.gmail.com> <20180619224651.GD4218@localhost> <CABcZeBObub+rYYURt9SSumYqqWGxDMqhOG64oA+979n=mduXMw@mail.gmail.com> <20180619230148.GE4218@localhost> <CABcZeBNmavpZvzNRZBdOTKQYZ=yW=y2poaoVtsOeESNyRrG15Q@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/d0v92XHlzKalx06lKn4pCXE-4m8>
Subject: Re: [IPsec] draft-pauly-ipsecme-split-dns
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.26
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, 20 Jun 2018 04:38:31 -0000
On Tue, 19 Jun 2018, Eric Rescorla wrote: > I'm asking if a common scenario will be that users of enterprise > VPNs who implement this feature will end up in a situation where the > VPN can impose TAs for any domain. I explained before that I think "for any domain" can be strictly limited on the client side, either by preconfiguration or by confirmation on the VPN client side. In IKEv1, the XAUTH attribute relaying the domain name typically only appears once. When checking the Cisco documentation, I see: domain name Example: Router (config-isakmp-group)# domain cisco.com Specifies the Domain Name Service (DNS) domain to which a group belongs. This does not suggest that there can be more than one. So my educated guess here is that implementations in IKEv1 typically did not support setting more the one domain name (we only support sending and receiving one). Note that the _use_ of the domain name attribute in IKEv1 is a bit unclear. Is it to be used only for resolv.conf style search lists, or was it to constrain the domain(s) that should be looked up with the supplied nameserver IPs? Again speaking for our implementation, if we detect a local DNS server running, we use the domain name and the obtained nameserver IPs to reconfigure the DNS server to add a forward for only this domain name via these nameserver IPs. If we did not find a local DNS server running we will add the domain to the search option in /etc/resolv.conf and prepend the nameserver IPs to /etc/resolv.conf. (and on termination of VPN, we restore the old resolv.conf) So I think most Enterprise configurations will only use one domain, but most likely still expect the client to give them all DNS traffic so they can just take over or make up any domains they want. With more validating (stub) resolvers on devices, this will become more problematic over time, and I suspect these networks will have to consolidate things under their own internal domain. Because even if the VPN will allow multiple domains via this draft, wifi and LAN connections don't support this. > As a followup question, I claim that that's not presently true with > existing VPNs. In some cases, the VPN requires you to install > a new trust anchor in order to accept its cert, but that's not an > inherently necessary practice. Note that the VPN server authentication is not under discussion here at all. I'm not sure why you keep bringing this up. You almost certainly will need to install some local webpki trust anchor to make use of your internal TLS servers reachable via the IPsec VPN. For example, to reach any of our internal redhat servers over HTTPS, I need to install a redhat internal CA into my system/browser. I believe this is extremely common (although I do hope it is less common to give these internal CA's the CN="Certificate Authority") Paul
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Tero Kivinen
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Tero Kivinen
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Benjamin Kaduk
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Nico Williams
- Re: [IPsec] draft-pauly-ipsecme-split-dns Paul Wouters
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Eric Rescorla
- Re: [IPsec] draft-pauly-ipsecme-split-dns Tommy Pauly
- Re: [IPsec] draft-pauly-ipsecme-split-dns Benjamin Kaduk