Re: [IPsec] Lars Eggert's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)

Valery Smyslov <smyslov.ietf@gmail.com> Tue, 01 March 2022 15:24 UTC

Return-Path: <smyslov.ietf@gmail.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 A5F763A0B6D; Tue, 1 Mar 2022 07:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sjPIkuZLeIG8; Tue, 1 Mar 2022 07:24:46 -0800 (PST)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 1A05A3A0B6B; Tue, 1 Mar 2022 07:24:46 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id v22so22330858ljh.7; Tue, 01 Mar 2022 07:24:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=+mHWKSk3Qzxd3EMx0Ps+LWHfz/2PUPg2dTUT/Y9amdI=; b=kWsZsiEiH4C5zx959QUG4s3o1yDdIcnkVHxicIZ0lYJSoRGxLKZp9a1q61KKU8xyKw mmA9KfiXp+nL9qux+7M+9n4dEU81ZsJNCpxdqnrkbtElXWfAGl/kQ+zBqHyqB60LCe2i 0RbAct6D/uHA23MUUKcuwZtLL8GeR304Brm7TNW+nJJzPPT/Ez1eLv57TxM92fpj+igh trgwePPNl8xRhu6Doa4UW169kyJVyCW2MgN3NRS8TAWJdAbcE+GmayqaDqeT4kK6uYTI rSJDd1JQ10GUzCuaHqEwcL+/VxJ9AZtn8PiNDR/vxipeWZY88iyrhFl+ON3d7QoYBmq+ FeNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=+mHWKSk3Qzxd3EMx0Ps+LWHfz/2PUPg2dTUT/Y9amdI=; b=osqTqPyyLcvqq7y/VMG4NKDmlwUITYH26GAH4Z1dQTtqyJpubHLnRYBAWfFhlORftA qE0d4RZART3rT/z/h30XbRu7nA2ym36zGxKWW7ZgrKIGiBa4L5sj4Ac6iN4WynqzVksI WDNHg9fEQm6Zt0rUnFg5FLlq7byKayJcplfoLXlR73pLbQbo1tpg4yEJYVwJNB961G9/ buMyqB2eIq29iOiacQvksYuSYkTxM/9OX8EDlmfDCulZVilyibSNIhIUqHSxV0Ou8FY/ NO+R84p7FQhJZ8a0z4oXlUznJ1iMNE8ETIrw2GEwZ7XGs19oXpRXbLALtCbkD3xKUrO9 MUnw==
X-Gm-Message-State: AOAM531V1/EzF5PqvKgAKH62z7huGXW6rI0jFpCm4UskvgnUP2DoMR83 8rPsNtVSly3GUj6AxxWOHUK94JD6dbY=
X-Google-Smtp-Source: ABdhPJyC4/HeJGlhiWZ/a7kl/PHNeLhBltKzq5jgtht3nw9w2JF4XUwPJ4Nnwv2QSDN9wST5m1ChCQ==
X-Received: by 2002:a2e:b0fa:0:b0:246:291a:5232 with SMTP id h26-20020a2eb0fa000000b00246291a5232mr17449481ljl.317.1646148283250; Tue, 01 Mar 2022 07:24:43 -0800 (PST)
Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id d12-20020ac241cc000000b004437eab8187sm1540486lfi.73.2022.03.01.07.24.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Mar 2022 07:24:42 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Lars Eggert' <lars@eggert.org>, 'Valery Smyslov' <svan@elvis.ru>
Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ikev2-intermediate@ietf.org, 'The IESG' <iesg@ietf.org>, ynir.ietf@gmail.com
References: <164612839381.20180.12376957342381821650@ietfa.amsl.com> <03fa01d82d73$af375e40$0da61ac0$@elvis.ru> <975E8857-BED9-4DF8-B069-C7CB3CEF954A@eggert.org>
In-Reply-To: <975E8857-BED9-4DF8-B069-C7CB3CEF954A@eggert.org>
Date: Tue, 01 Mar 2022 18:24:44 +0300
Message-ID: <041b01d82d80$7af94550$70ebcff0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIe8dMPfyTWHGrK2LsBdDkKKB7YvAI2YO4uAi9DXrmr+e7NAA==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/uzPlGsYaYJaHtl91x2Gxj8hRWw8>
Subject: Re: [IPsec] Lars Eggert's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)
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: Tue, 01 Mar 2022 15:24:51 -0000

Hi Lars,

> Hi,
> 
> On 2022-3-1, at 14:53, Valery Smyslov <svan@elvis.ru> wrote:
> >
> > I can add the following text at the end of Section 1 (as new paragraph):
> >
> >  Note, that the IKE_INTERMEDIATE exchange is not intended for
> >  bulk transfer. This specification doesn't set a hard cap on
> >  the amount of data that can be safely transferred using this mechanism,
> >  as it depends on its application. But it is anticipated that in most cases
> >  the amount of data will be limited to tens of Kbytes (few hundred Kbytes
> >  in extreme cases).
> >
> > Is it OK?
> 
> thanks, that looks very reasonable.
> 
> (If you wanted to, you could point at RFC6928 as an illustration that the IETF thought it OK for TCP to send up
> to ~15K in the first flight. There were also measurements done at the time that showed that at least some
> CDNs used even larger initial flight sizes.)

Thanks for the pointer. I updated the text as follows:

   Note, that the IKE_INTERMEDIATE exchange is not intended for bulk
   transfer.  This specification doesn't set a hard cap on the amount of
   data that can be safely transferred using this mechanism, as it
   depends on its application.  But it is anticipated that in most cases
   the amount of data will be limited to tens of Kbytes (few hundred
   Kbytes in extreme cases), which is believed to cause no network
   problems (see [RFC6928] as an example of experiments with sending
   similar amounts of data in the first flight of TCP).  See also
   Section 5 for the discussion of possible DoS attack vectors when
   amount of data sent in IKE_INTERMEDIATE is too large.

I also mentioned a possible DoS attack vectors when amount of data is too large.

Thank you,
Valery.

> Thanks,
> Lars