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

Rafa Marin-Lopez <> Fri, 07 June 2019 08:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52C8F120100; Fri, 7 Jun 2019 01:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QMtjGvFTIiH2; Fri, 7 Jun 2019 01:53:05 -0700 (PDT)
Received: from ( [IPv6:2001:720:1710:601::42]) by (Postfix) with ESMTP id 3E0C8120266; Fri, 7 Jun 2019 01:53:05 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FF8220657; Fri, 7 Jun 2019 10:53:03 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 31eYWy-74hw3; Fri, 7 Jun 2019 10:53:03 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 70866206C7; Fri, 7 Jun 2019 10:52:59 +0200 (CEST)
From: Rafa Marin-Lopez <>
Message-Id: <>
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: <>
Cc: Rafa Marin-Lopez <>, Paul Wouters <>, =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= <>, "" <>, Gabriel Lopez <>, Linda Dunbar <>, " WG" <>
To: Tero Kivinen <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>; escribió:
> Rafa Marin-Lopez writes:
>> Hi Tero, Paul:
>>    El 2 jun 2019, a las 17:09, Paul Wouters <>; 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 : 
>> <>
>> )
>> 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. 
> -- 
> <>
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: