Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike

Tommy Pauly <tpauly@apple.com> Thu, 11 November 2021 14:08 UTC

Return-Path: <tpauly@apple.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 69DD43A1028 for <ipsec@ietfa.amsl.com>; Thu, 11 Nov 2021 06:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 y9Gw9Erd-KSV for <ipsec@ietfa.amsl.com>; Thu, 11 Nov 2021 06:07:57 -0800 (PST)
Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.rno.apple.com [17.179.253.43]) (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 D81563A1072 for <ipsec@ietf.org>; Thu, 11 Nov 2021 06:07:46 -0800 (PST)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 1ABDwWdc003357; Thu, 11 Nov 2021 06:07:45 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=LnklWQVh8mGcVgqUu3BUtNoonzOYyEtobU60y1N8zB8=; b=Q+DemDVXtLrhCJNdRqnNLa0ZoZo8h2ttBZ0rjlXstaauSeTDqFBfqL3xwQBpkHMLvhvx AUwSys+Hi/vTTtwMOj3AQuHzFoY1Th/6WubZey/hkAYLbCXvNVwnD+UasA6fxwNnHSGJ b07zz80+0gRL7D7NGxNTLjsfRgsVzlHLucKKHGzfA5rUKWNKtnsLimRRGsOHhNMnAgjT 4SdmWhPGnrkyZpE7G+ZUOwU1UXdZ1EUrO5ZY5OKP8seGzLHxlN4VNj4VQE2L34U4YnUT VSMQpAhDyKl+jhmjvbyFPy2mSf8iHdyYFDRIa4lVOreIwZek4us3Sg8r15mYyxmFCbM7 Uw==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 3c5nj3wu4x-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Nov 2021 06:07:45 -0800
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R2E00YO9V8XTTJ0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Thu, 11 Nov 2021 06:07:45 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R2E00Z00UWCT700@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 11 Nov 2021 06:07:45 -0800 (PST)
X-Va-A:
X-Va-T-CD: cf7e0357b20545b517018a619dbaf7f7
X-Va-E-CD: 7939f63a1d60e7efe40ccdd3a7eaf69b
X-Va-R-CD: 06f5e98e649719a03016a26cc856a1dd
X-Va-CD: 0
X-Va-ID: fe462f6e-731d-4819-ba27-4113a1519d33
X-V-A:
X-V-T-CD: cf7e0357b20545b517018a619dbaf7f7
X-V-E-CD: 7939f63a1d60e7efe40ccdd3a7eaf69b
X-V-R-CD: 06f5e98e649719a03016a26cc856a1dd
X-V-CD: 0
X-V-ID: 4fc41bae-a062-4120-a13d-b6047944b93c
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-11_04:2021-11-11, 2021-11-11 signatures=0
Received: from smtpclient.apple (unknown [17.11.43.77]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R2E00MF3V8WK500@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 11 Nov 2021 06:07:44 -0800 (PST)
From: Tommy Pauly <tpauly@apple.com>
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\))
Date: Thu, 11 Nov 2021 06:07:44 -0800
References: <24969.12660.103330.619294@fireball.acr.fi>
To: Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org
In-reply-to: <24969.12660.103330.619294@fireball.acr.fi>
Message-id: <29541593-1A56-4B5D-901D-34B518CE72B9@apple.com>
X-Mailer: Apple Mail (2.3691.0.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-11_04:2021-11-11, 2021-11-11 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/TJtDkBOQ68q4xoF17bq0UCOveVM>
Subject: Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
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: Thu, 11 Nov 2021 14:08:01 -0000

I support adoption of this work. The mechanism of specifying the authentication domain name and service parameters is sound, and the right direction.

I do agree with Paul Wouter’s comments, and I think the parts of the document that deal with requirements for config requests need work. Ideally, this doesn’t need to update split-DNS, but instead just reference the fact that the encrypted resolvers MUST always be preferred when present.

The text also needs to be careful about not over-mandating behavior. For example, the text currently says the following:

   If the IPsec connection is a split-tunnel configuration and the
   initiator negotiated INTERNAL_DNS_DOMAIN as per [
RFC8598
], the DNS
   client MUST resolve the internal names using ENCDNS_IP* DNS servers.

RFC 8598 has a bit more leeway, explaining that there may be some domains that are prohibited by local policy from being claimed by the IKE tunnel. This needs to be maintained.

For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that is not
   prohibited by local policy, the client MUST use the provided
   INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only
   resolvers for the listed domains and its subdomains, and it MUST NOT
   attempt to resolve the provided DNS domains using its external DNS
   servers.

Best,
Tommy

> On Nov 8, 2021, at 6:17 AM, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> This is the start of 2 week WG adoption call for this document, ending
> 2021-11-22. Please send your reply about whether you support adopting
> this document as WG document or not.
> -- 
> kivinen@iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec