IETF Logo Mail Archive

Re: [IPsec] draft-pauly-ipsecme-split-dns

Eric Rescorla <ekr@rtfm.com> Wed, 20 June 2018 05:23 UTC

Return-Path: <ekr@rtfm.com>
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 368AE131032 for <ipsec@ietfa.amsl.com>; Tue, 19 Jun 2018 22:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 o4q2JnSIf_XF for <ipsec@ietfa.amsl.com>; Tue, 19 Jun 2018 22:23:20 -0700 (PDT)
Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (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 B38AC13103F for <ipsec@ietf.org>; Tue, 19 Jun 2018 22:23:20 -0700 (PDT)
Received: by mail-ot0-x244.google.com with SMTP id p95-v6so2348858ota.5 for <ipsec@ietf.org>; Tue, 19 Jun 2018 22:23:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eBLdzwzBi0kK0pMH+Bv5JNwje3c10cc4qnqQZnHoAPM=; b=qlsNrb6Zcbry4dVg1PEvRyisi9suh0BmoqU1A3SfPtBzcYq6VbrWrShoi6Ef6r9ijB ItTrS7XDv9Tt4k0M8Revn2VIebXWJQXF3aOOxoVvqye/ikeHbIyJqJmWFAGeaAsmZ9w8 AaDnGm/GtRBKsWQy6Lh44D8HnR6PZbmQ5XPmRX66SPc4qfdUc5otNatx3PGAqXrxkKah q+l08XRJqHSboI/BnLoRxaoa6Nz9loQMRzSWkd6KwQ2t8OOMK0lB6tdO2UXrSqLXXZLS ZlH1bgmXqjDDV8T2fL/bTz3j+DG/riSuCdchsgiIkQGAGc6EtVR4RG98AuYgyWkjM/Pw WYWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eBLdzwzBi0kK0pMH+Bv5JNwje3c10cc4qnqQZnHoAPM=; b=hkyQJrRR5nH7CM+iNyttOkMBCXs61jzOypPabJcEHYstxWE6leANAw+gPEhHxCgtV/ slrzZ+cfPirZfWrdiOOiwjZ5K1THOXPBa/FM+YyTaoEz3zJFsBKsxG2NUNsuKs+i2Ajb TEAHef3w/6j2DNdOIe2Tux/4L9l/+Rx4vy+pyOVEkOcOG5v866Y8zpyv16BrbVmJ86ci UdQcAzrdlRa+LqucML/Lh8rwL8/EgiVZG3oLOCMSCMr1OM6JF/z9PxFfn2JaI8/az2Rv Y1ij9toF1eqURXvK6EtjWkq5KmyhLz5xifbnPn6nVmP1TYEFyvdB1MCJJfKo4GdDuYPI S+Xw==
X-Gm-Message-State: APt69E0Cl5eD5Mip74L+eyt1D7AAjI6vyriW1ltx6SdNm1WqcxazjIXy j+RGuFSVm5ywQU2v9+vj70XA60s5D01dAER++N/gQ8o23tPlWA==
X-Google-Smtp-Source: ADUXVKKf+H0dijawy5GNy8XiXgKkNB0Bz2ue2F/4MUQ0Lmq8ToZ2jYvQImdmJDoApOCX8axAiRwCT5J65KS7foDVUFo=
X-Received: by 2002:a9d:2f45:: with SMTP id h63-v6mr13016871otb.371.1529472200104; Tue, 19 Jun 2018 22:23:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 22:22:39 -0700 (PDT)
In-Reply-To: <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> <alpine.LRH.2.21.1806200002340.18235@bofh.nohats.ca>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 19 Jun 2018 22:22:39 -0700
Message-ID: <CABcZeBPbq9ga8oSQ09GLyonPgZLOpFAy9hDJYAagUFz7GSHEoQ@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
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>
Content-Type: multipart/alternative; boundary="0000000000002e77a0056f0bff89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/yJuczR7uG5BUzBmiUCfgoEB_WII>
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 05:23:24 -0000

On Tue, Jun 19, 2018 at 9:38 PM, Paul Wouters <paul@nohats.ca> wrote:

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

Yes, that's technically true, but the question is whether it's in fact
practical for people to do that. I'm sorry to repeat myself, but once
again the document clearly states that this can happen:

   In most deployment scenario's, the IKE client has an expectation that
   it is connecting, using a split-network setup, to a specific
   organisation or enterprise.  A recommended policy would be to only
   accept INTERNAL_DNSSEC_TA directives from that organization's DNS
   names.  However, this might not be possible in all deployment
   scenarios, such as one where the IKE server is handing out a number
   of domains that are not within one parent domain.

Is that text wrong? If not, I suspect we're just quibbling about "common".

-Ekr

v2.23.0 | Report a Bug | By Email