Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

Tero Kivinen <kivinen@iki.fi> Tue, 04 June 2019 09:40 UTC

Return-Path: <kivinen@iki.fi>
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 8A907120182 for <i2nsf@ietfa.amsl.com>; Tue, 4 Jun 2019 02:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.42
X-Spam-Level:
X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=unavailable 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 ynhpgXE8Oc9x for <i2nsf@ietfa.amsl.com>; Tue, 4 Jun 2019 02:40:57 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A165412018F for <i2nsf@ietf.org>; Tue, 4 Jun 2019 02:40:56 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x549ehdR006058 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Jun 2019 12:40:43 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x549ef9L022752; Tue, 4 Jun 2019 12:40:41 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <23798.15513.517314.618936@fireball.acr.fi>
Date: Tue, 04 Jun 2019 12:40:41 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Rafa Marin-Lopez <rafa@um.es>
Cc: 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>
In-Reply-To: <997AE9FE-F0EB-4148-96B7-16A138E92205@um.es>
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>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 9 min
X-Total-Time: 9 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/VXmNw7kT11X2zSWlMixlG56yMWQ>
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: Tue, 04 Jun 2019 09:41:02 -0000

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.

> 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. 

>         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
> )
> 
> 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.

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