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

"touch@strayalpha.com" <touch@strayalpha.com> Mon, 31 October 2022 21:31 UTC

Return-Path: <touch@strayalpha.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 76EA7C14F74B for <ipsec@ietfa.amsl.com>; Mon, 31 Oct 2022 14:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.327
X-Spam-Level:
X-Spam-Status: No, score=-6.327 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, 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=pass (2048-bit key) header.d=strayalpha.com
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 uU8Y82vC8I49 for <ipsec@ietfa.amsl.com>; Mon, 31 Oct 2022 14:31:20 -0700 (PDT)
Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (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 C641BC14CF02 for <ipsec@ietf.org>; Mon, 31 Oct 2022 14:31:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2osstaJbWXupRGHD3Awg9seBVLO/QgZSR8ZOMfV4SeA=; b=2x44ujEmAWFxA5sLcaW5HVDbx4 UX4nTiLgXZKMeCfxUfAH4WINUBnqq3syDknovzmEsGTK0PYIdReZpTFFe6qWRNkKYAB7E4gLrCt7K t07KjrAaHJwD8aTOJMTex8AxjEoeND+pXonEhw0ubH24UJUyLzZ2s4s2AT3zovR4wImTwUIUFwcPj BxX2VpinIIDuqfWRFfOKmvjd10YQL+xaVspZM/+hcaM21M7/3+y/rXXkr9IUe1V34h73uDiQLF85c /+ae2wg/6bvBuIDLIVKphn8SrqE4HVHWAodkHLjWpDbsyQTsH/VFfl4S8uoQYabzWdJlqpq2SOk2p gUfdWTRQ==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:61332 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <touch@strayalpha.com>) id 1opcN7-00D0z3-NP; Mon, 31 Oct 2022 17:31:15 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <25440.11950.625195.698644@fireball.acr.fi>
Date: Mon, 31 Oct 2022 14:30:53 -0700
Cc: Daniel Migault <mglt.ietf@gmail.com>, ipsec@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <04C44824-A6D9-4BFC-BAD1-2546912C5ABF@strayalpha.com>
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> <BFCDB8B9-8386-47D3-B2EA-3679D63D353B@strayalpha.com> <25440.11950.625195.698644@fireball.acr.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/K0OOcVHAqTspGgxoilPl5B69kTI>
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 21:31:25 -0000

> On Oct 31, 2022, at 1:23 PM, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> touch@strayalpha.com writes:
>> 
>> What SHOULD happen in IPsec is that the SPI should have an MTU
>> (being a link) and the *router* where packets are forwarded into the
>> tunnel should determine when packets that want to enter that link
>> are too big - at which point, per RFC 1812, the *router* should be
>> sending the ICMP.
> 
> This is what the RFC4301 describes if I understood your description
> correctly. ...
> 
> So I think IPsec is still doing everything correctly.

For PTBs received along the path, then yes.

There are a few different cases here:
	- the reassembled tunnel packet is decrypted, decapsulated, and inside is an IPv4 DF=1 that exceeds the next-hop MTU
		at which point the IPsec tunnel egress router sends ICMP PTB based on that decapsulated (origin) packet (or not)

	- the tunnel hops generated a PTB to the IPsec ingress, which changes its MTU
		and the router at that ingress router sends PTBs back on subsequent packets if they receive IPv4 DF=1 that exceed that MTU

	- the egress reassembly fails because tunnel packet exceeds EMTU_R at the egress
		there’s no ICMP for this message, however

The PTBs of the tunnel (middle case) change the fragment size emitted from the ingress  (EMTU_S) accordingly, but it would not cause the tunnel to fail.

But note that the tunnel MTU is not its path MTU; it is the EMTU_R of the tunnel. Other packets CAN traverse it. So the only MTU the IPsec ingress should ever send back in a PTB would be EMTU_R of the tunnel.

This document tries to get around the fact that ICMP has no “packet bigger than I’d like” signal.

(Yes, I realize this means tunnels need to do frag/reassemly and this is expensive; the reason is explained in intarea-tunnels. If you’re talking about tunnels then reading that doc is a prerequisite - at least to my further involvement)

Until that signal exists, calculating it and relaying it is not useful. Even then, using ICMP to do this makes no sense, esp. given the entire mechanism assumes ICMP doesn’t work over the tunnel path.

Joe