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

mohamed.boucadair@orange.com Thu, 11 November 2021 15:45 UTC

Return-Path: <mohamed.boucadair@orange.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 39C9F3A0959; Thu, 11 Nov 2021 07:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, UNPARSEABLE_RELAY=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=orange.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 UcHNUoGjLHbh; Thu, 11 Nov 2021 07:44:57 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 C66FD3A08B6; Thu, 11 Nov 2021 07:44:56 -0800 (PST)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr21.francetelecom.fr (ESMTP service) with ESMTPS id 4HqmHq2s2Lz5wZR; Thu, 11 Nov 2021 16:44:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1636645495; bh=7BBIVtWxPYvRZPQfxShfwMyTYlzk5EbeOC7s3PKtSdY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=V7nDnz9FcgX68jUgCTQRw9G725/syDlpyiu1UBGSakToOH4+DNKcfSpRett5FNsFo 7PPhaL/Ks6thdN6bWXBMiqGg8lyYm4MZCqYbCYDsNT/BOlgajPAtOZ8PA4HDuaq/xP MgL+kETneB2sX9A9dIo0V0RkX+Apo9SdFSjz2UtYFOvAKb61C/e9oBLQiwAbqZqjGZ S2LQQeJJAU/ZACGlitl6NCBzOeap04vGT8kZxdI8lrWBtNSNMhoFe4d1pUkPMPUXer aPZYs4W4CbehN5JzkGPtOvPwzyGr5HW1+bLJQxbta4hZ9m94j9YNOMjqk2OQOyrcDO +a/iuIw7zUW1w==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 4HqmHq23p1zDq7W; Thu, 11 Nov 2021 16:44:55 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, Tero Kivinen <kivinen@iki.fi>, "ipsec@ietf.org" <ipsec@ietf.org>
CC: "draft-btw-add-ipsecme-ike@ietf.org" <draft-btw-add-ipsecme-ike@ietf.org>
Thread-Topic: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
Thread-Index: AQHX1wV/i4Q33A1l1EiWwu9gm8dljKv+dSYw
Content-Class:
Date: Thu, 11 Nov 2021 15:44:53 +0000
Message-ID: <14199_1636645495_618D3A77_14199_42_1_787AE7BB302AE849A7480A190F8B933035450019@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <24969.12660.103330.619294@fireball.acr.fi> <29541593-1A56-4B5D-901D-34B518CE72B9@apple.com>
In-Reply-To: <29541593-1A56-4B5D-901D-34B518CE72B9@apple.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-11-11T15:34:28Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=7c608d9f-ea76-4991-9d27-077c3c746800; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/WssncW33e_BH88k7uU_HcS8l52w>
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 15:45:01 -0000

Hi Tommy, 

All good points. Thanks. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : IPsec <ipsec-bounces@ietf.org> De la part de Tommy Pauly
> Envoyé : jeudi 11 novembre 2021 15:08
> À : Tero Kivinen <kivinen@iki.fi>; ipsec@ietf.org
> Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> 
> 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.

[Med] We will need to decide if we keep this as SHOULD/RECOMMENDED or use a strong language (MUST) as you suggest.  

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

[Med] Agree this should be better worded. The case we had in mind is when INTERNAL_DNS_DOMAIN is negotiated but INTERNAL_*_DNS attributes are not present. In such case, the name are resolved using ENCDNS_IP* servers. There is a MUST in RFC8598 that I do still think is problematic and need to be relaxed in the presence of ENCDNS_IP*. 

> 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
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.