Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt

Paul Wouters <paul@nohats.ca> Fri, 07 September 2018 14:06 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 4721F129AB8; Fri, 7 Sep 2018 07:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 geGS1DwIUgFM; Fri, 7 Sep 2018 07:06:04 -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 6D6C5130DD5; Fri, 7 Sep 2018 07:06:04 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 426K3Y1zXHzD0G; Fri, 7 Sep 2018 16:06:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1536329161; bh=AR5uIql1P+S6Ceff5pTdHI1kdGCSBxrONq7ELeGPkT8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=T2cnC8mzfFZyQNRHt6TjJHHOWeQwoBWus7q3lUAKSn9z8ThWN63PRGTB4uGyC87pG z52OwiKF7TrwGAU3hG63eMvNzA5GDCF2haW3q1QEwm30XigmUMR7tXDvMF0SVAB9yS ciVqsli9XPkFuxmfcdfVk4+AG4iI8JXM2WFc1ZQc=
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 JzRYEo_mu_Sq; Fri, 7 Sep 2018 16:05:59 +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; Fri, 7 Sep 2018 16:05:58 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 213DE5E2A4E; Fri, 7 Sep 2018 10:05:57 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 213DE5E2A4E
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1ACA84027A89; Fri, 7 Sep 2018 10:05:57 -0400 (EDT)
Date: Fri, 07 Sep 2018 10:05:57 -0400
From: Paul Wouters <paul@nohats.ca>
To: Valery Smyslov <svan@elvis.ru>
cc: IPsecME WG <ipsec@ietf.org>, draft-ietf-ipsecme-tcp-encaps@ietf.org
In-Reply-To: <058901d446ad$fd78b5a0$f86a20e0$@elvis.ru>
Message-ID: <alpine.LRH.2.21.1809070957170.20905@bofh.nohats.ca>
References: <153632409170.28963.3858352353321879475.idtracker@ietfa.amsl.com> <058901d446ad$fd78b5a0$f86a20e0$@elvis.ru>
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/b1IJCY6XdwrfC0riXA2WqW7M7w4>
Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt
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: Fri, 07 Sep 2018 14:06:08 -0000

On Fri, 7 Sep 2018, Valery Smyslov wrote:

> I've posted a draft with clarifications and implementation guidelines
> for RFC8229. These clarifications and recommendations are based
> on experience of implementing TCP encapsulation and testing it in
> various IKEv2 scenarios.
>
> Feedback of any sort is highly appreciated.

I would cut a lot of the introduction / abstract and come straight to
the point. Simiarly, further one not provide as much details and just
come to the point faster.

I don't see any consideration in the document about deployments that
use a TCP proxy in front of the IKE daemon. In those scenarios, the
daemon might not even know TCP is used or the proxy code is written in
a way that only minimal changes to the IKEv2 core are needed. So a lot
of decisions you specify, such as not sending retransmits, might not
be possible for those kind of implementations, and so this document
dictating them for make interop harder, not easier.

As this also touches on message IDs, and I think we might have some
msgid deadlocks even in the UDP only case, perhaps a clarifying
document could add some non-TCP items as well? And the TCP part could
be part of the new clarification draft ?

Paul