Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 31 October 2022 15:37 UTC

Return-Path: <mcr+ietf@sandelman.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 C3895C1524D9 for <ipsec@ietfa.amsl.com>; Mon, 31 Oct 2022 08:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.706
X-Spam-Level:
X-Spam-Status: No, score=-6.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (bad RSA signature)" header.d=sandelman.ca
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 M1HgDa8QGdrr for <ipsec@ietfa.amsl.com>; Mon, 31 Oct 2022 08:37:30 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FA4C14CE23 for <ipsec@ietf.org>; Mon, 31 Oct 2022 08:37:30 -0700 (PDT)
Received: from dyas.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 475AC1F45D; Mon, 31 Oct 2022 15:37:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=mail; t=1667230649; bh=YS4EU7x67+NEZ/C/pEGimXl2Es62YQuweRuO3qx2P2w=; h=From:To:Subject:In-reply-to:References:Date:From; b=lB15wub/Ll+fV7oyJl75oAm21a8f8UJKbAIO19xaHavB924wbIQFzruA+Uxlg3B4Z UurHQzCpyJgfS58FpvktLGv+UvX9QlDacnceMpF/ewe7gA2hoZeradWHCiRDZEpTvo S3fRpD9a7ckJRTcFwSwmoJJmiCT07hR8pRhKL/lSPG5zRxW91vBBtqKt9jhs1aKYul YGEj7GUQbCZpCrDWQu36vp+DfxJ7OXBbaAwKHMk7BcFsM2k0vc7qDCyFv9NM29XXe/ FZ3rcFwSAa7CaMc2czSQElxZ16EjCMefmdV1btMXhJetRYDNSfOfFLV2aAtDwZ2blQ v92tpcSqflSyA==
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 65E3CA0B51; Mon, 31 Oct 2022 16:36:57 +0100 (CET)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 63C1FA0B45; Mon, 31 Oct 2022 16:36:57 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org
In-reply-to: <25439.44817.648153.317135@fireball.acr.fi>
References: <53B61B29-20F3-4DBD-962B-6F7CFCDEDEE6@strayalpha.com> <CADZyTknjaYshjZrY0-KcjMN_0bDUpx5RFvH=Hki4UpFs7jFTjQ@mail.gmail.com> <2FFA31D7-8E7D-48DB-A3BC-DDA3EB2ECCE2@strayalpha.com> <25439.44817.648153.317135@fireball.acr.fi>
Comments: In-reply-to Tero Kivinen <kivinen@iki.fi> message dated "Mon, 31 Oct 2022 13:18:41 +0200."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 31 Oct 2022 16:36:57 +0100
Message-ID: <410257.1667230617@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/XnuQAHVA1tJiPqdBieh-VA2etO8>
Subject: Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
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: Mon, 31 Oct 2022 15:37:35 -0000

Tero Kivinen <kivinen@iki.fi> wrote:
    > My understanding is that this draft (which I have not yet properly
    > read) is solving the situation where the tunnel does not get ICMP PTB
    > messages as they are forwarding packets with DF bit set to 0, and then
    > the receiving end will see extra fragmentation happening for the
    > packets. Then the receiving end will simulate the ICMP PTB by sending
    > authenticated IKEv2 notification that tells the sending end that his
    > packets got fragmented.

While I think that the authors think they are solving this problem, I think
that what they have created is a protocol for dealing with fragmentation
beyond the far gateway.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-