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

Daniel Migault <mglt.ietf@gmail.com> Thu, 03 August 2023 01:30 UTC

Return-Path: <mglt.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 B8978C1516F2 for <ipsec@ietfa.amsl.com>; Wed, 2 Aug 2023 18:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, 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 (2048-bit key) header.d=gmail.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 ameFpzL9MTbj for <ipsec@ietfa.amsl.com>; Wed, 2 Aug 2023 18:30:04 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 366A9C1516EB for <ipsec@ietf.org>; Wed, 2 Aug 2023 18:30:04 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-267fabc8465so199138a91.1 for <ipsec@ietf.org>; Wed, 02 Aug 2023 18:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691026203; x=1691631003; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oxaRQW2MPtbcHkCPhiM/8GUjvdm8+xAKHWvtSfemU0k=; b=PDfMSQh3lXGXRO7PB/bQgm/JsV5eDAhWpRMye9/KLjFLXBdzi6rKUQadQsjOtGnKe+ /bwcuowgHIGa+C3hVj1abJ1WOF5CZGQaTi3V9gFTG7U4w1xtqxdZXg7iZfJqz5j3/Q44 KWZhjhRAFGzqxB41uk5E33/+CwIixFxaBNc8uItkQbr59yap7MFUpE3vpOJLu5VW7n87 fy51zhQR+WnUWxzeIy2GKtaogTt8JyCeAmcjnbABfpUbtvdDLg/QafY/TMplh7C64DfL qrCMIkk036asaJTLSMwcyHmIMoI2mHaAT9uOuYQhibXjfMlFUW6o/r2cK9w4UCf3chYB uugQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691026203; x=1691631003; 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=oxaRQW2MPtbcHkCPhiM/8GUjvdm8+xAKHWvtSfemU0k=; b=HHlFKeNUu0O7uTn1aEVd30s4RUdusXaW+zFxOEPGSK36Jmcl4hXEAN+VztgceJvr72 GdkxU+fZEvwGsuztT6HK3GTAN8c9yGTIcoEjyWg504RPjHRH8hgSEX40Zu/UhJVlrRYb pZXIMaHUgNP4bRs1iCq5H+46u8vBpFfOx1hWayqaEtpGTIvJLuaXqlx3eowvyr+HIc72 HMjl1tayY6JGfOzypIW5w03inVXgkEQPmmii8k1q+vFPZNOx+oAC94V8fC5vq7z+MnA4 1QQZewcbeaT7glizyYtXhCG5zdUlZwo7bm0noM/BB7+2+AbPHZonFUxipqwSUSN/lrBk /mSg==
X-Gm-Message-State: ABy/qLajj01oBMn3DBl2juGzv2ifDTFMTi+jRB72XOxaH5GChjC/2C3L TTA3IAlkhcbcC0dfwPaIqUcjjSzYWDPMjM1qYzu3DMCv
X-Google-Smtp-Source: APBJJlEYNSMX4pFJVUrhamb03MyXHQFHnA2kqJUuuQ6itRLGvtNSYDO6OVCi1QRBoRrPV11OxJj+vrwF9obeA70Fb+s=
X-Received: by 2002:a17:90a:3e4e:b0:268:29cb:f93a with SMTP id t14-20020a17090a3e4e00b0026829cbf93amr16126096pjm.1.1691026203369; Wed, 02 Aug 2023 18:30:03 -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: Daniel Migault <mglt.ietf@gmail.com>
Date: Wed, 02 Aug 2023 21:29:51 -0400
Message-ID: <CADZyTk=81ZbFU9iS-TtKsXcc+QUFtXARjP+k=5r_M+3dvan11g@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="00000000000028669f0601fab85e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/ljw0IvHFyI-4En2B06KAKVqqaFY>
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 01:30:08 -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.
>
> 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.
>
>     > 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.
>

Just note that IKE PTB is really not the core of the draft  and the LMAP is
the main notification, IKE PTB is mentioned for completeness.

>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


-- 
Daniel Migault
Ericsson