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, 02 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 Pereñíguez García <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
- [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sd… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Fernando Pereñíguez García
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Paul Wouters
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- [I2nsf] 答复: WGLC and IPR poll for draft-ietf-i2ns… Xialiang (Frank, Network Standard & Patent Dept)
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Gabriel Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Linda Dunbar
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin Lopez
- Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2ns… Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Paul Wouters
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Paul Wouters
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Tero Kivinen
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Paul Wouters
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Tero Kivinen
- Re: [I2nsf] [IPsec] WGLC and IPR poll for draft-i… Rafa Marin-Lopez