Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
Tero Kivinen <kivinen@iki.fi> Sun, 19 March 2023 20:45 UTC
Return-Path: <kivinen@iki.fi>
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 179A5C14CE2C; Sun, 19 Mar 2023 13:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jESP5Ilo4Dpt; Sun, 19 Mar 2023 13:45:18 -0700 (PDT)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C101C14CE24; Sun, 19 Mar 2023 13:45:16 -0700 (PDT)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4Pfqcn26N5z49Q7N; Sun, 19 Mar 2023 22:45:12 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1679258713; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5HdUB0RhN4mQjl/4CiIdJUOAhyCpyEewumbegfL0VP4=; b=FNgm0DAPMTfmEgp1M4UoEYEI/PMAPmyeSc8PkO8FKEh3s6Fa5qCa/4Gf+67Y/uJ2QGhQ9O bu/RNqj66cTvrKkasbkAcaaReiIj6HFQCj/3dzLJaF4P0qPR+DdmRJbtirotjkieM7AqiU oSywtbdeUnjLfh42kbpW1IOepM3OhAS86yE9HZlzKaLnHiq3T1uT+IAeHqZhT11GJnGc2g VeamXdzdPbEFkkBhlTylqGzDWYWCLYazy/tXc7CaZqO7eSVXl/l8ESzoga+jJIeL9keX7p llkmM5fNDylD2i7C6dfx9dsbdW2Kw4L9jQFLOMRl4TI4EqgS1fEb5k1W4nSKHQ==
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1679258713; a=rsa-sha256; cv=none; b=BtIRQhTumAkMFMX+yCOXcnWnoKLQtF9B1UZ2IergI5BaIflAV4QgZCcByITAN7m3ME9UXo xxf1taVOG1HLns+PkHT7dT/HdlaKi2cqCbO3xCHuvuhEK6IG0uFBWsRvIVkgKexE+prOBQ hxcLx6cSJLFrPwNRCvtVVgx+Sn24pjnKO70joohqaOXAFqd3iXrEgcTNzWfkpRiNZpugD6 gxaIxIOOR1sJ11T8Fzr+A3czjI/idcAcwpbwx5pnyMQcWm6HuZF8cvSdTnR+aAcQIVAC4Y TLnF52wP52VWEGjUl0us97Cs1XlU5ZebQhvI4bpKCmEyTdqJP1wcb5kVmS0muw==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1679258713; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5HdUB0RhN4mQjl/4CiIdJUOAhyCpyEewumbegfL0VP4=; b=XkZ0KufRhYoPrJTkTCC/MlDeaFGU56J+b6ebEmYeeWYqBvruN9TM/ks8UASZMWbAx3xmnI gLNcSFnkTC6oafqvgDxJxN/HvywL7TQbeTtzXfZmRODSUnQIwOiO9m4iGUsxX9nURLtlqU E2grsFbNBSO+1xfsGzooMgUHXYZ+LQ3In9bgQfMx9WJRG1sFvk8voez9WEFTXCL2+grbHH qLLtk1yw7t8O0cgo49dfwhSR8RQsH0SCHBVmsVYdTTTG5G4WpGonG0TS38Cc6apg61vLo3 G3iYYqO8KsOhHsMjtZp8OCwCwyxL7s7qVBMgiK3OINgza7Rw6xPnsQqcbeCJNw==
Received: by fireball.acr.fi (Postfix, from userid 15204) id 5B81425C1302; Sun, 19 Mar 2023 22:45:11 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <25623.29783.272536.677272@fireball.acr.fi>
Date: Sun, 19 Mar 2023 22:45:11 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: mohamed.boucadair@orange.com
Cc: Patrick Mevzek <ietf-datatracker@ext.deepcore.org>, "dnsdir@ietf.org" <dnsdir@ietf.org>, "draft-ietf-ipsecme-add-ike.all@ietf.org" <draft-ietf-ipsecme-add-ike.all@ietf.org>, "ipsec@ietf.org" <ipsec@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
In-Reply-To: <5789_1679061595_6414725B_5789_369_2_6e1502201e0a4fe5a9175893f58b83d2@orange.com>
References: <167899946604.826.16271744983493705402@ietfa.amsl.com> <4399_1679049495_64144317_4399_388_1_6c866c11ab584e4d8158d5f8ded3ec3c@orange.com> <25620.27436.363210.343938@fireball.acr.fi> <5789_1679061595_6414725B_5789_369_2_6e1502201e0a4fe5a9175893f58b83d2@orange.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 13 min
X-Total-Time: 15 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/SmvuAZJK7BVN8O2zvmrdAQ0y3co>
Subject: Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 19 Mar 2023 20:45:21 -0000
mohamed.boucadair@orange.com writes: > > But my understanding is that this is not the case here, as if you > > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with > > ENCDNS_IP* to implementations supporting old RFC, > > [Med] Responders know when it will break. They will basically supply > the encrypted DNS to initiators who indicated support as per: > > Initiators first indicate support for encrypted DNS by including > ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders > supply encrypted DNS configuration by including ENCDNS_IP* attributes > in their CFG_REPLY payloads. > > If responders decide to ignore the capabilities of the initiators, > returning **only** the ENCDNS_IP* won't break only split horizon but > the full DNS service! I mean if initiator proposes: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() ENCDNS_IP6() ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) INTERNAL_DNS_DOMAIN() to indicate that it only wants to talk ENCDNS server, and it does NOT want to have normal DNS server, then responder who do not understand ENCDNS_IP6() will see that this is against MUST in RFC8598 and as there is no other error to use, it will most likely consider this a malformed message (==fatal error) and return with INVALID_SYNTAX. This will tear down the IKE SA and does not specify for the initiator why the connection attempt failed. Note, that RFC8598 says that responder must return INTERNAL_IP*_DNS if INTERNAL_DNS_DOMAIN is present, but if the initiator does not offer them it can't add them. Thats why it would be better for even those RFC8598 implementations which will not support this RFC to be modified so that they will understand ENCDNS_IP* at least so much that they understand that they can ignore INTERNAL_DNS_DOMAIN attribute if there is no INTERNAL_IP*_DNS, and but there is ENCDNS_IP* instead. If they simply ignore ENCDNS_IP* (is they should, as they do not understand), and they ignore the INTERNAL_DNS_DOMAIN also because there is no INTERNAL_IP*_DNS then the initiator will be able to connect. And then the initiator can later do another configuration payload to fetch normal DNS servers ip-addresses if those would be acceptable for it. Or, have I misunderstood the protocol somehow. I.e., what should old responder implementation do when it receives the request like above? -- kivinen@iki.fi
- [IPsec] Dnsdir last call review of draft-ietf-ips… Patrick Mevzek via Datatracker
- Re: [IPsec] Dnsdir last call review of draft-ietf… mohamed.boucadair
- Re: [IPsec] Dnsdir last call review of draft-ietf… Tero Kivinen
- Re: [IPsec] Dnsdir last call review of draft-ietf… mohamed.boucadair
- Re: [IPsec] Dnsdir last call review of draft-ietf… Tero Kivinen
- Re: [IPsec] Dnsdir last call review of draft-ietf… Valery Smyslov
- Re: [IPsec] Dnsdir last call review of draft-ietf… Tero Kivinen
- Re: [IPsec] Dnsdir last call review of draft-ietf… mohamed.boucadair
- Re: [IPsec] Dnsdir last call review of draft-ietf… Tero Kivinen