From owner-freebsd-net@freebsd.org Wed Jun 8 12:15:39 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDBD4B6D9F7 for ; Wed, 8 Jun 2016 12:15:39 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 125F5116B; Wed, 8 Jun 2016 12:15:37 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 3C967376109B; Wed, 8 Jun 2016 14:12:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 2E7293761044; Wed, 8 Jun 2016 14:12:49 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Txx0IEMw6wMn; Wed, 8 Jun 2016 14:12:49 +0200 (CEST) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 1B89A3760915; Wed, 8 Jun 2016 14:12:49 +0200 (CEST) Date: Wed, 8 Jun 2016 14:12:48 +0200 (CEST) From: Emeric POUPON To: FreeBSD Net Cc: gnn@freebsd.org, jmg@freebsd.org Message-ID: <2079286727.3163127.1465387968941.JavaMail.zimbra@stormshield.eu> Subject: IPSec and large replay window support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Thread-Topic: IPSec and large replay window support Thread-Index: JYX/hDepe//Gsk4+yyl2x1mL618CJw== X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:15:39 -0000 Hello, We plan to support large replay windows in the IPsec stack. Currently, the replay window size is limited due to the size of the field used in the sadb_sa_replay structure. https://www.ietf.org/rfc/rfc2367.txt : struct sadb_sa { uint16_t sadb_sa_len; uint16_t sadb_sa_exttype; uint32_t sadb_sa_spi; uint8_t sadb_sa_replay; uint8_t sadb_sa_state; uint8_t sadb_sa_auth; uint8_t sadb_sa_encrypt; uint32_t sadb_sa_flags; }; => max is 255*8 = 2040 packets wide. Some time ago we already patched our kernel in order to use a 16bits field. This does the job but we are facing two problems: - the current algorithm is inefficient with large window sizes (bit shifting). - we are still limited in size (65535*8 = 524280 packets) Here are the ideas: - implement RFC 6479 : https://tools.ietf.org/html/rfc6479 - replace the 8bit field with a 32bits field I am not very comfortable with the idea to change a field that is described in the RFC 2367. Is there any other acceptable solution? Adding a new extension? What do you think ? Emeric