Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

Paul Wouters <paul.wouters@aiven.io> Thu, 03 August 2023 02:35 UTC

Return-Path: <paul.wouters@aiven.io>
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 E6938C15199B for <ipsec@ietfa.amsl.com>; Wed, 2 Aug 2023 19:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, 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=pass (1024-bit key) header.d=aiven.io
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 jDC3KLu_B6-w for <ipsec@ietfa.amsl.com>; Wed, 2 Aug 2023 19:35:38 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3EC3C15106E for <ipsec@ietf.org>; Wed, 2 Aug 2023 19:35:37 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5230f8da574so8907a12.3 for <ipsec@ietf.org>; Wed, 02 Aug 2023 19:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; t=1691030136; x=1691634936; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9rN41LftxuI4qfzLMIBzOVe9RzYd/fDKw/3WP7NbQSQ=; b=OdXZ8NvCNAtrMqL4gzgmnaCYjG8bNmC05yIPkOygiAsj0LzIhdnZi/NAcrO7NoNi7k fuEZM5tM339RCT7vioo2Xuze6RrUdej1Zm4gBKF+LWB4T4MTcmRSrPqA62iuaXeriHpB 6lXbHFmwinU8bUuz4w6sTKX7GRQdVHkcwoA2M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691030136; x=1691634936; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9rN41LftxuI4qfzLMIBzOVe9RzYd/fDKw/3WP7NbQSQ=; b=H9LrKfapZ9xUxrnViq9JSLaQDhS7UOGdV2wWpMZeGJVOx7/rmo1MEqdw+8x7B8misc +em4txvBwxz7HteCcelbr7i00IYJfskPgaDGZeLs7AiT4biUnlG50HulXcnJ1PFaKFjw y3qIJJHJfBWnSv6CpYiSsyWqCfBbG8FducKv0jnZhcAv7au5ebnb8y6inOH2VpSdR2m9 cJ1YSjdFTcrBttBz1fTD0RIG0pibMoc4Ofwdwg3z5oXD3IecZCcRTugxgMU+42Whowe6 adVQyw9cMbR6Z6ebbFxnP/HrKq/J9frQBv9SdhbHnczjKKABXjOKYoyy2kUKnxmYYVfn GgcA==
X-Gm-Message-State: ABy/qLaGZQyfJ/GzeU/HE1wptyAMUtblJmuYp48gL7MDHOxxR5yYZV96 IPn7LR7EkUnZnauxuB9FmZKHr5oHhRmYsticffa2GfQOZzXQBpaxLKM=
X-Google-Smtp-Source: APBJJlGVq2kcQWXxJpp8A9CIQiOgAXXWTtyUzL8wDk46eB+yhEiD9obqASAYvkFD8Q70VV2KJzbJTx0AY+uzCVk4tFM=
X-Received: by 2002:a50:ed91:0:b0:521:a99b:a233 with SMTP id h17-20020a50ed91000000b00521a99ba233mr6845642edr.10.1691030136430; Wed, 02 Aug 2023 19:35:36 -0700 (PDT)
MIME-Version: 1.0
References: <CADZyTknYfvifCSfaFJ8ET4=Gjhr-wH3uE=uZaDTVirnWw6GV3A@mail.gmail.com> <BN8PR15MB3281ECF9E6A3BD032433B02AB306A@BN8PR15MB3281.namprd15.prod.outlook.com> <CADZyTkmE8DzQCyDoQpqTvV1ppnOt1BabSwBUCq3dDRYZUPvAbw@mail.gmail.com> <DM6PR15MB32929267579BE76A455F2CEFB306A@DM6PR15MB3292.namprd15.prod.outlook.com> <AM6PR07MB605616564FD730DF453EAABAEB05A@AM6PR07MB6056.eurprd07.prod.outlook.com> <BN8PR15MB3281CEDB92996303F44CA183B305A@BN8PR15MB3281.namprd15.prod.outlook.com> <CADZyTk=-2DQijTzHW0pYJn0KXfDqctyh+ULZ-Zmvs6FfreOVnw@mail.gmail.com> <BN8PR15MB32812ABC7F6A9B7FB86093BDB305A@BN8PR15MB3281.namprd15.prod.outlook.com> <CADZyTkm_9FpVrfqdfRn7wsnTQjPTwLE9_=Fbj8TE8U=s-EsBgA@mail.gmail.com> <CADZyTknaU1EjrQ_4jRms-s-444VxhGBm5=ObnEW2p31KzCpBQw@mail.gmail.com> <62ee818145b242dabd253419c60221eb@huawei.com> <m28raut4tu.fsf@ja.int.chopps.org> <6726.1690986301@localhost> <ae66a899-5d50-6d56-190a-9ebffe70903c@nohats.ca> <29919.1691025445@localhost>
In-Reply-To: <29919.1691025445@localhost>
From: Paul Wouters <paul.wouters@aiven.io>
Date: Wed, 02 Aug 2023 22:35:25 -0400
Message-ID: <CAGL5yWbstr_1=zN8iC8y+WghaKVhjDbDSPtzP89-ErcKAoPxbA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Paul Wouters <paul@nohats.ca>, "ipsec@ietf.org WG" <ipsec@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000096a6360601fba229"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/OrrqBvgbTHvdvSwqDsJBqQKMmhA>
Subject: Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
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: Thu, 03 Aug 2023 02:35:42 -0000

On Wed, Aug 2, 2023 at 9:17 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Paul Wouters <paul@nohats.ca> wrote:
>     >> Christian Hopps <chopps@chopps.org> wrote: >> The ingress node
>     >> encrypts this packet and adds the IPsec >> encapsulation, and this
>     >> IPsec-processed packet is also larger than the >> Link MTU. The
>     >> ingress node fragments this IPsec-processed packet and >> sends all
>     >> the fragments to the egress node.
>     >>
>     >> > This should not happen. The ingress node should first fragment
> the >
>     >> inner IP packet so that it fits in the tunnel (i.e., so that the
> ESP >
>     >> packets it creates do not violate it's own MTU).
>     >>
>     >> You can't do that if DF=1, or IPv6.  You can form big ESP packets
> and
>     >> then fragment them, even with IPv6.  DF=0 for IPv4 on ESP packets is
>     >> good, until there is a firewall that cant cope with fragments.
>
>     > Why does any of this even matter? The applications should use
> PLPMTUD /
>     > DPLPMTUD ?
>
> 1) For TCP things.  We also have RFC9268 now.
>

Neat. I didn't know about that one.

I guess we might get it for UDP too then if we get
draft-ietf-tsvwg-udp-options  :)


> 2) how can we get it turned on by default?  I tried to make this case to
>    Linux distros and kernel people, but there is a lack of evidence that
>    it is safe, and the people who might have the evidence (at scale)
>    don't want to do it.
>
> 3) the gateways really have no idea if PLPMTUD is being done, and sometimes
>    it's better to just make things work.
>
>     > Sprinkling bits to try to communicate with hops in between hasn't
>     > worked for decades.
>
> Agreed. PMTUD is a fail.
>
>     > Or use IPTFS and set your own max packet size sufficiently low?
>
> I think that this is the killer app for IPTFS.
>

But of course this means either IPTFS should be able to auto-tune this, or
else we end up with
hardcoded configs that might stop working or cause future problems.


>     > I'm not convinced doing this between IPsec peers will solve any real
>     > use cases.
>
> I am also skeptical, but I don't object to the work getting standardized.
>
> In particular, for networks where there are MTU constraints on the far side
> of the far gateway, telling the sending gateway about the MTU has a far
> higher
> chance of working than anything else.  The sending gateway probably can
> send
> PTB ICMPs with better results.
>

There would need to be dynamic updating, kernel <-> userland
communications, etc.
Just hardcoding this in an ikev2 configuration would be pretty bad.

Paul