IETF Logo Mail Archive

Re: [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)

Paul Wouters <paul@nohats.ca> Wed, 21 November 2018 05:47 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 B2691124C04; Tue, 20 Nov 2018 21:47:23 -0800 (PST)
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 6hQMjgXuNfRz; Tue, 20 Nov 2018 21:47:21 -0800 (PST)
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 A292A12D4E6; Tue, 20 Nov 2018 21:47:21 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430BRX1qS0zLDZ; Wed, 21 Nov 2018 06:47:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542779240; bh=3vefl8zIbUgUSq4RP7vG1Ous4DVuFuxC+q8yj3nmLhA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Y8L6kcs47lcuH3s2d9MINYbNmBvSdhJKsATn7CL4pJHti9b3K4EbPu/rggAZN4aN5 qFRZCS24o6R+RVsoJfc6EY6slwtos9AC97BiKO+VxFjsWERU+1BQ89hdq0ZXxdmTVI tMFV4F8uCAPJjhURCOoSt4Wdck/BLD6mS7Cw3NBo=
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 HY9JAt04LBAs; Wed, 21 Nov 2018 06:47:18 +0100 (CET)
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, 21 Nov 2018 06:47:18 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id EEDE43797AD; Wed, 21 Nov 2018 00:47:17 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EEDE43797AD
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E2EB941C3B2E; Wed, 21 Nov 2018 00:47:17 -0500 (EST)
Date: Wed, 21 Nov 2018 00:47:17 -0500
From: Paul Wouters <paul@nohats.ca>
To: Ben Campbell <ben@nostrum.com>
cc: The IESG <iesg@ietf.org>, ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, david.waltermire@nist.gov
In-Reply-To: <154277111688.29795.6530139565050540963.idtracker@ietfa.amsl.com>
Message-ID: <alpine.LRH.2.21.1811210042170.29140@bofh.nohats.ca>
References: <154277111688.29795.6530139565050540963.idtracker@ietfa.amsl.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/6HPbiqesZsp_p8gZr9ZT-_tC6Vg>
Subject: Re: [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-split-dns-14: (with 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 05:47:24 -0000

On Tue, 20 Nov 2018, Ben Campbell wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - General: Once my client signals support for split DNS, what prevents a server
> from over claiming the domains that should be resolved via the private DNS
> servers? Perhaps for purposes of employee monitoring or censoring NTFW domains?
> (I've known some IT managers who would think that was a fine idea.)

Nothing prevents that. Just like they can run a transparent proxy on
port 53 to accomplish the same. When you install a split-tunnel VPN,
you place some trust in those enterprise administrators (forced or not)

Local policy might of course prevent it. Libreswan allows a client to
configure modecfdomains="redhat.com ibm.com" and when connected would
not send any DNS queries for catpictures.com to the internal DNS even
if the VPN server response contained an INTERNAL_DNS_DOMAIN for
catpictures.com.

> §6: "the IKE connection SHOULD only process
> the DNS information if the two connections are part of the same
> logical entity"
> How does a client determine the connections are part of the same logical
> entity? I can think of some ways, but I think the draft should be give some
> explicit guidance.

I think that would be very vendor specific. Some vendors might have
hierarchical structures so "Red Hat" can have two VPN connections,
others might just do it based on the same remote VPN server ID (eg
vpn.redhat.com)

I'll add some text similar to this.

Paul

>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

v2.23.0 | Report a Bug | By Email