From owner-freebsd-net@freebsd.org Fri Jan 17 10:30:27 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7BF6F229F06 for ; Fri, 17 Jan 2020 10:30:27 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47zclR174sz4LJ1 for ; Fri, 17 Jan 2020 10:30:26 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2a02:8109:1140:c3d:532:e64c:68b9:f8a2] (unknown [IPv6:2a02:8109:1140:c3d:532:e64c:68b9:f8a2]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6453C72106C11; Fri, 17 Jan 2020 11:30:22 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: IPSec transport mode, mtu, fragmentation... From: Michael Tuexen In-Reply-To: <7c153a5a-db38-2770-89c7-9f95f59d29de@yandex.ru> Date: Fri, 17 Jan 2020 11:30:21 +0100 Cc: Victor Sudakov , Eugene Grosbein , freebsd-net@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20191220152314.GA55278@admin.sibptus.ru> <4cc83b85-dd30-8c0d-330e-aa549ce98c98@yandex.ru> <20200116155305.GA465@admin.sibptus.ru> <55f7bafa-24c4-9810-0d21-f82cb332ee2d@grosbein.net> <20200116160745.GA1356@admin.sibptus.ru> <72355e03-1cf8-c58f-3aec-b0a21e631870@grosbein.net> <20200117093645.GA51899@admin.sibptus.ru> <7c153a5a-db38-2770-89c7-9f95f59d29de@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 47zclR174sz4LJ1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.07 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.80)[-0.796,0]; NEURAL_SPAM_LONG(0.72)[0.724,0]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 10:30:27 -0000 > On 17. Jan 2020, at 10:49, Andrey V. Elsukov wrote: > > On 17.01.2020 12:36, Victor Sudakov wrote: >> Back to the point. I've figured out that both encrypted (in transport >> mode) and unencrypted TCP segments have the same MSS=1460. Then I'm >> completely at a loss how the encrypted packets avoid being fragmented. >> TCP has no way to know in advance that encryption overhead will be >> added. > > For IPsec endpoints (i.e. when you encrypt own sessions) TCP for each > outgoing packet invokes IPSEC_HDRSIZE() method, that returns approximate > size required for IPsec, and using this information it calculates MSS. I > think this should work in this way. Can't you then use that also when the MSS is computed to be sent out in the MSS option? That would avoid using ICMP. Best regards Michael > > -- > WBR, Andrey V. Elsukov >