From owner-freebsd-net@freebsd.org Sat Jan 18 23:35:09 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 A83542362A0 for ; Sat, 18 Jan 2020 23:35:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 480Z6P19F5z4Ytd; Sat, 18 Jan 2020 23:35:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-73-225-95-104.hsd1.wa.comcast.net [73.225.95.104]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id 00INZ4v9094318 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 18 Jan 2020 15:35:05 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: IPSec transport mode, mtu, fragmentation... To: Eugene Grosbein , Victor Sudakov Cc: freebsd-net@freebsd.org, "Andrey V. Elsukov" , Michael Tuexen 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> <70b0b855-189b-03c2-0712-fc1e35640702@grosbein.net> From: Julian Elischer Message-ID: Date: Sat, 18 Jan 2020 15:34:58 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <70b0b855-189b-03c2-0712-fc1e35640702@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 480Z6P19F5z4Ytd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.16 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.71)[-0.711,0]; NEURAL_SPAM_LONG(0.87)[0.869,0]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US] 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: Sat, 18 Jan 2020 23:35:09 -0000 On 1/17/20 1:51 AM, Eugene Grosbein wrote: > 17.01.2020 16:36, Victor Sudakov пишет: > >> 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. Using multiple routing tables we could add a mechanism to the ipsec code so that encapsulated sessions are referred to one routing table and that the "envelope" routes are referencing another (specified in ipsec setup) routing table.  The two routing tables would have different MTUs.  This mechanism/framework would also be useful for other tunneling protocols in general. > If outgoing route (f.e. default route) has lower MTU, kernel should respond with EMSGSIZE > to TCP's attempt to send oversized packet when PMTUD is enabled. > > If PMTUD discovers that path mtu is low, it should store this information in the hostcache > (see sysctl net.inet.tcp.hostcache.list) and use hostcache's MTU for same goal. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >