Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes

Paul Wouters <paul@nohats.ca> Thu, 02 May 2019 18:25 UTC

Return-Path: <paul@nohats.ca>
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 527D1120075 for <ipsec@ietfa.amsl.com>; Thu, 2 May 2019 11:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 qE2m9zmf9hLr for <ipsec@ietfa.amsl.com>; Thu, 2 May 2019 11:25:16 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 E5960120099 for <ipsec@ietf.org>; Thu, 2 May 2019 11:25:15 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44w3bF3dXNzKyp; Thu, 2 May 2019 20:25:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1556821513; bh=tK6vYgxJwSjJ+zRwoPzuXhB5B+5uBuVcGuUwJz0v2AI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gRAs/E8QvdjXO0d2OmXlzoot1t/rzhjSttl/JxKS2OpkWPqsD3eoaTWpb1VPTDPem KnsyIYbfDBr+TfsWjgbr3cCvIb9UaAdi+HOv/U2QzuYhO3wo7zFB06pWltDiUrCuiF J7QAkQX6aP7PxW2yx5cEYf5Y+DkVb8m7f4IgP9tM=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Z4nOmkFUfuG4; Thu, 2 May 2019 20:25:11 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 2 May 2019 20:25:11 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 855C23A797B; Thu, 2 May 2019 14:25:10 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 855C23A797B
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7880E4027A8E; Thu, 2 May 2019 14:25:10 -0400 (EDT)
Date: Thu, 02 May 2019 14:25:10 -0400
From: Paul Wouters <paul@nohats.ca>
To: mohamed.boucadair@orange.com
cc: "ipsec@ietf.org" <ipsec@ietf.org>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA67EB7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Message-ID: <alpine.LRH.2.21.1905021420360.1269@bofh.nohats.ca>
References: <23734.7331.402882.289451@fireball.acr.fi> <01b201d4f4f1$e617eb90$b247c2b0$@gmail.com> <636D1D4B-3E3F-47F1-B64C-A266BF871010@nohats.ca> <787AE7BB302AE849A7480A190F8B93302EA67B69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <alpine.LRH.2.21.1904300938050.17071@bofh.nohats.ca> <787AE7BB302AE849A7480A190F8B93302EA67EB7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/iqp9RNFxxPhpK_A4lnoygKfIW7s>
Subject: Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
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, 02 May 2019 18:25:19 -0000

On Tue, 30 Apr 2019, mohamed.boucadair@orange.com wrote:

>> Why would the initiator that is allowed by policy to do both v4 and v6
>> not ask for both at once?
>
> [Med] I do fully agree that requesting both when supported would be straightforward, but I'm afraid that some implementations may not follow that behavior.

Do we currently have a large scale implementation issue, or are you
predicting that this may happen in the future. While I am okay with
doing it if it fixes a large deployment issue, I'm not okay with it
to pre-emptively support expected implementation issues.

>  Such implementations may do that:
> * for arbitrary reasons given that existing specs do not forbid such separate requests.

So what is the problem with bad implementations doing bad things? Why
would this notify tell them to do things differently next time?

> * or, in some contexts such cellular devices, mimic a similar behavior for requesting separate PDP contexts instead of a dual-stack one.

Is this actually happening at scale, or is this just a feared bad way
things will get implemented?

>> I don't see the "use of separate requests" as a real use case. Can you
>> explain how this would actually happen in a real world?
>
> [Med] See the cases above. There is also the case of a responder that wants (for policy reasons) requests to be made as separate IKE SAs. For this case, requests will need to be done separately.

If the "policy reason" is there, why would a notify change their
behaviour? If they are already sending a v4 and a separate v6
request, what value does the notify add?

Paul