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

Rafa Marin-Lopez <rafa@um.es> Mon, 03 June 2019 12:15 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 C793512020A; Mon, 3 Jun 2019 05:15:18 -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 hm_MicxbzNtB; Mon, 3 Jun 2019 05:15:16 -0700 (PDT)
Received: from xenon42.um.es (xenon42.um.es [IPv6:2001:720:1710:601::42]) by ietfa.amsl.com (Postfix) with ESMTP id F2D831200EA; Mon, 3 Jun 2019 05:15:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 8C3191FF64; Mon, 3 Jun 2019 14:15:14 +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 RqeKU2D-7M02; Mon, 3 Jun 2019 14:15:14 +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 C22B82099B; Mon, 3 Jun 2019 14:15:11 +0200 (CEST)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <997AE9FE-F0EB-4148-96B7-16A138E92205@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9739FEF-C2C6-4E4B-9876-03FB9C0FFD41"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 3 Jun 2019 14:15:11 +0200
In-Reply-To: <alpine.LRH.2.21.1906021105380.1550@bofh.nohats.ca>
Cc: Rafa Marin-Lopez <rafa@um.es>, =?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: Paul Wouters <paul@nohats.ca>, 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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/VYi08aEqiaX2d1wvwuc4gGF_rik>
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: Mon, 03 Jun 2019 12:15:19 -0000

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

Moreover the Security Controller is the one providing this identity to the NSFs so I think this case would not be possible, would it?.


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

leaf iv {
	nacm:default-deny-all;
        type yang:hex-string; 
        description 
		"ESP encryption IV value"; 
}

> 
>> When using IKEv2, we do not negotiate anti-replay service, it is
>> always assumed to be local matter on the receiver, thus there is no
>> need for two peers to agreee on that. On the other hand if anybody
>> would want to disable anti-replay, and use non-extended sequence
>> numbers, and allow sequence numbers to wrap, then the IKEv2 does not
>> offer that option, because it does not allow settign that flag in the
>> SAD.
> 
> 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?

We have also observed several types of overflow: xfrm_replay_overflow_bmp (not sure about the purpose of this, any clarification?), xfrm_replay_overflow_esn, xfrm_replay_overflow

if that is the case, we should include that notification in the model for IKE-less case so that the Security Controller is aware of this situation. However, wouldn't it be enough to use the number of packets lifetime instead of having this new threshold (in xfrm we have seen replay_maxdiff and replay_maxage as such as threshold).

Best Regards.

> 
> Paul
> 
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

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