Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
Rafa Marin-Lopez <rafa@um.es> Fri, 07 June 2019 08:53 UTC
Return-Path: <rafa@um.es>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C8F120100; Fri, 7 Jun 2019 01:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMtjGvFTIiH2; Fri, 7 Jun 2019 01:53:05 -0700 (PDT)
Received: from xenon42.um.es (xenon42.um.es [IPv6:2001:720:1710:601::42]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0C8120266; Fri, 7 Jun 2019 01:53:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 6FF8220657; Fri, 7 Jun 2019 10:53:03 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon42.um.es
Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31eYWy-74hw3; Fri, 7 Jun 2019 10:53:03 +0200 (CEST)
Received: from quantum.inf.um.es (quantum.inf.um.es [155.54.204.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon42.um.es (Postfix) with ESMTPSA id 70866206C7; Fri, 7 Jun 2019 10:52:59 +0200 (CEST)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <88BE764B-BC37-45F2-ABA0-AA8367D02A08@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FD56DD2B-757A-4255-9BD3-EB27EC0ADAA1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 07 Jun 2019 10:52:56 +0200
In-Reply-To: <23798.15513.517314.618936@fireball.acr.fi>
Cc: Rafa Marin-Lopez <rafa@um.es>, Paul Wouters <paul@nohats.ca>, Fernando Pereñíguez García <fernando.pereniguez@cud.upct.es>, "i2nsf@ietf.org" <i2nsf@ietf.org>, Gabriel Lopez <gabilm@um.es>, Linda Dunbar <linda.dunbar@huawei.com>, "ipsec@ietf.org WG" <ipsec@ietf.org>
To: Tero Kivinen <kivinen@iki.fi>
References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> <DBBD75C3-9FB3-473F-A627-062DB3F5C32D@um.es> <alpine.LRH.2.21.1904210811200.1903@bofh.nohats.ca> <ED73306E-F807-42A4-B063-D45E133B8419@um.es> <alpine.LRH.2.21.1905241401320.3939@bofh.nohats.ca> <23795.1716.390687.564153@fireball.acr.fi> <alpine.LRH.2.21.1906021105380.1550@bofh.nohats.ca> <997AE9FE-F0EB-4148-96B7-16A138E92205@um.es> <23798.15513.517314.618936@fireball.acr.fi>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/B880WXANARmCKu6dHa3Y7oR-SNI>
Subject: Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jun 2019 08:53:09 -0000
Hi Tero: > El 4 jun 2019, a las 11:40, Tero Kivinen <kivinen@iki.fi> escribió: > > Rafa Marin-Lopez writes: >> Hi Tero, Paul: >> >> El 2 jun 2019, a las 17:09, Paul Wouters <paul@nohats.ca> escribió: >> >> On Sun, 2 Jun 2019, Tero Kivinen wrote: >> >> I.e., if you have separate connections that share same authenticated >> identity then you need to disable INITIAL_CONTACT notifications. Also >> note that INITIAL_CONTACT is between identities, IP addresses, inner >> addresses etc does not matter, only the authenticated identities >> matter. >> >> Sure, but "don't do that" :) >> >> [Authors] Taking into account that road-warrior case is not considered in the >> I-D (only host-to-host and gw-to-gw) and Paul’s comment I think we can safely >> remove the leaf initial-contact, correct?. > > The same setting is also used in case there is replicated setups, > i.e., every case where you might have two nodes sharing identity and > authentication information. Load balancing, hotswap setups, replicated > servers etc quite often also want to make sure they set this setting > on. > > Those cases might be in scope for i2nsf too. [Authors] Then you propose to keep initial-contact, don’t you? > >> Moreover the Security Controller is the one providing this identity to the >> NSFs so I think this case would not be possible, would it?. > > It depends. Security controller might provide same identity to both > load balancing nodes, or both to the in sgw in use and the hot swap > replicated version. [Authors] So let’s keep the initial-contact node? > >> Note, that AEAD counter is not in the sequence number field, it is in >> the IV field, and every AEAD cipher RFC has text which requires that >> IV field is generated in a way that ensures uniqueness. From RFC4309: >> >> For now, but there are drafts going around that want to re-use the >> fields to save a few bytes :P >> >> [Authors] Our model allows the Security Controller to set the IV in >> the SAD in the IKE-less case. > > IV is per packet information, SC cannot really provide it. It can > provide initial value for it, but the updating of it must be done in > node. > >> Well, the IKEv2 endpoint that cares about this can just re-key or >> re-auth in time before reaching those counters. So yes, it does not >> need to be negotiated but it is the IKEv2 daemon handling this. So for >> the IKE-less case, I guess it should be there, although this is similar >> to the IKE-less case handling maxbytes, maxlife, maxidle counters. I >> think it is expected that the NSF sends the kernel message (pfkey, >> acquire) to the SC. So it could be avoided in the IKEless case than too. >> >> [Authors] We have a doubt here: if the IKEv2 endpoint that cares about this >> performs the re-key or re-auth, it needs to know when this event happens. I >> guess IKEv2 implementation would be expecting a notification from the kernel >> like xfrm_replay_notify(struct xfrm_state *x, int event) when a >> xfrm_replay_overflow happens (see for example : >> ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/kernel-3.10.14/net/xfrm/xfrm_replay.c <ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/kernel-3.10.14/net/xfrm/xfrm_replay.c> >> ) >> >> is this correct? > > IKEv2 will register suitable triggers to kernel, and kernel will then > use suitable method to notify IKEv2 when those timers, counters etc > are expiring. Not sure what those xfrm things do, as those are not > part of standard, but are internal implementation details for one > specific implementation. [Agree] Agree. From your answer we understand that we should have a notification for that anyway. We think that “expire" notification should be enough. Best Regards and thank you for your answers. > > Usually IKEv2 will set packet counter triggers that will expire way > before the actual overflow happens, so it has time to rekey before the > hard expiration happens. > -- > kivinen@iki.fi <mailto:kivinen@iki.fi> ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es -------------------------------------------------------
- [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sd… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Fernando Pereñíguez García
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Paul Wouters
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- [I2nsf] 答复: WGLC and IPR poll for draft-ietf-i2ns… Xialiang (Frank, Network Standard & Patent Dept)
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Paul Wouters
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Paul Wouters
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Tero Kivinen
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Paul Wouters
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Tero Kivinen
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin-Lopez