Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09

Tero Kivinen <kivinen@iki.fi> Fri, 17 March 2023 13:29 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 7DE17C1516E9; Fri, 17 Mar 2023 06:29:26 -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 nLps8wiiWiVw; Fri, 17 Mar 2023 06:29:25 -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 639A8C14CEF9; Fri, 17 Mar 2023 06:29:22 -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 4PdQ2j6f6Tz49Q6s; Fri, 17 Mar 2023 15:29:17 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1679059758; 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=oBSV4+scyfUjtUPLUQKc92LXGtXk9A59v3z2EdDAtHg=; b=rGApTNCego46M3R7uAChYwK65juUMfP9A8h4pRv3ypZzY+QPdUoit1KYLby12+EH/oF36R y30iuKIEyQ1r/yU8hHRfLLioU/uslYmsojEBg9pS3b0qZPkBLQOgB+lBZBAzoIykx6Zmm6 ZQ8R8NbIsk4hEHsB4JuAe9InuxbLoKmfH3aMo5RHwji86pIARddFOmEfeGBPucSUHWL/sO +qau/iBzKLvgAgcoTKd6BMOheVYv8e1lLqXpO3hYtPR6m9SMSIb4VQ6CrwuBBhoU5lcbG/ xp3c4tUWwYI6lAgvqWnbBO4s+0ckKL5Q3FW8E9bEuGWHgPM7RZ3w9E91dENwsg==
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1679059758; a=rsa-sha256; cv=none; b=ufTc+y/FeBJyaCI3ABgkj78aV3AQNLdGH8RSqYS7NZ9x8i29vj4gO+5+Tf0oYQRVjrrvTy eueSiazb9q483TNEU+S8OZii4yymUPpM+8d+tRYWeNYGzw3J07ZbSScMh4swne37Qf8pQz 44sh7+vEwatJlsOzJcVNu/nha7f8SggjsfSg+MAjDaUJEtI09aWNYGZAbTM2PriIU2qnXI MXOBoaWzxZgIknTJOq8w5Pc6h/8GtpMYz6qeH+xgJlFQ2BqKAV5/uE1tS0t6ehZjSOUXON 3WemjRvKeXZCMyGV5k7bXgGqml/EtNjSslHj8sWvL34JJfgslEmeHAeB91rSgg==
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=1679059758; 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=oBSV4+scyfUjtUPLUQKc92LXGtXk9A59v3z2EdDAtHg=; b=roymh2STRSew/aSOCj5ExfK9J+cYOuWdm/VU+Jj9qK05FY9+GbsXh2O+MGrES+p6T6qIjT snBRjwZBYxqBNTFtoTdBu+LQRBgMTsvFeo9ZXSII3Ax3tNBnn0qI0IInfShq5UgwHBHZoG gTM/aYeJopUPClDA1ENSvQyG9izDWAZysIhrov1xUgkOMAB/qPXp7wXEqhZzkLb4EKKR/Y 18FAglhFpWTz2kAGuIZUb12JOJOq6hngJoGSOFR9gFEtLxWX9ugSMGRPHDWRBGDMXPdC63 1Q1fz3hdU6HBVra+7swdAK8OcsxJmNwglryqyVvhzu1XOPZgi+gjOE/sE/oqBA==
Received: by fireball.acr.fi (Postfix, from userid 15204) id 9C41425C12B3; Fri, 17 Mar 2023 15:29:16 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <25620.27436.363210.343938@fireball.acr.fi>
Date: Fri, 17 Mar 2023 15:29:16 +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: <4399_1679049495_64144317_4399_388_1_6c866c11ab584e4d8158d5f8ded3ec3c@orange.com>
References: <167899946604.826.16271744983493705402@ietfa.amsl.com> <4399_1679049495_64144317_4399_388_1_6c866c11ab584e4d8158d5f8ded3ec3c@orange.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 12 min
X-Total-Time: 13 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/N4TJu8VMdY7vXooO4Kb1JSq9ckg>
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: Fri, 17 Mar 2023 13:29:26 -0000

mohamed.boucadair@orange.com writes:
> > At the IETF process level, which I don't master, because of last
> > note in §4, shouldn't that document explicitly say it updates
> > RFC8598?
> 
> [Med] We discussed this point at the time (and I was personally for
> adding the header), but we didn't because the convention in ipsecme
> WG is to not add the Update header if implementations are clearly
> able to distinguish the cases when an extension is being used even
> if the extension would change the behavior defined in the existing
> RFCs. In this spec, if the initiator receives any of ENCDNS_IP*
> attributes, it will know that it should not expect the
> INTERNAL_IP*_DNS even if it receives INTERNAL_DNS_DOMAIN too. The
> note you are referring to is to make that clear.

I think we usually use updates header if implementations supporting
old RFC but not this, needs to change their behavior.

I.e., if we just add new attributes, and the implementations of old
RFC simply ignore them then everything is fine.

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, then that RFC will consider this
as a fatal error, and tear down the whole IKE SA, instead of silently
ignoring ENCDNS_IP* and INTERNAL_DNS_DOMAIN attributes.

So in this case it would be better for the old Split DNS Configuration
for IKEv2 RFC8598 implementations to be changed in a way that they
recognize this situation and do not consider it as a fatal error.

Update to the RFC8598 would not be needed if the RFC8598
implementations would simply ignore both the INTERNAL_DNS_DOMAIN and
ENCDNS_IP* in configuration payload, but I do not think that is the
case here.

So question is not whether it is possible to recognize the situation,
it is what happens when you combine new and old implementations. If
things works without a need to change old implementations then no
updates is needed, if you need to update the old implentations too,
then you do need updates header.
-- 
kivinen@iki.fi