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, 7 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>, =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= <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
-------------------------------------------------------