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

Tero Kivinen <kivinen@iki.fi> Sat, 01 June 2019 23:14 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 D5D561201E9 for <i2nsf@ietfa.amsl.com>; Sat, 1 Jun 2019 16:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level:
X-Spam-Status: No, score=-3.419 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, URIBL_BLOCKED=0.001] 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 qri9eNo7K_SM for <i2nsf@ietfa.amsl.com>; Sat, 1 Jun 2019 16:14:16 -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 92B40120227 for <i2nsf@ietf.org>; Sat, 1 Jun 2019 16:14:15 -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 x51NDxMo007340 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Jun 2019 02:13:59 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x51NDuI6010295; Sun, 2 Jun 2019 02:13:56 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <23795.1716.390687.564153@fireball.acr.fi>
Date: Sun, 2 Jun 2019 02:13:56 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Wouters <paul@nohats.ca>
Cc: Rafa Marin-Lopez <rafa@um.es>, Fernando =?iso-8859-1?Q?Pere=F1=EDguez_Garc=EDa?= <fernando.pereniguez@cud.upct.es>, "i2nsf\@ietf.org" <i2nsf@ietf.org>, Gabriel Lopez <gabilm@um.es>, "ipsec\@ietf.org WG" <ipsec@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
In-Reply-To: <alpine.LRH.2.21.1905241401320.3939@bofh.nohats.ca>
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>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 19 min
X-Total-Time: 20 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/w5jOp6jHrCinVKj38NW4NjbPLeE>
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: Sat, 01 Jun 2019 23:14:21 -0000

Paul Wouters writes:
> > [Authors] We have observed some implementations (e.g. libreswan)
> > has this variable initial-contact as well in the ipsec.conf. That is
> > why we decide to 
> > keep it. Is it not useful then?
> 
> We added it because sending or not sending it might change te behaviour
> of the other endpoint. libreswan as implementation ignores the payload
> completely, because it has all the known information/state needed.
> Although based on the above new finding of multiple IPsec SA's, this
> might change.
> 
> I guess my point was more to the fact that instructing the NSF to send
> an INITIAL_CONTACT seems to mixup instructions from the SC. If the SC
> says "bring tunnel X to GW Y up", and then later says "bring tunnel Z
> up to GW Y and send INITIAL_CONTACT", it is implicitly sending a message
> to the NSF to bring tunnel X to gateway Y down. Now the NSF and SC might
> be out of sync if the SC wasn't expecting this result.

The reason implementations need a flag for telling whether or not to
send INITIAL_CONTACT notification is that there is no way for
implementation to know whether it is replicated. I.e., if you have
both your laptop and mobile phone making VPN connections to SGW, and
both of them use same identity (for example kivinen@iki.fi), you want
to disable sending INITIAL_CONTACT notifications as other wise when
you have your laptop connection up and running and you start your
phone, that will kill the IPsec SA for the laptop, as the phone would
send INITIAL_CONTACT notification. When you disable it by the
configuration then this will not happen.

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. 

> > [Authors] This is an interesting question. We must state that, for security reasons, any NSF should have a default DISCARD policy. A NSF restarting should
> > not allow any traffic unless SC says so. In other words, Since the NSF needs information coming from the SC, if that information is not in place yet the
> > safest option is DISCARD action.
> 
> Sure. I think adding some text that says a connection in the "configured
> but not up" state is expceted to drop or hold onto the packets, that
> would make it clear.

Of course the device still needs to configure the IPsec policy so that
device can connect to the security conntroller, and also perhaps add
other holes to the policy that are needed to make that connection
possible (arp, ND, perhaps ntp, etc). 

> >       Use "Configuration of IPsec Security Association (SA). Section 4.4.2.1 in RFC 4301"
> >       To ensure it is clear this is not about an IKE SA. Same on the next line for
> >       "for a particular SA"
> >
> >         leaf seq-number-overflow-flag { type boolean; description "The flag indicating whether overflow of the sequence number counter should
> >       prevent transmission of additional packets on the SA, or whether rollover is permitted."; }
> >
> >       What is the source of this? I thought sequence numbers were never allowed to overflow?
> > 
> > 
> > [Authors] According to RFC 4301 - 4.4.2.1.  Data Items in the SAD:
> > 
> > Sequence Counter Overflow: a flag indicating whether overflow of
> >       the sequence number counter should generate an auditable event and
> >       prevent transmission of additional packets on the SA, or whether
> >       rollover is permitted.  The audit log entry for this event SHOULD
> >       include the SPI value, current date/time, Local Address, Remote
> >       Address, and the selectors from the relevant SAD entry.
> 
> 
> Hmm, I have never heard of this so I should look into it, but I guess it
> means you should have the option for it, but please default it to not
> allow rollover, and it would need to forbid rollover for AEAD's.
> 
> Tero, do you know anything more about this feature? I don't think we
> could ever negotiate it via IKE anyway?

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:

   The AES CCM IV field MUST be eight octets.  The IV MUST be chosen by
   the encryptor in a manner that ensures that the same IV value is used
   only once for a given key.  The encryptor can generate the IV in any
   manner that ensures uniqueness.  Common approaches to IV generation
   include incrementing a counter for each packet and linear feedback
   shift registers (LFSRs).

Anyways, as replay preventation is optional for the receiver, there is
an option for ESP RFC4303 to disable it, and that case it does not
matter whether the sequence number field overflows or not. Because of
this the IPsec architecture document do allow option for wrapping
sequence numbers. Of course if sequence number ever wraps, we do loose
the anti-replay service, but there might be use cases where that does
not matter.

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. 

> >         leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; }
> >
> >       Why cap at 1024? That could be too low for 100gbps connections.
> > 
> > 
> > [Authors] The truth is that RFC 4301 mentions:
> > 
> > Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
> >       used to determine whether an inbound AH or ESP packet is a replay.
> > 
> > So we can replace this with uint64. On the other hand, we have observed with uint16 should be enough in real cases. We can remove the restriction (1024) .
> > what do you think?
> 
> Yes, I think the uint16 is more than enough, as long as you don't mention any cap like 1024.

Actually the RFC4303 says in appendix A2:

             Also, the algorithm described
   below assumes that the window is no greater than 2^31 packets in
   width.)  

so making it uint32, would work for any implementation using algorithm
described in the RFC4303...
-- 
kivinen@iki.fi