From owner-freebsd-net@freebsd.org Mon Dec 23 12:02:36 2019 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 54C1D1EE770 for ; Mon, 23 Dec 2019 12:02:36 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47hHzH1zdwz4Z7G; Mon, 23 Dec 2019 12:02:34 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate1.intern.punkt.de with ESMTP id xBNC2XcN003236; Mon, 23 Dec 2019 13:02:33 +0100 (CET) Received: from [217.29.44.222] ([217.29.44.222]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id xBNC2Xql037647; Mon, 23 Dec 2019 13:02:33 +0100 (CET) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: IPSec transport mode, mtu, fragmentation... From: "Patrick M. Hausen" In-Reply-To: <5793a8ad-bf37-f2f2-29d8-29497d782651@yandex.ru> Date: Mon, 23 Dec 2019 13:02:32 +0100 Cc: Eugene Grosbein , Victor Sudakov , freebsd-net@freebsd.org, Michael Tuexen Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191220152314.GA55278@admin.sibptus.ru> <20191220160357.GB56081@admin.sibptus.ru> <20191220162233.GA56815@admin.sibptus.ru> <55eeca4c-9633-339a-f521-b0db462cc1d6@yandex.ru> <20191223100655.GA41651@admin.sibptus.ru> <3edbc7ad-a760-48c7-3222-202d7a835fe5@yandex.ru> <35fd51d5-c171-c97c-5bb2-529912d75844@grosbein.net> <5793a8ad-bf37-f2f2-29d8-29497d782651@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 47hHzH1zdwz4Z7G X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hausen@punkt.de designates 217.29.33.131 as permitted sender) smtp.mailfrom=hausen@punkt.de X-Spamd-Result: default: False [-2.15 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.29.32.0/20:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[punkt.de]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[131.33.29.217.list.dnswl.org : 127.0.10.0]; IP_SCORE(-0.36)[ip: (-0.33), ipnet: 217.29.32.0/20(-0.80), asn: 16188(-0.63), country: DE(-0.02)]; FREEMAIL_TO(0.00)[yandex.ru]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; MID_RHS_MATCH_FROM(0.00)[] 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: Mon, 23 Dec 2019 12:02:36 -0000 Hi all, > Am 23.12.2019 um 12:28 schrieb Andrey V. Elsukov : > "If required, IP fragmentation occurs after IPsec processing within an > IPsec implementation. Thus, transport mode AH or ESP is applied only > to whole IP datagrams (not to IP fragments)." >=20 > This is exactly how it works now. IPsec does encryption and passes ESP > packet to IP stack, then it can be fragmented if it is allowed (i.e. = no > DF bit set). >=20 > "An IP packet to which AH or ESP has been applied may itself be > fragmented by routers en route, and such fragments MUST be reassembled > prior to IPsec processing at a receiver." >=20 > If fragmentation was allowed at previous step, the receiver will have > several fragments that will be reassembled into single ESP packet, and > then it will be decrypted and passed to IP stack. I.e. IPsec will not > try to decrypt each fragment before reassembly. I'm with Andrey on this one. Shouldn't the encryption and encapsulation layer send back a "fragmentation needed but DF set" ICMP to the sender? It surely would if - the system was a router - the traffic was passing through the box instead of originating locally - the SA was in in tunnel mode or - there was an interface for the encrypted connection with lower MTU Looks like an oversight for transport mode and locally originating = traffic to me. Kind regards, Patrick --=20 punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de info@punkt.de AG Mannheim 108285 Gesch=C3=A4ftsf=C3=BChrer: J=C3=BCrgen Egeling, Daniel Lienert, Fabian = Stein