From nobody Wed Jul 3 10:38:36 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1C5120663 for ; Wed, 3 Jul 2019 10:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KGMAVclUqCj5 for ; Wed, 3 Jul 2019 10:38:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E1F120630 for ; Wed, 3 Jul 2019 10:38:24 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id ED81B38192; Wed, 3 Jul 2019 13:36:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8CADCBB7; Wed, 3 Jul 2019 13:38:22 -0400 (EDT) From: Michael Richardson To: sandeepkampati@huawei.com, ipsec@ietf.org cc: MeduriS.Bharath@huawei.com X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [IPsec] draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 17:38:34 -0000 --=-=-= Content-Type: text/plain Sandeep, I read the document this past week. I found the claim that the TS and SA details were worth optimizing to be surprising. So I counted the size of the CHILDSA proposal. This means the SAi2, TSi and TSr in the initiator, With the responder providing SAr2, TSi and TSr. HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] TSi, TSr} --> TSx = 8 (header) + 8 + 8 = 24 (IPv4) 8 + 8 + 32 = 48 (IPv6) SAi2= 8+4(SPI) + transforms transforms = 8+ 4(cipher)+ 4(integ) = 16 bytes total = 28 bytes. Ni = 4 + nonce-size (16+ bytes) N(REKEY_SA) = 8 bytes. total: SAi2 (28bytes) plus 2x TSx 24 * 2 + Ni 20 bytes + N 8= 104 bytes (IPv4). SAi2 (28bytes) plus 2x TSx 48 * 2 + Ni 20 bytes + N 8= 152 bytes (IPv6). I have not included KEi, as you did in your section 3.2.1, because I assume that if computation and netweork resources are at premium, that doing additional exponentiation is inappropriate. Maybe a new DH every N rekeys. KEx = 8 + 32 bytes (256-bit ECDSA) = 40 bytes. potentially there are some notifications, at 8 bytes each, potentially longer. Replacing this with a single 16-byte Notify would be a win on total bytes, but as it does not reduce the number of packets at all, I'm still having difficulty believing it really matters. It might be worth putting the nonce into the SA_TS_UNCHANGED payload, as that saves another 4 bytes. A new Ni/Nr is needed each time as the child SA key derivation needs that freshness. So, the math is: all ts-opt all-ke ts-opt-ke IPv4: 104 36 144 74 IPv6: 152 36 202 74 {There are some assumptions that I have made in this calculation. Probably some mistakes, so if an important argument point, I'll post a Google Calc page with my assumptions. The cost of KE size with DH groups would be bigger than with ECDH groups. } -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0c6A4ACgkQgItw+93Q 3WWU4wf+OLsV1FRrKHNeqmb37OeYUhsBdS3tYS0NLlxiykYb2mfGfREkw1H2rS32 OP27j16c3QuMnc7vh50ktNsn4Ny83ZO0SIlbwmmEtDdWuLODbJR1ETko4WjI5szL ANlyuLeKoy5eNNXKWi64CzUVdzvvGWlZSYMZ61k9xpAu3GKJMhoPp2REx/IPwbNb BQhSOhEH5x7uNXAu1Wjs3rOTxw/LmFzGfxjkpKgYqjYRFA+Wsb/jEr/G1wnWKQPe 2xdAzu/jAJLd4HAepSwCctraQF6pXdb91nNKrYN7hResrvgwC31FM+3DbHm8TqvM mxCMFYaZam04+OEfTmg0ygS0XurwmQ== =XUuC -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 8 16:13:16 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 928D0120389; Mon, 8 Jul 2019 16:13:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <156262758653.1025.11171782937864379367@ietfa.amsl.com> Date: Mon, 08 Jul 2019 16:13:06 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 23:13:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Labeled IPsec Traffic Selector support for IKEv2 Authors : Paul Wouters Sahana Prasad Filename : draft-ietf-ipsecme-labeled-ipsec-01.txt Pages : 8 Date : 2019-07-08 Abstract: This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-01 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-labeled-ipsec-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 10 12:51:05 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2EC12004D; Wed, 10 Jul 2019 12:51:03 -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=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 jtPkQHCacNBn; Wed, 10 Jul 2019 12:51:01 -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 EF60B120147; Wed, 10 Jul 2019 12:51:00 -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 x6AJovZE027975 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Jul 2019 22:50:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6AJovDe006839; Wed, 10 Jul 2019 22:50:57 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23846.16801.98270.393296@fireball.acr.fi> Date: Wed, 10 Jul 2019 22:50:57 +0300 From: Tero Kivinen To: ipsec@ietf.org Cc: ipsecme-chairs@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 7 min Archived-At: Subject: [IPsec] IPsecME Montreal IETF agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 19:51:03 -0000 Now, when I am back from my Chile eclipse trip, I have some time to start working on the IETF issues again. So please send requests for agenda items for Monteral IETF to the chairs as soon as possible. We already have following requests for the agenda, and I would like to finalize the agenda quite soon, so I can start asking authors to send slides for their presentations. - ikev2-sa-ts-payloads-opt - iptfs - g-ikev2 - hybrid-qske-ikev2 - ikev2-intermediate -- kivinen@iki.fi From nobody Thu Jul 11 13:17:10 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B4B120143 for ; Thu, 11 Jul 2019 13:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 kSvUSCQ5x6vE for ; Thu, 11 Jul 2019 13:17:06 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 30BC7120121 for ; Thu, 11 Jul 2019 13:17:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45l6ly6Z5VzDfY; Thu, 11 Jul 2019 22:17:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1562876222; bh=+PMaDhZY3TG8nB8dXcQIg45/v0oQPAByIcBupOloCh4=; h=Date:From:To:cc:Subject; b=U3FPq5btpE2r/G/C4bFecChBTX7ubz6NitRB+xjjMXrFS6jKXxOLWus6j4BTfDPoC ljm238mjBkDF9MqBmb3C79Ai0TIgYwYFKCcewZrgZby5NyjLU+L8zBAQS/SzlEeLCf QJgfMgz/rwVLEVZS7sAvCPDF0w0ybtPvf7QNsqZM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DaFxeiUE-yhW; Thu, 11 Jul 2019 22:17:01 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 11 Jul 2019 22:17:00 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 27ED44AA; Thu, 11 Jul 2019 16:16:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 27ED44AA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1BA314009E88; Thu, 11 Jul 2019 16:16:59 -0400 (EDT) Date: Thu, 11 Jul 2019 16:16:59 -0400 (EDT) From: Paul Wouters To: Yaron Sheffer , Hannes Tschofenig , "ipsec@ietf.org WG" cc: vinay kornapalli Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Questions about RFC 5723 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 20:17:09 -0000 Hi, I'm a little confused about some parts in RFC 5723 The first is about which SA's can be resumed. The introduction leaves this ambiuous: To re-establish security associations (SAs) upon a failure recovery condition is time-consuming, It does not say IKE SA or IPsec SA. And I have a feeling it depends a bit on what you call "resumption". It then talks about resuming the IKE SAs.... Reading more, it seems IPsec SA's are not "resumed" but "created from scratch"? I also see: If a client temporarily loses network connectivity (and the IKE SA times out through the liveness test facility, a.k.a. "dead peer detection") This is also a little confusing for IKE and IPsec states, because the liveness test is for an IPsec SA, not an IKE SA. But it is send via an IKE SA. That is, if an IPsec SA has no outgoing traffic, there would never be a check using IKE for this. So it is kind of misusing the fact that the IKE SA is used for liveness tests to check on the status of the IKE SA. In 4.3.4 I see: Following the IKE_AUTH exchange, a new IKE SA is created by both parties, see Section 5, and a Child SA is derived, per Section 2.17 of [RFC4306]. Which Child SA? If the peers had more then one IPsec SA, how does one determine which IPsec SA to generate key material for first? Because this paragraph does not talk about a new CREATE_CHILD_SA, it looks as if the child sa derivation would not need another Exchange, but I can find no information on how this would be done, unless we just pull KEYMAT from the new SKEYSEED, but then child SA and ordering is completely unspecified and this could only work when there is a single IPsec SA for the IKE SA? And this is the really confusing part in section 5: IKE and IPsec State after Resumption During the resumption process, both peers create IKE and IPsec state for the resumed IKE SA. Although the SA is only completed following a successful IKE_AUTH exchange, many of its components are created earlier, notably the SA's crypto material So here too it says "create IKE and IPsec state". Which IPsec state first? Then it talks about "the SA" and "the SA's" ? My guess is that we first pull key material for the IKE SA, and then for one of the IPsec SA's (perhaps this document assumes there is only 1 IPsec SA for any IKE SA that can be resumed?). Or based on Note 6: Note 6: Since information about Child SAs and configuration payloads is not resumed, IKEv2 features related to Child SA negotiation (such as IPCOMP_SUPPORTED, ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec [ROHCoIPsec] and configuration) aren't usually affected by session resumption. Perhaps what is meant is that a session resumption only resumed a childless IKE SA, and now the initiator must do CREATE_CHILD_SA's for each IPsec SA it wants to have again (not really "resumption", as these are created "from scratch" like regular CREATE_CHILD_SA? Also, when using PFS, these CREATE_CHILD_SA's would do a DH again, at which point one wonders why to do resumption at all if you have more than one IPsec SA, as you would be doing DH's anyway for all children, you might as well do one more for a regular IKE_SA_INIT ? So the essense of my question is: Am I correct that an IKE session resumption only resumes the IKE SA, and that all IPsec SA's need to be re-negotiated using CREATE_CHILD_SA ? Secondary question: When using pfs=yes, what is the envisioned behaviour of CREATE_CHILD_SA? Do a new DH? Or is it assumed that resumption would be an incompatible policy with pfs=yes ? Paul From nobody Thu Jul 11 20:13:11 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEFB120052 for ; Thu, 11 Jul 2019 20:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 1hdGh4KHHkFL for ; Thu, 11 Jul 2019 20:13:08 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 1472E12001E for ; Thu, 11 Jul 2019 20:13:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45lJ012bQ3z6S for ; Fri, 12 Jul 2019 05:13:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1562901185; bh=NhFsnZ7RiqvtoRFmkVvb80oEcYhShlD037XQe1Gtc9I=; h=Date:From:To:Subject; b=nGcx7JrVS8cv9jeAbPJKHl1yJZl5Mpckj7gwPkMVptZ0U31OgI9ujlNY3N0jdT5HK MepxDz7TZf3bAjX9ycory4GX2ac1y1FAEnoOFkLFClLZ0HkPp1Nmr1dej/0h223j3V xKvwGmZObf1YJH3Lkjqk3ut0uTY7qsb8Q23+zz/k= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qdxsB-ncBFGP for ; Fri, 12 Jul 2019 05:13:03 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 12 Jul 2019 05:13:02 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 992AF4AA; Thu, 11 Jul 2019 23:13:01 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 992AF4AA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8CB5841064B9 for ; Thu, 11 Jul 2019 23:13:01 -0400 (EDT) Date: Thu, 11 Jul 2019 23:13:01 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; CHARSET=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: [IPsec] Public comment period for: Guide to IPsec VPNs: NIST Releases Draft of SP 800-77 Rev. 1 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 03:13:10 -0000 FYI, From: NIST Computer Security Division Subject: Guide to IPsec VPNs: NIST Releases Draft of SP 800-77 Rev. 1 Date: Tuesday, July 2, 2019 at 3:32 PM NIST invites comments on Draft Special Publication (SP) 800-77 Revision 1, Guide to IPsec VPNs, which contains practical recommendations for implementing security services based on IPsec and IKE to assist organizations in mitigating the risks associated with transmitting sensitive information across networks. Since the original publication of SP 800-77 in 2005, IPsec and IKE protocols have been enhanced, and much operational experience has been gained from the security solutions deployed. This revision contains new security and cryptographic recommendations and requirements with a focus on how IPsec provides network layer security services. The document also describes how organizations can implement IPsec, IKE, and their alternatives under varying circumstances. A public comment period for this document is open until October 8, 2019. See the publication details for a copy of the document and instructions for submitting comments. Publication details:| https://csrc.nist.gov/publications/detail/sp/800-77/rev-1/draft CSRC update: https://csrc.nist.gov/news/2019/nist-releases-draft-sp-800-77-rev-1-for-comment  Paul From nobody Fri Jul 12 00:35:13 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1760120128 for ; Fri, 12 Jul 2019 00:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IHPyjaNw_VRu for ; Fri, 12 Jul 2019 00:35:09 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5637D120096 for ; Fri, 12 Jul 2019 00:35:09 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id w13so8326953eds.4 for ; Fri, 12 Jul 2019 00:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Pe03So1Nv2vKM5Fe/P2RKcr4a00nUAZ+ikqnjkdVyiI=; b=QFcTlNna6DHACcJPmHwNZoo+Z5nlO9eopSG7V6RhOBZ7w1q37PeFMcOtP6jAfiqZue rX2kfKyY71WVpkY5zCfo+3soQGj89XYJY3R30MqpgCrP+xImpbKJ2S7RVbxUnLkyl0F4 +rqLXyL/LqebZGxTmQsDyECv9i+9k885GXClxTxRd5Roz1lp2nMsww/GC54YgZCvTGxk jtIOPMvYqv1k5+ladWQ1wyi7ZZUi90cSGkROPAFKaZb3twQXIxijEFRQYE8Pt3VWQCg0 BWcMPMVBh1Z9tkpm5Jr6zFOqEvULjDnojXvnMqE/CRln1id9RlRsVH1skDeqFIyHvqmS wtSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Pe03So1Nv2vKM5Fe/P2RKcr4a00nUAZ+ikqnjkdVyiI=; b=BNZ+lZlD4jV04Z/M/j6o1sReN5PoY7EQliwk97IBKgpp/4kvteH+oDahMIHJw5jR5c g+VFtWm//dgexOKFkQqZaxulciYzIkH0pxYGEFW0bc9S/84L9JTVt6C7zTra9zRiyr2y rahCObNDraUTOYQU17MbQcuroTWEs0ni57k0L8oBnm0Z4jQMAEJbWaB0HbM3pzCbRQ8F k4/e2kaoSoy2Jg0u1gj8uVMGYiMPbbmnzRTPoRc+uILNV0W8Rlf2hzK7b6lyARVeqWN+ X0+mv6W+gareT5RVFY3CnncVlxJpYK03kKPTuzb5xqrb9Hc9igBBq6puT2TlniPsuYcr 4j4A== X-Gm-Message-State: APjAAAVUYKdpvd7Uw6jzQCtib+nOcIsI+mkdpRiYnSIYx15iY3AQmK67 iao0NFKo8auxgyz9sTmse2U= X-Google-Smtp-Source: APXvYqwQ2f8WO0aLYZ+JUnUvgtbTBFRLw+xzoZylWKdUkGEdoXET1MHgOXgYlQvK4WSOMJus4moYMQ== X-Received: by 2002:a17:906:4acc:: with SMTP id u12mr6738606ejt.41.1562916907786; Fri, 12 Jul 2019 00:35:07 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id a3sm1571053ejb.83.2019.07.12.00.35.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Jul 2019 00:35:07 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Yaron Sheffer'" , "'Hannes Tschofenig'" , Cc: "'vinay kornapalli'" References: In-Reply-To: Date: Fri, 12 Jul 2019 10:34:57 +0300 Message-ID: <023401d53884$4f00aae0$ed0200a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7GMB6pW49T1HsJGbqfwQ0VbE//aZ60BDA Content-Language: ru Archived-At: Subject: Re: [IPsec] Questions about RFC 5723 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 07:35:12 -0000 Hi Paul, speaking as someone who implemented the IKE resumption. > Hi, > > I'm a little confused about some parts in RFC 5723 > > The first is about which SA's can be resumed. The introduction leaves > this ambiuous: > > To re-establish security associations (SAs) upon a failure recovery > condition is time-consuming, > > It does not say IKE SA or IPsec SA. And I have a feeling it depends a > bit on what you call "resumption". Only IKE SA is meant. > It then talks about resuming the IKE SAs.... Reading more, it seems > IPsec SA's are not "resumed" but "created from scratch"? Yes. > I also see: > > If a client temporarily loses network connectivity (and the IKE SA > times out through the liveness test facility, a.k.a. "dead peer > detection") > > This is also a little confusing for IKE and IPsec states, because the > liveness test is for an IPsec SA, not an IKE SA. But it is send via an > IKE SA. That is, if an IPsec SA has no outgoing traffic, there would > never be a check using IKE for this. So it is kind of misusing the fact > that the IKE SA is used for liveness tests to check on the status of > the IKE SA. I believe the authors meant that liveness check was triggered by traffic over IPsec SA, but resulted in timeout of IKE SA and thus deletion of IKE SA and all its children. > In 4.3.4 I see: > > Following the IKE_AUTH exchange, a new IKE SA is created by both > parties, see Section 5, and a Child SA is derived, per Section 2.17 > of [RFC4306]. > > Which Child SA? If the peers had more then one IPsec SA, how does one > determine which IPsec SA to generate key material for first? Because > this paragraph does not talk about a new CREATE_CHILD_SA, it looks as if > the child sa derivation would not need another Exchange, but I can find > no information on how this would be done, unless we just pull KEYMAT > from the new SKEYSEED, but then child SA and ordering is completely > unspecified and this could only work when there is a single IPsec SA for > the IKE SA? A single (pair of ) IPsec SA is created as result of IKE_AUTH following IKE_SA_RESUME, as if it follows IKE_SA_INIT instead of IKE_SA_RESUME. If more IPsec SAs are needed they are created via CREATE_CHILD_SA, as usual. > And this is the really confusing part in section 5: > > IKE and IPsec State after Resumption > > During the resumption process, both peers create IKE and IPsec state > for the resumed IKE SA. Although the SA is only completed following > a successful IKE_AUTH exchange, many of its components are created > earlier, notably the SA's crypto material > > So here too it says "create IKE and IPsec state". Which IPsec state > first? Then it talks about "the SA" and "the SA's" ? The IPsec SA you want to encrypt traffic with. Usually you have an outgoing traffic that triggers IPsec SA creation. If you don't have IKE SA at the moment, you create one with IKE_SA_INIT and then create IPsec SA for the traffic in the IKE_AUTH. With IKE resumption the only difference is that the initiator somehow determines that it has a ready to use ticket from the responder and instead of initiating IKE_SA_INIT it initiates IKE_SESSION_RESUME. The IPsec SA related stuff in the IKE_AUTH (traffic selectors, algorithms negotiation, cfg payload etc) is not affected by resumption. > My guess is that we first pull key material for the IKE SA, and then for > one of the IPsec SA's (perhaps this document assumes there is only 1 > IPsec SA for any IKE SA that can be resumed?). Or based on Note 6: > > Note 6: Since information about Child SAs and configuration payloads > is not resumed, IKEv2 features related to Child SA > negotiation (such as IPCOMP_SUPPORTED, > ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec [ROHCoIPsec] > and configuration) aren't usually affected by session > resumption. > > Perhaps what is meant is that a session resumption only resumed a > childless IKE SA, and now the initiator must do CREATE_CHILD_SA's for > each IPsec SA it wants to have again (not really "resumption", as these > are created "from scratch" like regular CREATE_CHILD_SA? No, one IPsec SA can be created in the IKE_AUTH (usually the IPsec SA you are in immediate need to protect the outgoing traffic). Other IPsec SAs can be later created via CREATE_CHILD_SA. > Also, when using PFS, these CREATE_CHILD_SA's would do a DH again, at > which point one wonders why to do resumption at all if you have more > than one IPsec SA, as you would be doing DH's anyway for all children, > you might as well do one more for a regular IKE_SA_INIT ? In any case you save on authentication (this may involve signature computing/verification and probably human intervention in case of EAP). > So the essense of my question is: Am I correct that an IKE session > resumption only resumes the IKE SA, and that all IPsec SA's need to be > re-negotiated using CREATE_CHILD_SA ? You are correct that IKE session resumption only resumes IKE SA. However, one IPsec SA can be created in the IKE_AUTH as part of session resumption, the others must be created via CREATE_CHILD_SA. > Secondary question: When using pfs=yes, what is the envisioned behaviour > of CREATE_CHILD_SA? Do a new DH? Or is it assumed that resumption would > be an incompatible policy with pfs=yes ? With resumption you essentially re-use DH from the old (already deleted) IKE SA for the IPsec SA that is created during resumption in the IKE_AUTH. If it is not appropriate, then resume IKE SA as childless and create all IPsec SAs via CREATE_CHILD_SA with DH. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jul 12 07:35:05 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58875120192 for ; Fri, 12 Jul 2019 07:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 10NHdVHlXcdu for ; Fri, 12 Jul 2019 07:35:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 2D9941201D5 for ; Fri, 12 Jul 2019 07:35:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45lb6p3Q0CzDZl; Fri, 12 Jul 2019 16:34:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1562942098; bh=eb9P3WV3lNwhld/Rm/T0Bosccu6LYJ2TmzmmOXncYb4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R7mwvfo8rUv/dXtkEl8NHzI9uAOzBv9BBU7WnL4sfT72Z6EbMuqHB+cSgvXJPVcff HVP0CDjeMYoYiLERaCyxm6dWu7YXjcZ1uyBeWR1B6CSCDZTOK7DywXBVCblFW/aLPy ADuTr6p2Lho83mBPH9YLo/pFpeJjaQog3M+B3Cbg= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id VaQzhQ0V2FAH; Fri, 12 Jul 2019 16:34:57 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 12 Jul 2019 16:34:56 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5291B4392F0; Fri, 12 Jul 2019 10:34:55 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5291B4392F0 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4D449406B8FB; Fri, 12 Jul 2019 10:34:55 -0400 (EDT) Date: Fri, 12 Jul 2019 10:34:55 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: 'Yaron Sheffer' , 'Hannes Tschofenig' , ipsec@ietf.org, 'vinay kornapalli' In-Reply-To: <023401d53884$4f00aae0$ed0200a0$@gmail.com> Message-ID: References: <023401d53884$4f00aae0$ed0200a0$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Questions about RFC 5723 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 14:35:03 -0000 On Fri, 12 Jul 2019, Valery Smyslov wrote: > A single (pair of ) IPsec SA is created as result of IKE_AUTH following > IKE_SA_RESUME, as if it follows IKE_SA_INIT instead of IKE_SA_RESUME. > If more IPsec SAs are needed they are created via CREATE_CHILD_SA, > as usual. Ahhhhh I totally missed this part when reading the document. Things make a lot more sense now. Thanks! >> Also, when using PFS, these CREATE_CHILD_SA's would do a DH again, at >> which point one wonders why to do resumption at all if you have more >> than one IPsec SA, as you would be doing DH's anyway for all children, >> you might as well do one more for a regular IKE_SA_INIT ? > > In any case you save on authentication (this may involve signature > computing/verification and probably human intervention in case of EAP). Indeed. Thanks for the clarifications! I guess formally, we would need to add the previous IKE traffic counters to the current one, since these are all derived from the same DH. (yes, for FIPS we need to ensure there is not more than 2^20 or so AES packets of IKE traffic, even though reaching that would be quite the accomplishment) Paul From nobody Fri Jul 12 08:39:35 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89786120700 for ; Fri, 12 Jul 2019 08:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eX_jQlc8uvqX for ; Fri, 12 Jul 2019 08:39:32 -0700 (PDT) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC215120714 for ; Fri, 12 Jul 2019 08:39:28 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id g17so10438689wrr.5 for ; Fri, 12 Jul 2019 08:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6uXHxuarYSNKe4FuZMrRZVd0ElQwCWnl3rdoV/Zbrdc=; b=o/Ht1LQi5o1zPD2WiriqtMn7a7H3Br9wFvJ8dqfFSdTyUEFhpnypjfCgC9zQQvNhLj qCLW3ZEMUwDueH0Oyj+oGBnwX1rFl/2fuJYErshT7VBUS9acD0MhSt1AMLYqtpwWTQ8z uDwShwjsfkJVoGBFwSOcD+0HWtaiRLOUxeJAPfrLDJS8iJF36JsjK7XXX6rikHUdfSl2 kE3UrI8dNUArRh3G0Qswditna1YmQar1NlN2aO8MVv3x46wySJJfiB8/dvUw3rEpU2vi 7Dd/NRhzbeujcZckhk309YDHKFE0nfhg2Q+HDcJiIygX5YxrGmMeUao1h7mCEUi44U7q NZCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6uXHxuarYSNKe4FuZMrRZVd0ElQwCWnl3rdoV/Zbrdc=; b=K/vLKdCFL4AFyYNkMd1nuCfCJeYc+8lTrV3Lx6vcAaKDJdZe+8GU6tXiSeYFWezcGP s31tX0ewvN7GOI73xnWRdJOA87Uznf9ABrbV9N8+L0F+6RiFTmxYux/fU7Dhro0oEY4Q jJHIsCL6PD/qrRMlEL9BPa8Wjo8XzkImxTl8nPZrgIpszStWEUaRVlA2opsUz510yu5h Pw12b9FKhVQfzHlbAzT0g5FfuZ0eip8bY0E4EpUb2M2Jt63wV9oQTWSIZCpK9KXD11IQ 9IT61nUS4VCY2/B74nRy5RFklsHsTrwoEtHsKOGPEpu0JbQ3eE4uCclTDB7RT5Nceqve Nrww== X-Gm-Message-State: APjAAAWlcdYfHR7C0cdOa7kmta7p5HLUbHk0dJ3kcyLo48SO78GIq2yM 5Aekn4ZEqwrxje0fdL8YKig= X-Google-Smtp-Source: APXvYqxtAHa/DByvnDSUyUDziqnMoOx6/msLGI/DCXS3zuzQueRxTZcBjzRsKpGAteHuFMMLVVsUag== X-Received: by 2002:adf:f8cf:: with SMTP id f15mr12115848wrq.333.1562945967515; Fri, 12 Jul 2019 08:39:27 -0700 (PDT) Received: from [10.0.0.156] (bzq-79-180-44-139.red.bezeqint.net. [79.180.44.139]) by smtp.gmail.com with ESMTPSA id w7sm9844763wrn.11.2019.07.12.08.39.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jul 2019 08:39:26 -0700 (PDT) To: Paul Wouters , Valery Smyslov Cc: 'Hannes Tschofenig' , ipsec@ietf.org, 'vinay kornapalli' References: <023401d53884$4f00aae0$ed0200a0$@gmail.com> From: Yaron Sheffer Message-ID: <8168d370-68a6-b376-6187-22f7756d17f3@gmail.com> Date: Fri, 12 Jul 2019 18:39:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] Questions about RFC 5723 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 15:39:34 -0000 Paul, please don't hesitate to submit an editorial erratum if you think one is needed. If you don't "get" this RFC, it probably means something is missing. Thanks, Yaron On 12/07/2019 17:34, Paul Wouters wrote: > On Fri, 12 Jul 2019, Valery Smyslov wrote: > >> A single (pair of ) IPsec SA is created as result of IKE_AUTH following >> IKE_SA_RESUME, as if it follows IKE_SA_INIT instead of IKE_SA_RESUME. >> If more IPsec SAs are needed they are created via CREATE_CHILD_SA, >> as usual. > > Ahhhhh I totally missed this part when reading the document. Things make > a lot more sense now. Thanks! > >>> Also, when using PFS, these CREATE_CHILD_SA's would do a DH again, at >>> which point one wonders why to do resumption at all if you have more >>> than one IPsec SA, as you would be doing DH's anyway for all children, >>> you might as well do one more for a regular IKE_SA_INIT ? >> >> In any case you save on authentication (this may involve signature >> computing/verification and probably human intervention in case of EAP). > > Indeed. Thanks for the clarifications! > > I guess formally, we would need to add the previous IKE traffic counters > to the current one, since these are all derived from the same DH. > > (yes, for FIPS we need to ensure there is not more than 2^20 or so AES > packets of IKE traffic, even though reaching that would be quite the > accomplishment) > > Paul From nobody Tue Jul 16 03:02:31 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122A8120222 for ; Tue, 16 Jul 2019 03:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xREHuGJdPiZu for ; Tue, 16 Jul 2019 03:02:27 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BDFCE1201EF for ; Tue, 16 Jul 2019 03:02:27 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D77F225480ABF4BA5C12; Tue, 16 Jul 2019 11:02:25 +0100 (IST) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 16 Jul 2019 11:02:24 +0100 Received: from DGGEMM505-MBX.china.huawei.com ([169.254.1.3]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Tue, 16 Jul 2019 18:02:08 +0800 From: Sandeep Kampati To: Michael Richardson , "ipsec@ietf.org" CC: "Meduri S S Bharath (A)" , "Shengde (DOPRA VISP)" Thread-Topic: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 Thread-Index: AQHVMcYqVQOAgpHiFECjRuyLgEYcpabND9Xw Date: Tue, 16 Jul 2019 10:02:07 +0000 Message-ID: <2DA788A5A7D91747AEA54B502558D73828253F93@DGGEMM505-MBX.china.huawei.com> References: <21677.1562175502@localhost> In-Reply-To: <21677.1562175502@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.152.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 10:02:30 -0000 Hi Michael Richardson, In Case of ESP=20 Sai2 =3D SA + Proposal + 3 transforms (1. Encryption 2. Integrity 3.Ext= ended Sequence Number ) Minimum Size of SA payload is 40 Bytes =3D (SA) 4 + (Proposal + SPI )12 += (3 transforms [3*8]) 24, SA payload size for ENCR_AES is 44 bytes REKEY_SA(12) + SA (40) + 48 (2x TSx 24 * 2) + Ni 20 bytes =3D 120 bytes = (IPv4). REKEY_SA(12) + SAi2 (40bytes) + 96 (2x TSx 48 * 2 )+ Ni 20 bytes =3D 16= 8 bytes (IPv6). REKEY_SA(12)+ SA_TS_UNCHANGED (12) + Ni 20 bytes =3D 44 bytes (IPv4). REKEY_SA(12)+ SA_TS_UNCHANGED (12) + Ni 20 bytes =3D 44 bytes (IPv6). KEx =3D 8 + 32 bytes (256-bit ECDSA) =3D 40 bytes. all ts-opt %Saved all-ke ts-opt-ke %Saved IPv4: 120 44 63% 160 84 47 % IPv6: 168 44 70% 208 84 59% If we send more number of cryptographic suits the percentage of saving will= increase=20 Most if deployment scenario what I observed is initiator is sending at leas= t 5 cryptographic suits, in some deployment scenarios they are sending 120 = cryptographic suites If more cryptographic suites are configured the saving with will increase e= xponential. Regards, Sandeep.k >> It might be worth putting the nonce into the SA_TS_UNCHANGED payload, as= that saves another 4 bytes. --> this also good suggestion we -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 Sent: 03 July 2019 23:08 To: Sandeep Kampati ; ipsec@ietf.org Cc: Meduri S S Bharath (A) Subject: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 Sandeep, I read the document this past week. I found the claim that the TS and SA details were worth optimizing to be su= rprising. So I counted the size of the CHILDSA proposal. This means the SAi2, TSi and TSr in the initiator, With the responder provi= ding SAr2, TSi and TSr. HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] TSi, TSr} --> TSx =3D 8 (header) + 8 + 8 =3D 24 (IPv4) 8 + 8 + 32 =3D 48 (IPv6) SAi2=3D 8+4(SPI) + transforms transforms =3D 8+ 4(cipher)+ 4(integ) =3D 16 bytes total =3D 28 bytes. Ni =3D 4 + nonce-size (16+ bytes) N(REKEY_SA) =3D 8 bytes. total: SAi2 (28bytes) plus 2x TSx 24 * 2 + Ni 20 bytes + N 8=3D 104 bytes (= IPv4). SAi2 (28bytes) plus 2x TSx 48 * 2 + Ni 20 bytes + N 8=3D 152 bytes (= IPv6). I have not included KEi, as you did in your section 3.2.1, because I assume= that if computation and netweork resources are at premium, that doing addi= tional exponentiation is inappropriate. Maybe a new DH every N rekeys. KEx =3D 8 + 32 bytes (256-bit ECDSA) =3D 40 bytes. potentially there are some notifications, at 8 bytes each, potentially long= er. Replacing this with a single 16-byte Notify would be a win on total by= tes, but as it does not reduce the number of packets at all, I'm still havi= ng difficulty believing it really matters. It might be worth putting the nonce into the SA_TS_UNCHANGED payload, as th= at saves another 4 bytes. A new Ni/Nr is needed each time as the child SA key derivation needs that f= reshness. So, the math is: all ts-opt all-ke ts-opt-ke IPv4: 104 36 144 74 IPv6: 152 36 202 74 {There are some assumptions that I have made in this calculation. Probably some mistakes, so if an important argument point, I'll post a Goog= le Calc page with my assumptions. The cost of KE size with DH groups would be bigger than with ECDH groups. = } -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Tue Jul 16 05:42:59 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833AC120412; Tue, 16 Jul 2019 05:42:49 -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 J8U043Bzk-2j; Tue, 16 Jul 2019 05:42:45 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [IPv6:2001:720:1710:601::42]) by ietfa.amsl.com (Postfix) with ESMTP id 204AB12004F; Tue, 16 Jul 2019 05:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 8D4AE1FF1C; Tue, 16 Jul 2019 14:42:40 +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 ZX4_1DnDfU3h; Tue, 16 Jul 2019 14:42:40 +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 79E3A1FE6A; Tue, 16 Jul 2019 14:42:37 +0200 (CEST) From: Rafa Marin-Lopez Content-Type: multipart/alternative; boundary="Apple-Mail=_C449926D-3684-4DC9-BC8B-A54674982BAD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 16 Jul 2019 14:42:35 +0200 References: <156253524318.473.14686910090362577746@ietfa.amsl.com> Cc: Rafa Marin-Lopez , "ipsec@ietf.org WG" , Gabriel Lopez , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , mbj@tail-f.com To: i2nsf@ietf.org Message-Id: <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [IPsec] Fwd: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 12:42:49 -0000 --Apple-Mail=_C449926D-3684-4DC9-BC8B-A54674982BAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all: We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 - We have dealt with YANG doctors=E2=80=99 review (Martin's) - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. - We have added more specific text in the descriptions. - Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller. - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. - We have added a subsection 5.3.4 about NSF discovery by the Security = Controller. - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: typedef encryption-algorithm-type { type uint32; description=20 "The encryption algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference=20 "IANA Registry- Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } - We have included three additional Annexes with examples in about the = usage of the YANG model. - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. Best Regards. > Inicio del mensaje reenviado: >=20 > De: internet-drafts@ietf.org > Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt > Fecha: 7 de julio de 2019, 23:34:03 CEST > Para: > Cc: i2nsf@ietf.org > Responder a: i2nsf@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Interface to Network Security = Functions WG of the IETF. >=20 > Title : Software-Defined Networking (SDN)-based IPsec = Flow Protection > Authors : Rafa Marin-Lopez > Gabriel Lopez-Millan > Fernando Pereniguez-Garcia > Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt > Pages : 81 > Date : 2019-07-07 >=20 > Abstract: > This document describes how providing IPsec-based flow protection by > means of a Software-Defined Network (SDN) controller (aka. Security > Controller) and establishes the requirements to support this = service. > It considers two main well-known scenarios in IPsec: (i) gateway-to- > gateway and (ii) host-to-host. The SDN-based service described in > this document allows the distribution and monitoring of IPsec > information from a Security Controller to one or several flow-based > Network Security Function (NSF). The NSFs implement IPsec to = protect > data traffic between network resources. >=20 > The document focuses on the NSF Facing Interface by providing models > for configuration and state data required to allow the Security > Controller to configure the IPsec databases (SPD, SAD, PAD) and = IKEv2 > to establish Security Associations with a reduced intervention of = the > network administrator. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection-05 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 ------------------------------------------------------- --Apple-Mail=_C449926D-3684-4DC9-BC8B-A54674982BAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear= all:

We submitted a new version of the I-D (v05) = where we have applied several changes. In the following you have a = summary of the main changes, which we will expand/explain during our = presentation: 

- We have dealt with YANG doctors=E2=80=99= review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.

- = We have added more specific text in the descriptions.

- = Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller.

- State data has been reduced. For example, in = IKE case, most of the information is related with IKE and not with the = specific details about IPsec SAs that IKE handles (after all, IKE can = abstract this information from the Security = Controller).

- We have included text in the security section to discuss = about the default IPsec policies that should be in the NSF when it = starts before contacting with the SC such as the IPsec policies required = to allow traffic between the SC and the NSF.

- We have added a subsection 5.3.4 = about NSF discovery by the Security Controller.

- = In order to specify the crypto-algorithms we have used a simple approach = by including an integer and adding a text pointing the = IANA in the reference clause. For example:

typedef encryption-algorithm-type {
          &nb= sp;type uint32;
          &nb= sp;description 
          &nb= sp;    "The encryption algorithm is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          &nb= sp;    values MUST follow the requirement levels = for
          &nb= sp;    encryption algorithms for ESP and = IKEv2.";
          &nb= sp;reference 
          &nb= sp;     "IANA Registry- Transform Type 1 - = Encryption
          &nb= sp;     Algorithm Transform IDs. RFC 8221 - = Cryptographic
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for Encapsulating Security = Payload (ESP)
          &nb= sp;     and Authentication Header (AH) and RFC = 8247 -
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for the Internet Key Exchange = Protocol
          &nb= sp;     Version 2 (IKEv2).";
       }

- We have included three additional Annexes with examples in = about the usage of the YANG model.

- We have = performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without = warnings.

Best = Regards.

Inicio del mensaje reenviado:

De: = internet-drafts@ietf.org
Asunto: = [I2nsf] I-D = Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Fecha: = 7 de julio de 2019, 23:34:03 = CEST
Para: = <i-d-announce@ietf.org>
Cc: i2nsf@ietf.org
Responder a: = i2nsf@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Interface to = Network Security Functions WG of the IETF.

=        Title =           : = Software-Defined Networking (SDN)-based IPsec Flow Protection
       Authors =         : Rafa Marin-Lopez
=             &n= bsp;           &nbs= p;Gabriel Lopez-Millan
=             &n= bsp;           &nbs= p;Fernando Pereniguez-Garcia
Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Pages =           : 81
= Date =            : = 2019-07-07

Abstract:
=   This document describes how providing IPsec-based flow = protection by
  means of a Software-Defined = Network (SDN) controller (aka.  Security
=   Controller) and establishes the requirements to support this = service.
  It considers two main well-known = scenarios in IPsec: (i) gateway-to-
  gateway = and (ii) host-to-host.  The SDN-based service described in
  this document allows the distribution and = monitoring of IPsec
  information from a = Security Controller to one or several flow-based
=   Network Security Function (NSF).  The NSFs implement = IPsec to protect
  data traffic between network = resources.

  The document = focuses on the NSF Facing Interface by providing models
=   for configuration and state data required to allow the = Security
  Controller to configure the IPsec = databases (SPD, SAD, PAD) and IKEv2
  to = establish Security Associations with a reduced intervention of the
  network administrator.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-05


Please = note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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




= --Apple-Mail=_C449926D-3684-4DC9-BC8B-A54674982BAD-- From nobody Tue Jul 16 10:30:28 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E155D120B08; Tue, 16 Jul 2019 10:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Wj1ZmAPqJQQh; Tue, 16 Jul 2019 10:30:17 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B008120B03; Tue, 16 Jul 2019 10:30:17 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id k8so21139298edr.11; Tue, 16 Jul 2019 10:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=S7RpZ3jAfo8/B/KVVZeORSzwjjUzE+aTL5NVQ0UZmi4=; b=Btlxf/jf6IwAeD5XgR2gl0i7o3INdeH1KckddLTnswMfkY/UYhHw+ovsSQWz0mJpFn sKI+REMRpQx8hnJp4S4fGS4p07u0VlOrhYbjh3iIyhIo6YYH9yjrV1vNBM1rNXiYbb7Q 0mpVTnwMgKJFDDw0PHnguPRL+DDc2udD+igmMvJKUYfOJr2XTU7bXgxLN0RWkPDrsdaJ jlkQRbcNaVEkOYiROEp8fkk80umCBcetN3yQwG3RC3pcbvx29niex9sD7O2Sl+SoIgxF v1AkVmVMYgT4vEWAFrs1RBa3fLjoLM+VNkS+udob0IXI0Fa7CntpatoK7fYlmBavZpDe 2RyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=S7RpZ3jAfo8/B/KVVZeORSzwjjUzE+aTL5NVQ0UZmi4=; b=LbM23YrNRd7ct5YbOQcwXrXrr6+YRgtGMijErbtgfpylzVP4lrcZ20SkkwdAF951mx kWNhKqSXDpKbjSlWcKSSvQJsAo3e+APlaplJHeqgb9vN/IRhjlMsfGbs59QC7VtfDPtn pqBTCIfCbaAdbANsiyJxFnN9fH5IaTqatDJW9QtqkgiEHgPBds8SGRA1Jf7wR+3W0kmx wYEfjFn2VvvmxKb/UXpfYUPUWXol0bpFqSxK81fiTSNTfAbTfb9i+HI33655LL3uLDWP lkg5Xmxb3OS0k7h9n8UVqc21qG/G3uHobz90GVlh6HWbAtYM4Wo+/cMgSWS35zlFNbPg kgaA== X-Gm-Message-State: APjAAAVXgqlnaFzpqJX8/Fe8P48q0OeAFcdmgtScz36JPzFGfcaKezFf 5AaPeoBoFSDmvYBrIteYGGk= X-Google-Smtp-Source: APXvYqwheCvwCfz8j3JNlF0ysCVCMo+A/msC14Grgxo8BFaT1mZuMRAzfygLv7XahagmQzzaqM72TQ== X-Received: by 2002:a50:b554:: with SMTP id z20mr30288328edd.296.1563298215457; Tue, 16 Jul 2019 10:30:15 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g7sm6133295eda.52.2019.07.16.10.30.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 10:30:13 -0700 (PDT) From: Yoav Nir Message-Id: <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3BB12C0A-463C-4E2C-B445-F961C82A5059" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 16 Jul 2019 20:30:10 +0300 In-Reply-To: <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> Cc: i2nsf@ietf.org, "ipsec@ietf.org WG" , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , Gabriel Lopez , mbj@tail-f.com To: Rafa Marin-Lopez References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 17:30:20 -0000 --Apple-Mail=_3BB12C0A-463C-4E2C-B445-F961C82A5059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for getting this done and published. We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. Barring any such shouting, we will request publication right after the = meeting. Thanks again, Linda and Yoav > On 16 Jul 2019, at 15:42, Rafa Marin-Lopez wrote: >=20 > Dear all: >=20 > We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 >=20 > - We have dealt with YANG doctors=E2=80=99 review (Martin's) >=20 > - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. >=20 > - We have added more specific text in the descriptions. >=20 > - Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller. >=20 > - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). >=20 > - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. >=20 > - We have added a subsection 5.3.4 about NSF discovery by the Security = Controller. >=20 > - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: >=20 > typedef encryption-algorithm-type { > type uint32; > description=20 > "The encryption algorithm is specified with a 32-bit > number extracted from IANA Registry. The acceptable > values MUST follow the requirement levels for > encryption algorithms for ESP and IKEv2."; > reference=20 > "IANA Registry- Transform Type 1 - Encryption > Algorithm Transform IDs. RFC 8221 - Cryptographic > Algorithm Implementation Requirements and Usage > Guidance for Encapsulating Security Payload (ESP) > and Authentication Header (AH) and RFC 8247 - > Algorithm Implementation Requirements and Usage > Guidance for the Internet Key Exchange Protocol > Version 2 (IKEv2)."; > } >=20 > - We have included three additional Annexes with examples in about the = usage of the YANG model. >=20 > - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. >=20 > Best Regards. >=20 >> Inicio del mensaje reenviado: >>=20 >> De: internet-drafts@ietf.org >> Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >> Fecha: 7 de julio de 2019, 23:34:03 CEST >> Para: > >> Cc: i2nsf@ietf.org >> Responder a: i2nsf@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Interface to Network Security = Functions WG of the IETF. >>=20 >> Title : Software-Defined Networking (SDN)-based = IPsec Flow Protection >> Authors : Rafa Marin-Lopez >> Gabriel Lopez-Millan >> Fernando Pereniguez-Garcia >> Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >> Pages : 81 >> Date : 2019-07-07 >>=20 >> Abstract: >> This document describes how providing IPsec-based flow protection = by >> means of a Software-Defined Network (SDN) controller (aka. = Security >> Controller) and establishes the requirements to support this = service. >> It considers two main well-known scenarios in IPsec: (i) = gateway-to- >> gateway and (ii) host-to-host. The SDN-based service described in >> this document allows the distribution and monitoring of IPsec >> information from a Security Controller to one or several flow-based >> Network Security Function (NSF). The NSFs implement IPsec to = protect >> data traffic between network resources. >>=20 >> The document focuses on the NSF Facing Interface by providing = models >> for configuration and state data required to allow the Security >> Controller to configure the IPsec databases (SPD, SAD, PAD) and = IKEv2 >> to establish Security Associations with a reduced intervention of = the >> network administrator. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ = >>=20 >> There are also htmlized versions available at: >> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 >> = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection-05 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-05 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf >=20 > ------------------------------------------------------- > 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:=C2=A0rafa@um.es = > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf --Apple-Mail=_3BB12C0A-463C-4E2C-B445-F961C82A5059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for getting this done and published.

We will wait with requesting = publication until the I2NSF session next week.  Between now and = then, please re-read the draft and send a message to the list is = something is seriously wrong.

Barring any such shouting, we will = request publication right after the meeting.

Thanks again,

Linda and Yoav

On 16 = Jul 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> wrote:

Dear all:

We submitted a new version of the I-D (v05) where we = have applied several changes. In the following you have a summary of the = main changes, which we will expand/explain during our = presentation: 

- We have dealt with = YANG doctors=E2=80=99 review (Martin's)

- We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99= s comments.

- = We have added more specific text in the descriptions.

- Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller.

- State data has been = reduced. For example, in IKE case, most of the information is related = with IKE and not with the specific details about IPsec SAs that IKE = handles (after all, IKE can abstract this information from the Security = Controller).

- We have included text in the security section to discuss = about the default IPsec policies that should be in the NSF when it = starts before contacting with the SC such as the IPsec policies required = to allow traffic between the SC and the NSF.

- We have added a subsection 5.3.4 = about NSF discovery by the Security Controller.

- In order to specify = the crypto-algorithms we have used a simple approach by including an = integer and adding a text pointing the IANA in the reference clause. For = example:

typedef encryption-algorithm-type {
          &nb= sp;type uint32;
          &nb= sp;description 
          &nb= sp;    "The encryption algorithm is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          &nb= sp;    values MUST follow the requirement levels = for
          &nb= sp;    encryption algorithms for ESP and = IKEv2.";
          &nb= sp;reference 
          &nb= sp;     "IANA Registry- Transform Type 1 - = Encryption
          &nb= sp;     Algorithm Transform IDs. RFC 8221 - = Cryptographic
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for Encapsulating Security = Payload (ESP)
          &nb= sp;     and Authentication Header (AH) and RFC = 8247 -
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for the Internet Key Exchange = Protocol
          &nb= sp;     Version 2 (IKEv2).";
       }

- We have included three additional Annexes = with examples in about the usage of the YANG model.

- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without warnings.

Best Regards.

Inicio = del mensaje reenviado:

De: internet-drafts@ietf.org
Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Fecha: 7 de julio de 2019, 23:34:03 CEST
Para: <i-d-announce@ietf.org>
Cc: i2nsf@ietf.org
Responder a: = i2nsf@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Interface to = Network Security Functions WG of the IETF.

=        Title =           : = Software-Defined Networking (SDN)-based IPsec Flow Protection
       Authors =         : Rafa Marin-Lopez
=             &n= bsp;           &nbs= p;Gabriel Lopez-Millan
=             &n= bsp;           &nbs= p;Fernando Pereniguez-Garcia
Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Pages =           : 81
= Date =            : = 2019-07-07

Abstract:
=   This document describes how providing IPsec-based flow = protection by
  means of a Software-Defined = Network (SDN) controller (aka.  Security
=   Controller) and establishes the requirements to support this = service.
  It considers two main well-known = scenarios in IPsec: (i) gateway-to-
  gateway = and (ii) host-to-host.  The SDN-based service described in
  this document allows the distribution and = monitoring of IPsec
  information from a = Security Controller to one or several flow-based
=   Network Security Function (NSF).  The NSFs implement = IPsec to protect
  data traffic between network = resources.

  The document = focuses on the NSF Facing Interface by providing models
=   for configuration and state data required to allow the = Security
  Controller to configure the IPsec = databases (SPD, SAD, PAD) and IKEv2
  to = establish Security Associations with a reduced intervention of the
  network administrator.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-05


Please = note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

= --Apple-Mail=_3BB12C0A-463C-4E2C-B445-F961C82A5059-- From nobody Tue Jul 16 11:23:56 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE18B120CF6 for ; Tue, 16 Jul 2019 11:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1uKagTL0uwz2 for ; Tue, 16 Jul 2019 11:23:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFCE120CF3 for ; Tue, 16 Jul 2019 11:23:51 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id CA3D53808A; Tue, 16 Jul 2019 14:23:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 84940B52; Tue, 16 Jul 2019 14:23:50 -0400 (EDT) From: Michael Richardson To: Sandeep Kampati cc: "ipsec\@ietf.org" , "Meduri S S Bharath \(A\)" , "Shengde \(DOPRA VISP\)" In-Reply-To: <2DA788A5A7D91747AEA54B502558D73828253F93@DGGEMM505-MBX.china.huawei.com> References: <21677.1562175502@localhost> <2DA788A5A7D91747AEA54B502558D73828253F93@DGGEMM505-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 18:23:55 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I wasn't sure from your reply if you agreed with my numbers, or wanted to revise them. I think some numbers should go into the document, do you? Sandeep Kampati wrote: > Most if deployment scenario what I observed is initiator is sending at > least 5 cryptographic suits, in some deployment scenarios they are > sending 120 cryptographic suites 5 suites makes sense. 120 does not sense to me, do you know what the combinatorics involved are? Since the gateway picks one and replies, the situation where the gateway wants to continue with the same one, there doesn't seem to be that much sav= ings. > If more cryptographic suites are configured the saving with will > increase exponential. I don't think it's *exponential*, I think it's linear per connection :-) If you want to count savings per gateway, then it's O(n*m) where n=3Dnumber= of clients, m=3Dnumber of suites. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uFjYACgkQgItw+93Q 3WVC7wf/ZJ11Ut5CXA8QroqtIkOrfryAvp3F+/B6pquj870t0IWr8mDlNflN1hD1 7LzUo/J02Q9Bwmc2qK4V/EP4Crd65iJoHQN8GtVxrxvAbV8mdhJU4UBYHGG8kw4I XEhAoXE+Hi+ZhLKZihys0ii0eIZpOJlP9XnARYld+4If5hNzDPdXdbM9gLlSJ8mR 5I8lUzicInptgQCmW7kdtYcaf5n4Mal0/U34Nhw1x1w/LqV+TDPFDPKulOneYN3E 1BNQx9HvhsD7VyJUsKBmIktTm9D/OLVNfYwtjqdMWyWO0JcYYNnoE89RjNJNrDQx 1/dbJIsRN30B6tdNK3AP0IuSJuF86A== =UB2C -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 14:39:42 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D591200F3 for ; Tue, 16 Jul 2019 14:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 wFPuew3rw-Nw for ; Tue, 16 Jul 2019 14:39:39 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 EBD081200D8 for ; Tue, 16 Jul 2019 14:39:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45pDLw3w18zKqS; Tue, 16 Jul 2019 23:39:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1563313176; bh=oU8TRquPZoBu5SaiVOed2eYtR9biN5p7Qt77Amu2MvA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=JTgb+a4hQ4fSZv8VDsc9BsqaCIdAnHrI5I5GYLnFBQT0gOlvLY9MVQCn58vTyP0UI g7Hcm8OEFqxgy/5jfE0nWqiKLPlsktmBLlBHo1zXXEcm6/9LnzRz028a2KpV9NDabT Qb0x+5ydeUdD2mdE+r5k5vomluJASGKgXkTUzFVI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id PWwo4qjsBYSI; Tue, 16 Jul 2019 23:39:35 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 16 Jul 2019 23:39:34 +0200 (CEST) Received: from [193.111.228.93] (unknown [193.111.228.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 4430D4392DB; Tue, 16 Jul 2019 17:39:33 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4430D4392DB Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16F203) In-Reply-To: <2DA788A5A7D91747AEA54B502558D73828253F93@DGGEMM505-MBX.china.huawei.com> Date: Tue, 16 Jul 2019 17:39:16 -0400 Cc: "ipsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <67B39EDF-7233-4E3A-94D1-2A0DFB2193E1@nohats.ca> References: <21677.1562175502@localhost> <2DA788A5A7D91747AEA54B502558D73828253F93@DGGEMM505-MBX.china.huawei.com> To: Sandeep Kampati Archived-At: Subject: Re: [IPsec] draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 21:39:41 -0000 > On Jul 16, 2019, at 06:02, Sandeep Kampati wro= te: >=20 >=20 > If we send more number of cryptographic suits the percentage of saving wil= l increase=20 But for a rekey, the initiator could just send the currently used negotiated= transforms. It knows these are accepted / favoured. If for some reason the c= urrently used transforms are no longer accepted, it could do a new initial e= xchange after the rekey failed, or another rekey attempt with more ciphers. So the gain should not be measured against the 120 transforms. > Most if deployment scenario what I observed is initiator is sending at lea= st 5 cryptographic suits, in some deployment scenarios they are sending 120 c= ryptographic suites Strongswan is known to send everything it got. Which is a giant amount. With= debugging enabled, the entire code was so slow the exchange timed out. We h= ad to rewrite proposal parser to be smarter. But I only expect such a large set on the initial exchanges - not on rekeys.= Paul From nobody Wed Jul 17 15:32:25 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C275512062E for ; Wed, 17 Jul 2019 15:32:18 -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=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 VQNJ6QVIQlw9 for ; Wed, 17 Jul 2019 15:32:15 -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 9B78C120168 for ; Wed, 17 Jul 2019 15:32:14 -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 x6HMWCW6018014 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 18 Jul 2019 01:32:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6HMWCuN027875; Thu, 18 Jul 2019 01:32:12 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23855.41451.981782.41314@fireball.acr.fi> Date: Thu, 18 Jul 2019 01:32:11 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] IPsecME Montreal 105 IETF agenda has been posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 22:32:24 -0000 Now I finally managed to collect presentation requests from my mailbox and make an agenda for IPsecME (this IEEE meeting has been really busy here, so I have not had time to do it before). Here is the agenda for IPsecME meeting. All presentors send your slides to us (or submit them to the system for approval) as soon as possible. ---------------------------------------------------------------------- # IPsecME WG ## IETF 105, Montreal * Date: 2019-07-23 * Time: 15:20-16:50 (90 min) * Room: Sainte-Catherine * Chair: Tero Kivinen * Chair: David Waltermire --- ## Agenda ### Adminstrivia (5 min) * Agenda bashing, Logistics -- Chairs (5 min) ### Draft status -- Chairs (10 min) * draft-ietf-ipsecme-implicit-iv - Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) * draft-ietf-ipsecme-ipv6-ipv4-codes - IKEv2 Notification Status Types for IPv4/IPv6 Coexistence * draft-ietf-ipsecme-qr-ikev2 - Postquantum Preshared Keys for IKEv2 ### Work Items (25 min) * draft-ietf-ipsecme-ikev2-intermediate -- Valery Smyslov (5 min) - Intermediate Exchange in the IKEv2 Protocol * draft-ietf-ipsecme-labeled-ipsec -- Paul Wouters (5 min) - Labeled IPsec Traffic Selector support for IKEv2 * draft-yeung-g-ikev2 -- Valery Smyslov (15 min) - Group Key Management using IKEv2 ### Other presentations (35 min) * draft-tjhai-ipsecme-hybrid-qske-ikev2 -- Valery Smyslov (10 min) - Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) * draft-hopps-ipsecme-iptfs -- Christian Hopps (10 min) - IP Traffic Flow Security * draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt -- Wei Pan/Sandeep Kampati (15 min) - IKEv2 Optional SA&TS Payloads in Child Exchange -- kivinen@iki.fi From nobody Sat Jul 20 07:39:17 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EB912017F; Sat, 20 Jul 2019 07:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UDyeD7KQrKec; Sat, 20 Jul 2019 07:39:07 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A08712010D; Sat, 20 Jul 2019 07:39:07 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id k20so64501404ios.10; Sat, 20 Jul 2019 07:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=qe25DgyLw3LrOvAOonlEWyb5Hw/2VSQn56CF/5sUBdI=; b=irKWZvQspEVtbMfOeewIcMTXBUUmQ0lpm3OwrztK8i0uknDUQ8p6KdXrYCeYc9wPJS qvtqldv1Bzu54252mDNkBXCWxukGWpd97QBB68pNAsqzw7NC3wVytt7LHAN3WCcgmkV6 DFPqzAIO1mFbNy5AIeKRqijB+U6EPgZ9gCKQJcmKWCfbNS8v8ixJapTFPbZRs7v6pH4o PHMrE6luDrprDW8SPhAf9ctYhKEz4kOy1LWuSZWaWMXfgFI1rPGkVVfgyZV24jg2Y+TN Cd5YwN3wWJtTDH6uD1FxjDFXA8E5CQJJgIaw45Ddh2pyQ/BagnU2USxkg/V92Rw42ycn UXxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=qe25DgyLw3LrOvAOonlEWyb5Hw/2VSQn56CF/5sUBdI=; b=nk77eVO7ZZDUALMhyRbsirA/+7o94bTJmd6BM7+90wynFXqaNR65YWcsuomVWL2poC udquMINRBElEi2BE/COtd67o1U48Il4XQu74pjyRPBlIl6AXtmUxjid52SHTZvjikO6Y VtwHlbIskYySkmTvn63v+/NJhA5rrsjgKgKQo1as3QFAIHq+IyUlJVZYTp1qUFSCjGvt QpTMGQ9frsQ0F8HjWjTgxN9sq+lEIO4gt7rIN/4l1mM0+a6TnGKYNvJX1SCA9EhjHySU Q2X77HJP/QCp/nS3yceFkdMI7bIBia9wkw4ikYIG9jpNQeoErB9zfrYaerX7S1YwqeGt Bf5g== X-Gm-Message-State: APjAAAUCSqi0Ad+zxSD9hb3nmuL8n9Af4Qg+5q+kjqJWTv5BN5dTkCOK Fqcf1DGdEtG6FzBbVq2nRts= X-Google-Smtp-Source: APXvYqxSCRZ7N58KgqZXc5NLNaH85/+zxxq3I7rLS5kj2tbCsD2hkV4md9PzyVDlpGIx7rhnK2ofhQ== X-Received: by 2002:a02:16c5:: with SMTP id a188mr62835857jaa.86.1563633546461; Sat, 20 Jul 2019 07:39:06 -0700 (PDT) Received: from svannotebook ([75.98.19.132]) by smtp.gmail.com with ESMTPSA id p3sm42118008iom.7.2019.07.20.07.39.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jul 2019 07:39:05 -0700 (PDT) From: "Valery Smyslov" To: "'Yoav Nir'" , "'Rafa Marin-Lopez'" Cc: , , =?utf-8?Q?'Fernando_Pere=C3=B1=C3=ADguez_Garc=C3=ADa'?= , , "'Gabriel Lopez'" References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> In-Reply-To: <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> Date: Sat, 20 Jul 2019 17:38:57 +0300 Message-ID: <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016D_01D53F22.0618E370" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHCFNK4T/q9sOv9UIwCeVdICbA12QI+UTb7AODQKd2m4OC+kA== Content-Language: ru Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 14:39:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_016D_01D53F22.0618E370 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 thank you for updating the document. I still think that some aspect of IKE-less use case are not discussed yet (well, probably they are not=20 "serious", depending on one's definition of "serious"). =20 Unlike IKE case. which we can consider as mostly static configuration, the IKE-less case is a dynamic one. If IPsec SA are being created=20 on demand (via kernel-acquire) and the traffic volume is high, then depending on the IPsec policy IKE-less case can become=20 a highly dynamic, which implies additional requirement on both the network connecting SC and NSF and the performance of the protocol = used to=20 secure their communications. In other words, in IKE case the = communication between IKE daemon and kernel is seamless, while in IKE-less case the communication between NSF ("kernel") and SC adds noticeable delay (and can potentially add quite a long delay), which can influence total performance of the system. =20 Generally IKE-less case requires more communications between different nodes to establish or rekey IPsec SA, than IKE case (I assume that IKE SA is already established), that may have an impact on high-speed networks with short-lived IPsec SAs, especially if they are created per transport connection (say one IPsec SA for one TCP session). =20 I believe, that SC's task of managing IPsec SAs in IKE-less case=20 may become quite complex, especially because due to the additional delay, introduced by the network, the picture of the state of the SAs the SC has can become inaccurate (well,=20 it will always be inaccurate, but with short delays it doesn't matter). Just an example. Consider an SC receives a signal from NSF that an SA is soft expired and starts rekeying process by first installing a new pair of inbound SAs. It successfully installs them on the NSF it receives notification from, but then it receives a notification that the other NSF has rebooted, so it must clear all the SAs on its peers, including the just installed new one (which is only half-done). There seems to be a lot of nuances, and the document=20 completely ignores them. Not that I think that the task is impossible, but the algorithm of managing the SAs can become quite complex and possibly unreliable. =20 I didn't find this discussion in the draft (sorry if I missed it). =20 Regards, Valery. =20 =20 =20 =20 Thanks for getting this done and published. =20 We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. =20 Barring any such shouting, we will request publication right after the = meeting. =20 Thanks again, =20 Linda and Yoav On 16 Jul 2019, at 15:42, Rafa Marin-Lopez > wrote: =20 Dear all: We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 - We have dealt with YANG doctors=E2=80=99 review (Martin's) - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. =20 - We have added more specific text in the descriptions. - Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller. - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). =20 - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. =20 - We have added a subsection 5.3.4 about NSF discovery by the Security = Controller. - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: typedef encryption-algorithm-type { type uint32; description=20 "The encryption algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference=20 "IANA Registry- Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } =20 - We have included three additional Annexes with examples in about the = usage of the YANG model. =20 - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. =20 Best Regards. Inicio del mensaje reenviado: =20 De: internet-drafts@ietf.org =20 Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Fecha: 7 de julio de 2019, 23:34:03 CEST Para: > Cc: i2nsf@ietf.org =20 Responder a: i2nsf@ietf.org =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Interface to Network Security Functions = WG of the IETF. Title : Software-Defined Networking (SDN)-based IPsec = Flow Protection Authors : Rafa Marin-Lopez Gabriel Lopez-Millan Fernando Pereniguez-Garcia Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Pages : 81 Date : 2019-07-07 Abstract: This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources. The document focuses on the NSF Facing Interface by providing models for configuration and state data required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish Security Associations with a reduced intervention of the network administrator. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05= https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-05 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I2nsf mailing list I2nsf@ietf.org =20 https://www.ietf.org/mailman/listinfo/i2nsf =20 ------------------------------------------------------- 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 ------------------------------------------------------- =20 =20 =20 =20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org =20 https://www.ietf.org/mailman/listinfo/i2nsf =20 ------=_NextPart_000_016D_01D53F22.0618E370 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

thank you for = updating the document. I still think that some = aspect

of IKE-less use = case are not discussed yet (well, probably they are not =

"serious"= , depending on one's definition of = "serious").

 

Unlike IKE case. = which we can consider as mostly static = configuration,

the = IKE-less case is a dynamic one. If IPsec SA are being created =

on demand (via = kernel-acquire) and the traffic volume is high,

then depending on = the IPsec policy IKE-less case can become

a highly dynamic, = which implies additional requirement on both

the network = connecting SC and NSF and the performance of the protocol used to =

secure their = communications. In other words, in IKE case the = communication

between IKE daemon = and kernel is seamless, while in IKE-less

case the = communication between NSF ("kernel") and SC = adds

noticeable delay = (and can potentially add quite a long delay),

which can = influence total performance of the system.

 

Generally IKE-less = case requires more communications between

different nodes to = establish or rekey IPsec SA, than IKE case

(I assume that IKE = SA is already established), that may have

an impact on = high-speed networks with short-lived IPsec SAs,

especially if they = are created per transport connection

(say one IPsec SA = for one TCP session).

 

I believe, that = SC's task of managing IPsec SAs in IKE-less case =

may become quite = complex, especially because due to the

additional delay, = introduced by the network, the picture of the

state of the SAs = the SC has can become inaccurate (well,

it will always be = inaccurate, but with short delays it doesn't = matter).

Just an example. = Consider an SC receives a signal from NSF that an = SA

is soft expired = and starts rekeying process by first installing a = new

pair of inbound = SAs. It successfully installs them on the NSF

it receives = notification from, but then it receives a = notification

that = the other NSF has rebooted, so it must clear all the SAs = on

its peers, = including the just installed new one (which is = only

half-done). There = seems to be a lot of nuances, and the document

completely ignores = them. Not that I think that the task

is impossible, but = the algorithm of managing the SAs can become

quite complex and = possibly unreliable.

 

I didn't find this = discussion in the draft (sorry if I missed it).

 

Regards,=

Valery.<= /span>

 

 

 

 

Thanks for getting this done and = published.

 

We will wait with requesting publication until the = I2NSF session next week.  Between now and then, please re-read the = draft and send a message to the list is something is seriously = wrong.

 

Barring any such shouting, we will request publication = right after the meeting.

 

Thanks again,

 

Linda and Yoav



On 16 Jul 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> = wrote:

 

Dear all:

We submitted a new version of the = I-D (v05) where we have applied several changes. In the following = you have a summary of the main changes, which we will expand/explain = during our presentation: 

- We have dealt with YANG = doctors=E2=80=99 review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.

 

- = We have added more specific text in the descriptions.

- = Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller.

- State data has been reduced. For example, in IKE = case, most of the information is related with IKE and not with the = specific details about IPsec SAs that IKE handles (after all, IKE can = abstract this information from the Security = Controller).

 

- = We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF.

 

- = We have added a subsection 5.3.4 about NSF discovery by the Security = Controller.

- In order to specify the crypto-algorithms we have = used a simple approach by including an integer and adding a text = pointing the IANA in the reference clause. For = example:


typedef = encryption-algorithm-type = {
           ty= pe = uint32;
          &n= bsp;description 
        =        "The encryption algorithm = is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          = ;     values MUST follow the requirement levels = for
           =     encryption algorithms for ESP and = IKEv2.";
         &n= bsp; reference 
       &n= bsp;        "IANA Registry- = Transform Type 1 - = Encryption
          = ;      Algorithm Transform IDs. RFC 8221 - = Cryptographic
         &n= bsp;      Algorithm Implementation = Requirements and = Usage
          &nbs= p;     Guidance for Encapsulating Security = Payload = (ESP)
          &nbs= p;     and Authentication Header (AH) and RFC = 8247 = -
           &n= bsp;    Algorithm Implementation Requirements and = Usage
          &nbs= p;     Guidance for the Internet Key Exchange = Protocol
          &= nbsp;     Version 2 = (IKEv2).";
       }=

 

- We have included three additional Annexes with = examples in about the usage of the YANG = model.

 

- = We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without = warnings.

 

Best Regards.



Inicio del mensaje reenviado:

 

Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

Fecha: 7 de julio de 2019, = 23:34:03 CEST

Cc: i2nsf@ietf.org

Responder a: = i2nsf@ietf.org

 


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the = Interface to Network Security Functions WG of the = IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow = Protection
       Authors =         : Rafa = Marin-Lopez
         &nbs= p;            = ;   Gabriel = Lopez-Millan
         &nb= sp;           &nbs= p;   Fernando Pereniguez-Garcia
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Filename        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Pages =           : = 81
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Date =            : = 2019-07-07

Abstract:
  This document describes how = providing IPsec-based flow protection by
  means of a = Software-Defined Network (SDN) controller (aka. =  Security
  Controller) and establishes the = requirements to support this service.
  It considers two = main well-known scenarios in IPsec: (i) = gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document allows the = distribution and monitoring of IPsec
  information from a = Security Controller to one or several flow-based
  Network = Security Function (NSF).  The NSFs implement IPsec to = protect
  data traffic between network = resources.

  The document focuses on the NSF Facing = Interface by providing models
  for configuration and state = data required to allow the Security
  Controller to = configure the IPsec databases (SPD, SAD, PAD) and = IKEv2
  to establish Security Associations with a reduced = intervention of the
  network administrator.


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-= flow-protection/

There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2ns= f-sdn-ipsec-flow-protection-05

A diff from the previous = version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sd= n-ipsec-flow-protection-05


Please note that it may take a = couple of minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-= drafts/

_______________________________________________
I2n= sf 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
---------------= ----------------------------------------

=

 

 

 

 

_______________________________________________
I2ns= f mailing list
I2nsf@ietf.org
https://www.ietf.org= /mailman/listinfo/i2nsf

 

------=_NextPart_000_016D_01D53F22.0618E370-- From nobody Sat Jul 20 18:23:32 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43619120104; Sat, 20 Jul 2019 18:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mn1s7nL_1ipP; Sat, 20 Jul 2019 18:23:19 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FA51200EF; Sat, 20 Jul 2019 18:23:19 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id r6so30744013qtt.0; Sat, 20 Jul 2019 18:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PW5G8czcZDR0KEskN1AyTc6IejzOXlxiRTKGabtTiv4=; b=tNcqq+FUmaqsFOHr5zWtT5JYDNyRrgN2hV2ilHgbsfsdxwEo/KVA0omAUH4vFTWU5K auWY+da/iXJ4rogsvhQhPBjkLx4oCFl5OiXDpSr9F4gWBV0D9swECRbq5hEptg22bKGU +Lr4s2hh/QozVwDDp1gxaqR1yDSyc9N7aQOGvAFuKmHnY8SnOQdUwW+zf3aJv7T+F+xm q2+G3GmojHe2UCnPLPsMyx20DwER6DIV4GxUDoX38JwU9O17xVldw1VMAhX/dquIelN+ AetrRU6XzUHuPGznsDwqeW2KxcBotDGpz0u6ojc6u6mXNUmt0fbAAw+VeoyiYFhBV2nV gHvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PW5G8czcZDR0KEskN1AyTc6IejzOXlxiRTKGabtTiv4=; b=o0rJx8S+caCORby2iYM7UotS2w/cjrAKPwvoecVrWvOKa4s9BfbmQSEXexq9n7L4u9 JdYuS1kpAUKM4mD2+OhYoSIb1b1FnJ+DaI2FxDt27GkTWWRj0mkVFI8LeHCbjMkJHb/q H0c4ZL10X7vrH6zH13L6u5aswjbv4CccW7+lHMU81LJ1seUQEJXwXJOw8CwiuWpoal5M JTBqb3xmJqHc9851YSl7rFQbdU3mInKPz2gTcfmT9m/rTQYOTMKn+5Xm/Ffsxh+cnLcM 8DE54t2rzYhbzhKpphYosO6XX4sLZdtDFUaYQdwmwRFAFuZAPRfzjrHvNl8LMEZ6VLo7 TrQQ== X-Gm-Message-State: APjAAAVqfoK38JrwP2leem1g02NKbN/R0S/WyjtfXIaLvuWrYLNqi2/T V93GlpR0qq+2M2q9vdoMuPU= X-Google-Smtp-Source: APXvYqzKDtS9ASrtE8SVPi7sMOd8V5aRIQC0UqgNL44COBVs+OvR7UH1uNt/sMrHRXc4y3MJPhs9ZQ== X-Received: by 2002:a0c:c604:: with SMTP id v4mr42847990qvi.21.1563672198284; Sat, 20 Jul 2019 18:23:18 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:e072:f96:2cd6:81e0? ([2001:67c:1232:144:e072:f96:2cd6:81e0]) by smtp.gmail.com with ESMTPSA id d123sm17331281qkb.94.2019.07.20.18.23.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jul 2019 18:23:17 -0700 (PDT) From: Yoav Nir Message-Id: <2CFA92C9-EB16-48C4-BFE2-E3A4067F068C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_04900C51-5BFE-479E-A497-29BF56432E58" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 20 Jul 2019 21:23:15 -0400 In-Reply-To: <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> Cc: Rafa Marin-Lopez , i2nsf@ietf.org, ipsec@ietf.org, =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , mbj@tail-f.com, Gabriel Lopez To: Valery Smyslov References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 01:23:23 -0000 --Apple-Mail=_04900C51-5BFE-479E-A497-29BF56432E58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Valery [no hats] Thanks for that. I think this demonstrates that the current document is not enough and we = will need some follow-up documents explaining when to use either case. I don=E2=80=99t think it=E2=80=99s very useful for the controller to = distribute a policy (SPD entries) but no SAs (SAD entries) in the = IKE-less case. It makes sense in the IKE case because the NSFs can then = use IKE to generate the SAs, but in the IKE-less case that would mean = that one NSF gets a packet that should be protected, sends a message to = the controller, which generates an SA and sends it to both the requester = and the other NSF. This seems high latency. I think the case for IKE-less is where the controller sends SPD entries = and SAD entries at the same time (perhaps later updating the SAD entries = to rekey). In that case the action of the controller is to bring up a = tunnel. For example, if the user (or application) decides that = communications between node A and node B should be encrypted, the = controller will send both policy and keys at the same time to make that = tunnel. Yoav > On 20 Jul 2019, at 10:38, Valery Smyslov = wrote: >=20 > Hi, > =20 > thank you for updating the document. I still think that some aspect > of IKE-less use case are not discussed yet (well, probably they are = not=20 > "serious", depending on one's definition of "serious"). > =20 > Unlike IKE case. which we can consider as mostly static configuration, > the IKE-less case is a dynamic one. If IPsec SA are being created=20 > on demand (via kernel-acquire) and the traffic volume is high, > then depending on the IPsec policy IKE-less case can become=20 > a highly dynamic, which implies additional requirement on both > the network connecting SC and NSF and the performance of the protocol = used to=20 > secure their communications. In other words, in IKE case the = communication > between IKE daemon and kernel is seamless, while in IKE-less > case the communication between NSF ("kernel") and SC adds > noticeable delay (and can potentially add quite a long delay), > which can influence total performance of the system. > =20 > Generally IKE-less case requires more communications between > different nodes to establish or rekey IPsec SA, than IKE case > (I assume that IKE SA is already established), that may have > an impact on high-speed networks with short-lived IPsec SAs, > especially if they are created per transport connection > (say one IPsec SA for one TCP session). > =20 > I believe, that SC's task of managing IPsec SAs in IKE-less case=20 > may become quite complex, especially because due to the > additional delay, introduced by the network, the picture of the > state of the SAs the SC has can become inaccurate (well,=20 > it will always be inaccurate, but with short delays it doesn't = matter). > Just an example. Consider an SC receives a signal from NSF that an SA > is soft expired and starts rekeying process by first installing a new > pair of inbound SAs. It successfully installs them on the NSF > it receives notification from, but then it receives a notification > that the other NSF has rebooted, so it must clear all the SAs on > its peers, including the just installed new one (which is only > half-done). There seems to be a lot of nuances, and the document=20 > completely ignores them. Not that I think that the task > is impossible, but the algorithm of managing the SAs can become > quite complex and possibly unreliable. > =20 > I didn't find this discussion in the draft (sorry if I missed it). > =20 > Regards, > Valery. > =20 > =20 > =20 > =20 > Thanks for getting this done and published. > =20 > We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. > =20 > Barring any such shouting, we will request publication right after the = meeting. > =20 > Thanks again, > =20 > Linda and Yoav >=20 >=20 >> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez > wrote: >> =20 >> Dear all: >>=20 >> We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 >>=20 >> - We have dealt with YANG doctors=E2=80=99 review (Martin's) >>=20 >> - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. >> =20 >> - We have added more specific text in the descriptions. >>=20 >> - Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller. >>=20 >> - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). >> =20 >> - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. >> =20 >> - We have added a subsection 5.3.4 about NSF discovery by the = Security Controller. >>=20 >> - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: >>=20 >> typedef encryption-algorithm-type { >> type uint32; >> description=20 >> "The encryption algorithm is specified with a 32-bit >> number extracted from IANA Registry. The acceptable >> values MUST follow the requirement levels for >> encryption algorithms for ESP and IKEv2."; >> reference=20 >> "IANA Registry- Transform Type 1 - Encryption >> Algorithm Transform IDs. RFC 8221 - Cryptographic >> Algorithm Implementation Requirements and Usage >> Guidance for Encapsulating Security Payload (ESP) >> and Authentication Header (AH) and RFC 8247 - >> Algorithm Implementation Requirements and Usage >> Guidance for the Internet Key Exchange Protocol >> Version 2 (IKEv2)."; >> } >> =20 >> - We have included three additional Annexes with examples in about = the usage of the YANG model. >> =20 >> - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. >> =20 >> Best Regards. >>=20 >>=20 >>> Inicio del mensaje reenviado: >>> =20 >>> De: internet-drafts@ietf.org >>> Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>> Fecha: 7 de julio de 2019, 23:34:03 CEST >>> Para: > >>> Cc: i2nsf@ietf.org >>> Responder a: i2nsf@ietf.org >>> =20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Interface to Network Security = Functions WG of the IETF. >>>=20 >>> Title : Software-Defined Networking (SDN)-based = IPsec Flow Protection >>> Authors : Rafa Marin-Lopez >>> Gabriel Lopez-Millan >>> Fernando Pereniguez-Garcia >>> Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>> Pages : 81 >>> Date : 2019-07-07 >>>=20 >>> Abstract: >>> This document describes how providing IPsec-based flow protection = by >>> means of a Software-Defined Network (SDN) controller (aka. = Security >>> Controller) and establishes the requirements to support this = service. >>> It considers two main well-known scenarios in IPsec: (i) = gateway-to- >>> gateway and (ii) host-to-host. The SDN-based service described in >>> this document allows the distribution and monitoring of IPsec >>> information from a Security Controller to one or several = flow-based >>> Network Security Function (NSF). The NSFs implement IPsec to = protect >>> data traffic between network resources. >>>=20 >>> The document focuses on the NSF Facing Interface by providing = models >>> for configuration and state data required to allow the Security >>> Controller to configure the IPsec databases (SPD, SAD, PAD) and = IKEv2 >>> to establish Security Associations with a reduced intervention of = the >>> network administrator. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ = >>>=20 >>> There are also htmlized versions available at: >>> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 = >>> = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection-05 = >>>=20 >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-05 = >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ = >>>=20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf = >> =20 >> ------------------------------------------------------- >> 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:=C2=A0rafa@um.es = >> ------------------------------------------------------- >> =20 >> =20 >> =20 >> =20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf = --Apple-Mail=_04900C51-5BFE-479E-A497-29BF56432E58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Valery

[no hats]

Thanks = for that.

I = think this demonstrates that the current document is not enough and we = will need some follow-up documents explaining when to use either = case.

I = don=E2=80=99t think it=E2=80=99s very useful for the controller to = distribute a policy (SPD entries) but no SAs (SAD entries) in the = IKE-less case.  It makes sense in the IKE case because the NSFs can = then use IKE to generate the SAs, but in the IKE-less case that would = mean that one NSF gets a packet that should be protected, sends a = message to the controller, which generates an SA and sends it to both = the requester and the other NSF.  This seems high = latency.

I = think the case for IKE-less is where the controller sends SPD entries = and SAD entries at the same time (perhaps later updating the SAD entries = to rekey). In that case the action of the controller is to bring up a = tunnel.  For example, if the user (or application) decides that = communications between node A and node B should be encrypted, the = controller will send both policy and keys at the same time to make that = tunnel.

Yoav

On 20 Jul 2019, at 10:38, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi,
 
thank you for updating the document. I still think that some = aspect
of = IKE-less use case are not discussed yet (well, probably they are = not 
"serious", = depending on one's definition of "serious").
 
Unlike IKE case. which we can consider as mostly static = configuration,
the = IKE-less case is a dynamic one. If IPsec SA are being created 
on demand (via = kernel-acquire) and the traffic volume is high,
then depending on = the IPsec policy IKE-less case can become 
a highly dynamic, = which implies additional requirement on both
the network = connecting SC and NSF and the performance of the protocol used to 
secure their = communications. In other words, in IKE case the communication
between IKE daemon = and kernel is seamless, while in IKE-less
case the = communication between NSF ("kernel") and SC adds
noticeable delay = (and can potentially add quite a long delay),
which can influence = total performance of the system.
 
Generally IKE-less case requires more communications = between
different nodes to establish or rekey IPsec SA, than IKE = case
(I = assume that IKE SA is already established), that may have
an impact on = high-speed networks with short-lived IPsec SAs,
especially if they = are created per transport connection
(say one IPsec SA = for one TCP session).
 
I believe, that SC's task of managing IPsec SAs in = IKE-less case 
may become quite = complex, especially because due to the
additional delay, = introduced by the network, the picture of the
state of the SAs = the SC has can become inaccurate (well, 
it will always be = inaccurate, but with short delays it doesn't matter).
Just an example. = Consider an SC receives a signal from NSF that an SA
is soft expired and = starts rekeying process by first installing a new
pair of inbound = SAs. It successfully installs them on the NSF
it receives = notification from, but then it receives a notification
that the other NSF = has rebooted, so it must clear all the SAs on
its peers, = including the just installed new one (which is only
half-done). There = seems to be a lot of nuances, and the document 
completely ignores = them. Not that I think that the task
is impossible, but = the algorithm of managing the SAs can become
quite complex and = possibly unreliable.
 
I didn't find this discussion in the draft (sorry if I = missed it).
 
Regards,
Valery.
 
 
 
 
Thanks = for getting this done and published.
 
We will wait with requesting = publication until the I2NSF session next week.  Between now and = then, please re-read the draft and send a message to the list is = something is seriously wrong.
 
Barring any such shouting, we will request publication right = after the meeting.
 
Thanks again,
 
Linda and Yoav


On 16 Jul 2019, at 15:42, Rafa = Marin-Lopez <rafa@um.es> wrote:
 
Dear all:

We= submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation: 

- We have dealt with YANG doctors=E2=80=99 = review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.
 
- We have added more specific text in = the descriptions.

- Notifications have a = simpler format now since most of the information that contained in the = past is already handled by the Security Controller.

- State data has been reduced. For example, in IKE case, most = of the information is related with IKE and not with the specific details = about IPsec SAs that IKE handles (after all, IKE can abstract this = information from the Security Controller).
 
- We have included text in the security = section to discuss about the default IPsec policies that should be in = the NSF when it starts before contacting with the SC such as the IPsec = policies required to allow traffic between the SC and the NSF.
 
- We have added a subsection 5.3.4 = about NSF discovery by the Security Controller.

- In order to specify the crypto-algorithms we have used a = simple approach by including an integer and adding a text pointing the = IANA in the reference clause. For = example:

typedef = encryption-algorithm-type {
          &nb= sp;type uint32;
          &nb= sp;description 
          &nb= sp;    "The encryption algorithm is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          &nb= sp;    values MUST follow the requirement levels = for
          &nb= sp;    encryption algorithms for ESP and IKEv2.";
          &nb= sp;reference 
          &nb= sp;     "IANA Registry- Transform Type 1 - = Encryption
          &nb= sp;     Algorithm Transform IDs. RFC 8221 - = Cryptographic
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for Encapsulating Security = Payload (ESP)
          &nb= sp;     and Authentication Header (AH) and RFC = 8247 -
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for the Internet Key Exchange = Protocol
          &nb= sp;     Version 2 (IKEv2).";
       }
 
- We have included three additional = Annexes with examples in about the usage of the YANG model.
 
- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without warnings.
 
Best Regards.


Inicio del mensaje reenviado:
 
Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Fecha: 7 de julio de = 2019, 23:34:03 CEST
Para: <i-d-announce@ietf.org>
Responder a: i2nsf@ietf.org
 

A New Internet-Draft is = available from the on-line Internet-Drafts directories.
This= draft is a work item of the Interface to Network Security Functions WG = of the IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow Protection
       Authors =         : Rafa Marin-Lopez
          &nb= sp;            = ;  Gabriel Lopez-Millan
          &nb= sp;            = ;  Fernando Pereniguez-Garcia
        &= nbsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &= nbsp;  Pages=           : 81
        &= nbsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how providing IPsec-based = flow protection by
  means of a Software-Defined = Network (SDN) controller (aka.  Security
  Controller) and establishes the requirements to = support this service.
  It considers two main = well-known scenarios in IPsec: (i) gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document = allows the distribution and monitoring of IPsec
  information from a Security Controller to one or = several flow-based
  Network Security Function = (NSF).  The NSFs implement IPsec to protect
  data traffic between network resources.

  The document focuses on the NSF = Facing Interface by providing models
  for = configuration and state data required to allow the Security
  Controller to configure the IPsec databases (SPD, = SAD, PAD) and IKEv2
  to establish Security = Associations with a reduced intervention of the
  network administrator.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-05


Please = note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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
-------------------------------------------------------
 
 
 
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

= --Apple-Mail=_04900C51-5BFE-479E-A497-29BF56432E58-- From nobody Sun Jul 21 04:42:57 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FDB1200B5; Sun, 21 Jul 2019 04:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 s97kCB9rgBSV; Sun, 21 Jul 2019 04:42:45 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD0612001A; Sun, 21 Jul 2019 04:42:45 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id k10so35717307qtq.1; Sun, 21 Jul 2019 04:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=vgwVGCAD3vpNtbA9KzdkMSG3ncQJJ4aNhmLzh8SKO1s=; b=sqvFoQ7q4UyBIjjpy6z94w/3yLb+GK4Q+WSVtiSo//BING0mXSp4u0Mac0iIpK5RUG 705Hp8HwLt9LzDMsIqC0yK8pr+Pz6s3er9u6emRwfRoUjHgBmjGSHT9TxaqODJeKcuj/ U18RE/3z2jHqKWYrBBDmy08SPzYwLaOEYSigS3vjtz7vrH7ocs7hR9FKpVzVJFr56jUL DbgAQPWeh+jrJPBVhsBSiGnDdvuUZsdlgNNMacV8bLwBnAKkxJTDXPcoy7o6jVTvsj6F sJefj5eM3McHi1/KZHZmUQRDZDuX62kYSix//zLbQl3/wwz2oTqUQfKZewD/vSBAtLGJ Ub9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=vgwVGCAD3vpNtbA9KzdkMSG3ncQJJ4aNhmLzh8SKO1s=; b=N0/dmjOCfXiLVg1oNuDHkzJJny2ujd9kj0rTWmhURychGyWNnocYceuDK0O8K063ZF b7CR81H72NcmlzrnDFD3D0wHPR0fNC+RompOE1iMQRL9Pk4Vp59M236eEgo9oekLFMwB bvkOBQ1ZMa/Fk14z2wnwoh74Yhpsa1x7Haq6T2q/mtv/PKe7KSZmnwBzGGQNIk4Mz1Yy a5TrW3u1wuwbkYD7hcJuJzvEGE9qikiihPEU0EauAiTk3dbRiTv/XaqfwzU7C4rB7P8+ 4uzwToJS/Xg5KykF4UK94f6uGEhoBsIZEf5j8csulBqXL7qIc95tzoQzOuFzqRt6w9BO 5zrg== X-Gm-Message-State: APjAAAX2LMCz+E3IzoHuLKynzCWOgJfJ1vYV5BsgcDmiwGfLuVMHplLz kLR6zQJnenT2FhcLLVPMaw8= X-Google-Smtp-Source: APXvYqxYpohj9Q/eQ4DQ7Qd5mEyqgEN3bVVJCLC/7YFJ2FO7tGCHzWNDV14f6Ng5mnkBjjr3I5i1AA== X-Received: by 2002:ac8:7611:: with SMTP id t17mr46291639qtq.112.1563709364041; Sun, 21 Jul 2019 04:42:44 -0700 (PDT) Received: from svannotebook (modemcable142.183-83-70.mc.videotron.ca. [70.83.183.142]) by smtp.gmail.com with ESMTPSA id o71sm15634093qke.18.2019.07.21.04.42.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 04:42:43 -0700 (PDT) From: "Valery Smyslov" To: "'Yoav Nir'" Cc: "'Rafa Marin-Lopez'" , , , =?utf-8?Q?'Fernando_Pere=C3=B1=C3=ADguez_Garc=C3=ADa'?= , , "'Gabriel Lopez'" References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <2CFA92C9-EB16-48C4-BFE2-E3A4067F068C@gmail.com> In-Reply-To: <2CFA92C9-EB16-48C4-BFE2-E3A4067F068C@gmail.com> Date: Sun, 21 Jul 2019 14:42:40 +0300 Message-ID: <01dc01d53fb9$674d0c60$35e72520$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DD_01D53FD2.8CA3BA40" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHCFNK4T/q9sOv9UIwCeVdICbA12QI+UTb7AODQKd0B9E5Q0QMPmbQ9prouR3A= Content-Language: ru Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 11:42:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01DD_01D53FD2.8CA3BA40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Yoav, =20 Hi, Valery =20 [no hats] =20 Thanks for that. =20 I think this demonstrates that the current document is not enough and we = will need some follow-up documents explaining when to use either case. =20 I don=E2=80=99t think it=E2=80=99s very useful for the controller to = distribute a policy (SPD entries) but no SAs (SAD entries) in the = IKE-less case. It makes sense in the IKE case because the NSFs can then = use IKE to generate the SAs, but in the IKE-less case that would mean = that one NSF gets a packet that should be protected, sends a message to = the controller, which generates an SA and sends it to both the requester = and the other NSF. This seems high latency. =20 I think the case for IKE-less is where the controller sends SPD entries = and SAD entries at the same time (perhaps later updating the SAD entries = to rekey). In that case the action of the controller is to bring up a = tunnel. For example, if the user (or application) decides that = communications between node A and node B should be encrypted, the = controller will send both policy and keys at the same time to make that = tunnel. =20 Sure that will make things more static and the concerns = expressed in my message will gone. However, other concerns appear in this case. First, you'll = lose some of ipsec functionality -=20 an ability to have per-connection IPsec SA, when each TCP = connection is protected with its own SA (don't ask me when I last time saw this in real = life, please :-)). Then, in this case a situation is possible when (some of) installed SAs are = never used. You preinstall them regardless of the traffic, and traffic can never happen. = Not that it is a big deal, but still... =20 Regards, Valery. =20 =20 Yoav On 20 Jul 2019, at 10:38, Valery Smyslov > wrote: =20 Hi, =20 thank you for updating the document. I still think that some aspect of IKE-less use case are not discussed yet (well, probably they are not=20 "serious", depending on one's definition of "serious"). =20 Unlike IKE case. which we can consider as mostly static configuration, the IKE-less case is a dynamic one. If IPsec SA are being created=20 on demand (via kernel-acquire) and the traffic volume is high, then depending on the IPsec policy IKE-less case can become=20 a highly dynamic, which implies additional requirement on both the network connecting SC and NSF and the performance of the protocol = used to=20 secure their communications. In other words, in IKE case the = communication between IKE daemon and kernel is seamless, while in IKE-less case the communication between NSF ("kernel") and SC adds noticeable delay (and can potentially add quite a long delay), which can influence total performance of the system. =20 Generally IKE-less case requires more communications between different nodes to establish or rekey IPsec SA, than IKE case (I assume that IKE SA is already established), that may have an impact on high-speed networks with short-lived IPsec SAs, especially if they are created per transport connection (say one IPsec SA for one TCP session). =20 I believe, that SC's task of managing IPsec SAs in IKE-less case=20 may become quite complex, especially because due to the additional delay, introduced by the network, the picture of the state of the SAs the SC has can become inaccurate (well,=20 it will always be inaccurate, but with short delays it doesn't matter). Just an example. Consider an SC receives a signal from NSF that an SA is soft expired and starts rekeying process by first installing a new pair of inbound SAs. It successfully installs them on the NSF it receives notification from, but then it receives a notification that the other NSF has rebooted, so it must clear all the SAs on its peers, including the just installed new one (which is only half-done). There seems to be a lot of nuances, and the document=20 completely ignores them. Not that I think that the task is impossible, but the algorithm of managing the SAs can become quite complex and possibly unreliable. =20 I didn't find this discussion in the draft (sorry if I missed it). =20 Regards, Valery. =20 =20 =20 =20 Thanks for getting this done and published. =20 We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. =20 Barring any such shouting, we will request publication right after the = meeting. =20 Thanks again, =20 Linda and Yoav On 16 Jul 2019, at 15:42, Rafa Marin-Lopez < = rafa@um.es> wrote: =20 Dear all: We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 - We have dealt with YANG doctors=E2=80=99 review (Martin's) - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. =20 - We have added more specific text in the descriptions. - Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller. - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). =20 - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. =20 - We have added a subsection 5.3.4 about NSF discovery by the Security = Controller. - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: typedef encryption-algorithm-type { type uint32; description=20 "The encryption algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference=20 "IANA Registry- Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } =20 - We have included three additional Annexes with examples in about the = usage of the YANG model. =20 - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. =20 Best Regards. Inicio del mensaje reenviado: =20 De: internet-drafts@ietf.org Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Fecha: 7 de julio de 2019, 23:34:03 CEST Para: < i-d-announce@ietf.org> Cc: i2nsf@ietf.org Responder a: i2nsf@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Interface to Network Security Functions = WG of the IETF. Title : Software-Defined Networking (SDN)-based IPsec = Flow Protection Authors : Rafa Marin-Lopez Gabriel Lopez-Millan Fernando Pereniguez-Garcia Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Pages : 81 Date : 2019-07-07 Abstract: This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources. The document focuses on the NSF Facing Interface by providing models for configuration and state data required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish Security Associations with a reduced intervention of the network administrator. The IETF datatracker status page for this draft is: = = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on/ There are also htmlized versions available at: = = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05= = = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05 A diff from the previous version is available at: = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-05 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org = . Internet-Drafts are also available by anonymous FTP at: = ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------------------------------------------------------- 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 ------------------------------------------------------- =20 =20 =20 =20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------=_NextPart_000_01DD_01D53FD2.8CA3BA40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Yoav,

 

Hi, = Valery

 

[no hats]

 

Thanks for that.

 

I = think this demonstrates that the current document is not enough and we = will need some follow-up documents explaining when to use either = case.

 

I = don=E2=80=99t think it=E2=80=99s very useful for the controller to = distribute a policy (SPD entries) but no SAs (SAD entries) in the = IKE-less case.  It makes sense in the IKE case because the NSFs can = then use IKE to generate the SAs, but in the IKE-less case that would = mean that one NSF gets a packet that should be protected, sends a = message to the controller, which generates an SA and sends it to both = the requester and the other NSF.  This seems high = latency.

 

I = think the case for IKE-less is where the controller sends SPD entries = and SAD entries at the same time (perhaps later updating the SAD entries = to rekey). In that case the action of the controller is to bring up a = tunnel.  For example, if the user (or application) decides that = communications between node A and node B should be encrypted, the = controller will send both policy and keys at the same time to make that = tunnel.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Sure that = will make things more static and the concerns expressed in my message = will gone.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 However, other concerns appear in this case. First, you'll lose = some of ipsec functionality -

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 an ability to have per-connection IPsec SA, when each TCP = connection is protected with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 its own SA (don't ask me when I last time saw this in real life, = please :-)). Then, in this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 case a situation is possible when (some of) installed SAs are = never used. You preinstall

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 them regardless of the traffic, and traffic can never happen. Not = that it is a big deal,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 but still...

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Valery.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =

 

Yoav



On 20 Jul 2019, at 10:38, Valery Smyslov <smyslov.ietf@gmail.com> = wrote:

 

Hi,

 

thank = you for updating the document. I still think that some = aspect

of IKE-less use case are not = discussed yet (well, probably they are not 

"serious", depending on one's = definition of "serious").

 

Unlike = IKE case. which we can consider as mostly static = configuration,

the = IKE-less case is a dynamic one. If IPsec SA are being created 

on = demand (via kernel-acquire) and the traffic volume is = high,

then depending on the IPsec = policy IKE-less case can become 

a = highly dynamic, which implies additional requirement on = both

the network connecting SC and = NSF and the performance of the protocol used to 

secure their communications. In other words, = in IKE case the communication

between = IKE daemon and kernel is seamless, while in = IKE-less

case the communication between = NSF ("kernel") and SC adds

noticeable delay (and can potentially add = quite a long delay),

which = can influence total performance of the = system.

 

Generally IKE-less case requires more = communications between

different nodes to establish or rekey IPsec = SA, than IKE case

(I = assume that IKE SA is already established), that may = have

an impact on high-speed networks = with short-lived IPsec SAs,

especially if they are created per transport = connection

(say one IPsec SA for one TCP = session).

 

I = believe, that SC's task of managing IPsec SAs in IKE-less case 

may become quite complex, especially because = due to the

additional delay, introduced by = the network, the picture of the

state of = the SAs the SC has can become inaccurate (well, 

it = will always be inaccurate, but with short delays it doesn't = matter).

Just an example. Consider an SC = receives a signal from NSF that an SA

is soft = expired and starts rekeying process by first installing a = new

pair of inbound SAs. It = successfully installs them on the NSF

it = receives notification from, but then it receives a = notification

that the other NSF has rebooted, = so it must clear all the SAs on

its = peers, including the just installed new one (which is = only

half-done). There seems to be a = lot of nuances, and the document 

completely ignores them. Not that I think = that the task

is impossible, but the algorithm = of managing the SAs can become

quite = complex and possibly unreliable.

 

I didn't = find this discussion in the draft (sorry if I missed = it).

 

Regards,

Valery.

 

 

 

 

Thanks for getting = this done and published.

 

We will wait with requesting publication until the = I2NSF session next week.  Between now and then, please re-read the = draft and send a message to the list is something is seriously = wrong.

 

Barring any such shouting, we will request publication = right after the meeting.

 

Thanks again,

 

Linda and Yoav




On 16 Jul 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> = wrote:

 

Dear all:

We submitted a new version of the = I-D (v05) where we have applied several changes. In the following = you have a summary of the main changes, which we will expand/explain = during our presentation: 

- We have dealt with YANG = doctors=E2=80=99 review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.

 

- We have added more specific text in the = descriptions.

- Notifications have a simpler format now since = most of the information that contained in the past is already handled by = the Security Controller.

- State data has been reduced. For = example, in IKE case, most of the information is related with IKE and = not with the specific details about IPsec SAs that IKE handles (after = all, IKE can abstract this information from the Security = Controller).

 

- We have included text in the security section to = discuss about the default IPsec policies that should be in the NSF when = it starts before contacting with the SC such as the IPsec policies = required to allow traffic between the SC and the = NSF.

 

- We have added a subsection 5.3.4 about NSF discovery = by the Security Controller.

- In order to specify the = crypto-algorithms we have used a simple approach by including an integer = and adding a text pointing the IANA in = the reference clause. For = example:


typedef encryption-algorithm-type = {
           ty= pe = uint32;
          &n= bsp;description 
        =        "The encryption algorithm = is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          = ;     values MUST follow the requirement levels = for
           =     encryption algorithms for ESP and = IKEv2.";
         &n= bsp; reference 
       &n= bsp;        "IANA Registry- = Transform Type 1 - = Encryption
          = ;      Algorithm Transform IDs. RFC 8221 - = Cryptographic
         &n= bsp;      Algorithm Implementation = Requirements and = Usage
          &nbs= p;     Guidance for Encapsulating Security = Payload = (ESP)
          &nbs= p;     and Authentication Header (AH) and RFC = 8247 = -
           &n= bsp;    Algorithm Implementation Requirements and = Usage
          &nbs= p;     Guidance for the Internet Key Exchange = Protocol
          &= nbsp;     Version 2 = (IKEv2).";
       }=

 

- We have included three additional Annexes with = examples in about the usage of the YANG = model.

 

- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without warnings.

 

Best Regards.




Inicio del mensaje = reenviado:

 

Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

Fecha: 7 de julio de 2019, = 23:34:03 CEST

Responder a: i2nsf@ietf.org

 


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the = Interface to Network Security Functions WG of the = IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow = Protection
       Authors =         : Rafa = Marin-Lopez
         &nbs= p;            = ;   Gabriel = Lopez-Millan
         &nb= sp;           &nbs= p;   Fernando Pereniguez-Garcia
        &n= bsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &n= bsp;  Pages =           : = 81
        &n= bsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how = providing IPsec-based flow protection by
  means of a = Software-Defined Network (SDN) controller (aka. =  Security
  Controller) and establishes the = requirements to support this service.
  It considers two = main well-known scenarios in IPsec: (i) = gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document allows the = distribution and monitoring of IPsec
  information from a = Security Controller to one or several flow-based
  Network = Security Function (NSF).  The NSFs implement IPsec to = protect
  data traffic between network = resources.

  The document focuses on the NSF Facing = Interface by providing models
  for configuration and state = data required to allow the Security
  Controller to = configure the IPsec databases (SPD, SAD, PAD) and = IKEv2
  to establish Security Associations with a reduced = intervention of the
  network administrator.


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-= sdn-ipsec-flow-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-i= psec-flow-protection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i= 2nsf-sdn-ipsec-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2n= sf-sdn-ipsec-flow-protection-05


Please note that = it may take a couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Drafts= are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
=
_______________________________________________
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
------------= -------------------------------------------

 

 

 

 

_______________________________________________
I2ns= f mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf=

 

------=_NextPart_000_01DD_01D53FD2.8CA3BA40-- From nobody Sun Jul 21 08:39:48 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2662112004D for ; Sun, 21 Jul 2019 08:39:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156372358715.20543.10703090213577874928.idtracker@ietfa.amsl.com> Date: Sun, 21 Jul 2019 08:39:47 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 15:39:47 -0000 Changed milestone "IETF Last Call on Split-DNS Configuration for IKEv2", added draft-ietf-ipsecme-split-dns to milestone. Changed milestone "IETF Last Call on Implicit IV in IPsec", resolved as "Done", added draft-ietf-ipsecme-implicit-iv to milestone. Changed milestone "IETF Last Call on partially quantum resistant IKEv2", resolved as "Done", added draft-ietf-ipsecme-qr-ikev2 to milestone. URL: https://datatracker.ietf.org/wg/ipsecme/about/ From nobody Sun Jul 21 17:17:15 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A80120156 for ; Sun, 21 Jul 2019 17:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KbrhMBhR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IjNbnu3w 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 F2HsKOH4aP25 for ; Sun, 21 Jul 2019 17:17:10 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8319312004F for ; Sun, 21 Jul 2019 17:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10250; q=dns/txt; s=iport; t=1563754630; x=1564964230; h=from:to:subject:date:message-id:mime-version; bh=HGnI0j6i4pnu9DH7wpCOVVBMTSE/oNLVcAL0zJ3NAbU=; b=KbrhMBhRs42FCPb4Digy2PLHqkQ1PtJ6zENuAQ1xLF0FZu6OZl07E/Ma A2Gtpdv6B3qs8G21si5QpND39h66VAiEadGjwStMId9ACpewUhX6NRHTn HMyBIJejAJyrcIaKE3Hm768TyumRiTgG1Ry7HO/M5/8v4c77jvwsCqyjb g=; IronPort-PHdr: =?us-ascii?q?9a23=3A7xrBRxGz5zi44rfhlwYW2J1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeXkazE6BslYfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwCAAJADVd/4kNJK1mH4F6gRUvUAN?= =?us-ascii?q?tVSAECyoKh1oDjX1MlQqEVYJSA1QJAQEBDAEBLQIBAYRAAoJSIzcGDgEDAQE?= =?us-ascii?q?EAQECAQZthR4BC4VjFQYTAQE4EQGBACYBBBsagwGBHU0DHQGeKgKBOIhggXA?= =?us-ascii?q?zgnkBAQWFAhiCEwmBNItCHReBQD+BV4dQgzuCJowCIIdUlgRtCQKCGQOLQ4h?= =?us-ascii?q?hmAqNNZdQAgQCBAUCDgEBBYFmIoFYcBWDJ4JLGoNOilNygSmNBQGBIAEB?= X-IronPort-AV: E=Sophos;i="5.64,292,1559520000"; d="scan'208,217";a="599355150" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jul 2019 00:17:09 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6M0H9pt006731 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Jul 2019 00:17:09 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 21 Jul 2019 19:17:08 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 21 Jul 2019 19:17:08 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 21 Jul 2019 19:17:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L2ysW2DV1u9bjQkvzwZ11W7EFVTGqTgu2Nxz5F2vuZXlLD+LC4eBQ64gmGWYj6X80pXDqcbmPtp5vA+A+bG/TH3ksTH6KSEPfF3f0khfkXKiQ8iVK/M/8UuKi5PDN/xIyIOB3qM3FryWGZnmHOKy2nCWJyej/t6UziX7U8K+wuqWAoLPoAHosynNtV0ZYwh0QtqBpdMKanfQA6I1nT2XuL1Bqex7j6ujGV2lyFoU/fWQl2H673zT35JrhPi2fHmhv9Skgx4rci7TSIWiG25vSMiHpY8jj6XitthhrAwUTZ+W+/PzVl6KAiex+/B+GTWPzhY4RpiJw2myb4lnIFdkMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=imD2LSzNQ5XJq85b3XDvpS22alIzBOw0eKb0oSDIF3w=; b=i5tUutGoipErRyG+sfNe8BJVhW1GxR1hrPHoyssrC4DlpMGCOuCsSqd0XYMLzj+WCw8HGkfXlsBtssWXf/X+et189WnoSav57IYQ4W5rWpPQh5GlUeTJ+wtcc4pCCsQvMBPWjBRRQTYphEcKnYVn93CjFiGkemgr+jTx8C5mgVDV47TqiW9bH34kg/8Vz5Gz9xaCNKPq1nBE8TNeAOH254rHVbr2T2S2+3r52ZFihi9Vbbze5h6cRYRlRNQhHbt/dipfrqFPDAtiFEw9XdMIei+jAqYGRB096QNMEe8KtLa9ieiPOIxYDGALMBbwq0oMTRr+hDpsa1/N4Wb9Jf8v9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=imD2LSzNQ5XJq85b3XDvpS22alIzBOw0eKb0oSDIF3w=; b=IjNbnu3wfEk4vzsR88Evat2S9hW7rgf9eiEvJ3eDxAMrsirrnTmlYZP4JgTvgwDl320kuctE+lYfUW5U8V4NpFb8rijNx/4c6odX6XseXtkGdfMPruFKnr+mblDnjcS99XlFG4KSflWh8ogsOFNSjWc30zUYvD8jhJaqgrQI9y0= Received: from MN2PR11MB3871.namprd11.prod.outlook.com (10.255.180.204) by MN2PR11MB3984.namprd11.prod.outlook.com (10.255.181.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 00:17:07 +0000 Received: from MN2PR11MB3871.namprd11.prod.outlook.com ([fe80::4c5:965:c7b7:387b]) by MN2PR11MB3871.namprd11.prod.outlook.com ([fe80::4c5:965:c7b7:387b%3]) with mapi id 15.20.2094.013; Mon, 22 Jul 2019 00:17:07 +0000 From: "Scott Fluhrer (sfluhrer)" To: "ipsec@ietf.org" Thread-Topic: Comments on draft-ietf-lwig-minimal-esp-00 Thread-Index: AdVAH1PvRJB9s0MWQrmZVSpKQQMxMA== Date: Mon, 22 Jul 2019 00:17:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sfluhrer@cisco.com; x-originating-ip: [173.38.117.74] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5d0b6a4-fbe0-4653-17e9-08d70e39ee66 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3984; x-ms-traffictypediagnostic: MN2PR11MB3984: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(396003)(136003)(39860400002)(366004)(189003)(199004)(76114002)(14454004)(81166006)(1730700003)(7696005)(99286004)(26005)(5660300002)(53936002)(5640700003)(7736002)(68736007)(2906002)(3846002)(6116002)(790700001)(81156014)(55016002)(54896002)(6306002)(86362001)(8936002)(9686003)(64756008)(66066001)(66446008)(256004)(14444005)(6436002)(2351001)(102836004)(25786009)(316002)(186003)(74316002)(71190400001)(71200400001)(33656002)(476003)(76116006)(66946007)(66556008)(66476007)(478600001)(52536014)(486006)(6916009)(8676002)(6506007)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3984; H:MN2PR11MB3871.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: semuBBnBfaj5n6wg2H1rpA8zp8h4zDNtxelk9f0YctyI10DGW+PVd98plow8Ee11SVOMbPJrEgu0JmKurAYCeouMMDl81kzSOVuWkUudHZgI/yHrpIBe7wjS4ZmUznYGaY84oAGXUvBIp1r9zBx6TTfAcUJ2QYZ87DZZTFFXp9bbCGViC5kICXOM9KGvLRQNzCmT6Cswi7N+jMfFZxHWktibKXnd5Sy2f/crsxIFMue8Q7VEf9CSn/Jy4RX3P3paBNkrDrWgw0PEjDVL7KUVdGK4Z7PpC5t1YfYIYGn2Nqde17oDj1Wx+un4p303aJ/0ff2KA8Tej9Tgk4WZ+tKrBNqHCTcjZbB1qRzsjmpnT1EukV8S4iuyr9zyCwm6vpq7NYBmsU+YWOX9IAD8ErbG/iWtvOeIkgrqa1wlIAArZxs= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3871D71922DC05E087BDF992C1C40MN2PR11MB3871namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e5d0b6a4-fbe0-4653-17e9-08d70e39ee66 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 00:17:07.0388 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sfluhrer@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3984 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 00:17:13 -0000 --_000_MN2PR11MB3871D71922DC05E087BDF992C1C40MN2PR11MB3871namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments: * I have issues with the draft's emphasis on fixed SPI values. One rea= son for the SPI value is to handle key updates cleanly; during the transiti= on, the SPI can be used to indicate whether the packet was encrypted with t= he previous set of key or the new ones. As we really don't want to discour= age rekeying I would suggest that, instead of talking so much about fixed S= PIs, you instead address how to do nonrandom SPIs (for example, by having t= he top 3 bytes of the inbound SPI being the SAD entry, and the lower byte b= eing the rekey index). * "Values 0-255 SHOULD NOT be used."; shouldn't that be MUST NOT? Can = you think of an advantage a device might have for using a SPI in that regio= n? The use of fix SPI MUST NOT be considered as a way to avoid strong random g= enerators. Such generator will be required in order to provide strong cryp= tographic protection"; actually, if the IPsec implementation doesn't actual= ly generate its own keys (that is, it relies on an external service to prov= ide them), and the transform itself doesn't require random data (CBC can be= implemented securely without one), then the IPsec implementation doesn't a= ctually need an CSPRNG. * SN based on clocks; one issue that is not addressed is that standard = receivers are tuned for an increment of one-per-packet; if the sender uses = increments significantly larger than that, and packets are reordered, the r= eceiver is more likely to reject valid packets because they fell outside th= e window. * One issue you do not address (but I believe you should) is the fact t= hat some cryptographical transforms are more resilient for key reuse (e.g. = because you use a fixed key, and don't change it after a reboot) than other= s. In particular, both GCM and ChaCha20-Poly1305 have real problems when t= hat happens, and should be avoided. Typos: * a random SPI may consume to much -> too much * fix SPI -> fixed SPI * can be alleviate -> can be alleviated * algorythm -> algorithm * --_000_MN2PR11MB3871D71922DC05E087BDF992C1C40MN2PR11MB3871namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments:

 

  • I have issues with the draft’s emphasis on fixed SPI values.&nb= sp; One reason for the SPI value is to handle key updates cleanly; during t= he transition, the SPI can be used to indicate whether the packet was encrypted with the previous set of key or the new o= nes.  As we really don’t want to discourage rekeying I would sug= gest that, instead of talking so much about fixed SPIs, you instead address= how to do nonrandom SPIs (for example, by having the top 3 bytes of the inbound SPI being the SAD entry, and the low= er byte being the rekey index).
  • “Values 0-255 SHOULD NOT be used.”; shou= ldn’t that be MUST NOT?  Can you think of an advantage a device = might have for using a SPI in that region?

The use of fix SPI MUST NOT be considered as= a way to avoid strong random generators.  Such generator will be required in order to provide strong cryptographic protec= tion”; actu= ally, if the IPsec implementation doesn’t actually generate its own k= eys (that is, it relies on an external service to provide them), and the tr= ansform itself doesn’t require random data (CBC can be implemented securely without one), then the IPsec implementati= on doesn’t actually need an CSPRNG.

  • SN based on clocks; one issue that is not addressed is that standard = receivers are tuned for an increment of one-per-packet; if the sender uses = increments significantly larger than that, and packets are reordered, the receiver is more likely to reject val= id packets because they fell outside the window.
  • One= issue you do not address (but I believe you should) is the fact that some = cryptographical transforms are more resilient for key reuse (e.g. because y= ou use a fixed key, and don’t change it after a reboot) than others.  In particular, both GCM and C= haCha20-Poly1305 have real problems when that happens, and should be avoide= d.

 

Typos:

  • a random SPI may consume to much -> too much
  • = fix SPI -> fixed SPI
  • can be alleviate -> can be = alleviated
  • algorythm -> algorithm
    •  
--_000_MN2PR11MB3871D71922DC05E087BDF992C1C40MN2PR11MB3871namp_-- From nobody Sun Jul 21 20:24:55 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0FB12007C; Sun, 21 Jul 2019 20:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 stVaAJcMpm0T; Sun, 21 Jul 2019 20:24:51 -0700 (PDT) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E45120033; Sun, 21 Jul 2019 20:24:51 -0700 (PDT) Received: by mail-vs1-f50.google.com with SMTP id a186so23535565vsd.7; Sun, 21 Jul 2019 20:24:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4BwM7RWsHoJWdFflkc9UlEs+ZhgVaaIP0PvRqluxjLA=; b=J4sDEYucQUOBGB4v+HsWI878eT8mNTwalWPNxKZzy3aDn+0aHZQyzhxDojuO55ObX7 JVTkXSaLKKzHkamzuSR7joUrho5bb1DmLdnXI83ocMmO2WC1r+GFRGxzPy4VoA1OuSBt VHyTgLEMY8gU1rVUXvfUA+N3zr+VXWgJbOf/63+x62Nc5/+Z+/BXXPkuWQDRJZbADNZu iDOmL1Hj50XNkzWipWKvJFw0o1Lw/HqjSjLZTV09NUiYom1TR/w5o8zRum1PlwzorhuP PV8PD/uvzZPd9gygxtsFblxLb6RwMrJf6PZGEqrRATG0s2VGrve8cHVsxRlpv/G6JCT+ aZ2A== X-Gm-Message-State: APjAAAV/et5GL8IF9e1ryBFaiZcY92OES2kZuj+wL+3gnwHSrg+1Ib8R iUWkwOz82ZnoNFhck4+7bGcskP49PzDtPK6NH84= X-Google-Smtp-Source: APXvYqwagejKyh6LV/GgCi1rHBHWQBYBZH3izZyv2jSJMr3EoLZN86wOt2llAqKkvNoOSemT5WsybIBtbw5oi0Op41c= X-Received: by 2002:a67:f998:: with SMTP id b24mr41029185vsq.180.1563765889951; Sun, 21 Jul 2019 20:24:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Sun, 21 Jul 2019 23:24:39 -0400 Message-ID: To: "Scott Fluhrer (sfluhrer)" , lwip@ietf.org Cc: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary="00000000000061ed73058e3c9e11" Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 03:24:53 -0000 --00000000000061ed73058e3c9e11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Scott for the comment. I will address them tomorrow, I am just sharing the review to the lwig list. Yours, Daniel On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer) wrote: > Comments: > > > > - I have issues with the draft=E2=80=99s emphasis on fixed SPI values.= One > reason for the SPI value is to handle key updates cleanly; during the > transition, the SPI can be used to indicate whether the packet was > encrypted with the previous set of key or the new ones. As we really = don=E2=80=99t > want to discourage rekeying I would suggest that, instead of talking s= o > much about fixed SPIs, you instead address how to do nonrandom SPIs (f= or > example, by having the top 3 bytes of the inbound SPI being the SAD en= try, > and the lower byte being the rekey index). > - =E2=80=9CValues 0-255 SHOULD NOT be used.=E2=80=9D; shouldn=E2=80=99= t that be MUST NOT? Can > you think of an advantage a device might have for using a SPI in that > region? > > The use of fix SPI MUST NOT be considered as a way to avoid strong random > generators. Such generator will be required in order to provide strong > cryptographic protection=E2=80=9D; actually, if the IPsec implementation = doesn=E2=80=99t > actually generate its own keys (that is, it relies on an external service > to provide them), and the transform itself doesn=E2=80=99t require random= data (CBC > can be implemented securely without one), then the IPsec implementation > doesn=E2=80=99t actually need an CSPRNG. > > - SN based on clocks; one issue that is not addressed is that standard > receivers are tuned for an increment of one-per-packet; if the sender = uses > increments significantly larger than that, and packets are reordered, = the > receiver is more likely to reject valid packets because they fell outs= ide > the window. > - One issue you do not address (but I believe you should) is the fact > that some cryptographical transforms are more resilient for key reuse = (e.g. > because you use a fixed key, and don=E2=80=99t change it after a reboo= t) than > others. In particular, both GCM and ChaCha20-Poly1305 have real probl= ems > when that happens, and should be avoided. > > > > Typos: > > - a random SPI may consume to much -> too much > - fix SPI -> fixed SPI > - can be alleviate -> can be alleviated > - algorythm -> algorithm > - > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --00000000000061ed73058e3c9e11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Scott for the comment. I will address them tomorrow= , I am just sharing the review to the lwig list.=C2=A0=C2=A0
Yours,=C2= =A0
Daniel

On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sf= luhrer) <sfluhrer@cisco.com>= ; wrote:

Comments:

=C2=A0

  • I have issues with the draft=E2=80=99s emphasis on fixed SPI valu= es.=C2=A0 One reason for the SPI value is to handle key updates cleanly; du= ring the transition, the SPI can be used to indicate whether the packet was encrypted with the previous set of key or the new o= nes.=C2=A0 As we really don=E2=80=99t want to discourage rekeying I would s= uggest that, instead of talking so much about fixed SPIs, you instead addre= ss how to do nonrandom SPIs (for example, by having the top 3 bytes of the inbound SPI being the SAD entry, and the low= er byte being the rekey index).
  • =E2=80=9CValues 0-255 SHOULD NOT be used.=E2=80=9D; shouldn=E2=80=99t that be MUST NOT?=C2=A0 Can you think of an advantag= e a device might have for using a SPI in that region?<= /li>

The use= of fix SPI MUST NOT be considered as a way to avoid strong random generato= rs.=C2=A0 Such generator will be required in order to provide strong cryptographic protec= tion=E2=80=9D; actually, if the IPsec implementation doesn=E2=80=99t actually generat= e its own keys (that is, it relies on an external service to provide them),= and the transform itself doesn=E2=80=99t require random data (CBC can be implemented securely without one), then the IPsec implementati= on doesn=E2=80=99t actually need an CSPRNG.

  • SN based on clocks; one issue that is not addressed is that stand= ard receivers are tuned for an increment of one-per-packet; if the sender u= ses increments significantly larger than that, and packets are reordered, the receiver is more likely to reject val= id packets because they fell outside the window.
  • One issue you do not address (but I believe you should) is the fact that = some cryptographical transforms are more resilient for key reuse (e.g. beca= use you use a fixed key, and don=E2=80=99t change it after a reboot) than others.=C2=A0 In particular, both GCM and C= haCha20-Poly1305 have real problems when that happens, and should be avoide= d.

=C2=A0

Typos:

  • a random SPI may consume to much -> too much
  • fix SPI -> fixed SPI
  • can be allev= iate -> can be alleviated
  • algorythm -> al= gorithm
  • =C2=A0
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--00000000000061ed73058e3c9e11-- From nobody Mon Jul 22 07:52:55 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C22120286; Mon, 22 Jul 2019 07:52:43 -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=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 jg6n0IX1mEap; Mon, 22 Jul 2019 07:52:42 -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 05D6B1202C0; Mon, 22 Jul 2019 07:52:41 -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 x6MEqZZm006928 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jul 2019 17:52:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6MEqXs2018687; Mon, 22 Jul 2019 17:52:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23861.52657.34874.178244@fireball.acr.fi> Date: Mon, 22 Jul 2019 17:52:33 +0300 From: Tero Kivinen To: Rafa Marin-Lopez Cc: i2nsf@ietf.org, "ipsec\@ietf.org WG" , , Gabriel Lopez , mbj@tail-f.com In-Reply-To: <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: [IPsec] Fwd: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:52:48 -0000 Rafa Marin-Lopez writes: > We submitted a new version of the I-D (v05) where we have applied several > changes. In the following you have a summary of the main changes, which we > will expand/explain during our presentation: I put that on my to-read queue. Cannot promise when I have time to read it. > - In order to specify the crypto-algorithms we have used a simple approach by > including an integer and adding a text pointing the IANA in the reference > clause. For example: > > typedef encryption-algorithm-type { > type uint32; > description > "The encryption algorithm is specified with a 32-bit Is there specific reason why the size of the registry does not match the yang definition? The IANA registry is 16-bit and the SA payloads in the IKEv2 only have space for Tranform ID used to carry this information over. So why is this text using uint32 and 32-bit numbers. What happens if someone puts number 0x00010000 there which cannot be transported over IKEv2? -- kivinen@iki.fi From nobody Mon Jul 22 08:11:44 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E06C120286; Mon, 22 Jul 2019 08:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 xL0l0VUx5pDq; Mon, 22 Jul 2019 08:10:49 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 38F42120280; Mon, 22 Jul 2019 08:10:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 43D1B2028C; Mon, 22 Jul 2019 17:10:46 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UIJgyzyKLQBL; Mon, 22 Jul 2019 17:10:46 +0200 (CEST) Received: from [155.54.15.68] (unknown [155.54.15.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 5C5482015C; Mon, 22 Jul 2019 17:10:43 +0200 (CEST) From: Rafa Marin Lopez Message-Id: <422BC608-F527-4BFF-A04F-B8FE42CA3169@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_2E8C0A82-56D8-4DF0-87D1-3907D83713F9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 22 Jul 2019 17:10:42 +0200 In-Reply-To: <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> Cc: Rafa Marin Lopez , Yoav Nir , i2nsf@ietf.org, ipsec@ietf.org, =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , mbj@tail-f.com, Gabriel Lopez To: Valery Smyslov References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:10:55 -0000 --Apple-Mail=_2E8C0A82-56D8-4DF0-87D1-3907D83713F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery: Thank you very much for your comments. Please see ours inside. > El 20 jul 2019, a las 16:38, Valery Smyslov = escribi=C3=B3: >=20 > Hi, > =20 > thank you for updating the document. I still think that some aspect > of IKE-less use case are not discussed yet (well, probably they are = not=20 > "serious", depending on one's definition of "serious"). > =20 > Unlike IKE case. which we can consider as mostly static configuration, > the IKE-less case is a dynamic one. If IPsec SA are being created=20 > on demand (via kernel-acquire) and the traffic volume is high, > then depending on the IPsec policy IKE-less case can become=20 > a highly dynamic, which implies additional requirement on both > the network connecting SC and NSF and the performance of the protocol = used to=20 > secure their communications. In other words, in IKE case the = communication > between IKE daemon and kernel is seamless, while in IKE-less > case the communication between NSF ("kernel") and SC adds > noticeable delay (and can potentially add quite a long delay), > which can influence total performance of the system. > =20 > Generally IKE-less case requires more communications between > different nodes to establish or rekey IPsec SA, than IKE case > (I assume that IKE SA is already established), that may have > an impact on high-speed networks with short-lived IPsec SAs, > especially if they are created per transport connection > (say one IPsec SA for one TCP session). [Authors] What you have just described is what happens in any SDN-based = network. In fact, your comment would be applicable to practically any = scenario based on the SDN paradigm. In the particular case of the I-D, = the IKE-less case is the most similar to case you can see in, for = example, Openflow networks where latency is also important (just as an = example : https://ieeexplore.ieee.org/document/6573052 ) > =20 > I believe, that SC's task of managing IPsec SAs in IKE-less case=20 > may become quite complex, especially because due to the > additional delay, introduced by the network, the picture of the > state of the SAs the SC has can become inaccurate (well,=20 > it will always be inaccurate, but with short delays it doesn't = matter). > Just an example. Consider an SC receives a signal from NSF that an SA > is soft expired and starts rekeying process by first installing a new > pair of inbound SAs. It successfully installs them on the NSF > it receives notification from, but then it receives a notification > that the other NSF has rebooted, so it must clear all the SAs on > its peers, including the just installed new one (which is only > half-done). There seems to be a lot of nuances, and the document=20 > completely ignores them. Not that I think that the task > is impossible, but the algorithm of managing the SAs can become > quite complex and possibly unreliable. [Authors] We largely thought about this kind of cases, although we do = not see any different that may happen in SDN-based network nowadays. And = it seems to me that SDN is becoming something generally accepted despite = the different nuances that needs to be consider. In any case, what you = mention is not ignored in our document because it is included in the = text we have in section 5.3 (see below) where we highlight the = complexity is shifted to the SC (that=E2=80=99s clear). But as I = mentioned, this is not specific to IKE-less case but for any solution = based on the pure SDN paradigm (such as Openflow networks). In other = words, the cases you well mention are applicable to any SDN-based = solution. > =20 > I didn't find this discussion in the draft (sorry if I missed it). Your comments are somehow summarized in the following text section 5.3 "On the contrary, the overload of creating fresh IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side. This overload may create some scalability issues when the number of NSFs is high. In general, literature around SDN-based network management using a centralized Security Controller is aware about scalability issues and solutions have been already provided (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, etc)." I would add that a high-speed dedicated management network between the = SC and the NSFs can be also in place to even limit reduce these delays = between the SC and NSFs (this idea comes again from Openflow networks). = Also the SC can select more =E2=80=9Cintelligent=E2=80=9D lifetime to = orchestrate better when the notifications may appear. In any case, we think we can improve that text as follows:=20 "On the contrary, the overload of creating and managing IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side in comparison with IKE case. For example, the Security Controller have to deal with=20 the latency existing in the path between the Security Controller=20 and the NSF in order to solve tasks such as, rekey or creation and=20 installation of new IPsec SAs. However, this is not specific to our=20= contribution but a general aspect in any SDN-based network.=20 In summary, this overload may create some scalability and performance=20= issues when the number of NSFs is high. Nevertheless, literature around SDN-based network management using a centralized Security Controller is aware about scalability and performance issues and solutions have been already provided and discussed (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, dedicated high-speed management networks, etc). In the context of SDN-based IPsec management, one way to reduce the latency and alleviate some performance issues can be the installation of the IPsec policies and IPsec SAs at the same = time (proactive mode, as described in Section 7.1) instead of waiting for notifications (e.g. a notification sadb-acquire when a new IPsec SA=20= is required) to proceed with the IPsec SA installations (reactive = mode).=20 Another way to reduce the overhead and the potential scalability and performance issues in the Security Controller is to apply the IKE case described in this document, since the IPsec SAs are managed between NSFs without the involvement of the Security Controller at all, except by the initial IKE configuration provided by the Security Controller.=E2=80=9D Please see also our comments to Yoav. Best Regards. > =20 > Regards, > Valery. > =20 > =20 > =20 > =20 > Thanks for getting this done and published. > =20 > We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. > =20 > Barring any such shouting, we will request publication right after the = meeting. > =20 > Thanks again, > =20 > Linda and Yoav >=20 >=20 >> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez > wrote: >> =20 >> Dear all: >>=20 >> We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 >>=20 >> - We have dealt with YANG doctors=E2=80=99 review (Martin's) >>=20 >> - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. >> =20 >> - We have added more specific text in the descriptions. >>=20 >> - Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller. >>=20 >> - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). >> =20 >> - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. >> =20 >> - We have added a subsection 5.3.4 about NSF discovery by the = Security Controller. >>=20 >> - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: >>=20 >> typedef encryption-algorithm-type { >> type uint32; >> description=20 >> "The encryption algorithm is specified with a 32-bit >> number extracted from IANA Registry. The acceptable >> values MUST follow the requirement levels for >> encryption algorithms for ESP and IKEv2."; >> reference=20 >> "IANA Registry- Transform Type 1 - Encryption >> Algorithm Transform IDs. RFC 8221 - Cryptographic >> Algorithm Implementation Requirements and Usage >> Guidance for Encapsulating Security Payload (ESP) >> and Authentication Header (AH) and RFC 8247 - >> Algorithm Implementation Requirements and Usage >> Guidance for the Internet Key Exchange Protocol >> Version 2 (IKEv2)."; >> } >> =20 >> - We have included three additional Annexes with examples in about = the usage of the YANG model. >> =20 >> - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. >> =20 >> Best Regards. >>=20 >>=20 >>> Inicio del mensaje reenviado: >>> =20 >>> De: internet-drafts@ietf.org >>> Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>> Fecha: 7 de julio de 2019, 23:34:03 CEST >>> Para: > >>> Cc: i2nsf@ietf.org >>> Responder a: i2nsf@ietf.org >>> =20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Interface to Network Security = Functions WG of the IETF. >>>=20 >>> Title : Software-Defined Networking (SDN)-based = IPsec Flow Protection >>> Authors : Rafa Marin-Lopez >>> Gabriel Lopez-Millan >>> Fernando Pereniguez-Garcia >>> Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>> Pages : 81 >>> Date : 2019-07-07 >>>=20 >>> Abstract: >>> This document describes how providing IPsec-based flow protection = by >>> means of a Software-Defined Network (SDN) controller (aka. = Security >>> Controller) and establishes the requirements to support this = service. >>> It considers two main well-known scenarios in IPsec: (i) = gateway-to- >>> gateway and (ii) host-to-host. The SDN-based service described in >>> this document allows the distribution and monitoring of IPsec >>> information from a Security Controller to one or several = flow-based >>> Network Security Function (NSF). The NSFs implement IPsec to = protect >>> data traffic between network resources. >>>=20 >>> The document focuses on the NSF Facing Interface by providing = models >>> for configuration and state data required to allow the Security >>> Controller to configure the IPsec databases (SPD, SAD, PAD) and = IKEv2 >>> to establish Security Associations with a reduced intervention of = the >>> network administrator. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ = >>>=20 >>> There are also htmlized versions available at: >>> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 = >>> = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection-05 = >>>=20 >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-05 = >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ = >>>=20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf = >> =20 >> ------------------------------------------------------- >> 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:=C2=A0rafa@um.es = >> ------------------------------------------------------- >> =20 >> =20 >> =20 >> =20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf = --Apple-Mail=_2E8C0A82-56D8-4DF0-87D1-3907D83713F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Valery:

Thank you very much for = your comments. Please see ours inside.
El 20 jul 2019, a las 16:38, = Valery Smyslov <smyslov.ietf@gmail.com> escribi=C3=B3:

Hi,
 
thank you for updating the document. I still think = that some aspect
of = IKE-less use case are not discussed yet (well, probably they are = not 
"serious", = depending on one's definition of "serious").
 
Unlike IKE case. which we can consider as mostly static = configuration,
the = IKE-less case is a dynamic one. If IPsec SA are being created 
on demand (via = kernel-acquire) and the traffic volume is high,
then depending on = the IPsec policy IKE-less case can become 
a highly dynamic, = which implies additional requirement on both
the network = connecting SC and NSF and the performance of the protocol used to 
secure their = communications. In other words, in IKE case the communication
between IKE daemon = and kernel is seamless, while in IKE-less
case the = communication between NSF ("kernel") and SC adds
noticeable delay = (and can potentially add quite a long delay),
which can influence = total performance of the system.
 
Generally IKE-less case requires more communications = between
different nodes to establish or rekey IPsec SA, than IKE = case
(I = assume that IKE SA is already established), that may have
an impact on = high-speed networks with short-lived IPsec SAs,
especially if they = are created per transport connection
(say one IPsec SA = for one TCP session).

[Authors] What you have just described is what = happens in any SDN-based network. In fact, your comment would be = applicable to practically any scenario based on the SDN paradigm. In the = particular case of the I-D, the IKE-less case is the most similar to = case you can see in, for example, Openflow networks where latency is = also important (just as an example : https://ieeexplore.ieee.org/document/6573052 )

 
I = believe, that SC's task of managing IPsec SAs in IKE-less case 
may become quite = complex, especially because due to the
additional delay, = introduced by the network, the picture of the
state of the SAs = the SC has can become inaccurate (well, 
it will always be = inaccurate, but with short delays it doesn't matter).
Just an example. = Consider an SC receives a signal from NSF that an SA
is soft expired and = starts rekeying process by first installing a new
pair of inbound = SAs. It successfully installs them on the NSF
it receives = notification from, but then it receives a notification
that the other NSF = has rebooted, so it must clear all the SAs on
its peers, = including the just installed new one (which is only
half-done). There = seems to be a lot of nuances, and the document 
completely ignores = them. Not that I think that the task
is impossible, but = the algorithm of managing the SAs can become
quite complex and = possibly unreliable.

[Authors] We largely thought about this kind of = cases, although we do not see any different that may happen in SDN-based = network nowadays. And it seems to me that SDN is becoming something = generally accepted despite the different nuances that needs to be = consider. In any case, what you mention is not ignored in our document = because it is included in the text we have in section 5.3 (see below) = where we highlight the complexity is shifted to the SC (that=E2=80=99s = clear). But as I mentioned, this is not specific to IKE-less case but = for any solution based on the pure SDN paradigm (such as Openflow = networks). In other words, the cases you well mention are applicable to = any SDN-based solution.

 
I = didn't find this discussion in the draft (sorry if I missed = it).

Your comments are somehow summarized in the = following text section 5.3

"On the contrary, the overload of creating fresh IPsec
   SAs is shifted to the Security Controller since = IKEv2 is not in the
   NSF.  As a = consequence, this may result in a more complex
   implementation in the controller side. =  This overload may create some
  =  scalability issues when the number of NSFs is high.

In general, literature around = SDN-based network management using a
  =  centralized Security Controller is aware about scalability issues = and
   solutions have been already = provided (e.g. hierarchical Security
  =  Controllers; having multiple replicated Security Controllers, = etc)."

I would add that a high-speed = dedicated management network between the SC and the NSFs can be also in = place to even limit reduce these delays between the SC and NSFs (this = idea comes again from Openflow networks). Also the SC can select more = =E2=80=9Cintelligent=E2=80=9D lifetime to orchestrate better when the = notifications may appear.

In any case, we think we can improve that text as = follows: 

"On the contrary, the overload of creating and managing = IPsec
   SAs is shifted to the Security Controller since = IKEv2 is not in the
   NSF. As a consequence, = this may result in a more complex
  =  implementation in the controller side in comparison = with
   IKE case.  For example, the = Security Controller have to deal with 
  =  the latency existing in the path between the Security = Controller 
   and the NSF in order to solve = tasks such as, rekey or creation and 
  =  installation of new IPsec SAs. However, this is not specific to = our 
   contribution but a general aspect in = any SDN-based network. 
   In summary, this = overload may create some scalability and = performance 
   issues when the number of NSFs = is high.

   Nevertheless, literature = around SDN-based network management using a
  =  centralized Security Controller is aware about scalability and
   performance issues and solutions have been = already provided and
   discussed (e.g. =  hierarchical Security Controllers; having multiple
   replicated Security Controllers, dedicated = high-speed management
   networks, etc). In the = context of SDN-based IPsec management, one
   way to = reduce the latency and alleviate some performance issues = can
   be the installation of the IPsec policies and = IPsec SAs at the same time
   (proactive mode, as = described in Section 7.1) instead of waiting for
  =  notifications (e.g. a notification sadb-acquire when a new IPsec = SA 
   is required) to proceed with the IPsec = SA installations (reactive mode). 
   Another = way to reduce the overhead and the potential scalability = and
   performance issues in the Security Controller = is to apply the IKE
   case described in this = document, since the IPsec SAs are managed
  =  between NSFs without the involvement of the Security Controller = at
   all, except by the initial IKE = configuration provided by the Security
  =  Controller.=E2=80=9D

Please = see also our comments to Yoav.

Best Regards.

 
Regards,
Valery.
 
 
 
 
Thanks = for getting this done and published.
 
We will wait with requesting = publication until the I2NSF session next week.  Between now and = then, please re-read the draft and send a message to the list is = something is seriously wrong.
 
Barring any such shouting, we will request publication right = after the meeting.
 
Thanks again,
 
Linda and Yoav


On 16 Jul 2019, at 15:42, Rafa = Marin-Lopez <rafa@um.es> wrote:
 
Dear all:

We= submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation: 

- We have dealt with YANG doctors=E2=80=99 = review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.
 
- We have added more specific text in = the descriptions.

- Notifications have a = simpler format now since most of the information that contained in the = past is already handled by the Security Controller.

- State data has been reduced. For example, in IKE case, most = of the information is related with IKE and not with the specific details = about IPsec SAs that IKE handles (after all, IKE can abstract this = information from the Security Controller).
 
- We have included text in the security = section to discuss about the default IPsec policies that should be in = the NSF when it starts before contacting with the SC such as the IPsec = policies required to allow traffic between the SC and the NSF.
 
- We have added a subsection 5.3.4 = about NSF discovery by the Security Controller.

- In order to specify the crypto-algorithms we have used a = simple approach by including an integer and adding a text pointing the = IANA in the reference clause. For = example:

typedef = encryption-algorithm-type {
          &nb= sp;type uint32;
          &nb= sp;description 
          &nb= sp;    "The encryption algorithm is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          &nb= sp;    values MUST follow the requirement levels = for
          &nb= sp;    encryption algorithms for ESP and IKEv2.";
          &nb= sp;reference 
          &nb= sp;     "IANA Registry- Transform Type 1 - = Encryption
          &nb= sp;     Algorithm Transform IDs. RFC 8221 - = Cryptographic
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for Encapsulating Security = Payload (ESP)
          &nb= sp;     and Authentication Header (AH) and RFC = 8247 -
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for the Internet Key Exchange = Protocol
          &nb= sp;     Version 2 (IKEv2).";
       }
 
- We have included three additional = Annexes with examples in about the usage of the YANG model.
 
- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without warnings.
 
Best Regards.


Inicio del mensaje reenviado:
 
Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Fecha: 7 de julio de = 2019, 23:34:03 CEST
Para: <i-d-announce@ietf.org>
Responder a: i2nsf@ietf.org
 

A New Internet-Draft is = available from the on-line Internet-Drafts directories.
This= draft is a work item of the Interface to Network Security Functions WG = of the IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow Protection
       Authors =         : Rafa Marin-Lopez
          &nb= sp;            = ;  Gabriel Lopez-Millan
          &nb= sp;            = ;  Fernando Pereniguez-Garcia
        &= nbsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &= nbsp;  Pages=           : 81
        &= nbsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how providing IPsec-based = flow protection by
  means of a Software-Defined = Network (SDN) controller (aka.  Security
  Controller) and establishes the requirements to = support this service.
  It considers two main = well-known scenarios in IPsec: (i) gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document = allows the distribution and monitoring of IPsec
  information from a Security Controller to one or = several flow-based
  Network Security Function = (NSF).  The NSFs implement IPsec to protect
  data traffic between network resources.

  The document focuses on the NSF = Facing Interface by providing models
  for = configuration and state data required to allow the Security
  Controller to configure the IPsec databases (SPD, = SAD, PAD) and IKEv2
  to establish Security = Associations with a reduced intervention of the
  network administrator.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-05


Please = note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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
-------------------------------------------------------
 
 
 
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

= --Apple-Mail=_2E8C0A82-56D8-4DF0-87D1-3907D83713F9-- From nobody Mon Jul 22 08:11:56 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA1A120323; Mon, 22 Jul 2019 08:11:16 -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 kIOrmXqG7c8h; Mon, 22 Jul 2019 08:11:13 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [IPv6:2001:720:1710:601::44]) by ietfa.amsl.com (Postfix) with ESMTP id 7824B120333; Mon, 22 Jul 2019 08:11:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 3ACF92028C; Mon, 22 Jul 2019 17:11:11 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Io3R74_qYV4c; Mon, 22 Jul 2019 17:11:11 +0200 (CEST) Received: from [155.54.15.68] (unknown [155.54.15.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id CACAA2015C; Mon, 22 Jul 2019 17:11:09 +0200 (CEST) From: Rafa Marin Lopez Message-Id: <4A3ADE90-C7E5-4198-9D2E-A441806A00B1@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_1B1E8E97-E623-4859-BDCE-5999F2E7E52F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 22 Jul 2019 17:11:09 +0200 In-Reply-To: <2CFA92C9-EB16-48C4-BFE2-E3A4067F068C@gmail.com> Cc: Rafa Marin Lopez , Valery Smyslov , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , mbj@tail-f.com, i2nsf@ietf.org, Gabriel Lopez , ipsec@ietf.org To: Yoav Nir References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <2CFA92C9-EB16-48C4-BFE2-E3A4067F068C@gmail.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:11:17 -0000 --Apple-Mail=_1B1E8E97-E623-4859-BDCE-5999F2E7E52F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoav: > El 21 jul 2019, a las 3:23, Yoav Nir escribi=C3=B3= : >=20 > Hi, Valery >=20 > [no hats] >=20 > Thanks for that. >=20 > I think this demonstrates that the current document is not enough and = we will need some follow-up documents explaining when to use either = case. [Authors] The objective of the current document is to present the idea = and the interfaces to make things possible. Once we have this, we have = also to work on performance analysis, experimentation (we are actually = working on this already) and other uses cases. In any case, we are more than happy to contribute on those potential = documents, of course.=20 >=20 > I don=E2=80=99t think it=E2=80=99s very useful for the controller to = distribute a policy (SPD entries) but no SAs (SAD entries) in the = IKE-less case. It makes sense in the IKE case because the NSFs can then = use IKE to generate the SAs, but in the IKE-less case that would mean = that one NSF gets a packet that should be protected, sends a message to = the controller, which generates an SA and sends it to both the requester = and the other NSF. This seems high latency. [Authors] What you have just described is the proactive vs reactive mode = of operation that you can find in SDN-based networks. In our case, in = the reactive mode, you install the SPD first and waits for a = sadb_acquire notification. In the proactive mode you install the IPsec = SAs at the same time. In fact, section 7.1 (Figure 4) in our I-D assumes = proactive (step 2) 2. The Security Controller translates the flow-based security policies into IPsec SPD and SAD entries. Clearly there are advantages and disadvantages in proactive and reactive = models, as it may happen in Openflow network. For example, proactive = reduces latency but it may create unnecessary state in the NSFs. = Reactive increases latency but the state is created in the NSFs just = when it is required. You can install rules to avoid a PACKET_IN (the = =E2=80=9Cnotification=E2=80=9D) so you avoid the delay. As I mentioned = to Valery, all of this is expected and assumed in the SDN paradigm (the = IKE-less is the most similar to SDN paradigm nowadays).=20 As per =E2=80=9Chigh latency=E2=80=9D I would say =E2=80=9Chigher = latency=E2=80=9D. And that=E2=80=99s true. The latency increases (it is = reactive mode) but this latency is generally assumable in SDN networks = (until certain level of tolerance, of course). In fact you can find = interesting studies out there about this in Openflow networks.=20 >=20 > I think the case for IKE-less is where the controller sends SPD = entries and SAD entries at the same time (perhaps later updating the SAD = entries to rekey). > In that case the action of the controller is to bring up a tunnel. = For example, if the user (or application) decides that communications = between node A and node B should be encrypted, the controller will send = both policy and keys at the same time to make that tunnel. [Authors] This would be the proactive mode, very valid to reduce = latency. But I assume it is a decision for the SC to make. Right now the = YANG model admits both cases (proactive and reactive). In fact an hybrid = (proactive for some flows and reactive for others) might be possible. Best Regards. >=20 > Yoav >=20 >> On 20 Jul 2019, at 10:38, Valery Smyslov > wrote: >>=20 >> Hi, >> =20 >> thank you for updating the document. I still think that some aspect >> of IKE-less use case are not discussed yet (well, probably they are = not=20 >> "serious", depending on one's definition of "serious"). >> =20 >> Unlike IKE case. which we can consider as mostly static = configuration, >> the IKE-less case is a dynamic one. If IPsec SA are being created=20 >> on demand (via kernel-acquire) and the traffic volume is high, >> then depending on the IPsec policy IKE-less case can become=20 >> a highly dynamic, which implies additional requirement on both >> the network connecting SC and NSF and the performance of the protocol = used to=20 >> secure their communications. In other words, in IKE case the = communication >> between IKE daemon and kernel is seamless, while in IKE-less >> case the communication between NSF ("kernel") and SC adds >> noticeable delay (and can potentially add quite a long delay), >> which can influence total performance of the system. >> =20 >> Generally IKE-less case requires more communications between >> different nodes to establish or rekey IPsec SA, than IKE case >> (I assume that IKE SA is already established), that may have >> an impact on high-speed networks with short-lived IPsec SAs, >> especially if they are created per transport connection >> (say one IPsec SA for one TCP session). >> =20 >> I believe, that SC's task of managing IPsec SAs in IKE-less case=20 >> may become quite complex, especially because due to the >> additional delay, introduced by the network, the picture of the >> state of the SAs the SC has can become inaccurate (well,=20 >> it will always be inaccurate, but with short delays it doesn't = matter). >> Just an example. Consider an SC receives a signal from NSF that an SA >> is soft expired and starts rekeying process by first installing a new >> pair of inbound SAs. It successfully installs them on the NSF >> it receives notification from, but then it receives a notification >> that the other NSF has rebooted, so it must clear all the SAs on >> its peers, including the just installed new one (which is only >> half-done). There seems to be a lot of nuances, and the document=20 >> completely ignores them. Not that I think that the task >> is impossible, but the algorithm of managing the SAs can become >> quite complex and possibly unreliable. >> =20 >> I didn't find this discussion in the draft (sorry if I missed it). >> =20 >> Regards, >> Valery. >> =20 >> =20 >> =20 >> =20 >> Thanks for getting this done and published. >> =20 >> We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. >> =20 >> Barring any such shouting, we will request publication right after = the meeting. >> =20 >> Thanks again, >> =20 >> Linda and Yoav >>=20 >>=20 >>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez > wrote: >>> =20 >>> Dear all: >>>=20 >>> We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 >>>=20 >>> - We have dealt with YANG doctors=E2=80=99 review (Martin's) >>>=20 >>> - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s= comments. >>> =20 >>> - We have added more specific text in the descriptions. >>>=20 >>> - Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller. >>>=20 >>> - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). >>> =20 >>> - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. >>> =20 >>> - We have added a subsection 5.3.4 about NSF discovery by the = Security Controller. >>>=20 >>> - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: >>>=20 >>> typedef encryption-algorithm-type { >>> type uint32; >>> description=20 >>> "The encryption algorithm is specified with a 32-bit >>> number extracted from IANA Registry. The acceptable >>> values MUST follow the requirement levels for >>> encryption algorithms for ESP and IKEv2."; >>> reference=20 >>> "IANA Registry- Transform Type 1 - Encryption >>> Algorithm Transform IDs. RFC 8221 - Cryptographic >>> Algorithm Implementation Requirements and Usage >>> Guidance for Encapsulating Security Payload (ESP) >>> and Authentication Header (AH) and RFC 8247 - >>> Algorithm Implementation Requirements and Usage >>> Guidance for the Internet Key Exchange Protocol >>> Version 2 (IKEv2)."; >>> } >>> =20 >>> - We have included three additional Annexes with examples in about = the usage of the YANG model. >>> =20 >>> - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. >>> =20 >>> Best Regards. >>>=20 >>>=20 >>>> Inicio del mensaje reenviado: >>>> =20 >>>> De: internet-drafts@ietf.org >>>> Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>> Fecha: 7 de julio de 2019, 23:34:03 CEST >>>> Para: > >>>> Cc: i2nsf@ietf.org >>>> Responder a: i2nsf@ietf.org >>>> =20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the Interface to Network Security = Functions WG of the IETF. >>>>=20 >>>> Title : Software-Defined Networking (SDN)-based = IPsec Flow Protection >>>> Authors : Rafa Marin-Lopez >>>> Gabriel Lopez-Millan >>>> Fernando Pereniguez-Garcia >>>> Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>> Pages : 81 >>>> Date : 2019-07-07 >>>>=20 >>>> Abstract: >>>> This document describes how providing IPsec-based flow protection = by >>>> means of a Software-Defined Network (SDN) controller (aka. = Security >>>> Controller) and establishes the requirements to support this = service. >>>> It considers two main well-known scenarios in IPsec: (i) = gateway-to- >>>> gateway and (ii) host-to-host. The SDN-based service described = in >>>> this document allows the distribution and monitoring of IPsec >>>> information from a Security Controller to one or several = flow-based >>>> Network Security Function (NSF). The NSFs implement IPsec to = protect >>>> data traffic between network resources. >>>>=20 >>>> The document focuses on the NSF Facing Interface by providing = models >>>> for configuration and state data required to allow the Security >>>> Controller to configure the IPsec databases (SPD, SAD, PAD) and = IKEv2 >>>> to establish Security Associations with a reduced intervention of = the >>>> network administrator. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ = >>>>=20 >>>> There are also htmlized versions available at: >>>> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 = >>>> = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection-05 = >>>>=20 >>>> A diff from the previous version is available at: >>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-05 = >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at tools.ietf.org = . >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ = >>>>=20 >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2nsf = >>> =20 >>> ------------------------------------------------------- >>> 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:=C2=A0rafa@um.es = >>> ------------------------------------------------------- >>> =20 >>> =20 >>> =20 >>> =20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf = > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_1B1E8E97-E623-4859-BDCE-5999F2E7E52F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Yoav:

El 21 jul 2019, a las 3:23, Yoav Nir <ynir.ietf@gmail.com>= escribi=C3=B3:

Hi, = Valery

[no hats]

Thanks = for that.

I = think this demonstrates that the current document is not enough and we = will need some follow-up documents explaining when to use either = case.

[Authors] The objective of the current document is = to present the idea and the interfaces to make things possible. Once we = have this, we have also to work on performance analysis, experimentation = (we are actually working on this already) and other uses = cases.

In any case, we are more than = happy to contribute on those potential documents, of = course. 


I = don=E2=80=99t think it=E2=80=99s very useful for the controller to = distribute a policy (SPD entries) but no SAs (SAD entries) in the = IKE-less case.  It makes sense in the IKE case because the NSFs can = then use IKE to generate the SAs, but in the IKE-less case that would = mean that one NSF gets a packet that should be protected, sends a = message to the controller, which generates an SA and sends it to both = the requester and the other NSF.  This seems high = latency.

[Authors] What you have just described is the proactive vs reactive mode of operation = that you can find in SDN-based networks. In our case, in the reactive = mode, you install the SPD first and waits for a sadb_acquire = notification. In the proactive mode you install the IPsec SAs at the = same time. In fact, section 7.1 (Figure 4) in our I-D assumes proactive = (step 2)

  =  2.  The Security Controller translates the flow-based = security
       policies into = IPsec SPD and SAD entries.

Clearly there are advantages and disadvantages in = proactive and reactive models, as it may happen in Openflow network. For = example, proactive reduces latency but it may create unnecessary state = in the NSFs. Reactive increases latency but the state is created in the = NSFs just when it is required. You can install rules to avoid a = PACKET_IN (the =E2=80=9Cnotification=E2=80=9D) so you avoid the delay. = As I mentioned to Valery, all of this is expected and assumed in the SDN = paradigm (the IKE-less is the most similar to SDN paradigm = nowadays). 

As per =E2=80=9Chigh = latency=E2=80=9D I would say =E2=80=9Chigher latency=E2=80=9D. And = that=E2=80=99s true. The latency increases (it is reactive mode) but = this latency is generally assumable in SDN networks (until certain level = of tolerance, of course). In fact you can find interesting studies out = there about this in Openflow networks. 


I think the case for IKE-less is where = the controller sends SPD entries and SAD entries at the same time = (perhaps later updating the SAD entries to = rekey).
In that case the action of the controller is = to bring up a tunnel.  For example, if the user (or application) = decides that communications between node A and node B should be = encrypted, the controller will send both policy and keys at the same = time to make that tunnel.

[Authors] This would be the proactive mode, very valid = to reduce latency. But I assume it is a decision for the SC to make. = Right now the YANG model admits both cases (proactive and reactive). In = fact an hybrid (proactive for some flows and reactive for others) might = be possible.

Best Regards.

Yoav

On 20 = Jul 2019, at 10:38, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi,
 
thank you for updating the document. I still think that some = aspect
of = IKE-less use case are not discussed yet (well, probably they are = not 
"serious", = depending on one's definition of "serious").
 
Unlike IKE case. which we can consider as mostly static = configuration,
the = IKE-less case is a dynamic one. If IPsec SA are being created 
on demand (via = kernel-acquire) and the traffic volume is high,
then depending on = the IPsec policy IKE-less case can become 
a highly dynamic, = which implies additional requirement on both
the network = connecting SC and NSF and the performance of the protocol used to 
secure their = communications. In other words, in IKE case the communication
between IKE daemon = and kernel is seamless, while in IKE-less
case the = communication between NSF ("kernel") and SC adds
noticeable delay = (and can potentially add quite a long delay),
which can influence = total performance of the system.
 
Generally IKE-less case requires more communications = between
different nodes to establish or rekey IPsec SA, than IKE = case
(I = assume that IKE SA is already established), that may have
an impact on = high-speed networks with short-lived IPsec SAs,
especially if they = are created per transport connection
(say one IPsec SA = for one TCP session).
 
I believe, that SC's task of managing IPsec SAs in = IKE-less case 
may become quite = complex, especially because due to the
additional delay, = introduced by the network, the picture of the
state of the SAs = the SC has can become inaccurate (well, 
it will always be = inaccurate, but with short delays it doesn't matter).
Just an example. = Consider an SC receives a signal from NSF that an SA
is soft expired and = starts rekeying process by first installing a new
pair of inbound = SAs. It successfully installs them on the NSF
it receives = notification from, but then it receives a notification
that the other NSF = has rebooted, so it must clear all the SAs on
its peers, = including the just installed new one (which is only
half-done). There = seems to be a lot of nuances, and the document 
completely ignores = them. Not that I think that the task
is impossible, but = the algorithm of managing the SAs can become
quite complex and = possibly unreliable.
 
I didn't find this discussion in the draft (sorry if I = missed it).
 
Regards,
Valery.
 
 
 
 
Thanks = for getting this done and published.
 
We will wait with requesting = publication until the I2NSF session next week.  Between now and = then, please re-read the draft and send a message to the list is = something is seriously wrong.
 
Barring any such shouting, we will request publication right = after the meeting.
 
Thanks again,
 
Linda and Yoav


On 16 Jul 2019, at 15:42, Rafa = Marin-Lopez <rafa@um.es> wrote:
 
Dear all:

We= submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation: 

- We have dealt with YANG doctors=E2=80=99 = review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.
 
- We have added more specific text in = the descriptions.

- Notifications have a = simpler format now since most of the information that contained in the = past is already handled by the Security Controller.

- State data has been reduced. For example, in IKE case, most = of the information is related with IKE and not with the specific details = about IPsec SAs that IKE handles (after all, IKE can abstract this = information from the Security Controller).
 
- We have included text in the security = section to discuss about the default IPsec policies that should be in = the NSF when it starts before contacting with the SC such as the IPsec = policies required to allow traffic between the SC and the NSF.
 
- We have added a subsection 5.3.4 = about NSF discovery by the Security Controller.

- In order to specify the crypto-algorithms we have used a = simple approach by including an integer and adding a text pointing the = IANA in the reference clause. For = example:

typedef = encryption-algorithm-type {
          &nb= sp;type uint32;
          &nb= sp;description 
          &nb= sp;    "The encryption algorithm is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          &nb= sp;    values MUST follow the requirement levels = for
          &nb= sp;    encryption algorithms for ESP and IKEv2.";
          &nb= sp;reference 
          &nb= sp;     "IANA Registry- Transform Type 1 - = Encryption
          &nb= sp;     Algorithm Transform IDs. RFC 8221 - = Cryptographic
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for Encapsulating Security = Payload (ESP)
          &nb= sp;     and Authentication Header (AH) and RFC = 8247 -
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for the Internet Key Exchange = Protocol
          &nb= sp;     Version 2 (IKEv2).";
       }
 
- We have included three additional = Annexes with examples in about the usage of the YANG model.
 
- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without warnings.
 
Best Regards.


Inicio del mensaje reenviado:
 
Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Fecha: 7 de julio de = 2019, 23:34:03 CEST
Para: <i-d-announce@ietf.org>
Responder a: i2nsf@ietf.org
 

A New Internet-Draft is = available from the on-line Internet-Drafts directories.
This= draft is a work item of the Interface to Network Security Functions WG = of the IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow Protection
       Authors =         : Rafa Marin-Lopez
          &nb= sp;            = ;  Gabriel Lopez-Millan
          &nb= sp;            = ;  Fernando Pereniguez-Garcia
        &= nbsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &= nbsp;  Pages=           : 81
        &= nbsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how providing IPsec-based = flow protection by
  means of a Software-Defined = Network (SDN) controller (aka.  Security
  Controller) and establishes the requirements to = support this service.
  It considers two main = well-known scenarios in IPsec: (i) gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document = allows the distribution and monitoring of IPsec
  information from a Security Controller to one or = several flow-based
  Network Security Function = (NSF).  The NSFs implement IPsec to protect
  data traffic between network resources.

  The document focuses on the NSF = Facing Interface by providing models
  for = configuration and state data required to allow the Security
  Controller to configure the IPsec databases (SPD, = SAD, PAD) and IKEv2
  to establish Security = Associations with a reduced intervention of the
  network administrator.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-05


Please = note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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
-------------------------------------------------------
 
 
 
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

_____________________________________________= __
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_1B1E8E97-E623-4859-BDCE-5999F2E7E52F-- From nobody Mon Jul 22 08:12:02 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AB91202FF; Mon, 22 Jul 2019 08:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KVVZR2Drm_rx; Mon, 22 Jul 2019 08:11:40 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id EECED1202F1; Mon, 22 Jul 2019 08:11:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 506A22028C; Mon, 22 Jul 2019 17:11:29 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ia7KC2D54Wjf; Mon, 22 Jul 2019 17:11:29 +0200 (CEST) Received: from [155.54.15.68] (unknown [155.54.15.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 2826A2015C; Mon, 22 Jul 2019 17:11:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Rafa Marin-Lopez In-Reply-To: <23861.52657.34874.178244@fireball.acr.fi> Date: Mon, 22 Jul 2019 17:11:27 +0200 Cc: Rafa Marin-Lopez , i2nsf@ietf.org, "ipsec@ietf.org WG" , fernando.pereniguez@cud.upct.es, mbj@tail-f.com, Gabriel Lopez Content-Transfer-Encoding: quoted-printable Message-Id: References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <23861.52657.34874.178244@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:11:44 -0000 Hi Tero: > El 22 jul 2019, a las 16:52, Tero Kivinen escribi=C3=B3= : >=20 > Rafa Marin-Lopez writes: >> We submitted a new version of the I-D (v05) where we have applied = several >> changes. In the following you have a summary of the main changes, = which we >> will expand/explain during our presentation:=20 >=20 > I put that on my to-read queue. Cannot promise when I have time > to read it. Thanks. >=20 >> - In order to specify the crypto-algorithms we have used a simple = approach by >> including an integer and adding a text pointing the IANA in the = reference >> clause. For example: >>=20 >> typedef encryption-algorithm-type { >> type uint32; >> description=20 >> "The encryption algorithm is specified with a 32-bit >=20 > Is there specific reason why the size of the registry does not match > the yang definition? The IANA registry is 16-bit and the SA payloads > in the IKEv2 only have space for Tranform ID used to carry this > information over. >=20 > So why is this text using uint32 and 32-bit numbers. What happens if > someone puts number 0x00010000 there which cannot be transported over > IKEv2?=20 Completely true. It must be a uint16. We will change it. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jul 22 08:37:17 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108D212012B; Mon, 22 Jul 2019 08:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.949 X-Spam-Level: X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 SS8sHTuT3Bzs; Mon, 22 Jul 2019 08:37:04 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACD212013B; Mon, 22 Jul 2019 08:36:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.154.200; From: "Susan Hares" To: "'Rafa Marin Lopez'" , "'Yoav Nir'" Cc: , , , "'Gabriel Lopez'" , =?utf-8?Q?'Fernando_Pere=C3=B1=C3=ADguez_Garc=C3=ADa'?= , "'Valery Smyslov'" , , , "'Vigoureux, Martin \(Nokia - FR/Paris-Saclay\)'" References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <2CFA92C9-EB16-48C4-BFE2-E3A4067F068C@gmail.com> <4A3ADE90-C7E5-4198-9D2E-A441806A00B1@um.es> In-Reply-To: <4A3ADE90-C7E5-4198-9D2E-A441806A00B1@um.es> Date: Mon, 22 Jul 2019 11:36:34 -0400 Message-ID: <008201d540a3$3ef9c1a0$bced44e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01D54081.B7EDEE00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHCFNK4T/q9sOv9UIwCeVdICbA12QI+UTb7AODQKd0B9E5Q0QMPmbQ9AnwHr9GmqCDx4A== Content-Language: en-us X-Antivirus: AVG (VPS 190722-4, 07/22/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:37:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0083_01D54081.B7EDEE00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rafa and Yoav: =20 [IDR co-chair hat on] and Caveat =E2=80=93 I am not a IPSEC or security = expert.=20 =20 >I don=E2=80=99t think it=E2=80=99s very useful for the controller to = distribute a policy (SPD entries) but no SAs (SAD entries) in the = IKE-less case. It makes sense >in the IKE case because the NSFs can = then use IKE to generate the SAs, but in the IKE-less case that would = mean that one NSF gets a packet >that should be protected, sends a = message to the controller, which generates an SA and sends it to both = the requester and the other NSF. This >seems high latency. =20 We may have a case that suggests it is useful for the controller to = distribute policy but no SA (SAD) entries in the Ike-less cae. =20 =20 The IDR and BESS Working groups are considering using BGP to create = secure VPNs. The architecture is controller-device where the controller = distributed the security information (SPD, SA). Some of the pathways in = these VPNS will use IPSEC with Ike over the link. Some of these = pathways will be IKE-less (e.g.) secure private VPN without encrypted = lengths . The VPNs will combine both paths. =20 =20 BGP signaling is passing the keying nonce, rekying time, secure = encryption type, and SA transform information. The BGP is a point-to = multiple-point distribution method (using BGP route-reflectors) combing = BGP and IPSEC information distribution. BGP is being secured per link = (over IPSEC) and the data is being secure in a variety of methods (BGP = origin, filters, or BGPSEC).=20 =20 We=E2=80=99ve set-up a session on Wed (7/24) to discuss the BGP = proposals with security experts. As the leader of the session, I need = help to understand why you think =E2=80=9Cit is not very = useful=E2=80=9D. You can respond to me privately or just attend the = session.=20 =20 Sue Hares=20 =20 =20 From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Rafa Marin = Lopez Sent: Monday, July 22, 2019 11:11 AM To: Yoav Nir Cc: ipsec@ietf.org; mbj@tail-f.com; i2nsf@ietf.org; Gabriel Lopez; = Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa; Rafa Marin Lopez; Valery = Smyslov Subject: Re: [I2nsf] [IPsec] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt =20 Hi Yoav: =20 El 21 jul 2019, a las 3:23, Yoav Nir = escribi=C3=B3: =20 Hi, Valery =20 [no hats] =20 Thanks for that. =20 I think this demonstrates that the current document is not enough and we = will need some follow-up documents explaining when to use either case. =20 [Authors] The objective of the current document is to present the idea = and the interfaces to make things possible. Once we have this, we have = also to work on performance analysis, experimentation (we are actually = working on this already) and other uses cases. =20 In any case, we are more than happy to contribute on those potential = documents, of course.=20 =20 I don=E2=80=99t think it=E2=80=99s very useful for the controller to = distribute a policy (SPD entries) but no SAs (SAD entries) in the = IKE-less case. It makes sense in the IKE case because the NSFs can then = use IKE to generate the SAs, but in the IKE-less case that would mean = that one NSF gets a packet that should be protected, sends a message to = the controller, which generates an SA and sends it to both the requester = and the other NSF. This seems high latency. =20 [Authors] What you have just described is the proactive vs reactive mode = of operation that you can find in SDN-based networks. In our case, in = the reactive mode, you install the SPD first and waits for a = sadb_acquire notification. In the proactive mode you install the IPsec = SAs at the same time. In fact, section 7.1 (Figure 4) in our I-D assumes = proactive (step 2) =20 2. The Security Controller translates the flow-based security policies into IPsec SPD and SAD entries. =20 Clearly there are advantages and disadvantages in proactive and reactive = models, as it may happen in Openflow network. For example, proactive = reduces latency but it may create unnecessary state in the NSFs. = Reactive increases latency but the state is created in the NSFs just = when it is required. You can install rules to avoid a PACKET_IN (the = =E2=80=9Cnotification=E2=80=9D) so you avoid the delay. As I mentioned = to Valery, all of this is expected and assumed in the SDN paradigm (the = IKE-less is the most similar to SDN paradigm nowadays).=20 =20 As per =E2=80=9Chigh latency=E2=80=9D I would say =E2=80=9Chigher = latency=E2=80=9D. And that=E2=80=99s true. The latency increases (it is = reactive mode) but this latency is generally assumable in SDN networks = (until certain level of tolerance, of course). In fact you can find = interesting studies out there about this in Openflow networks.=20 =20 I think the case for IKE-less is where the controller sends SPD entries = and SAD entries at the same time (perhaps later updating the SAD entries = to rekey). In that case the action of the controller is to bring up a tunnel. For = example, if the user (or application) decides that communications = between node A and node B should be encrypted, the controller will send = both policy and keys at the same time to make that tunnel. =20 [Authors] This would be the proactive mode, very valid to reduce = latency. But I assume it is a decision for the SC to make. Right now the = YANG model admits both cases (proactive and reactive). In fact an hybrid = (proactive for some flows and reactive for others) might be possible. =20 Best Regards. =20 Yoav On 20 Jul 2019, at 10:38, Valery Smyslov wrote: =20 Hi, =20 thank you for updating the document. I still think that some aspect of IKE-less use case are not discussed yet (well, probably they are not=20 "serious", depending on one's definition of "serious"). =20 Unlike IKE case. which we can consider as mostly static configuration, the IKE-less case is a dynamic one. If IPsec SA are being created=20 on demand (via kernel-acquire) and the traffic volume is high, then depending on the IPsec policy IKE-less case can become=20 a highly dynamic, which implies additional requirement on both the network connecting SC and NSF and the performance of the protocol = used to=20 secure their communications. In other words, in IKE case the = communication between IKE daemon and kernel is seamless, while in IKE-less case the communication between NSF ("kernel") and SC adds noticeable delay (and can potentially add quite a long delay), which can influence total performance of the system. =20 Generally IKE-less case requires more communications between different nodes to establish or rekey IPsec SA, than IKE case (I assume that IKE SA is already established), that may have an impact on high-speed networks with short-lived IPsec SAs, especially if they are created per transport connection (say one IPsec SA for one TCP session). =20 I believe, that SC's task of managing IPsec SAs in IKE-less case=20 may become quite complex, especially because due to the additional delay, introduced by the network, the picture of the state of the SAs the SC has can become inaccurate (well,=20 it will always be inaccurate, but with short delays it doesn't matter). Just an example. Consider an SC receives a signal from NSF that an SA is soft expired and starts rekeying process by first installing a new pair of inbound SAs. It successfully installs them on the NSF it receives notification from, but then it receives a notification that the other NSF has rebooted, so it must clear all the SAs on its peers, including the just installed new one (which is only half-done). There seems to be a lot of nuances, and the document=20 completely ignores them. Not that I think that the task is impossible, but the algorithm of managing the SAs can become quite complex and possibly unreliable. =20 I didn't find this discussion in the draft (sorry if I missed it). =20 Regards, Valery. =20 =20 =20 =20 Thanks for getting this done and published. =20 We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. =20 Barring any such shouting, we will request publication right after the = meeting. =20 Thanks again, =20 Linda and Yoav On 16 Jul 2019, at 15:42, Rafa Marin-Lopez < = rafa@um.es> wrote: =20 Dear all: We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 - We have dealt with YANG doctors=E2=80=99 review (Martin's) - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. =20 - We have added more specific text in the descriptions. - Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller. - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). =20 - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. =20 - We have added a subsection 5.3.4 about NSF discovery by the Security = Controller. - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: typedef encryption-algorithm-type { type uint32; description=20 "The encryption algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference=20 "IANA Registry- Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } =20 - We have included three additional Annexes with examples in about the = usage of the YANG model. =20 - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. =20 Best Regards. Inicio del mensaje reenviado: =20 De: internet-drafts@ietf.org Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Fecha: 7 de julio de 2019, 23:34:03 CEST Para: < i-d-announce@ietf.org> Cc: i2nsf@ietf.org Responder a: i2nsf@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Interface to Network Security Functions = WG of the IETF. Title : Software-Defined Networking (SDN)-based IPsec = Flow Protection Authors : Rafa Marin-Lopez Gabriel Lopez-Millan Fernando Pereniguez-Garcia Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Pages : 81 Date : 2019-07-07 Abstract: This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources. The document focuses on the NSF Facing Interface by providing models for configuration and state data required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish Security Associations with a reduced intervention of the network administrator. The IETF datatracker status page for this draft is: = = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on/ There are also htmlized versions available at: = = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05= = = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05 A diff from the previous version is available at: = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-05 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org = . Internet-Drafts are also available by anonymous FTP at: = ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------------------------------------------------------- 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 ------------------------------------------------------- =20 =20 =20 =20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 ------=_NextPart_000_0083_01D54081.B7EDEE00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Rafa and Yoav:

 

[IDR co-chair hat on] =C2=A0and Caveat =E2=80=93 I am not a IPSEC or = security expert.

 

>I don=E2=80=99t = think it=E2=80=99s very useful for the controller to distribute a policy = (SPD entries) but no SAs (SAD entries) in the IKE-less case.  It = makes sense >in the IKE case because the NSFs can then use IKE to = generate the SAs, but in the IKE-less case that would mean that one NSF = gets a packet >that should be protected, sends a message to the = controller, which generates an SA and sends it to both the requester and = the other NSF.  This >seems high latency.

 

We may have = a case that suggests it is useful for the controller to distribute = policy but no SA (SAD) entries in the Ike-less cae.=C2=A0 =

 

The IDR and BESS Working groups are considering using BGP to create = secure VPNs.=C2=A0 The architecture is controller-device where the = controller distributed the security information (SPD, SA).=C2=A0 Some of = the pathways in these VPNS will use IPSEC with Ike over the link.=C2=A0 = Some =C2=A0of these pathways will be IKE-less (e.g.) secure private VPN = without encrypted lengths . =C2=A0=C2=A0The VPNs will combine both = paths.=C2=A0

 

BGP signaling is passing the keying nonce, rekying time, secure = encryption type, and SA transform information. =C2=A0The BGP is a = point-to multiple-point distribution method (using BGP route-reflectors) = combing BGP and IPSEC information distribution. =C2=A0=C2=A0BGP is being = secured per link (over IPSEC) and the data is being secure in a variety = of methods (BGP origin, filters, or BGPSEC).

 

We=E2=80=99ve set-up a session on Wed (7/24) to discuss the BGP = proposals with security experts.=C2=A0=C2=A0 As the leader of the = session, I need help to understand why you think =E2=80=9Cit is not very = useful=E2=80=9D.=C2=A0 =C2=A0=C2=A0You can respond to me privately or = just attend the session.

 

Sue Hares

 

 

From:= = I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Rafa Marin = Lopez
Sent: Monday, July 22, 2019 11:11 AM
To: Yoav = Nir
Cc: ipsec@ietf.org; mbj@tail-f.com; i2nsf@ietf.org; = Gabriel Lopez; Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa; Rafa Marin = Lopez; Valery Smyslov
Subject: Re: [I2nsf] [IPsec] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

 

Hi Yoav:

 

El 21 jul 2019, a las 3:23, Yoav Nir <ynir.ietf@gmail.com> = escribi=C3=B3:

 

Hi, Valery

 

[no hats]

 

Thanks for that.

 

I = think this demonstrates that the current document is not enough and we = will need some follow-up documents explaining when to use either = case.

 

[Authors] The objective of the current document is to = present the idea and the interfaces to make things possible. Once we = have this, we have also to work on performance analysis, experimentation = (we are actually working on this already) and other uses = cases.

 

In any case, we are more than happy to contribute on = those potential documents, of course. 



 

I = don=E2=80=99t think it=E2=80=99s very useful for the controller to = distribute a policy (SPD entries) but no SAs (SAD entries) in the = IKE-less case.  It makes sense in the IKE case because the NSFs can = then use IKE to generate the SAs, but in the IKE-less case that would = mean that one NSF gets a packet that should be protected, sends a = message to the controller, which generates an SA and sends it to both = the requester and the other NSF.  This seems high = latency.

 

[Authors] What you have just described is the = proactive vs reactive mode of operation that you can find = in SDN-based networks. In our case, in the reactive mode, you install = the SPD first and waits for a sadb_acquire notification. In the = proactive mode you install the IPsec SAs at the same time. In fact, = section 7.1 (Figure 4) in our I-D assumes proactive (step = 2)

 

   2.  The Security Controller = translates the flow-based security

       policies into IPsec SPD and = SAD entries.

 

Clearly there are advantages and disadvantages in = proactive and reactive models, as it may happen in Openflow network. For = example, proactive reduces latency but it may create unnecessary state = in the NSFs. Reactive increases latency but the state is created in the = NSFs just when it is required. You can install rules to avoid a = PACKET_IN (the =E2=80=9Cnotification=E2=80=9D) so you avoid the delay. = As I mentioned to Valery, all of this is expected and assumed in the SDN = paradigm (the IKE-less is the most similar to SDN paradigm = nowadays). 

 

As per =E2=80=9Chigh latency=E2=80=9D I would say = =E2=80=9Chigher latency=E2=80=9D. And that=E2=80=99s true. The latency = increases (it is reactive mode) but this latency is generally assumable = in SDN networks (until certain level of tolerance, of course). In fact = you can find interesting studies out there about this in Openflow = networks. 



 

I = think the case for IKE-less is where the controller sends SPD entries = and SAD entries at the same time (perhaps later updating the SAD entries = to rekey).

In that case the action of the controller is to bring = up a tunnel.  For example, if the user (or application) decides = that communications between node A and node B should be encrypted, the = controller will send both policy and keys at the same time to make that = tunnel.

 

[Authors] This would be the proactive mode, very valid = to reduce latency. But I assume it is a decision for the SC to make. = Right now the YANG model admits both cases (proactive and reactive). In = fact an hybrid (proactive for some flows and reactive for others) might = be possible.

 

Best = Regards.

 

Yoav



On 20 = Jul 2019, at 10:38, Valery Smyslov <smyslov.ietf@gmail.com> = wrote:

 

Hi,<= span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>=

 =

thank you = for updating the document. I still think that some aspect=

of = IKE-less use case are not discussed yet (well, probably they are = not =

"serio= us", depending on one's definition of = "serious").=

 =

Unlike IKE = case. which we can consider as mostly static configuration,=

the = IKE-less case is a dynamic one. If IPsec SA are being created =

on demand = (via kernel-acquire) and the traffic volume is high,=

then = depending on the IPsec policy IKE-less case can become =

a highly = dynamic, which implies additional requirement on both=

the = network connecting SC and NSF and the performance of the protocol used = to =

secure = their communications. In other words, in IKE case the = communication=

between = IKE daemon and kernel is seamless, while in IKE-less=

case the = communication between NSF ("kernel") and SC adds=

noticeable = delay (and can potentially add quite a long delay),=

which can = influence total performance of the system.=

 =

Generally = IKE-less case requires more communications between=

different = nodes to establish or rekey IPsec SA, than IKE case=

(I assume = that IKE SA is already established), that may have=

an impact = on high-speed networks with short-lived IPsec SAs,=

especially = if they are created per transport connection=

(say one = IPsec SA for one TCP session).=

 =

I believe, = that SC's task of managing IPsec SAs in IKE-less case =

may become = quite complex, especially because due to the=

additional = delay, introduced by the network, the picture of the=

state of = the SAs the SC has can become inaccurate (well, =

it will = always be inaccurate, but with short delays it doesn't = matter).=

Just an = example. Consider an SC receives a signal from NSF that an = SA=

is soft = expired and starts rekeying process by first installing a = new=

pair of = inbound SAs. It successfully installs them on the NSF=

it = receives notification from, but then it receives a = notification=

that the = other NSF has rebooted, so it must clear all the SAs on=

its peers, = including the just installed new one (which is only=

half-done).= There seems to be a lot of nuances, and the document =

completely = ignores them. Not that I think that the task=

is = impossible, but the algorithm of managing the SAs can become=

quite = complex and possibly unreliable.=

 =

I didn't = find this discussion in the draft (sorry if I missed it).=

 =

Regards,=

Valery.=

 =

 =

 =

 =

Thanks for = getting this done and published.

 =

We will = wait with requesting publication until the I2NSF session next week. =  Between now and then, please re-read the draft and send a message = to the list is something is seriously = wrong.

 =

Barring = any such shouting, we will request publication right after the = meeting.

 =

Thanks = again,

 =

Linda and = Yoav



On 16 Jul = 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> = wrote:

 =

Dear = all:

We submitted a new version of the I-D (v05) where we = have applied several changes. In the following you have a summary of the = main changes, which we will expand/explain during our = presentation: 

- We have dealt with YANG doctors=E2=80=99 = review (Martin's)

- We have dealt with Paul = Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.

 =

- We have = added more specific text in the descriptions.

- Notifications = have a simpler format now since most of the information that contained = in the past is already handled by the Security Controller.

- = State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security = Controller).

 =

- We have = included text in the security section to discuss about the default IPsec = policies that should be in the NSF when it starts before contacting with = the SC such as the IPsec policies required to allow traffic between the = SC and the NSF.

 =

- We have = added a subsection 5.3.4 about NSF discovery by the Security = Controller.

- In order to specify the crypto-algorithms we have = used a simple approach by including an integer and adding a text = pointing the IANA in the reference clause. For = example:


typedef= encryption-algorithm-type = {
           ty= pe = uint32;
          &n= bsp;description 
        =        "The encryption algorithm = is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          = ;     values MUST follow the requirement levels = for
           =     encryption algorithms for ESP and = IKEv2.";
         &n= bsp; reference 
       &n= bsp;        "IANA Registry- = Transform Type 1 - = Encryption
          = ;      Algorithm Transform IDs. RFC 8221 - = Cryptographic
         &n= bsp;      Algorithm Implementation = Requirements and = Usage
          &nbs= p;     Guidance for Encapsulating Security = Payload = (ESP)
          &nbs= p;     and Authentication Header (AH) and RFC = 8247 = -
           &n= bsp;    Algorithm Implementation Requirements and = Usage
          &nbs= p;     Guidance for the Internet Key Exchange = Protocol
          &= nbsp;     Version 2 = (IKEv2).";
       }=

 =

- We have = included three additional Annexes with examples in about the usage of = the YANG model.

 =

- We have = performed pyang --lint --lint-ensure-hyphenated-names and pyang -f = yang --yang-line-length 69 in our model without = warnings.

 =

Best = Regards.



Inicio del = mensaje reenviado:

 =

Asunto: = [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt=

Fecha: 7 de = julio de 2019, 23:34:03 CEST=

Responder= a: i2nsf@ietf.org=

 =


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Interface to Network = Security Functions WG of the = IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow = Protection
       Authors =         : Rafa = Marin-Lopez
         &nbs= p;            = ;   Gabriel = Lopez-Millan
         &nb= sp;           &nbs= p;   Fernando Pereniguez-Garcia
        &n= bsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &n= bsp;  Pages =           : = 81
        &n= bsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how = providing IPsec-based flow protection by
  means of a = Software-Defined Network (SDN) controller (aka. =  Security
  Controller) and establishes the = requirements to support this service.
  It considers two = main well-known scenarios in IPsec: (i) = gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document allows the = distribution and monitoring of IPsec
  information from a = Security Controller to one or several flow-based
  Network = Security Function (NSF).  The NSFs implement IPsec to = protect
  data traffic between network = resources.

  The document focuses on the NSF Facing = Interface by providing models
  for configuration and state = data required to allow the Security
  Controller to = configure the IPsec databases (SPD, SAD, PAD) and = IKEv2
  to establish Security Associations with a reduced = intervention of the
  network administrator.


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-= sdn-ipsec-flow-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-i= psec-flow-protection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i= 2nsf-sdn-ipsec-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2n= sf-sdn-ipsec-flow-protection-05


Please note that = it may take a couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Draft= s are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
=
_______________________________________________
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
------------= -------------------------------------------=

 =

 =

 =

 =

___________= ____________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf=

 

_______________________________________________
IPse= c mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

 

------=_NextPart_000_0083_01D54081.B7EDEE00-- From nobody Mon Jul 22 08:38:43 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C941202D7; Mon, 22 Jul 2019 08:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 w65l3RKP1hYh; Mon, 22 Jul 2019 08:38:32 -0700 (PDT) Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) (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 3541A1202BB; Mon, 22 Jul 2019 08:38:32 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6A3455018AF; Mon, 22 Jul 2019 15:38:30 +0000 (UTC) Received: from pdx1-sub0-mail-a62.g.dreamhost.com (100-96-38-36.trex.outbound.svc.cluster.local [100.96.38.36]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BFC895016FC; Mon, 22 Jul 2019 15:38:29 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a62.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.3); Mon, 22 Jul 2019 15:38:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Shoe-Suffer: 7e2753cb306ef00e_1563809910184_2231471533 X-MC-Loop-Signature: 1563809910184:232320837 X-MC-Ingress-Time: 1563809910184 Received: from pdx1-sub0-mail-a62.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a62.g.dreamhost.com (Postfix) with ESMTP id 0869F837A8; Mon, 22 Jul 2019 08:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=EUYPFXbTbq6MP8 DdZUnR+fI2r4w=; b=ForJ8E+gg2L8o8vnlIa1hAFZ5R7FrFtxy13vc5+QiBwgec zhXT+3PXzLcSnuygNXbvAeGXopAiV3jmtvhfl6GOd2Up5LC93AMwGG7CDLSOQ1R7 8cTOXh0PIZ6SqKbyEo5O0BVJo03vk65JzAjml9ISDKGY0aNwE2KbhhOtm6Suo= Received: from localhost (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a62.g.dreamhost.com (Postfix) with ESMTPSA id 55380837AE; Mon, 22 Jul 2019 08:38:22 -0700 (PDT) Date: Mon, 22 Jul 2019 10:38:21 -0500 X-DH-BACKEND: pdx1-sub0-mail-a62 From: Nico Williams To: Rafa Marin-Lopez Cc: i2nsf@ietf.org, "ipsec@ietf.org WG" , Fernando =?iso-8859-1?Q?Pere=F1=EDguez_Garc=EDa?= , Gabriel Lopez , mbj@tail-f.com Message-ID: <20190722153820.GJ24576@localhost> References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrjeeggdelgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppeekrddvrddutdehrddujeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpeekrddvrddutdehrddujedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [IPsec] Fwd: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:38:41 -0000 On Tue, Jul 16, 2019 at 02:42:35PM +0200, Rafa Marin-Lopez wrote: > We submitted a new version of the I-D (v05) where we have applied > several changes. In the following you have a summary of the main > changes, which we will expand/explain during our presentation: Hey! I'm sorry I've missed this. If you want flow protection... have you seen RFC5660? RFC5660 (yes, by yours truly) provides flow protection without any changes to ESP/AH, or even to IKEv2. Nico -- From nobody Mon Jul 22 08:39:27 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D818612013B; Mon, 22 Jul 2019 08:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RlR4-xSxxRYV; Mon, 22 Jul 2019 08:39:19 -0700 (PDT) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42EB8120052; Mon, 22 Jul 2019 08:39:19 -0700 (PDT) Received: by mail-vs1-xe43.google.com with SMTP id a186so24777983vsd.7; Mon, 22 Jul 2019 08:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=h6kTiaHxUypV5ZSxO9XTWz8mGlwrSrxmr958xIPTqPs=; b=jxDkMSLx6upi258GC1ScvKf83EP9k8gJ4+a7YXgl+7s+WFoz3ZjBNG2ibJdfePIBw0 Cot70hSmx9A823NTzjlTqm593lUmtrYzOSTd3JwdyVMzYP30HIJjKD58Mkm4tQkGCFv5 +QHvvrYuKoiRpb1vioi4GSrUa2amECWmwpjqPIuFATE/cAhcDxRPPhlMR7+6kuYsXbzK SP0zT7CDdZTtOfFhfSEkXcD7elpbpeKHn7LnSx9WGYwsIANjactQi23Oi8ReLAbv1sMq IdYAxSwUBKRx6sZjRAugKlHMDI2HPw7drhAnpF4bDwIKcXlUg+kMeCNCgM6gtApnTdSP MmnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=h6kTiaHxUypV5ZSxO9XTWz8mGlwrSrxmr958xIPTqPs=; b=poWdjloAxkqPK2GQGzWgp7/jsiW9XwfwtbmgFqgR9W73O4edZvCfvNgO1Ag5fqE8aq AXV88fpbY3lC5ELuWIPA2Hd2m9/9yAzGyQp1wAlfebAjjhQ2j42Yd+c2Jzw2aOadDoHy c41+4kwtwhmwsIqUUyK1TeFax4710OLooige3Nf3S34F8xSEqcXn16oJHVx7kEWRMHyH q5rsNPgaT4RlSFPMdbxCZ4ABHmB4BSZH88N7ZWhfff3u7H5nr4RSeSm+kVlfwp0L9U7g e24uZHkOs7giRicoGDWWLoIPjNRYST3dpIx7wmp9LvP99M+ObV3RHNqnQ+8F4y6V7tYX wARw== X-Gm-Message-State: APjAAAU+UhGTS3EC6aCr4OJK/sSyRjxT+PXGoHacwAMA3SM/NysKrZK+ qBLDVdnsxf/AlFsHbuzGiKw= X-Google-Smtp-Source: APXvYqxx+av6NC/y/tG2hXBT0kTxwuu/YcOzo26LvGwzs7JYJjV+B0/ZG5DHduI/qZzPR85+t64H4A== X-Received: by 2002:a67:bc7:: with SMTP id 190mr20262856vsl.6.1563809958244; Mon, 22 Jul 2019 08:39:18 -0700 (PDT) Received: from svannotebook ([2001:67c:370:128:b8f4:fc59:5b3c:83af]) by smtp.gmail.com with ESMTPSA id l129sm37222734vki.45.2019.07.22.08.39.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 08:39:17 -0700 (PDT) From: "Valery Smyslov" To: "'Rafa Marin Lopez'" Cc: "'Yoav Nir'" , , , =?utf-8?Q?'Fernando_Pere=C3=B1=C3=ADguez_Garc=C3=ADa'?= , , "'Gabriel Lopez'" References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <422BC608-F527-4BFF-A04F-B8FE42CA3169@um.es> In-Reply-To: <422BC608-F527-4BFF-A04F-B8FE42CA3169@um.es> Date: Mon, 22 Jul 2019 18:39:14 +0300 Message-ID: <030c01d540a3$9e7a74d0$db6f5e70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_030D_01D540BC.C3D2D060" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHCFNK4T/q9sOv9UIwCeVdICbA12QI+UTb7AODQKd0B9E5Q0QGsr2TdpscZwzA= Content-Language: ru Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:39:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_030D_01D540BC.C3D2D060 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Rafa, =20 sure this problem is general for any SDN solution. My point was that if SC performs a lot of real-time=20 (or near real-time) tasks as it may happen in IKE-less case,=20 then this problem may become serious. =20 Anyway, I'm happy with the updated text, thank you. However, in a following document(s), suggested by Yoav, I'd like to see more concrete advices of how SC should act in this situation to ensure that the consistence of the=20 network is preserved despite all the possible delays etc. =20 Regards, Valery. =20 =20 From: Rafa Marin Lopez =20 Sent: Monday, July 22, 2019 6:11 PM To: Valery Smyslov Cc: Rafa Marin Lopez ; Yoav Nir ; = i2nsf@ietf.org; ipsec@ietf.org; Fernando Pere=C3=B1=C3=ADguez = Garc=C3=ADa ; mbj@tail-f.com; Gabriel = Lopez Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt =20 Hi Valery: =20 Thank you very much for your comments. Please see ours inside. El 20 jul 2019, a las 16:38, Valery Smyslov > escribi=C3=B3: =20 Hi, =20 thank you for updating the document. I still think that some aspect of IKE-less use case are not discussed yet (well, probably they are not=20 "serious", depending on one's definition of "serious"). =20 Unlike IKE case. which we can consider as mostly static configuration, the IKE-less case is a dynamic one. If IPsec SA are being created=20 on demand (via kernel-acquire) and the traffic volume is high, then depending on the IPsec policy IKE-less case can become=20 a highly dynamic, which implies additional requirement on both the network connecting SC and NSF and the performance of the protocol = used to=20 secure their communications. In other words, in IKE case the = communication between IKE daemon and kernel is seamless, while in IKE-less case the communication between NSF ("kernel") and SC adds noticeable delay (and can potentially add quite a long delay), which can influence total performance of the system. =20 Generally IKE-less case requires more communications between different nodes to establish or rekey IPsec SA, than IKE case (I assume that IKE SA is already established), that may have an impact on high-speed networks with short-lived IPsec SAs, especially if they are created per transport connection (say one IPsec SA for one TCP session). =20 [Authors] What you have just described is what happens in any SDN-based = network. In fact, your comment would be applicable to practically any = scenario based on the SDN paradigm. In the particular case of the I-D, = the IKE-less case is the most similar to case you can see in, for = example, Openflow networks where latency is also important (just as an = example : https://ieeexplore.ieee.org/document/6573052 ) =20 I believe, that SC's task of managing IPsec SAs in IKE-less case=20 may become quite complex, especially because due to the additional delay, introduced by the network, the picture of the state of the SAs the SC has can become inaccurate (well,=20 it will always be inaccurate, but with short delays it doesn't matter). Just an example. Consider an SC receives a signal from NSF that an SA is soft expired and starts rekeying process by first installing a new pair of inbound SAs. It successfully installs them on the NSF it receives notification from, but then it receives a notification that the other NSF has rebooted, so it must clear all the SAs on its peers, including the just installed new one (which is only half-done). There seems to be a lot of nuances, and the document=20 completely ignores them. Not that I think that the task is impossible, but the algorithm of managing the SAs can become quite complex and possibly unreliable. =20 [Authors] We largely thought about this kind of cases, although we do = not see any different that may happen in SDN-based network nowadays. And = it seems to me that SDN is becoming something generally accepted despite = the different nuances that needs to be consider. In any case, what you = mention is not ignored in our document because it is included in the = text we have in section 5.3 (see below) where we highlight the = complexity is shifted to the SC (that=E2=80=99s clear). But as I = mentioned, this is not specific to IKE-less case but for any solution = based on the pure SDN paradigm (such as Openflow networks). In other = words, the cases you well mention are applicable to any SDN-based = solution. =20 I didn't find this discussion in the draft (sorry if I missed it). =20 Your comments are somehow summarized in the following text section 5.3 =20 "On the contrary, the overload of creating fresh IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side. This overload may create some scalability issues when the number of NSFs is high. In general, literature around SDN-based network management using a centralized Security Controller is aware about scalability issues and solutions have been already provided (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, etc)." =20 I would add that a high-speed dedicated management network between the = SC and the NSFs can be also in place to even limit reduce these delays = between the SC and NSFs (this idea comes again from Openflow networks). = Also the SC can select more =E2=80=9Cintelligent=E2=80=9D lifetime to = orchestrate better when the notifications may appear. =20 In any case, we think we can improve that text as follows:=20 =20 "On the contrary, the overload of creating and managing IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side in comparison with IKE case. For example, the Security Controller have to deal with=20 the latency existing in the path between the Security Controller=20 and the NSF in order to solve tasks such as, rekey or creation and=20 installation of new IPsec SAs. However, this is not specific to our=20 contribution but a general aspect in any SDN-based network.=20 In summary, this overload may create some scalability and performance = issues when the number of NSFs is high. Nevertheless, literature around SDN-based network management using a centralized Security Controller is aware about scalability and performance issues and solutions have been already provided and discussed (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, dedicated high-speed management networks, etc). In the context of SDN-based IPsec management, one way to reduce the latency and alleviate some performance issues can be the installation of the IPsec policies and IPsec SAs at the same = time (proactive mode, as described in Section 7.1) instead of waiting for notifications (e.g. a notification sadb-acquire when a new IPsec SA=20 is required) to proceed with the IPsec SA installations (reactive = mode).=20 Another way to reduce the overhead and the potential scalability and performance issues in the Security Controller is to apply the IKE case described in this document, since the IPsec SAs are managed between NSFs without the involvement of the Security Controller at all, except by the initial IKE configuration provided by the Security Controller.=E2=80=9D =20 Please see also our comments to Yoav. =20 Best Regards. =20 Regards, Valery. =20 =20 =20 =20 Thanks for getting this done and published. =20 We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. =20 Barring any such shouting, we will request publication right after the = meeting. =20 Thanks again, =20 Linda and Yoav On 16 Jul 2019, at 15:42, Rafa Marin-Lopez < = rafa@um.es> wrote: =20 Dear all: We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 - We have dealt with YANG doctors=E2=80=99 review (Martin's) - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. =20 - We have added more specific text in the descriptions. - Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller. - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). =20 - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. =20 - We have added a subsection 5.3.4 about NSF discovery by the Security = Controller. - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: typedef encryption-algorithm-type { type uint32; description=20 "The encryption algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference=20 "IANA Registry- Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } =20 - We have included three additional Annexes with examples in about the = usage of the YANG model. =20 - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. =20 Best Regards. Inicio del mensaje reenviado: =20 De: internet-drafts@ietf.org Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Fecha: 7 de julio de 2019, 23:34:03 CEST Para: < i-d-announce@ietf.org> Cc: i2nsf@ietf.org Responder a: i2nsf@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Interface to Network Security Functions = WG of the IETF. Title : Software-Defined Networking (SDN)-based IPsec = Flow Protection Authors : Rafa Marin-Lopez Gabriel Lopez-Millan Fernando Pereniguez-Garcia Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Pages : 81 Date : 2019-07-07 Abstract: This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources. The document focuses on the NSF Facing Interface by providing models for configuration and state data required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish Security Associations with a reduced intervention of the network administrator. The IETF datatracker status page for this draft is: = = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on/ There are also htmlized versions available at: = = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05= = = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05 A diff from the previous version is available at: = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-05 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org = . Internet-Drafts are also available by anonymous FTP at: = ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------------------------------------------------------- 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 ------------------------------------------------------- =20 =20 =20 =20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------=_NextPart_000_030D_01D540BC.C3D2D060 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Rafa,

 

sure this problem = is general for any SDN solution.

My point was that = if SC performs a lot of real-time

(or near = real-time) tasks as it may happen in IKE-less case, =

then this problem = may become serious.

 

Anyway, I'm happy = with the updated text, thank you.

However, in a = following document(s), suggested by Yoav,

I'd like to see = more concrete advices of how SC should

act in this = situation to ensure that the consistence of the

network is = preserved despite all the possible delays etc.

 

Regards,=

Valery.<= /span>

 

 

From: Rafa Marin Lopez = <rafa@um.es>
Sent: Monday, July 22, 2019 6:11 = PM
To: Valery Smyslov = <smyslov.ietf@gmail.com>
Cc: Rafa Marin Lopez = <rafa@um.es>; Yoav Nir <ynir.ietf@gmail.com>; = i2nsf@ietf.org; ipsec@ietf.org; Fernando Pere=C3=B1=C3=ADguez = Garc=C3=ADa <fernando.pereniguez@cud.upct.es>; mbj@tail-f.com; = Gabriel Lopez <gabilm@um.es>
Subject: Re: [I2nsf] I-D = Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

 

Hi Valery:

 

Thank you very much for your comments. Please see ours = inside.

El 20 jul 2019, a las 16:38, Valery Smyslov <smyslov.ietf@gmail.com> = escribi=C3=B3:

 

Hi,

 

thank = you for updating the document. I still think that some = aspect

of IKE-less use case are not = discussed yet (well, probably they are not 

"serious", depending on one's = definition of "serious").

 

Unlike = IKE case. which we can consider as mostly static = configuration,

the = IKE-less case is a dynamic one. If IPsec SA are being created 

on = demand (via kernel-acquire) and the traffic volume is = high,

then depending on the IPsec = policy IKE-less case can become 

a = highly dynamic, which implies additional requirement on = both

the network connecting SC and = NSF and the performance of the protocol used to 

secure their communications. In other words, = in IKE case the communication

between = IKE daemon and kernel is seamless, while in = IKE-less

case the communication between = NSF ("kernel") and SC adds

noticeable delay (and can potentially add = quite a long delay),

which = can influence total performance of the = system.

 

Generally IKE-less case requires more = communications between

different nodes to establish or rekey IPsec = SA, than IKE case

(I = assume that IKE SA is already established), that may = have

an impact on high-speed networks = with short-lived IPsec SAs,

especially if they are created per transport = connection

(say one IPsec SA for one TCP = session).

 

[Authors] What you have just described is what happens = in any SDN-based network. In fact, your comment would be applicable to = practically any scenario based on the SDN paradigm. In the particular = case of the I-D, the IKE-less case is the most similar to case you can = see in, for example, Openflow networks where latency is also important = (just as an example : https://ieeexplore.= ieee.org/document/6573052 )



 

I = believe, that SC's task of managing IPsec SAs in IKE-less case 

may become quite complex, especially because = due to the

additional delay, introduced by = the network, the picture of the

state of = the SAs the SC has can become inaccurate (well, 

it = will always be inaccurate, but with short delays it doesn't = matter).

Just an example. Consider an SC = receives a signal from NSF that an SA

is soft = expired and starts rekeying process by first installing a = new

pair of inbound SAs. It = successfully installs them on the NSF

it = receives notification from, but then it receives a = notification

that the other NSF has rebooted, = so it must clear all the SAs on

its = peers, including the just installed new one (which is = only

half-done). There seems to be a = lot of nuances, and the document 

completely ignores them. Not that I think = that the task

is impossible, but the algorithm = of managing the SAs can become

quite = complex and possibly = unreliable.

 

[Authors] We largely thought about this kind of cases, = although we do not see any different that may happen in SDN-based = network nowadays. And it seems to me that SDN is becoming something = generally accepted despite the different nuances that needs to be = consider. In any case, what you mention is not ignored in our document = because it is included in the text we have in section 5.3 (see below) = where we highlight the complexity is shifted to the SC (that=E2=80=99s = clear). But as I mentioned, this is not specific to IKE-less case but = for any solution based on the pure SDN paradigm (such as Openflow = networks). In other words, the cases you well mention are applicable to = any SDN-based solution.



 

I didn't = find this discussion in the draft (sorry if I missed = it).

 

Your comments are somehow summarized in the following = text section 5.3

 

"On the contrary, = the overload of creating fresh IPsec
   SAs is shifted to = the Security Controller since IKEv2 is not in the
   NSF. =  As a consequence, this may result in a more complex
  =  implementation in the controller side.  This overload may = create some
   scalability issues when the number of NSFs = is high.

In general, literature = around SDN-based network management using a

   centralized Security Controller is aware = about scalability issues and

   solutions have been already provided = (e.g. hierarchical Security

   Controllers; having multiple replicated = Security Controllers, etc)."

 

I would add that a high-speed dedicated management = network between the SC and the NSFs can be also in place to even limit = reduce these delays between the SC and NSFs (this idea comes again from = Openflow networks). Also the SC can select more = =E2=80=9Cintelligent=E2=80=9D lifetime to orchestrate better when the = notifications may appear.

 

In any case, we think we can improve that text as = follows: 

 

"On the contrary, the overload of creating and = managing IPsec

   SAs = is shifted to the Security Controller since IKEv2 is not in = the
   NSF. As a consequence, this may result in a more = complex
   implementation in the controller side in = comparison with

  =  IKE case.  For example, the Security Controller have to = deal with 

  =  the latency existing in the path between the Security = Controller 

  =  and the NSF in order to solve tasks such as, rekey or = creation and 

  =  installation of new IPsec SAs. However, this is not specific to = our 

  =  contribution but a general aspect in any SDN-based = network. 

  =  In summary, this overload may create some scalability and = performance 

  =  issues when the number of NSFs is = high.


  =  Nevertheless, literature around SDN-based network management using = a
   centralized Security Controller is aware about = scalability and
   performance issues and solutions have = been already provided and
   discussed (e.g. =  hierarchical Security Controllers; having multiple
  =  replicated Security Controllers, dedicated high-speed = management
   networks, etc). In the context of SDN-based = IPsec management, one

   way to reduce the latency and alleviate = some performance issues can

   be the installation of the IPsec policies = and IPsec SAs at the same time

   (proactive mode, as described in Section = 7.1) instead of waiting for

   notifications (e.g. a notification = sadb-acquire when a new IPsec SA 

   is required) to proceed with the IPsec SA = installations (reactive mode). 

   Another way to reduce the overhead and = the potential scalability and

   performance issues in the Security = Controller is to apply the IKE
   case described in this = document, since the IPsec SAs are managed
   between NSFs = without the involvement of the Security Controller at
  =  all, except by the initial IKE configuration provided by the = Security
  =  Controller.=E2=80=9D

 

Please see also our comments to = Yoav.

 

Best Regards.



 

Regards,

Valery.

 

 

 

 

Thanks for getting = this done and published.

 

We will wait with requesting publication until the = I2NSF session next week.  Between now and then, please re-read the = draft and send a message to the list is something is seriously = wrong.

 

Barring any such shouting, we will request publication = right after the meeting.

 

Thanks again,

 

Linda and Yoav




On 16 Jul 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> = wrote:

 

Dear all:

We submitted a new version of the = I-D (v05) where we have applied several changes. In the following = you have a summary of the main changes, which we will expand/explain = during our presentation: 

- We have dealt with YANG = doctors=E2=80=99 review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.

 

- We have added more specific text in the = descriptions.

- Notifications have a simpler format now since = most of the information that contained in the past is already handled by = the Security Controller.

- State data has been reduced. For = example, in IKE case, most of the information is related with IKE and = not with the specific details about IPsec SAs that IKE handles (after = all, IKE can abstract this information from the Security = Controller).

 

- We have included text in the security section to = discuss about the default IPsec policies that should be in the NSF when = it starts before contacting with the SC such as the IPsec policies = required to allow traffic between the SC and the = NSF.

 

- We have added a subsection 5.3.4 about NSF discovery = by the Security Controller.

- In order to specify the = crypto-algorithms we have used a simple approach by including an integer = and adding a text pointing the IANA in = the reference clause. For = example:


typedef encryption-algorithm-type = {
           ty= pe = uint32;
          &n= bsp;description 
        =        "The encryption algorithm = is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          = ;     values MUST follow the requirement levels = for
           =     encryption algorithms for ESP and = IKEv2.";
         &n= bsp; reference 
       &n= bsp;        "IANA Registry- = Transform Type 1 - = Encryption
          = ;      Algorithm Transform IDs. RFC 8221 - = Cryptographic
         &n= bsp;      Algorithm Implementation = Requirements and = Usage
          &nbs= p;     Guidance for Encapsulating Security = Payload = (ESP)
          &nbs= p;     and Authentication Header (AH) and RFC = 8247 = -
           &n= bsp;    Algorithm Implementation Requirements and = Usage
          &nbs= p;     Guidance for the Internet Key Exchange = Protocol
          &= nbsp;     Version 2 = (IKEv2).";
       }=

 

- We have included three additional Annexes with = examples in about the usage of the YANG = model.

 

- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without warnings.

 

Best Regards.




Inicio del mensaje = reenviado:

 

Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

Fecha: 7 de julio de 2019, = 23:34:03 CEST

Responder a: i2nsf@ietf.org

 


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the = Interface to Network Security Functions WG of the = IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow = Protection
       Authors =         : Rafa = Marin-Lopez
         &nbs= p;            = ;   Gabriel = Lopez-Millan
         &nb= sp;           &nbs= p;   Fernando Pereniguez-Garcia
        &n= bsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &n= bsp;  Pages =           : = 81
        &n= bsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how = providing IPsec-based flow protection by
  means of a = Software-Defined Network (SDN) controller (aka. =  Security
  Controller) and establishes the = requirements to support this service.
  It considers two = main well-known scenarios in IPsec: (i) = gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document allows the = distribution and monitoring of IPsec
  information from a = Security Controller to one or several flow-based
  Network = Security Function (NSF).  The NSFs implement IPsec to = protect
  data traffic between network = resources.

  The document focuses on the NSF Facing = Interface by providing models
  for configuration and state = data required to allow the Security
  Controller to = configure the IPsec databases (SPD, SAD, PAD) and = IKEv2
  to establish Security Associations with a reduced = intervention of the
  network administrator.


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-= sdn-ipsec-flow-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-i= psec-flow-protection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i= 2nsf-sdn-ipsec-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2n= sf-sdn-ipsec-flow-protection-05


Please note that = it may take a couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Drafts= are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
=
_______________________________________________
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
------------= -------------------------------------------

 

 

 

 

_______________________________________________
I2ns= f mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf=

 

------=_NextPart_000_030D_01D540BC.C3D2D060-- From nobody Mon Jul 22 08:52:19 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A049612012B; Mon, 22 Jul 2019 08:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lI7qtA8SaTDQ; Mon, 22 Jul 2019 08:52:06 -0700 (PDT) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83513120325; Mon, 22 Jul 2019 08:52:06 -0700 (PDT) Received: by mail-vs1-xe43.google.com with SMTP id m8so26512544vsj.0; Mon, 22 Jul 2019 08:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TXnxxXl6oKbq8Tf1Xnk/WJd3yykOS00fuLoN+PujfJs=; b=f6HiDT6OPx4oDrri6Eh1p4PWeNjOVTW3y+f7lM18GAAe9wBZSzZja5s89etWNwHxS2 saMrImRzh1PL5y6+sy2iG4XPDICsLimj7hGSt8ZexE1S7NcsoPU2DiPBFSvf3N2n2sDp O2Uje37oQC8TysFlA/OzSkeYnX5pl/Y0KCdo0C9y6oKUNhDvRZBU/D4BLE6MWZWEN5Xs dgkBlRY4QQc5RfRBJNHU3HeecHrHx2rrxPIejCeRStuaLyUtil9JpcyT8rY1iQwx7NFz EfcmJXQ5HDE7ERkFZCT1ZOcxQw0AOaT2nE7xSQFPGgJiBs2L5dOfrXj1Qv4imEG3/6d4 X2tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TXnxxXl6oKbq8Tf1Xnk/WJd3yykOS00fuLoN+PujfJs=; b=gG9EvYun8GIUikfkyDMsXaDHgOsyZ8+wmSI2Xx7Yhul+p0febMyk9xcvA5W9xPgclq Glb6+cPGevP6MS0X3qgy6tXmo2+BIK9FEU3z4fYJpYrNTZa34ImWwdtO/KRWQmkLY5IF YsGjYl77giFlRBPNOfMslP/NMDwpaMrjnNMq/wmbtJR86Ii10cUKQdKZ9JRCR5dTmz2W wWSg8V2o8eW9r2Y5PndztylUAgv2Rhxjgl3JzFrGRAUBaFdwOG63+anZapye2MqOe7Dv pgeax6BhaNRkCMTk4ZnUOOWf6721FwNLvP/r7MsWutFhZBf6vCNCicXN0PHwj4+Nh3NN wKIg== X-Gm-Message-State: APjAAAUzhEqTEA6WJbChvM9iN/cRXxkzrr0ipDEmwD9KSsB6g+zN9qzT /Fqz2PSSPETUhWbVtotjdPo= X-Google-Smtp-Source: APXvYqzvpq7MXTuyfjFD6eRPX+FBxSLcLZdA+/Lt9CrjvvFvhxB+jm0hwcj6N5qqlRYSVCITSy1OeA== X-Received: by 2002:a67:6988:: with SMTP id e130mr44583215vsc.197.1563810725546; Mon, 22 Jul 2019 08:52:05 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:986c:a2ed:73ea:486? ([2001:67c:1232:144:986c:a2ed:73ea:486]) by smtp.gmail.com with ESMTPSA id a136sm12947659vsd.2.2019.07.22.08.52.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 08:52:04 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_392A723C-5A9C-4F91-88B6-A9D636C06865" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 11:52:03 -0400 In-Reply-To: <030c01d540a3$9e7a74d0$db6f5e70$@gmail.com> Cc: Rafa Marin Lopez , i2nsf@ietf.org, "ipsec@ietf.org WG" , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , mbj@tail-f.com, Gabriel Lopez To: Valery Smyslov References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <422BC608-F527-4BFF-A04F-B8FE42CA3169@um.es> <030c01d540a3$9e7a74d0$db6f5e70$@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:52:12 -0000 --Apple-Mail=_392A723C-5A9C-4F91-88B6-A9D636C06865 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Valery Obviously, you need a security controller that scales to the number of = SAs it needs to generate. But generating an SA in the IKE-less case is = just generating 72 random bytes (for AES-GCM-256) and packaging them. I = don=E2=80=99t think with a properly scaled SC this would produce more = latency than IKE between the nodes, which has 1/2 round-trips and = requires asymmetric operations. > On 22 Jul 2019, at 11:39, Valery Smyslov = wrote: >=20 > Hi Rafa, > =20 > sure this problem is general for any SDN solution. > My point was that if SC performs a lot of real-time=20 > (or near real-time) tasks as it may happen in IKE-less case,=20 > then this problem may become serious. > =20 > Anyway, I'm happy with the updated text, thank you. > However, in a following document(s), suggested by Yoav, > I'd like to see more concrete advices of how SC should > act in this situation to ensure that the consistence of the=20 > network is preserved despite all the possible delays etc. > =20 > Regards, > Valery. > =20 > =20 > From: Rafa Marin Lopez =20 > Sent: Monday, July 22, 2019 6:11 PM > To: Valery Smyslov > Cc: Rafa Marin Lopez ; Yoav Nir ; = i2nsf@ietf.org; ipsec@ietf.org; Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa = ; mbj@tail-f.com; Gabriel Lopez = > Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt > =20 > Hi Valery: > =20 > Thank you very much for your comments. Please see ours inside. >> El 20 jul 2019, a las 16:38, Valery Smyslov > escribi=C3=B3: >> =20 >> Hi, >> =20 >> thank you for updating the document. I still think that some aspect >> of IKE-less use case are not discussed yet (well, probably they are = not=20 >> "serious", depending on one's definition of "serious"). >> =20 >> Unlike IKE case. which we can consider as mostly static = configuration, >> the IKE-less case is a dynamic one. If IPsec SA are being created=20 >> on demand (via kernel-acquire) and the traffic volume is high, >> then depending on the IPsec policy IKE-less case can become=20 >> a highly dynamic, which implies additional requirement on both >> the network connecting SC and NSF and the performance of the protocol = used to=20 >> secure their communications. In other words, in IKE case the = communication >> between IKE daemon and kernel is seamless, while in IKE-less >> case the communication between NSF ("kernel") and SC adds >> noticeable delay (and can potentially add quite a long delay), >> which can influence total performance of the system. >> =20 >> Generally IKE-less case requires more communications between >> different nodes to establish or rekey IPsec SA, than IKE case >> (I assume that IKE SA is already established), that may have >> an impact on high-speed networks with short-lived IPsec SAs, >> especially if they are created per transport connection >> (say one IPsec SA for one TCP session). > =20 > [Authors] What you have just described is what happens in any = SDN-based network. In fact, your comment would be applicable to = practically any scenario based on the SDN paradigm. In the particular = case of the I-D, the IKE-less case is the most similar to case you can = see in, for example, Openflow networks where latency is also important = (just as an example : https://ieeexplore.ieee.org/document/6573052 = ) >=20 >=20 >> =20 >> I believe, that SC's task of managing IPsec SAs in IKE-less case=20 >> may become quite complex, especially because due to the >> additional delay, introduced by the network, the picture of the >> state of the SAs the SC has can become inaccurate (well,=20 >> it will always be inaccurate, but with short delays it doesn't = matter). >> Just an example. Consider an SC receives a signal from NSF that an SA >> is soft expired and starts rekeying process by first installing a new >> pair of inbound SAs. It successfully installs them on the NSF >> it receives notification from, but then it receives a notification >> that the other NSF has rebooted, so it must clear all the SAs on >> its peers, including the just installed new one (which is only >> half-done). There seems to be a lot of nuances, and the document=20 >> completely ignores them. Not that I think that the task >> is impossible, but the algorithm of managing the SAs can become >> quite complex and possibly unreliable. > =20 > [Authors] We largely thought about this kind of cases, although we do = not see any different that may happen in SDN-based network nowadays. And = it seems to me that SDN is becoming something generally accepted despite = the different nuances that needs to be consider. In any case, what you = mention is not ignored in our document because it is included in the = text we have in section 5.3 (see below) where we highlight the = complexity is shifted to the SC (that=E2=80=99s clear). But as I = mentioned, this is not specific to IKE-less case but for any solution = based on the pure SDN paradigm (such as Openflow networks). In other = words, the cases you well mention are applicable to any SDN-based = solution. >=20 >=20 >> =20 >> I didn't find this discussion in the draft (sorry if I missed it). > =20 > Your comments are somehow summarized in the following text section 5.3 > =20 > "On the contrary, the overload of creating fresh IPsec > SAs is shifted to the Security Controller since IKEv2 is not in the > NSF. As a consequence, this may result in a more complex > implementation in the controller side. This overload may create = some > scalability issues when the number of NSFs is high. >=20 > In general, literature around SDN-based network management using a > centralized Security Controller is aware about scalability issues = and > solutions have been already provided (e.g. hierarchical Security > Controllers; having multiple replicated Security Controllers, = etc)." > =20 > I would add that a high-speed dedicated management network between the = SC and the NSFs can be also in place to even limit reduce these delays = between the SC and NSFs (this idea comes again from Openflow networks). = Also the SC can select more =E2=80=9Cintelligent=E2=80=9D lifetime to = orchestrate better when the notifications may appear. > =20 > In any case, we think we can improve that text as follows:=20 > =20 > "On the contrary, the overload of creating and managing IPsec > SAs is shifted to the Security Controller since IKEv2 is not in the > NSF. As a consequence, this may result in a more complex > implementation in the controller side in comparison with > IKE case. For example, the Security Controller have to deal with=20= > the latency existing in the path between the Security Controller=20 > and the NSF in order to solve tasks such as, rekey or creation and=20= > installation of new IPsec SAs. However, this is not specific to our=20= > contribution but a general aspect in any SDN-based network.=20 > In summary, this overload may create some scalability and = performance=20 > issues when the number of NSFs is high. >=20 > Nevertheless, literature around SDN-based network management using = a > centralized Security Controller is aware about scalability and > performance issues and solutions have been already provided and > discussed (e.g. hierarchical Security Controllers; having multiple > replicated Security Controllers, dedicated high-speed management > networks, etc). In the context of SDN-based IPsec management, one > way to reduce the latency and alleviate some performance issues can > be the installation of the IPsec policies and IPsec SAs at the same = time > (proactive mode, as described in Section 7.1) instead of waiting = for > notifications (e.g. a notification sadb-acquire when a new IPsec SA=20= > is required) to proceed with the IPsec SA installations (reactive = mode).=20 > Another way to reduce the overhead and the potential scalability = and > performance issues in the Security Controller is to apply the IKE > case described in this document, since the IPsec SAs are managed > between NSFs without the involvement of the Security Controller at > all, except by the initial IKE configuration provided by the = Security > Controller.=E2=80=9D > =20 > Please see also our comments to Yoav. > =20 > Best Regards. >=20 >=20 >> =20 >> Regards, >> Valery. >> =20 >> =20 >> =20 >> =20 >> Thanks for getting this done and published. >> =20 >> We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. >> =20 >> Barring any such shouting, we will request publication right after = the meeting. >> =20 >> Thanks again, >> =20 >> Linda and Yoav >>=20 >>=20 >>=20 >>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez > wrote: >>> =20 >>> Dear all: >>>=20 >>> We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 >>>=20 >>> - We have dealt with YANG doctors=E2=80=99 review (Martin's) >>>=20 >>> - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s= comments. >>> =20 >>> - We have added more specific text in the descriptions. >>>=20 >>> - Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller. >>>=20 >>> - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). >>> =20 >>> - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. >>> =20 >>> - We have added a subsection 5.3.4 about NSF discovery by the = Security Controller. >>>=20 >>> - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: >>>=20 >>> typedef encryption-algorithm-type { >>> type uint32; >>> description=20 >>> "The encryption algorithm is specified with a 32-bit >>> number extracted from IANA Registry. The acceptable >>> values MUST follow the requirement levels for >>> encryption algorithms for ESP and IKEv2."; >>> reference=20 >>> "IANA Registry- Transform Type 1 - Encryption >>> Algorithm Transform IDs. RFC 8221 - Cryptographic >>> Algorithm Implementation Requirements and Usage >>> Guidance for Encapsulating Security Payload (ESP) >>> and Authentication Header (AH) and RFC 8247 - >>> Algorithm Implementation Requirements and Usage >>> Guidance for the Internet Key Exchange Protocol >>> Version 2 (IKEv2)."; >>> } >>> =20 >>> - We have included three additional Annexes with examples in about = the usage of the YANG model. >>> =20 >>> - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. >>> =20 >>> Best Regards. >>>=20 >>>=20 >>>=20 >>>> Inicio del mensaje reenviado: >>>> =20 >>>> De: internet-drafts@ietf.org >>>> Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>> Fecha: 7 de julio de 2019, 23:34:03 CEST >>>> Para: > >>>> Cc: i2nsf@ietf.org >>>> Responder a: i2nsf@ietf.org >>>> =20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the Interface to Network Security = Functions WG of the IETF. >>>>=20 >>>> Title : Software-Defined Networking (SDN)-based = IPsec Flow Protection >>>> Authors : Rafa Marin-Lopez >>>> Gabriel Lopez-Millan >>>> Fernando Pereniguez-Garcia >>>> Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>> Pages : 81 >>>> Date : 2019-07-07 >>>>=20 >>>> Abstract: >>>> This document describes how providing IPsec-based flow protection = by >>>> means of a Software-Defined Network (SDN) controller (aka. = Security >>>> Controller) and establishes the requirements to support this = service. >>>> It considers two main well-known scenarios in IPsec: (i) = gateway-to- >>>> gateway and (ii) host-to-host. The SDN-based service described = in >>>> this document allows the distribution and monitoring of IPsec >>>> information from a Security Controller to one or several = flow-based >>>> Network Security Function (NSF). The NSFs implement IPsec to = protect >>>> data traffic between network resources. >>>>=20 >>>> The document focuses on the NSF Facing Interface by providing = models >>>> for configuration and state data required to allow the Security >>>> Controller to configure the IPsec databases (SPD, SAD, PAD) and = IKEv2 >>>> to establish Security Associations with a reduced intervention of = the >>>> network administrator. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ = >>>>=20 >>>> There are also htmlized versions available at: >>>> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 = >>>> = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection-05 = >>>>=20 >>>> A diff from the previous version is available at: >>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-05 = >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at tools.ietf.org = . >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ = >>>>=20 >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2nsf = >>> =20 >>> ------------------------------------------------------- >>> 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:=C2=A0rafa@um.es = >>> ------------------------------------------------------- >>> =20 >>> =20 >>> =20 >>> =20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf = --Apple-Mail=_392A723C-5A9C-4F91-88B6-A9D636C06865 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Valery

Obviously, = you need a security controller that scales to the number of SAs it needs = to generate. But generating an SA in the IKE-less case is just = generating 72 random bytes (for AES-GCM-256) and packaging them.  I = don=E2=80=99t think with a properly scaled SC this would produce more = latency than IKE between the nodes, which has 1/2 round-trips and = requires asymmetric operations.


On 22 Jul 2019, at 11:39, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi Rafa,
 
sure= this problem is general for any SDN solution.
My point was that = if SC performs a lot of real-time 
(or near real-time) = tasks as it may happen in IKE-less case, 
then this problem = may become serious.
 
Anyway, I'm happy with the updated text, thank = you.
However, in a following document(s), suggested by Yoav,
I'd like to see = more concrete advices of how SC should
act in this = situation to ensure that the consistence of the 
network is = preserved despite all the possible delays etc.
 
Regards,
Valery.
 
 
From: Rafa Marin Lopez <rafa@um.es> 
Sent: Monday, July 22, 2019 6:11 = PM
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: Rafa = Marin Lopez <rafa@um.es>; Yoav Nir <ynir.ietf@gmail.com>; i2nsf@ietf.org; ipsec@ietf.org; Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa = <fernando.pereniguez@cud.upct.es>; mbj@tail-f.com; Gabriel = Lopez <gabilm@um.es>
Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
 
Hi Valery:
 
Thank you very much for your comments. = Please see ours inside.
El 20 jul 2019, a las 16:38, Valery Smyslov <smyslov.ietf@gmail.com> = escribi=C3=B3:
 
Hi,
 
thank you for updating the = document. I still think that some aspect
of = IKE-less use case are not discussed yet (well, probably they are = not 
"serious", depending on one's definition of = "serious").
 
Unlike IKE case. which we can = consider as mostly static configuration,
the = IKE-less case is a dynamic one. If IPsec SA are being created 
on = demand (via kernel-acquire) and the traffic volume is high,
then= depending on the IPsec policy IKE-less case can become 
a = highly dynamic, which implies additional requirement on both
the = network connecting SC and NSF and the performance of the protocol used = to 
secure their communications. In other words, in IKE case the = communication
between IKE daemon and kernel is seamless, while in = IKE-less
case the communication between NSF ("kernel") and SC = adds
noticeable delay (and can potentially add quite a long = delay),
which can influence total performance of the = system.
 
Generally IKE-less case requires = more communications between
different nodes to establish or = rekey IPsec SA, than IKE case
(I assume that IKE SA is already = established), that may have
an impact on high-speed networks = with short-lived IPsec SAs,
especially if they are created per = transport connection
(say one IPsec SA for one TCP = session).
 
[Authors] What you have just described is what happens in any = SDN-based network. In fact, your comment would be applicable to = practically any scenario based on the SDN paradigm. In the particular = case of the I-D, the IKE-less case is the most similar to case you can = see in, for example, Openflow networks where latency is also important = (just as an example : https://ieeexplore.ieee.org/document/6573052 )


 
I believe, that SC's task of = managing IPsec SAs in IKE-less case 
may = become quite complex, especially because due to the
additional delay, introduced by the network, the picture of = the
state of the SAs the SC has can become inaccurate = (well, 
it = will always be inaccurate, but with short delays it doesn't = matter).
Just an example. Consider an SC receives a signal from = NSF that an SA
is soft expired and starts = rekeying process by first installing a new
pair= of inbound SAs. It successfully installs them on the NSF
it = receives notification from, but then it receives a = notification
that the other NSF has rebooted, so it must clear all = the SAs on
its peers, including the just installed new one (which = is only
half-done). There seems to be a lot of nuances, and = the document 
completely ignores them. Not that I think that the = task
is impossible, but the algorithm of managing the SAs = can become
quite complex and possibly unreliable.
 
[Authors] We largely thought about this kind of cases, = although we do not see any different that may happen in SDN-based = network nowadays. And it seems to me that SDN is becoming something = generally accepted despite the different nuances that needs to be = consider. In any case, what you mention is not ignored in our document = because it is included in the text we have in section 5.3 (see below) = where we highlight the complexity is shifted to the SC (that=E2=80=99s = clear). But as I mentioned, this is not specific to IKE-less case but = for any solution based on the pure SDN paradigm (such as Openflow = networks). In other words, the cases you well mention are applicable to = any SDN-based solution.


 
I = didn't find this discussion in the draft (sorry if I missed = it).
 
Your comments are somehow summarized in the following text = section 5.3
 

"On the contrary, the overload of = creating fresh IPsec
   SAs is shifted to the = Security Controller since IKEv2 is not in the
  =  NSF.  As a consequence, this may result in a more = complex
   implementation in the controller side. =  This overload may create some
  =  scalability issues when the number of NSFs is high.

In general, literature around SDN-based network management = using a
   centralized Security = Controller is aware about scalability issues and
   solutions have been already provided (e.g. = hierarchical Security
   Controllers; = having multiple replicated Security Controllers, etc)."
 
I would add that a high-speed dedicated = management network between the SC and the NSFs can be also in place to = even limit reduce these delays between the SC and NSFs (this idea comes = again from Openflow networks). Also the SC can select more = =E2=80=9Cintelligent=E2=80=9D lifetime to orchestrate better when the = notifications may appear.
 
In any case, we think we can improve that text as = follows: 
 
"On the contrary, the overload of creating and managing = IPsec
   SAs is shifted to the Security Controller since = IKEv2 is not in the
   NSF. As a consequence, = this may result in a more complex
  =  implementation in the controller side in comparison with
   IKE case.  For example, the = Security Controller have to deal with 
   the latency existing in the path between = the Security Controller 
   and the NSF = in order to solve tasks such as, rekey or creation and 
   installation of new IPsec SAs. However, this is = not specific to our 
   contribution = but a general aspect in any SDN-based network. 
   In summary, this overload may create some = scalability and performance 
   issues when = the number of NSFs is high.

  =  Nevertheless, literature around SDN-based network management using = a
   centralized Security Controller is aware = about scalability and
   performance issues and = solutions have been already provided and
  =  discussed (e.g.  hierarchical Security Controllers; having = multiple
   replicated Security Controllers, = dedicated high-speed management
   networks, = etc). In the context of SDN-based IPsec management, one
   way to reduce the latency and alleviate some = performance issues can
   be the = installation of the IPsec policies and IPsec SAs at the same time
   (proactive mode, as described in Section 7.1) = instead of waiting for
   notifications = (e.g. a notification sadb-acquire when a new IPsec SA 
   is required) to proceed with the IPsec SA = installations (reactive mode). 
   Another way = to reduce the overhead and the potential scalability and
   performance issues in the Security Controller is = to apply the IKE
   case described in this = document, since the IPsec SAs are managed
  =  between NSFs without the involvement of the Security Controller = at
   all, except by the initial IKE = configuration provided by the Security
  =  Controller.=E2=80=9D
 
Please see also our comments to Yoav.
 
Best Regards.


 
Regards,
Valery.
 
 
 
 
Thanks for getting this done = and published.
 
We will wait with requesting = publication until the I2NSF session next week.  Between now and = then, please re-read the draft and send a message to the list is = something is seriously wrong.
 
Barring any such shouting, we will = request publication right after the meeting.
 
Thanks again,
 
Linda and Yoav



On 16 Jul 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> wrote:
 
Dear = all:

We submitted a new version of the = I-D (v05) where we have applied several changes. In the following = you have a summary of the main changes, which we will expand/explain = during our presentation: 

- We have = dealt with YANG doctors=E2=80=99 review (Martin's)

- We have dealt with Paul Wouters=E2=80=99 comments = and Tero=E2=80=99s comments.
 
- We have added more specific text in = the descriptions.

- Notifications have a = simpler format now since most of the information that contained in the = past is already handled by the Security Controller.

- State data has been reduced. For example, in IKE case, most = of the information is related with IKE and not with the specific details = about IPsec SAs that IKE handles (after all, IKE can abstract this = information from the Security Controller).
 
- We have included text in the security = section to discuss about the default IPsec policies that should be in = the NSF when it starts before contacting with the SC such as the IPsec = policies required to allow traffic between the SC and the NSF.
 
- We have added a subsection 5.3.4 = about NSF discovery by the Security Controller.

- In order to specify the crypto-algorithms we have used a = simple approach by including an integer and adding a text pointing the = IANA in the reference clause. For = example:

typedef = encryption-algorithm-type {
          &nb= sp;type uint32;
          &nb= sp;description 
          &nb= sp;    "The encryption algorithm is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          &nb= sp;    values MUST follow the requirement levels = for
          &nb= sp;    encryption algorithms for ESP and IKEv2.";
          &nb= sp;reference 
          &nb= sp;     "IANA Registry- Transform Type 1 - = Encryption
          &nb= sp;     Algorithm Transform IDs. RFC 8221 - = Cryptographic
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for Encapsulating Security = Payload (ESP)
          &nb= sp;     and Authentication Header (AH) and RFC = 8247 -
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for the Internet Key Exchange = Protocol
          &nb= sp;     Version 2 (IKEv2).";
       }
 
- We have included three additional = Annexes with examples in about the usage of the YANG model.
 
- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without warnings.
 
Best Regards.



Inicio del mensaje reenviado:
 
De: internet-drafts@ietf.org
Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Fecha: 7 de julio de = 2019, 23:34:03 CEST
Para: <i-d-announce@ietf.org>
Cc: i2nsf@ietf.org
Responder a: i2nsf@ietf.org
 

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Interface to Network Security Functions WG of the IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow Protection
       Authors =         : Rafa Marin-Lopez
          &nb= sp;            = ;  Gabriel Lopez-Millan
          &nb= sp;            = ;  Fernando Pereniguez-Garcia
        &= nbsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &= nbsp;  Pages=           : 81
        &= nbsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how providing IPsec-based = flow protection by
  means of a Software-Defined = Network (SDN) controller (aka.  Security
  Controller) and establishes the requirements to = support this service.
  It considers two main = well-known scenarios in IPsec: (i) gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document = allows the distribution and monitoring of IPsec
  information from a Security Controller to one or = several flow-based
  Network Security Function = (NSF).  The NSFs implement IPsec to protect
  data traffic between network resources.

  The document focuses on the NSF = Facing Interface by providing models
  for = configuration and state data required to allow the Security
  Controller to configure the IPsec databases (SPD, = SAD, PAD) and IKEv2
  to establish Security = Associations with a reduced intervention of the
  network administrator.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/

There are also = htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection-05

A diff from = the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-05


Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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
-------------------------------------------------------<= o:p class=3D"">
 
 
 
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

= --Apple-Mail=_392A723C-5A9C-4F91-88B6-A9D636C06865-- From nobody Mon Jul 22 09:07:57 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0737D12012B; Mon, 22 Jul 2019 09:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DNQZnayeUghI; Mon, 22 Jul 2019 09:07:44 -0700 (PDT) Received: from mail-ua1-x942.google.com (mail-ua1-x942.google.com [IPv6:2607:f8b0:4864:20::942]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE4F120052; Mon, 22 Jul 2019 09:07:43 -0700 (PDT) Received: by mail-ua1-x942.google.com with SMTP id v18so15517686uad.12; Mon, 22 Jul 2019 09:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=CNaLWdo/mVDKvD1EUxrIknzScXqP22fsX0nuY+k1VR0=; b=EwPkJmO0qDH+AX8T1EdGxznJUfkdx43ZVkuJbd/52JyYxK8Md30akIhSkNFEXtYg2Y v8eNpwg8ntV48RbAXj5FIqb+Qa3jvVHYFJmuzQFifiMQiUnAlpaQyz4jweg3Gw69h2DD lkZVuMKkCnhetSzYF0tzt3Hg70uFifi19eOmFZNDqXkP9KHpnY6FhBAcnP4+QE+Am0Rg 4BQ6A7MD8siNQiogEvVDUfpXcVVYAVcbCY5mWEDHD8WFxUrJGYfFQaN8HTtmWAEWwiDB 6bCxtTSmpzMgrynUOaFnNxLLR2RMSCkaulQnvS0/AJQbSh8IwJG+h+amKyOxwm7aJtlf b74Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=CNaLWdo/mVDKvD1EUxrIknzScXqP22fsX0nuY+k1VR0=; b=Izict+xs9g96oOUxvSyK9Wi7RBa4wQQwOUjuKLyHLkc40pE9ojmCoqTEWbeBigQlqe C1pyW8xWkl5UFMpdQIP2/mX+X00BiDP8NogbfHpNlsv/1YGFY5eyhWgcQzKg3fotpFT2 jalbZqYIgErnXELymWT7WbfnKA4p06KcYHFo2VYlVQwuox8AfyVyd306hLORHv2nK+Ih KGTPucUKXr9mwu9lIxwSQLJVgJSSQfl7It3i94NVrpDAt3tsuypkf4DvtK9TfncxBAF0 F0DV4sPM4njdPVffF0svZBGEz+ssbLWuheGYDcS3kpbFQXxV/+puCt8IZtL9mQL0YAIY dm5A== X-Gm-Message-State: APjAAAXNn5mv+GcGRLzAtDrNhBk2/ew9+IS4aCprNFuHz95VQfoxToyD oPVmzny/y4lYmgcdnUnZcQQ= X-Google-Smtp-Source: APXvYqzRWErkZ9gDG6rXq2P4E2xWbEnQAlJcJILGI7wQuM5XfNsD6NasS6PjpOMxzE8jFlpmqY2F3Q== X-Received: by 2002:a9f:21e7:: with SMTP id 94mr37465129uac.137.1563811662583; Mon, 22 Jul 2019 09:07:42 -0700 (PDT) Received: from svannotebook ([2001:67c:370:128:b8f4:fc59:5b3c:83af]) by smtp.gmail.com with ESMTPSA id w73sm16602686vkh.14.2019.07.22.09.07.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 09:07:41 -0700 (PDT) From: "Valery Smyslov" To: "'Yoav Nir'" Cc: "'Rafa Marin Lopez'" , , , =?utf-8?Q?'Fernando_Pere=C3=B1=C3=ADguez_Garc=C3=ADa'?= , , "'Gabriel Lopez'" References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <422BC608-F527-4BFF-A04F-B8FE42CA3169@um.es> <030c01d540a3$9e7a74d0$db6f5e70$@gmail.com> In-Reply-To: Date: Mon, 22 Jul 2019 19:07:38 +0300 Message-ID: <031f01d540a7$96424820$c2c6d860$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0320_01D540C0.BB9B6700" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHCFNK4T/q9sOv9UIwCeVdICbA12QI+UTb7AODQKd0B9E5Q0QGsr2TdAnMulMEBTsRs2KapERiQ Content-Language: ru Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 16:07:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0320_01D540C0.BB9B6700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Yoav, =20 I think that it is not the performance of the SC that would matter, but the possible delays in the network. If we think of the network connecting the SC and the NSFs as of one close to "ideal", then we have no problems. Otherwise the SC must be prepared to deal with=20 network issues. Note, that in case of reactive SA setup and in case of rekeying the SC must manage two NSFs in a synchronized manner, and any of these NSF can go offline or reboot or stop responding during this, and SC must properly deal with all this events, making proper roll-back on the other NSF. =20 With IKE case RFC7296 contains very specific advices what to do in case of packet loss, delay etc (e.g in case of=20 simultaneous rekeying). I'd like to see the same advices for SC's behavior in case of network issues. =20 Regards, Valery. =20 =20 =20 =20 Hi, Valery =20 Obviously, you need a security controller that scales to the number of = SAs it needs to generate. But generating an SA in the IKE-less case is = just generating 72 random bytes (for AES-GCM-256) and packaging them. I = don=E2=80=99t think with a properly scaled SC this would produce more = latency than IKE between the nodes, which has 1/2 round-trips and = requires asymmetric operations. =20 On 22 Jul 2019, at 11:39, Valery Smyslov > wrote: =20 Hi Rafa, =20 sure this problem is general for any SDN solution. My point was that if SC performs a lot of real-time=20 (or near real-time) tasks as it may happen in IKE-less case,=20 then this problem may become serious. =20 Anyway, I'm happy with the updated text, thank you. However, in a following document(s), suggested by Yoav, I'd like to see more concrete advices of how SC should act in this situation to ensure that the consistence of the=20 network is preserved despite all the possible delays etc. =20 Regards, Valery. =20 =20 From: Rafa Marin Lopez >=20 Sent: Monday, July 22, 2019 6:11 PM To: Valery Smyslov > Cc: Rafa Marin Lopez >; Yoav Nir = >; i2nsf@ietf.org = ; ipsec@ietf.org ; = Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa = >; mbj@tail-f.com = ; Gabriel Lopez > Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt =20 Hi Valery: =20 Thank you very much for your comments. Please see ours inside. El 20 jul 2019, a las 16:38, Valery Smyslov < = smyslov.ietf@gmail.com> escribi=C3=B3: =20 Hi, =20 thank you for updating the document. I still think that some aspect of IKE-less use case are not discussed yet (well, probably they are not=20 "serious", depending on one's definition of "serious"). =20 Unlike IKE case. which we can consider as mostly static configuration, the IKE-less case is a dynamic one. If IPsec SA are being created=20 on demand (via kernel-acquire) and the traffic volume is high, then depending on the IPsec policy IKE-less case can become=20 a highly dynamic, which implies additional requirement on both the network connecting SC and NSF and the performance of the protocol = used to=20 secure their communications. In other words, in IKE case the = communication between IKE daemon and kernel is seamless, while in IKE-less case the communication between NSF ("kernel") and SC adds noticeable delay (and can potentially add quite a long delay), which can influence total performance of the system. =20 Generally IKE-less case requires more communications between different nodes to establish or rekey IPsec SA, than IKE case (I assume that IKE SA is already established), that may have an impact on high-speed networks with short-lived IPsec SAs, especially if they are created per transport connection (say one IPsec SA for one TCP session). =20 [Authors] What you have just described is what happens in any SDN-based = network. In fact, your comment would be applicable to practically any = scenario based on the SDN paradigm. In the particular case of the I-D, = the IKE-less case is the most similar to case you can see in, for = example, Openflow networks where latency is also important (just as an = example : = https://ieeexplore.ieee.org/document/6573052 ) =20 I believe, that SC's task of managing IPsec SAs in IKE-less case=20 may become quite complex, especially because due to the additional delay, introduced by the network, the picture of the state of the SAs the SC has can become inaccurate (well,=20 it will always be inaccurate, but with short delays it doesn't matter). Just an example. Consider an SC receives a signal from NSF that an SA is soft expired and starts rekeying process by first installing a new pair of inbound SAs. It successfully installs them on the NSF it receives notification from, but then it receives a notification that the other NSF has rebooted, so it must clear all the SAs on its peers, including the just installed new one (which is only half-done). There seems to be a lot of nuances, and the document=20 completely ignores them. Not that I think that the task is impossible, but the algorithm of managing the SAs can become quite complex and possibly unreliable. =20 [Authors] We largely thought about this kind of cases, although we do = not see any different that may happen in SDN-based network nowadays. And = it seems to me that SDN is becoming something generally accepted despite = the different nuances that needs to be consider. In any case, what you = mention is not ignored in our document because it is included in the = text we have in section 5.3 (see below) where we highlight the = complexity is shifted to the SC (that=E2=80=99s clear). But as I = mentioned, this is not specific to IKE-less case but for any solution = based on the pure SDN paradigm (such as Openflow networks). In other = words, the cases you well mention are applicable to any SDN-based = solution. =20 I didn't find this discussion in the draft (sorry if I missed it). =20 Your comments are somehow summarized in the following text section 5.3 =20 "On the contrary, the overload of creating fresh IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side. This overload may create some scalability issues when the number of NSFs is high. In general, literature around SDN-based network management using a centralized Security Controller is aware about scalability issues and solutions have been already provided (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, etc)." =20 I would add that a high-speed dedicated management network between the = SC and the NSFs can be also in place to even limit reduce these delays = between the SC and NSFs (this idea comes again from Openflow networks). = Also the SC can select more =E2=80=9Cintelligent=E2=80=9D lifetime to = orchestrate better when the notifications may appear. =20 In any case, we think we can improve that text as follows:=20 =20 "On the contrary, the overload of creating and managing IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side in comparison with IKE case. For example, the Security Controller have to deal with=20 the latency existing in the path between the Security Controller=20 and the NSF in order to solve tasks such as, rekey or creation and=20 installation of new IPsec SAs. However, this is not specific to our=20 contribution but a general aspect in any SDN-based network.=20 In summary, this overload may create some scalability and performance = issues when the number of NSFs is high. Nevertheless, literature around SDN-based network management using a centralized Security Controller is aware about scalability and performance issues and solutions have been already provided and discussed (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, dedicated high-speed management networks, etc). In the context of SDN-based IPsec management, one way to reduce the latency and alleviate some performance issues can be the installation of the IPsec policies and IPsec SAs at the same = time (proactive mode, as described in Section 7.1) instead of waiting for notifications (e.g. a notification sadb-acquire when a new IPsec SA=20 is required) to proceed with the IPsec SA installations (reactive = mode).=20 Another way to reduce the overhead and the potential scalability and performance issues in the Security Controller is to apply the IKE case described in this document, since the IPsec SAs are managed between NSFs without the involvement of the Security Controller at all, except by the initial IKE configuration provided by the Security Controller.=E2=80=9D =20 Please see also our comments to Yoav. =20 Best Regards. =20 Regards, Valery. =20 =20 =20 =20 Thanks for getting this done and published. =20 We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. =20 Barring any such shouting, we will request publication right after the = meeting. =20 Thanks again, =20 Linda and Yoav On 16 Jul 2019, at 15:42, Rafa Marin-Lopez < = rafa@um.es> wrote: =20 Dear all: We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 - We have dealt with YANG doctors=E2=80=99 review (Martin's) - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. =20 - We have added more specific text in the descriptions. - Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller. - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). =20 - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. =20 - We have added a subsection 5.3.4 about NSF discovery by the Security = Controller. - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: typedef encryption-algorithm-type { type uint32; description=20 "The encryption algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference=20 "IANA Registry- Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } =20 - We have included three additional Annexes with examples in about the = usage of the YANG model. =20 - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. =20 Best Regards. Inicio del mensaje reenviado: =20 De: internet-drafts@ietf.org Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Fecha: 7 de julio de 2019, 23:34:03 CEST Para: < i-d-announce@ietf.org> Cc: i2nsf@ietf.org Responder a: i2nsf@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Interface to Network Security Functions = WG of the IETF. Title : Software-Defined Networking (SDN)-based IPsec = Flow Protection Authors : Rafa Marin-Lopez Gabriel Lopez-Millan Fernando Pereniguez-Garcia Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Pages : 81 Date : 2019-07-07 Abstract: This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources. The document focuses on the NSF Facing Interface by providing models for configuration and state data required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish Security Associations with a reduced intervention of the network administrator. The IETF datatracker status page for this draft is: = = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on/ There are also htmlized versions available at: = = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05= = = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05 A diff from the previous version is available at: = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-05 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: = ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------------------------------------------------------- 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 ------------------------------------------------------- =20 =20 =20 =20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------=_NextPart_000_0320_01D540C0.BB9B6700 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Yoav,

 

I think that it is = not the performance of the SC that would matter,

but the possible = delays in the network. If we think of the = network

connecting the SC = and the NSFs as of one close to "ideal", then we = have

no problems. = Otherwise the SC must be prepared to deal with

network issues. = Note, that in case of reactive SA setup and in = case

of rekeying the SC = must manage two NSFs in a synchronized manner,

and any of these = NSF can go offline or reboot or stop responding

during this, and = SC must properly deal with all this events,

making proper = roll-back on the other NSF.

 

With IKE case = RFC7296 contains very specific advices what

to do in case of = packet loss, delay etc (e.g in case of

simultaneous = rekeying). I'd like to see the same advices

for SC's behavior = in case of network issues.

 

Regards,=

Valery.<= /span>

 

 

 

 

Hi, Valery

 

Obviously, you need a security controller that scales = to the number of SAs it needs to generate. But generating an SA in the = IKE-less case is just generating 72 random bytes (for AES-GCM-256) and = packaging them.  I don=E2=80=99t think with a properly scaled SC = this would produce more latency than IKE between the nodes, which has = 1/2 round-trips and requires asymmetric = operations.

 



On 22 Jul 2019, at 11:39, Valery Smyslov <smyslov.ietf@gmail.com> = wrote:

 

Hi = Rafa,

 

sure = this problem is general for any SDN = solution.

My point was that if SC performs = a lot of real-time 

(or near real-time) tasks as it may happen in = IKE-less case, 

then this problem may become = serious.

 

Anyway, = I'm happy with the updated text, thank = you.

However, in a following = document(s), suggested by Yoav,

I'd like = to see more concrete advices of how SC = should

act in this situation to ensure = that the consistence of the 

network is preserved despite all the possible = delays etc.

 

Regards,

Valery.

 

 

From: Rafa Marin Lopez = <rafa@um.es> 
Sent: Monday, July 22, 2019 6:11 = PM
To: Valery = Smyslov <smyslov.ietf@gmail.com>
= Cc: Rafa Marin = Lopez <rafa@um.es>; Yoav Nir = <ynir.ietf@gmail.com>; = i2nsf@ietf.org; ipsec@ietf.org; Fernando = Pere=C3=B1=C3=ADguez Garc=C3=ADa <fernando.pereniguez@cud.u= pct.es>; mbj@tail-f.com; = Gabriel Lopez <gabilm@um.es>
Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

 

Hi Valery:

 

Thank you very much for your comments. Please see ours = inside.

El 20 jul 2019, a las 16:38, Valery Smyslov <smyslov.ietf@gmail.com> = escribi=C3=B3:

 

Hi,

 

<= div>

thank you for updating the document. I still = think that some aspect

of = IKE-less use case are not discussed yet (well, probably they are = not 

"serious", depending on one's = definition of = "serious").

 

<= div>

Unlike IKE case. which we can consider as = mostly static = configuration,

the = IKE-less case is a dynamic one. If IPsec SA are being created 

on demand (via kernel-acquire) and the = traffic volume is high,

then = depending on the IPsec policy IKE-less case can become 

a highly dynamic, which implies additional = requirement on both

the = network connecting SC and NSF and the performance of the protocol used = to 

secure their communications. In other words, = in IKE case the = communication

between = IKE daemon and kernel is seamless, while in = IKE-less

case the = communication between NSF ("kernel") and SC = adds

noticeable delay (and can potentially add = quite a long delay),

which = can influence total performance of the = system.

 

<= div>

Generally IKE-less case requires more = communications between

different nodes to establish or rekey IPsec = SA, than IKE case

(I = assume that IKE SA is already established), that may = have

an = impact on high-speed networks with short-lived IPsec = SAs,

especially if they are created per transport = connection

(say one = IPsec SA for one TCP = session).

<= p class=3DMsoNormal> 

[Authors] What you have just described is what happens = in any SDN-based network. In fact, your comment would be applicable to = practically any scenario based on the SDN paradigm. In the particular = case of the I-D, the IKE-less case is the most similar to case you can = see in, for example, Openflow networks where latency is also important = (just as an example : https://ieeexplore.ieee.org/document/6573052 )




 

<= div>

I = believe, that SC's task of managing IPsec SAs in IKE-less case 

may become quite complex, especially because = due to the

additional delay, introduced by the network, = the picture of the

state of = the SAs the SC has can become inaccurate (well, 

it will always be inaccurate, but with short = delays it doesn't matter).

Just an = example. Consider an SC receives a signal from NSF that an = SA

is soft expired and starts = rekeying process by first installing a = new

pair of = inbound SAs. It successfully installs them on the = NSF

it = receives notification from, but then it receives a = notification

that the = other NSF has rebooted, so it must clear all the SAs = on

its peers, including the just = installed new one (which is = only

half-done). There seems to be a lot of = nuances, and the document 

completely ignores them. Not that I think = that the task

is = impossible, but the algorithm of managing the SAs can = become

quite = complex and possibly = unreliable.

 

[Authors] We largely thought about this kind of cases, = although we do not see any different that may happen in SDN-based = network nowadays. And it seems to me that SDN is becoming something = generally accepted despite the different nuances that needs to be = consider. In any case, what you mention is not ignored in our document = because it is included in the text we have in section 5.3 (see below) = where we highlight the complexity is shifted to the SC (that=E2=80=99s = clear). But as I mentioned, this is not specific to IKE-less case but = for any solution based on the pure SDN paradigm (such as Openflow = networks). In other words, the cases you well mention are applicable to = any SDN-based solution.




 

<= div>

I = didn't find this discussion in the draft (sorry if I missed = it).

 

Your comments are somehow summarized in the following = text section 5.3

 

"On the contrary, = the overload of creating fresh IPsec
   SAs is shifted to = the Security Controller since IKEv2 is not in the
   NSF. =  As a consequence, this may result in a more complex
  =  implementation in the controller side. =  This overload may create some
   scalability issues = when the number of NSFs is high.

In general, literature around SDN-based network = management using a

   centralized Security Controller is aware = about scalability issues and

   solutions have been already provided = (e.g. hierarchical Security

   Controllers; having multiple replicated = Security Controllers, = etc)."

 

I would add that a high-speed dedicated management = network between the SC and the NSFs can be also in place to even limit = reduce these delays between the SC and NSFs (this idea comes again from = Openflow networks). Also the SC can select more = =E2=80=9Cintelligent=E2=80=9D lifetime to orchestrate better when the = notifications may appear.

 

In any case, we think we can improve that text as = follows: 

 

"On the contrary, the overload of creating and = managing IPsec

   SAs is shifted to the Security Controller = since IKEv2 is not in the
   NSF. As a consequence, this = may result in a more complex
   implementation in the = controller side in comparison = with

  =  IKE case.  For example, the Security Controller have to = deal with 

   the latency existing in the = path between the Security = Controller 

   and the NSF in order to solve = tasks such as, rekey or creation = and 

   installation of new IPsec SAs. However, = this is not specific to our 

   contribution but a general aspect in any = SDN-based network. 

   In summary, this overload may create some = scalability and performance 

   issues when the number of NSFs is = high.


   Nevertheless, literature around = SDN-based network management using a
   centralized = Security Controller is aware about scalability and
  =  performance issues and solutions have been already provided = and
   discussed (e.g.  hierarchical Security = Controllers; having multiple
   replicated Security = Controllers, dedicated high-speed management
   networks, = etc). In the context of SDN-based IPsec management, = one

  =  way to reduce the latency and alleviate some performance issues = can

  =  be the installation of the IPsec policies and IPsec SAs at the = same time

   (proactive mode, as described in Section = 7.1) instead of waiting for

   notifications (e.g. a notification = sadb-acquire when a new IPsec = SA 

  =  is required) to proceed with the IPsec SA installations (reactive = mode). 

   Another way to reduce the overhead and = the potential scalability and

   performance issues in the Security = Controller is to apply the IKE
   case described in this = document, since the IPsec SAs are managed
   between NSFs = without the involvement of the Security Controller at
  =  all, except by the initial IKE configuration provided by the = Security
  =  Controller.=E2=80=9D

 

Please see also our comments to = Yoav.

 

Best Regards.




 

<= div>

Regards,

Valery.

=

 

<= div>

 

<= div>

 

<= div>

 

Thanks for = getting this done and = published.

 

We will wait with requesting publication until the = I2NSF session next week.  Between now and then, please re-read the = draft and send a message to the list is something is seriously = wrong.

 

<= p class=3DMsoNormal>Barring any such shouting, we will request = publication right after the = meeting.

 

<= p class=3DMsoNormal>Thanks = again,

 

<= p class=3DMsoNormal>Linda and = Yoav





On 16 Jul 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> = wrote:

 

Dear all:

We submitted a new version of the = I-D (v05) where we have applied several changes. In the following = you have a summary of the main changes, which we will expand/explain = during our presentation: 

- We have dealt with YANG = doctors=E2=80=99 review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.

 

<= p class=3DMsoNormal>- We have added more specific text in the = descriptions.

- Notifications have a simpler format now since = most of the information that contained in the past is already handled by = the Security Controller.

- State data has been reduced. For = example, in IKE case, most of the information is related with IKE and = not with the specific details about IPsec SAs that IKE handles (after = all, IKE can abstract this information from the Security = Controller).

 

<= p class=3DMsoNormal>- We have included text in the security section to = discuss about the default IPsec policies that should be in the NSF when = it starts before contacting with the SC such as the IPsec policies = required to allow traffic between the SC and the = NSF.

 

<= p class=3DMsoNormal>- We have added a subsection 5.3.4 about NSF = discovery by the Security Controller.

- In order to specify the = crypto-algorithms we have used a simple approach by including an integer = and adding a text pointing the IANA in = the reference clause. For = example:


typedef encryption-algorithm-type = {
           ty= pe = uint32;
          &n= bsp;description 
        =        "The encryption algorithm = is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          = ;     values MUST follow the requirement levels = for
           =     encryption algorithms for ESP and = IKEv2.";
         &n= bsp; reference 
       &n= bsp;        "IANA Registry- = Transform Type 1 - = Encryption
          = ;      Algorithm Transform IDs. RFC 8221 - = Cryptographic
         &n= bsp;      Algorithm Implementation = Requirements and = Usage
          &nbs= p;     Guidance for Encapsulating Security = Payload = (ESP)
          &nbs= p;     and Authentication Header (AH) and RFC = 8247 = -
           &n= bsp;    Algorithm Implementation Requirements and = Usage
          &nbs= p;     Guidance for the Internet Key Exchange = Protocol
          &= nbsp;     Version 2 = (IKEv2).";
       }=

 

<= p class=3DMsoNormal>- We have included three additional Annexes with = examples in about the usage of the YANG = model.

 

<= p class=3DMsoNormal>- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without = warnings.

 

<= p class=3DMsoNormal>Best = Regards.





Inicio del mensaje = reenviado:

 

Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

Fecha: 7 de julio de 2019, = 23:34:03 CEST

Responder a: i2nsf@ietf.org

 


A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work item of the = Interface to Network Security Functions WG of the = IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow = Protection
       Authors =         : Rafa = Marin-Lopez
         &nbs= p;            = ;   Gabriel = Lopez-Millan
         &nb= sp;           &nbs= p;   Fernando Pereniguez-Garcia
        &n= bsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &n= bsp;  Pages =           : = 81
        &n= bsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how = providing IPsec-based flow protection by
  means of a = Software-Defined Network (SDN) controller (aka. =  Security
  Controller) and establishes the = requirements to support this service.
  It considers two = main well-known scenarios in IPsec: (i) = gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document allows the = distribution and monitoring of IPsec
  information from a = Security Controller to one or several flow-based
  Network = Security Function (NSF).  The NSFs implement IPsec to = protect
  data traffic between network = resources.

  The document focuses on the NSF Facing = Interface by providing models
  for configuration and state = data required to allow the Security
  Controller to = configure the IPsec databases (SPD, SAD, PAD) and = IKEv2
  to establish Security Associations with a reduced = intervention of the
  network administrator.


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-= sdn-ipsec-flow-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-i= psec-flow-protection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i= 2nsf-sdn-ipsec-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2n= sf-sdn-ipsec-flow-protection-05


Please note that = it may take a couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
=
_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf=

<= p = class=3DMsoNormal> 

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

 

 

 

 

_______________________________________________
I2ns= f mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf=

 

------=_NextPart_000_0320_01D540C0.BB9B6700-- From nobody Tue Jul 23 02:49:06 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936E1120194; Tue, 23 Jul 2019 02:48:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 IVhrUuoau88U; Tue, 23 Jul 2019 02:48:49 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0712018F; Tue, 23 Jul 2019 02:48:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 454ED20AA2; Tue, 23 Jul 2019 11:48:46 +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 vOuJ_uOOlpzw; Tue, 23 Jul 2019 11:48:46 +0200 (CEST) Received: from [155.54.13.4] (unknown [155.54.13.4]) (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 CE60D201F9; Tue, 23 Jul 2019 11:48:42 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_57461EEE-0FC8-4EDF-B8CE-38905E8E6DD4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 23 Jul 2019 11:48:41 +0200 In-Reply-To: <031f01d540a7$96424820$c2c6d860$@gmail.com> Cc: Rafa Marin-Lopez , Yoav Nir , i2nsf@ietf.org, "ipsec@ietf.org WG" , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , Gabriel Lopez To: Valery Smyslov References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <422BC608-F527-4BFF-A04F-B8FE42CA3169@um.es> <030c01d540a3$9e7a74d0$db6f5e70$@gmail.com> <031f01d540a7$96424820$c2c6d860$@gmail.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 09:48:56 -0000 --Apple-Mail=_57461EEE-0FC8-4EDF-B8CE-38905E8E6DD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery: > El 22 jul 2019, a las 18:07, Valery Smyslov = escribi=C3=B3: >=20 > Hi Yoav, > =20 > I think that it is not the performance of the SC that would matter, > but the possible delays in the network. If we think of the network > connecting the SC and the NSFs as of one close to "ideal", then we = have > no problems. Otherwise the SC must be prepared to deal with=20 > network issues. Note, that in case of reactive SA setup and in case > of rekeying the SC must manage two NSFs in a synchronized manner, > and any of these NSF can go offline or reboot or stop responding > during this, and SC must properly deal with all this events, > making proper roll-back on the other NSF. Regarding this: steps 1, 2 and 3 in section 5.3.1 are lock-step. As you = may see we mention:=20 "Once the Security Controller receives confirmation from A and B, the = controller knows that the inbound=20 IPsec A are correctly installed.=E2=80=9D Having said this. Maybe this text after the description of steps 1, 2 = and 3 may help: =E2=80=9CIf some of the operations in step 1 fails (e.g. the NSF1 = reports an error when the Security Controller is trying to install anew = new inbound IPsec SA) the Security Controller must perform rollback = operations by removing any new inbound SA that had been successfully = installed during step 1.=20 If step 1 is successful but some of the operations in step 2 fails (e.g. = the NSF1 reports an error when the Security Controller is trying to = install the new outbound IPsec SA), the Security Controller must perform = a rollback operation by deleting any new outbound SA that had been = successfully installed during step 2 and by deleting the inbound SAs = created in step 1.=20 If the steps 1 an 2 are successful and the step 3 fails the Security = Controller will avoid any rollback of the operations carried out in step = 1 and step 2 since new and valid IPsec SAs were created and are = functional. The Security Controller may reattempt to remove the old = inbound and outbound SAs in NSF1 and NSF2 several times until it = receives a success or it gives up. In the last case, the old IPsec SAs = will be removed when the hard lifetime is reached."=20 Btw, you can also find some text about NSF state loss in section 5.3.2.=20= > =20 > With IKE case RFC7296 contains very specific advices what > to do in case of packet loss, delay etc (e.g in case of=20 > simultaneous rekeying). I'd like to see the same advices > for SC's behavior in case of network issues. > =20 > Regards, > Valery. > =20 > =20 > =20 > =20 > Hi, Valery > =20 > Obviously, you need a security controller that scales to the number of = SAs it needs to generate. But generating an SA in the IKE-less case is = just generating 72 random bytes (for AES-GCM-256) and packaging them. I = don=E2=80=99t think with a properly scaled SC this would produce more = latency than IKE between the nodes, which has 1/2 round-trips and = requires asymmetric operations. > =20 >=20 >=20 >> On 22 Jul 2019, at 11:39, Valery Smyslov > wrote: >> =20 >> Hi Rafa, >> =20 >> sure this problem is general for any SDN solution. >> My point was that if SC performs a lot of real-time=20 >> (or near real-time) tasks as it may happen in IKE-less case,=20 >> then this problem may become serious. >> =20 >> Anyway, I'm happy with the updated text, thank you. >> However, in a following document(s), suggested by Yoav, >> I'd like to see more concrete advices of how SC should >> act in this situation to ensure that the consistence of the=20 >> network is preserved despite all the possible delays etc. >> =20 >> Regards, >> Valery. >> =20 >> =20 >> From: Rafa Marin Lopez >=20 >> Sent: Monday, July 22, 2019 6:11 PM >> To: Valery Smyslov > >> Cc: Rafa Marin Lopez >; Yoav Nir = >; i2nsf@ietf.org = ; ipsec@ietf.org ; = Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa = >; mbj@tail-f.com = ; Gabriel Lopez > >> Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >> =20 >> Hi Valery: >> =20 >> Thank you very much for your comments. Please see ours inside. >>> El 20 jul 2019, a las 16:38, Valery Smyslov > escribi=C3=B3: >>> =20 >>> Hi, >>> =20 >>> thank you for updating the document. I still think that some aspect >>> of IKE-less use case are not discussed yet (well, probably they are = not=20 >>> "serious", depending on one's definition of "serious"). >>> =20 >>> Unlike IKE case. which we can consider as mostly static = configuration, >>> the IKE-less case is a dynamic one. If IPsec SA are being created=20 >>> on demand (via kernel-acquire) and the traffic volume is high, >>> then depending on the IPsec policy IKE-less case can become=20 >>> a highly dynamic, which implies additional requirement on both >>> the network connecting SC and NSF and the performance of the = protocol used to=20 >>> secure their communications. In other words, in IKE case the = communication >>> between IKE daemon and kernel is seamless, while in IKE-less >>> case the communication between NSF ("kernel") and SC adds >>> noticeable delay (and can potentially add quite a long delay), >>> which can influence total performance of the system. >>> =20 >>> Generally IKE-less case requires more communications between >>> different nodes to establish or rekey IPsec SA, than IKE case >>> (I assume that IKE SA is already established), that may have >>> an impact on high-speed networks with short-lived IPsec SAs, >>> especially if they are created per transport connection >>> (say one IPsec SA for one TCP session). >> =20 >> [Authors] What you have just described is what happens in any = SDN-based network. In fact, your comment would be applicable to = practically any scenario based on the SDN paradigm. In the particular = case of the I-D, the IKE-less case is the most similar to case you can = see in, for example, Openflow networks where latency is also important = (just as an example : https://ieeexplore.ieee.org/document/6573052 = ) >>=20 >>=20 >>=20 >>> =20 >>> I believe, that SC's task of managing IPsec SAs in IKE-less case=20 >>> may become quite complex, especially because due to the >>> additional delay, introduced by the network, the picture of the >>> state of the SAs the SC has can become inaccurate (well,=20 >>> it will always be inaccurate, but with short delays it doesn't = matter). >>> Just an example. Consider an SC receives a signal from NSF that an = SA >>> is soft expired and starts rekeying process by first installing a = new >>> pair of inbound SAs. It successfully installs them on the NSF >>> it receives notification from, but then it receives a notification >>> that the other NSF has rebooted, so it must clear all the SAs on >>> its peers, including the just installed new one (which is only >>> half-done). There seems to be a lot of nuances, and the document=20 >>> completely ignores them. Not that I think that the task >>> is impossible, but the algorithm of managing the SAs can become >>> quite complex and possibly unreliable. >> =20 >> [Authors] We largely thought about this kind of cases, although we do = not see any different that may happen in SDN-based network nowadays. And = it seems to me that SDN is becoming something generally accepted despite = the different nuances that needs to be consider. In any case, what you = mention is not ignored in our document because it is included in the = text we have in section 5.3 (see below) where we highlight the = complexity is shifted to the SC (that=E2=80=99s clear). But as I = mentioned, this is not specific to IKE-less case but for any solution = based on the pure SDN paradigm (such as Openflow networks). In other = words, the cases you well mention are applicable to any SDN-based = solution. >>=20 >>=20 >>=20 >>> =20 >>> I didn't find this discussion in the draft (sorry if I missed it). >> =20 >> Your comments are somehow summarized in the following text section = 5.3 >> =20 >> "On the contrary, the overload of creating fresh IPsec >> SAs is shifted to the Security Controller since IKEv2 is not in = the >> NSF. As a consequence, this may result in a more complex >> implementation in the controller side. This overload may create = some >> scalability issues when the number of NSFs is high. >>=20 >> In general, literature around SDN-based network management using a >> centralized Security Controller is aware about scalability issues = and >> solutions have been already provided (e.g. hierarchical Security >> Controllers; having multiple replicated Security Controllers, = etc)." >> =20 >> I would add that a high-speed dedicated management network between = the SC and the NSFs can be also in place to even limit reduce these = delays between the SC and NSFs (this idea comes again from Openflow = networks). Also the SC can select more =E2=80=9Cintelligent=E2=80=9D = lifetime to orchestrate better when the notifications may appear. >> =20 >> In any case, we think we can improve that text as follows:=20 >> =20 >> "On the contrary, the overload of creating and managing IPsec >> SAs is shifted to the Security Controller since IKEv2 is not in = the >> NSF. As a consequence, this may result in a more complex >> implementation in the controller side in comparison with >> IKE case. For example, the Security Controller have to deal with=20= >> the latency existing in the path between the Security Controller=20= >> and the NSF in order to solve tasks such as, rekey or creation and=20= >> installation of new IPsec SAs. However, this is not specific to = our=20 >> contribution but a general aspect in any SDN-based network.=20 >> In summary, this overload may create some scalability and = performance=20 >> issues when the number of NSFs is high. >>=20 >> Nevertheless, literature around SDN-based network management using = a >> centralized Security Controller is aware about scalability and >> performance issues and solutions have been already provided and >> discussed (e.g. hierarchical Security Controllers; having = multiple >> replicated Security Controllers, dedicated high-speed management >> networks, etc). In the context of SDN-based IPsec management, one >> way to reduce the latency and alleviate some performance issues = can >> be the installation of the IPsec policies and IPsec SAs at the = same time >> (proactive mode, as described in Section 7.1) instead of waiting = for >> notifications (e.g. a notification sadb-acquire when a new IPsec = SA=20 >> is required) to proceed with the IPsec SA installations (reactive = mode).=20 >> Another way to reduce the overhead and the potential scalability = and >> performance issues in the Security Controller is to apply the IKE >> case described in this document, since the IPsec SAs are managed >> between NSFs without the involvement of the Security Controller at >> all, except by the initial IKE configuration provided by the = Security >> Controller.=E2=80=9D >> =20 >> Please see also our comments to Yoav. >> =20 >> Best Regards. >>=20 >>=20 >>=20 >>> =20 >>> Regards, >>> Valery. >>> =20 >>> =20 >>> =20 >>> =20 >>> Thanks for getting this done and published. >>> =20 >>> We will wait with requesting publication until the I2NSF session = next week. Between now and then, please re-read the draft and send a = message to the list is something is seriously wrong. >>> =20 >>> Barring any such shouting, we will request publication right after = the meeting. >>> =20 >>> Thanks again, >>> =20 >>> Linda and Yoav >>>=20 >>>=20 >>>=20 >>>=20 >>>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez > wrote: >>>> =20 >>>> Dear all: >>>>=20 >>>> We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 >>>>=20 >>>> - We have dealt with YANG doctors=E2=80=99 review (Martin's) >>>>=20 >>>> - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99= s comments. >>>> =20 >>>> - We have added more specific text in the descriptions. >>>>=20 >>>> - Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller. >>>>=20 >>>> - State data has been reduced. For example, in IKE case, most of = the information is related with IKE and not with the specific details = about IPsec SAs that IKE handles (after all, IKE can abstract this = information from the Security Controller). >>>> =20 >>>> - We have included text in the security section to discuss about = the default IPsec policies that should be in the NSF when it starts = before contacting with the SC such as the IPsec policies required to = allow traffic between the SC and the NSF. >>>> =20 >>>> - We have added a subsection 5.3.4 about NSF discovery by the = Security Controller. >>>>=20 >>>> - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: >>>>=20 >>>> typedef encryption-algorithm-type { >>>> type uint32; >>>> description=20 >>>> "The encryption algorithm is specified with a 32-bit >>>> number extracted from IANA Registry. The acceptable >>>> values MUST follow the requirement levels for >>>> encryption algorithms for ESP and IKEv2."; >>>> reference=20 >>>> "IANA Registry- Transform Type 1 - Encryption >>>> Algorithm Transform IDs. RFC 8221 - Cryptographic >>>> Algorithm Implementation Requirements and Usage >>>> Guidance for Encapsulating Security Payload (ESP) >>>> and Authentication Header (AH) and RFC 8247 - >>>> Algorithm Implementation Requirements and Usage >>>> Guidance for the Internet Key Exchange Protocol >>>> Version 2 (IKEv2)."; >>>> } >>>> =20 >>>> - We have included three additional Annexes with examples in about = the usage of the YANG model. >>>> =20 >>>> - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. >>>> =20 >>>> Best Regards. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Inicio del mensaje reenviado: >>>>> =20 >>>>> De: internet-drafts@ietf.org >>>>> Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>>> Fecha: 7 de julio de 2019, 23:34:03 CEST >>>>> Para: > >>>>> Cc: i2nsf@ietf.org >>>>> Responder a: i2nsf@ietf.org >>>>> =20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>> This draft is a work item of the Interface to Network Security = Functions WG of the IETF. >>>>>=20 >>>>> Title : Software-Defined Networking (SDN)-based = IPsec Flow Protection >>>>> Authors : Rafa Marin-Lopez >>>>> Gabriel Lopez-Millan >>>>> Fernando Pereniguez-Garcia >>>>> Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>>> Pages : 81 >>>>> Date : 2019-07-07 >>>>>=20 >>>>> Abstract: >>>>> This document describes how providing IPsec-based flow = protection by >>>>> means of a Software-Defined Network (SDN) controller (aka. = Security >>>>> Controller) and establishes the requirements to support this = service. >>>>> It considers two main well-known scenarios in IPsec: (i) = gateway-to- >>>>> gateway and (ii) host-to-host. The SDN-based service described = in >>>>> this document allows the distribution and monitoring of IPsec >>>>> information from a Security Controller to one or several = flow-based >>>>> Network Security Function (NSF). The NSFs implement IPsec to = protect >>>>> data traffic between network resources. >>>>>=20 >>>>> The document focuses on the NSF Facing Interface by providing = models >>>>> for configuration and state data required to allow the Security >>>>> Controller to configure the IPsec databases (SPD, SAD, PAD) and = IKEv2 >>>>> to establish Security Associations with a reduced intervention = of the >>>>> network administrator. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ = >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 = >>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection-05 = >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-05 = >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org . >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ = >>>>>=20 >>>>> _______________________________________________ >>>>> I2nsf mailing list >>>>> I2nsf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2nsf = >>>> =20 >>>> ------------------------------------------------------- >>>> 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:=C2=A0rafa@um.es = >>>> ------------------------------------------------------- >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2nsf = --Apple-Mail=_57461EEE-0FC8-4EDF-B8CE-38905E8E6DD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Valery:

El 22 jul 2019, a las 18:07, Valery Smyslov <smyslov.ietf@gmail.com> escribi=C3=B3:

Hi Yoav,
 
I = think that it is not the performance of the SC that would matter,
but the possible = delays in the network. If we think of the network
connecting the SC = and the NSFs as of one close to "ideal", then we have
no problems. = Otherwise the SC must be prepared to deal with 
network issues. = Note, that in case of reactive SA setup and in case
of rekeying the SC = must manage two NSFs in a synchronized manner,
and any of these = NSF can go offline or reboot or stop responding
during this, and SC = must properly deal with all this events,
making proper = roll-back on the other = NSF.

Regarding this: steps 1, 2 and 3 in section 5.3.1 = are lock-step. As you may see we mention: 

"Once the Security Controller receives confirmation from A and B, the controller knows = that the inbound 
IPsec A are correctly = installed.=E2=80=9D

Having said this. Maybe this text after the description of = steps 1, 2 and 3 may help:

=E2=80=9CIf some of the operations in step 1 fails = (e.g. the NSF1 reports an error when the Security Controller is = trying to install anew new inbound IPsec SA) the Security = Controller must perform rollback operations by removing any new = inbound SA that had been successfully installed during step = 1. 

If = step 1 is successful but some of the operations in step 2 fails = (e.g. the NSF1 reports an error when the Security Controller is = trying to install the new outbound IPsec SA), the Security = Controller must perform a rollback operation by deleting any new = outbound SA that had been successfully installed during step 2 and by = deleting the inbound SAs created in step 1. 
If the steps 1 an 2 are successful and = the step 3 fails the Security Controller will avoid any = rollback of the operations carried out in step 1 and step 2 since new = and valid IPsec SAs were created and are functional. The Security = Controller may reattempt to remove the old inbound and outbound SAs = in NSF1 and NSF2 several times until it receives a success or it gives = up. In the last case, the old IPsec SAs will be removed when the hard = lifetime is reached." 

Btw, you can also find some text about NSF = state loss in section 5.3.2. 

 
With= IKE case RFC7296 contains very specific advices what
to do in case of = packet loss, delay etc (e.g in case of 
simultaneous = rekeying). I'd like to see the same advices
for SC's behavior = in case of network issues.
 
Regards,
Valery.
 
 
 
 
Hi, = Valery
 
Obviously, you need a security = controller that scales to the number of SAs it needs to generate. But = generating an SA in the IKE-less case is just generating 72 random bytes = (for AES-GCM-256) and packaging them.  I don=E2=80=99t think with a = properly scaled SC this would produce more latency than IKE between the = nodes, which has 1/2 round-trips and requires asymmetric operations.
 


On 22 Jul 2019, at 11:39, Valery = Smyslov <smyslov.ietf@gmail.com> wrote:
 
Hi Rafa,
 
sure= this problem is general for any SDN solution.
My = point was that if SC performs a lot of real-time 
(or = near real-time) tasks as it may happen in IKE-less case, 
then= this problem may become serious.
 
Anyway, I'm happy with the updated = text, thank you.
However, in a following = document(s), suggested by Yoav,
I'd = like to see more concrete advices of how SC should
act = in this situation to ensure that the consistence of the 
network is preserved despite all the possible delays = etc.
 
Regards,
Valery.
 
 
From: Rafa Marin Lopez <rafa@um.es> 
Sent: Monday, July 22, 2019 6:11 = PM
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: Rafa Marin Lopez <rafa@um.es>; Yoav Nir <ynir.ietf@gmail.com>; i2nsf@ietf.org; ipsec@ietf.org; Fernando Pere=C3=B1=C3=ADguez = Garc=C3=ADa <fernando.pereniguez@cud.upct.es>; mbj@tail-f.com; Gabriel Lopez <gabilm@um.es>
Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
 
Hi Valery:
 
Thank you very much for your comments. = Please see ours inside.
El 20 jul 2019, a las 16:38, Valery = Smyslov <smyslov.ietf@gmail.com> escribi=C3=B3:
 
Hi,
 
thank you for updating the document. I still think = that some aspect
of IKE-less use = case are not discussed yet (well, probably they are not 
"serious", depending on one's definition of = "serious").
 
Unlike IKE case. which we can consider as mostly = static configuration,
the IKE-less case = is a dynamic one. If IPsec SA are being created 
on demand (via kernel-acquire) and the traffic volume = is high,
then depending on = the IPsec policy IKE-less case can become 
a highly dynamic, which implies additional requirement = on both
the network connecting SC and NSF = and the performance of the protocol used to 
secure their communications. In other words, in IKE = case the communication
between IKE daemon = and kernel is seamless, while in IKE-less
case the communication between NSF ("kernel") and SC = adds
noticeable delay (and can = potentially add quite a long delay),
which can influence total performance of the = system.
 
Generally IKE-less case requires more communications = between
different nodes to establish or = rekey IPsec SA, than IKE case
(I assume that IKE SA is already established), that = may have
an impact on = high-speed networks with short-lived IPsec SAs,
especially if they are created per transport = connection
(say one IPsec SA = for one TCP session).
 
[Authors] What you have just described = is what happens in any SDN-based network. In fact, your comment would be = applicable to practically any scenario based on the SDN paradigm. In the = particular case of the I-D, the IKE-less case is the most similar to = case you can see in, for example, Openflow networks where latency is = also important (just as an example : https://ieeexplore.ieee.org/document/6573052 )



 
I believe, that SC's task of managing IPsec SAs in = IKE-less case 
may become quite complex, especially because due to = the
additional delay, introduced by = the network, the picture of the
state of the SAs the SC has can become inaccurate = (well, 
it will always be inaccurate, but with short delays it = doesn't matter).
Just an example. = Consider an SC receives a signal from NSF that an SA
is soft expired and starts rekeying process by first = installing a new
pair of inbound = SAs. It successfully installs them on the NSF
it receives notification from, but then it receives a = notification
that the other NSF = has rebooted, so it must clear all the SAs on
its peers, including the just installed new one (which = is only
half-done). There seems to be a = lot of nuances, and the document 
completely ignores them. Not that I think that the = task
is impossible, but the algorithm = of managing the SAs can become
quite complex and possibly unreliable.
 
[Authors] We largely thought about this = kind of cases, although we do not see any different that may happen in = SDN-based network nowadays. And it seems to me that SDN is becoming = something generally accepted despite the different nuances that needs to = be consider. In any case, what you mention is not ignored in our = document because it is included in the text we have in section 5.3 (see = below) where we highlight the complexity is shifted to the SC (that=E2=80=99= s clear). But as I mentioned, this is not specific to IKE-less case but = for any solution based on the pure SDN paradigm (such as Openflow = networks). In other words, the cases you well mention are applicable to = any SDN-based solution.



 
I didn't find this discussion in the draft (sorry if I = missed it).
 
Your comments are somehow summarized in = the following text section 5.3
 

"On the contrary, the overload of = creating fresh IPsec
   SAs is shifted to the = Security Controller since IKEv2 is not in the
  =  NSF.  As a consequence, this may result in a more = complex
   implementation in the controller side. =  This overload may create some
  =  scalability issues when the number of NSFs is high.

In general, literature around SDN-based network management = using a
   centralized = Security Controller is aware about scalability issues and
   solutions have been = already provided (e.g. hierarchical Security
   Controllers; having = multiple replicated Security Controllers, etc)."
 
I would add that a = high-speed dedicated management network between the SC and the NSFs can = be also in place to even limit reduce these delays between the SC and = NSFs (this idea comes again from Openflow networks). Also the SC can = select more =E2=80=9Cintelligent=E2=80=9D lifetime to orchestrate better = when the notifications may appear.
 
In any case, we think we can improve = that text as follows: 
 
"On the contrary, the overload of = creating and managing IPsec
   SAs is = shifted to the Security Controller since IKEv2 is not in the
   NSF. As a consequence, this may result in a more = complex
   implementation in the controller side = in comparison with
  =  IKE case.  For example, the Security Controller have to = deal with 
  =  the latency existing in the path between the Security = Controller 
  =  and the NSF in order to solve tasks such as, rekey or = creation and 
  =  installation of new IPsec SAs. However, this is not specific to = our 
   contribution = but a general aspect in any SDN-based network. 
   In summary, this overload = may create some scalability and performance 
   issues when the number of = NSFs is high.

  =  Nevertheless, literature around SDN-based network management using = a
   centralized Security Controller is aware = about scalability and
   performance issues and = solutions have been already provided and
  =  discussed (e.g.  hierarchical Security Controllers; having = multiple
   replicated Security Controllers, = dedicated high-speed management
   networks, = etc). In the context of SDN-based IPsec management, one
   way to reduce the latency = and alleviate some performance issues can
   be the installation of the = IPsec policies and IPsec SAs at the same time
   (proactive mode, as = described in Section 7.1) instead of waiting for
   notifications (e.g. a = notification sadb-acquire when a new IPsec SA 
   is required) to proceed = with the IPsec SA installations (reactive mode). 
   Another way to reduce the = overhead and the potential scalability and
   performance issues in the = Security Controller is to apply the IKE
   case = described in this document, since the IPsec SAs are managed
   between NSFs without the involvement of the = Security Controller at
   all, except by the = initial IKE configuration provided by the Security
  =  Controller.=E2=80=9D
 
Please see also our comments to = Yoav.
 
Best Regards.



 
Regards,
Valery.
 
 
 
 
Thanks = for getting this done and published.
 
We will wait with requesting publication until the I2NSF = session next week.  Between now and then, please re-read the draft = and send a message to the list is something is seriously wrong.
 
Barring = any such shouting, we will request publication right after the = meeting.
 
Thanks = again,
 
Linda and = Yoav




On 16 Jul = 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> wrote:
 
Dear = all:

We submitted a new version of the = I-D (v05) where we have applied several changes. In the following = you have a summary of the main changes, which we will expand/explain = during our presentation: 

- We have = dealt with YANG doctors=E2=80=99 review (Martin's)

- We have dealt with Paul Wouters=E2=80=99 comments = and Tero=E2=80=99s comments.
 
-= We have added more specific text in the descriptions.

- Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller.

- State data has been = reduced. For example, in IKE case, most of the information is related = with IKE and not with the specific details about IPsec SAs that IKE = handles (after all, IKE can abstract this information from the Security = Controller).
 
-= We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF.
 
- We have = added a subsection 5.3.4 about NSF discovery by the Security = Controller.

- In order to specify the = crypto-algorithms we have used a simple approach by including an integer = and adding a text pointing the IANA in the reference clause. For example:

typedef encryption-algorithm-type {
          &nb= sp;type uint32;
          &nb= sp;description 
          &nb= sp;    "The encryption algorithm is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          &nb= sp;    values MUST follow the requirement levels = for
          &nb= sp;    encryption algorithms for ESP and IKEv2.";
          &nb= sp;reference 
          &nb= sp;     "IANA Registry- Transform Type 1 - = Encryption
          &nb= sp;     Algorithm Transform IDs. RFC 8221 - = Cryptographic
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for Encapsulating Security = Payload (ESP)
          &nb= sp;     and Authentication Header (AH) and RFC = 8247 -
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for the Internet Key Exchange = Protocol
          &nb= sp;     Version 2 (IKEv2).";
       }
 
- We have = included three additional Annexes with examples in about the usage of = the YANG model.
 
-= We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings.
 
Best = Regards.




Inicio = del mensaje reenviado:
 
De: internet-drafts@ietf.org
Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Fecha: 7 de julio de = 2019, 23:34:03 CEST
Para: <i-d-announce@ietf.org>
Cc: i2nsf@ietf.org
Responder a: i2nsf@ietf.org
 

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Interface to Network Security Functions WG of the IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow Protection
       Authors =         : Rafa Marin-Lopez
          &nb= sp;            = ;  Gabriel Lopez-Millan
          &nb= sp;            = ;  Fernando Pereniguez-Garcia
        &= nbsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &= nbsp;  Pages=           : 81
        &= nbsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how providing IPsec-based = flow protection by
  means of a Software-Defined = Network (SDN) controller (aka.  Security
  Controller) and establishes the requirements to = support this service.
  It considers two main = well-known scenarios in IPsec: (i) gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document = allows the distribution and monitoring of IPsec
  information from a Security Controller to one or = several flow-based
  Network Security Function = (NSF).  The NSFs implement IPsec to protect
  data traffic between network resources.

  The document focuses on the NSF = Facing Interface by providing models
  for = configuration and state data required to allow the Security
  Controller to configure the IPsec databases (SPD, = SAD, PAD) and IKEv2
  to establish Security = Associations with a reduced intervention of the
  network administrator.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/

There are also = htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection-05

A diff from = the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-05


Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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
-------------------------------------------------------<= o:p class=3D"">
 
 
 
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

= --Apple-Mail=_57461EEE-0FC8-4EDF-B8CE-38905E8E6DD4-- From nobody Tue Jul 23 03:31:30 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099B61201C8; Tue, 23 Jul 2019 03:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bX56ShBaYJk1; Tue, 23 Jul 2019 03:31:18 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62A4120099; Tue, 23 Jul 2019 03:31:17 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id r21so30740306qke.2; Tue, 23 Jul 2019 03:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=bXO2lmeLetskyIQqpICkiaX/B5w/d3xATNabKSuPMDA=; b=c+UzwgrijNg4ag0zytkHylCzjPQepiiTuw0sfkVMuUvY01T2CDgcP17ATLAHCgNiWN abvodVe9Q8pB13DysPe+fvqDMO19Gb0l9cHhYG+o9kFTYP5wuDZG3qmUwLPipPpYPcIi MiwIYFANaAFcQZOeOSd6oHLDW+aeeCAdBjKq62cUembRWOifN3Bw/7+vSkH9TuaVDUuU A362jqYiP4SHN/3ej10XaZrzGcvRC6gdIWyb6MbmC1YM8hWJDh+gC7StKvtsTfvwetLi LmbQslTExM3mjUqWwQITPqh1uE5xUyfYrQpMs6gqIWBA6dLnWPlpnVeajDqZsGC49V6m c9Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=bXO2lmeLetskyIQqpICkiaX/B5w/d3xATNabKSuPMDA=; b=SSoHVEduD2vSyK4axopMBSlXNruN9cGTdUkASnayRQSEPLtMkFqdHVgA37hLAyKx2A xIlPtkYkPKbk8yb5IDJPg+CbRfx1K0z5xooF94SNdklCJPagE+KaytwBCVrYjVuB0dG+ HsnuRAPxdYPrL43LOG1n4Pa1RusATPcpfQbr4IAqq2xEt/5YK03iUY5coTntXcYJHi/3 wCAH7NB17Dw+nIksDjTdhzp9hMOlx1999UbJFOkOdqLa8tyWO03Bfy0LDbOAUna48Uif IvyN13UzBXJrc8955xDGxOqZtoGCDnos2ipIuOLnZbMWhAUjE1xbA5FuCebqwMhcX9pb fq8g== X-Gm-Message-State: APjAAAWSyKxQYj/id3GA4xmLzgi0kKdBj8+tA1GHtlm+oi6kZhQcEsxw eZ1UpXDOnvrqW+5xBFAk6nc= X-Google-Smtp-Source: APXvYqwTNHTEk4GY19cHWmJmpTxfZ/R6G8jXmTFY8kJwZBpB+xc3wpalrOFgGPy9mX8p9QLF/Mm+XQ== X-Received: by 2002:a37:a2cc:: with SMTP id l195mr47744883qke.362.1563877876589; Tue, 23 Jul 2019 03:31:16 -0700 (PDT) Received: from svannotebook (modemcable142.183-83-70.mc.videotron.ca. [70.83.183.142]) by smtp.gmail.com with ESMTPSA id c74sm19601735qke.128.2019.07.23.03.31.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 03:31:15 -0700 (PDT) From: "Valery Smyslov" To: "'Rafa Marin-Lopez'" Cc: "'Yoav Nir'" , , , =?utf-8?Q?'Fernando_Pere=C3=B1=C3=ADguez_Garc=C3=ADa'?= , =?utf-8?Q?'Martin_Bj=C3=B6rklund'?= , "'Gabriel Lopez'" References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <422BC608-F527-4BFF-A04F-B8FE42CA3169@um.es> <030c01d540a3$9e7a74d0$db6f5e70$@gmail.com> <031f01d540a7$96424820$c2c6d860$@gmail.com> In-Reply-To: Date: Tue, 23 Jul 2019 13:31:12 +0300 Message-ID: <041301d54141$c0bae090$4230a1b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0414_01D5415A.E60CD380" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHCFNK4T/q9sOv9UIwCeVdICbA12QI+UTb7AODQKd0B9E5Q0QGsr2TdAnMulMEBTsRs2AIsVOg+AejEzsqmiZ+SgA== Content-Language: ru Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 10:31:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0414_01D5415A.E60CD380 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Rafa, =20 =20 Hi Valery: El 22 jul 2019, a las 18:07, Valery Smyslov > escribi=C3=B3: =20 Hi Yoav, =20 I think that it is not the performance of the SC that would matter, but the possible delays in the network. If we think of the network connecting the SC and the NSFs as of one close to "ideal", then we have no problems. Otherwise the SC must be prepared to deal with=20 network issues. Note, that in case of reactive SA setup and in case of rekeying the SC must manage two NSFs in a synchronized manner, and any of these NSF can go offline or reboot or stop responding during this, and SC must properly deal with all this events, making proper roll-back on the other NSF. =20 Regarding this: steps 1, 2 and 3 in section 5.3.1 are lock-step. As you = may see we mention:=20 =20 "Once the Security Controller receives confirmation from A and B, the = controller knows that the inbound=20 IPsec A are correctly installed.=E2=80=9D =20 Having said this. Maybe this text after the description of steps 1, 2 = and 3 may help: =20 =E2=80=9CIf some of the operations in step 1 fails (e.g. the NSF1 = reports an error when the Security Controller is trying to install anew = new inbound IPsec SA) the Security Controller must perform rollback = operations by removing any new inbound SA that had been successfully = installed during step 1.=20 =20 If step 1 is successful but some of the operations in step 2 fails (e.g. = the NSF1 reports an error when the Security Controller is trying to = install the new outbound IPsec SA), the Security Controller must perform = a rollback operation by deleting any new outbound SA that had been = successfully installed during step 2 and by deleting the inbound SAs = created in step 1.=20 =20 If the steps 1 an 2 are successful and the step 3 fails the Security = Controller will avoid any rollback of the operations carried out in step = 1 and step 2 since new and valid IPsec SAs were created and are = functional. The Security Controller may reattempt to remove the old = inbound and outbound SAs in NSF1 and NSF2 several times until it = receives a success or it gives up. In the last case, the old IPsec SAs = will be removed when the hard lifetime is reached."=20 =20 Yes, this text would help. =20 Thank you, Valery. =20 Btw, you can also find some text about NSF state loss in section 5.3.2.=20 =20 With IKE case RFC7296 contains very specific advices what to do in case of packet loss, delay etc (e.g in case of=20 simultaneous rekeying). I'd like to see the same advices for SC's behavior in case of network issues. =20 Regards, Valery. =20 =20 =20 =20 Hi, Valery =20 Obviously, you need a security controller that scales to the number of = SAs it needs to generate. But generating an SA in the IKE-less case is = just generating 72 random bytes (for AES-GCM-256) and packaging them. I = don=E2=80=99t think with a properly scaled SC this would produce more = latency than IKE between the nodes, which has 1/2 round-trips and = requires asymmetric operations. =20 On 22 Jul 2019, at 11:39, Valery Smyslov < = smyslov.ietf@gmail.com> wrote: =20 Hi Rafa, =20 sure this problem is general for any SDN solution. My point was that if SC performs a lot of real-time=20 (or near real-time) tasks as it may happen in IKE-less case,=20 then this problem may become serious. =20 Anyway, I'm happy with the updated text, thank you. However, in a following document(s), suggested by Yoav, I'd like to see more concrete advices of how SC should act in this situation to ensure that the consistence of the=20 network is preserved despite all the possible delays etc. =20 Regards, Valery. =20 =20 From: Rafa Marin Lopez < rafa@um.es>=20 Sent: Monday, July 22, 2019 6:11 PM To: Valery Smyslov < = smyslov.ietf@gmail.com> Cc: Rafa Marin Lopez < rafa@um.es>; Yoav Nir < = ynir.ietf@gmail.com>; = i2nsf@ietf.org; = ipsec@ietf.org; Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa < = = fernando.pereniguez@cud.upct.es>; = mbj@tail-f.com; Gabriel Lopez < gabilm@um.es> Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt =20 Hi Valery: =20 Thank you very much for your comments. Please see ours inside. El 20 jul 2019, a las 16:38, Valery Smyslov < = smyslov.ietf@gmail.com> escribi=C3=B3: =20 Hi, =20 thank you for updating the document. I still think that some aspect of IKE-less use case are not discussed yet (well, probably they are not=20 "serious", depending on one's definition of "serious"). =20 Unlike IKE case. which we can consider as mostly static configuration, the IKE-less case is a dynamic one. If IPsec SA are being created=20 on demand (via kernel-acquire) and the traffic volume is high, then depending on the IPsec policy IKE-less case can become=20 a highly dynamic, which implies additional requirement on both the network connecting SC and NSF and the performance of the protocol = used to=20 secure their communications. In other words, in IKE case the = communication between IKE daemon and kernel is seamless, while in IKE-less case the communication between NSF ("kernel") and SC adds noticeable delay (and can potentially add quite a long delay), which can influence total performance of the system. =20 Generally IKE-less case requires more communications between different nodes to establish or rekey IPsec SA, than IKE case (I assume that IKE SA is already established), that may have an impact on high-speed networks with short-lived IPsec SAs, especially if they are created per transport connection (say one IPsec SA for one TCP session). =20 [Authors] What you have just described is what happens in any SDN-based = network. In fact, your comment would be applicable to practically any = scenario based on the SDN paradigm. In the particular case of the I-D, = the IKE-less case is the most similar to case you can see in, for = example, Openflow networks where latency is also important (just as an = example : = https://ieeexplore.ieee.org/document/6573052 ) =20 I believe, that SC's task of managing IPsec SAs in IKE-less case=20 may become quite complex, especially because due to the additional delay, introduced by the network, the picture of the state of the SAs the SC has can become inaccurate (well,=20 it will always be inaccurate, but with short delays it doesn't matter). Just an example. Consider an SC receives a signal from NSF that an SA is soft expired and starts rekeying process by first installing a new pair of inbound SAs. It successfully installs them on the NSF it receives notification from, but then it receives a notification that the other NSF has rebooted, so it must clear all the SAs on its peers, including the just installed new one (which is only half-done). There seems to be a lot of nuances, and the document=20 completely ignores them. Not that I think that the task is impossible, but the algorithm of managing the SAs can become quite complex and possibly unreliable. =20 [Authors] We largely thought about this kind of cases, although we do = not see any different that may happen in SDN-based network nowadays. And = it seems to me that SDN is becoming something generally accepted despite = the different nuances that needs to be consider. In any case, what you = mention is not ignored in our document because it is included in the = text we have in section 5.3 (see below) where we highlight the = complexity is shifted to the SC (that=E2=80=99s clear). But as I = mentioned, this is not specific to IKE-less case but for any solution = based on the pure SDN paradigm (such as Openflow networks). In other = words, the cases you well mention are applicable to any SDN-based = solution. =20 I didn't find this discussion in the draft (sorry if I missed it). =20 Your comments are somehow summarized in the following text section 5.3 =20 "On the contrary, the overload of creating fresh IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side. This overload may create some scalability issues when the number of NSFs is high. In general, literature around SDN-based network management using a centralized Security Controller is aware about scalability issues and solutions have been already provided (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, etc)." =20 I would add that a high-speed dedicated management network between the = SC and the NSFs can be also in place to even limit reduce these delays = between the SC and NSFs (this idea comes again from Openflow networks). = Also the SC can select more =E2=80=9Cintelligent=E2=80=9D lifetime to = orchestrate better when the notifications may appear. =20 In any case, we think we can improve that text as follows:=20 =20 "On the contrary, the overload of creating and managing IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side in comparison with IKE case. For example, the Security Controller have to deal with=20 the latency existing in the path between the Security Controller=20 and the NSF in order to solve tasks such as, rekey or creation and=20 installation of new IPsec SAs. However, this is not specific to our=20 contribution but a general aspect in any SDN-based network.=20 In summary, this overload may create some scalability and performance = issues when the number of NSFs is high. Nevertheless, literature around SDN-based network management using a centralized Security Controller is aware about scalability and performance issues and solutions have been already provided and discussed (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, dedicated high-speed management networks, etc). In the context of SDN-based IPsec management, one way to reduce the latency and alleviate some performance issues can be the installation of the IPsec policies and IPsec SAs at the same = time (proactive mode, as described in Section 7.1) instead of waiting for notifications (e.g. a notification sadb-acquire when a new IPsec SA=20 is required) to proceed with the IPsec SA installations (reactive = mode).=20 Another way to reduce the overhead and the potential scalability and performance issues in the Security Controller is to apply the IKE case described in this document, since the IPsec SAs are managed between NSFs without the involvement of the Security Controller at all, except by the initial IKE configuration provided by the Security Controller.=E2=80=9D =20 Please see also our comments to Yoav. =20 Best Regards. =20 Regards, Valery. =20 =20 =20 =20 Thanks for getting this done and published. =20 We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. =20 Barring any such shouting, we will request publication right after the = meeting. =20 Thanks again, =20 Linda and Yoav On 16 Jul 2019, at 15:42, Rafa Marin-Lopez < = rafa@um.es> wrote: =20 Dear all: We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 - We have dealt with YANG doctors=E2=80=99 review (Martin's) - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. =20 - We have added more specific text in the descriptions. - Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller. - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). =20 - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. =20 - We have added a subsection 5.3.4 about NSF discovery by the Security = Controller. - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: typedef encryption-algorithm-type { type uint32; description=20 "The encryption algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference=20 "IANA Registry- Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } =20 - We have included three additional Annexes with examples in about the = usage of the YANG model. =20 - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. =20 Best Regards. Inicio del mensaje reenviado: =20 De: internet-drafts@ietf.org Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Fecha: 7 de julio de 2019, 23:34:03 CEST Para: < i-d-announce@ietf.org> Cc: i2nsf@ietf.org Responder a: i2nsf@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Interface to Network Security Functions = WG of the IETF. Title : Software-Defined Networking (SDN)-based IPsec = Flow Protection Authors : Rafa Marin-Lopez Gabriel Lopez-Millan Fernando Pereniguez-Garcia Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Pages : 81 Date : 2019-07-07 Abstract: This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources. The document focuses on the NSF Facing Interface by providing models for configuration and state data required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish Security Associations with a reduced intervention of the network administrator. The IETF datatracker status page for this draft is: = = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on/ There are also htmlized versions available at: = = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05= = = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05 A diff from the previous version is available at: = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-05 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: = ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------------------------------------------------------- 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 ------------------------------------------------------- =20 =20 =20 =20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------=_NextPart_000_0414_01D5415A.E60CD380 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Rafa,

 

 

Hi = Valery:



El 22 jul 2019, a las 18:07, Valery Smyslov <smyslov.ietf@gmail.com> = escribi=C3=B3:

 

Hi = Yoav,

 

I think = that it is not the performance of the SC that would = matter,

but the possible delays in the = network. If we think of the network

connecting the SC and the NSFs as of one = close to "ideal", then we = have

no problems. Otherwise the SC = must be prepared to deal with 

network issues. Note, that in case of = reactive SA setup and in case

of = rekeying the SC must manage two NSFs in a synchronized = manner,

and any of these NSF can go = offline or reboot or stop responding

during = this, and SC must properly deal with all this = events,

making proper roll-back on the = other NSF.

 

Regarding this: steps 1, 2 and 3 in section 5.3.1 are = lock-step. As you may see we mention: 

 

"Once the Security Controller receives = confirmation from A and B, the controller knows that the = inbound 

IPsec A are = correctly installed.=E2=80=9D

 

Having said this. Maybe this text after the = description of steps 1, 2 and 3 may help:

 

=E2=80=9CIf some of the operations in step 1 fails = (e.g. the NSF1 reports an error when the Security Controller is = trying to install anew new inbound IPsec SA) the Security = Controller must perform rollback operations by removing any new = inbound SA that had been successfully installed during step = 1. 

 

If step 1 is successful but some of the operations in = step 2 fails (e.g. the NSF1 reports an error when the Security = Controller is trying to install the new outbound IPsec SA), = the Security Controller must perform a rollback operation by = deleting any new outbound SA that had been successfully installed during = step 2 and by deleting the inbound SAs created in step = 1. 

 

If the steps 1 an 2 are successful and the step 3 = fails the Security Controller will avoid any rollback of the = operations carried out in step 1 and step 2 since new and valid IPsec = SAs were created and are functional. The Security = Controller may reattempt to remove the old inbound and outbound SAs = in NSF1 and NSF2 several times until it receives a success or it gives = up. In the last case, the old IPsec SAs will be removed when the hard = lifetime is reached." 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Yes, this = text would help.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Thank you,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Valery.

 

Btw, you can also find some text about NSF state loss = in section 5.3.2. 



 

With IKE = case RFC7296 contains very specific advices = what

to do in case of packet loss, = delay etc (e.g in case of 

simultaneous rekeying). I'd like to see the = same advices

for SC's behavior in case of = network issues.

 

Regards,

Valery.

 

 

 

 

Hi, = Valery

 

Obviously, you need a security controller that scales = to the number of SAs it needs to generate. But generating an SA in the = IKE-less case is just generating 72 random bytes (for AES-GCM-256) and = packaging them.  I don=E2=80=99t think with a properly scaled SC = this would produce more latency than IKE between the nodes, which has = 1/2 round-trips and requires asymmetric = operations.

 




On 22 Jul 2019, at 11:39, Valery Smyslov <smyslov.ietf@gmail.com> = wrote:

 

Hi = Rafa,

 

<= div>

sure this problem is general for any SDN = solution.

My point = was that if SC performs a lot of real-time 

(or near real-time) tasks as it may happen in = IKE-less case, 

then this problem may become = serious.

 

<= div>

Anyway, I'm happy with the updated text, = thank you.

However, = in a following document(s), suggested by = Yoav,

I'd like = to see more concrete advices of how SC = should

act in = this situation to ensure that the consistence of the 

network is preserved despite all the possible = delays etc.

 

<= div>

Regards,

Valery.

=

 

<= div>

 

From: Rafa Marin Lopez = <rafa@um.es> 
Sent: Monday, July 22, 2019 6:11 = PM
To: Valery = Smyslov <smyslov.ietf@gmail.com>
Cc: Rafa Marin Lopez = <rafa@um.es>; Yoav Nir <ynir.ietf@gmail.com>; i2nsf@ietf.org; ipsec@ietf.org; Fernando = Pere=C3=B1=C3=ADguez Garc=C3=ADa <fernando.pereniguez@cud.upct.es>; mbj@tail-f.com; Gabriel Lopez <gabilm@um.es>
Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

 

Hi Valery:

 

<= p class=3DMsoNormal>Thank you very much for your comments. Please see = ours inside.

El 20 jul 2019, a las 16:38, Valery Smyslov <smyslov.ietf@gmail.com> = escribi=C3=B3:

 

Hi,

 

=

thank you for updating the document. I still = think that some = aspect

of = IKE-less use case are not discussed yet (well, probably they are = not 

"serious", depending on one's = definition of = "serious").

 

=

Unlike IKE case. which we can consider as = mostly static = configuration,

the = IKE-less case is a dynamic one. If IPsec SA are being created 

on demand (via kernel-acquire) and the = traffic volume is = high,

then = depending on the IPsec policy IKE-less case can become 

a highly dynamic, which implies additional = requirement on = both

the = network connecting SC and NSF and the performance of the protocol used = to 

secure their communications. In other words, = in IKE case the = communication

between = IKE daemon and kernel is seamless, while in = IKE-less

case the = communication between NSF ("kernel") and SC = adds

noticeable delay (and can potentially add = quite a long = delay),

which = can influence total performance of the = system.

 

=

Generally IKE-less case requires more = communications = between

different nodes to establish or rekey IPsec = SA, than IKE = case

(I = assume that IKE SA is already established), that may = have

an = impact on high-speed networks with short-lived IPsec = SAs,

especially if they are created per transport = connection

(say one = IPsec SA for one TCP = session).

=

 

<= p class=3DMsoNormal>[Authors] What you have just described is what = happens in any SDN-based network. In fact, your comment would be = applicable to practically any scenario based on the SDN paradigm. In the = particular case of the I-D, the IKE-less case is the most similar to = case you can see in, for example, Openflow networks where latency is = also important (just as an example : https://ieeexplore.ieee.org/document/6573052 )





 

=

I believe, that SC's task of managing IPsec = SAs in IKE-less case 

may become quite complex, especially because = due to the

additional delay, introduced by the network, = the picture of = the

state of = the SAs the SC has can become inaccurate (well, 

it will always be inaccurate, but with short = delays it doesn't = matter).

Just an = example. Consider an SC receives a signal from NSF that an = SA

is soft = expired and starts rekeying process by first installing a = new

pair of = inbound SAs. It successfully installs them on the = NSF

it = receives notification from, but then it receives a = notification

that the = other NSF has rebooted, so it must clear all the SAs = on

its = peers, including the just installed new one (which is = only

half-done). There seems to be a lot of = nuances, and the document 

completely ignores them. Not that I think = that the task

is = impossible, but the algorithm of managing the SAs can = become

quite = complex and possibly = unreliable.

 

<= p class=3DMsoNormal>[Authors] We largely thought about this kind of = cases, although we do not see any different that may happen in SDN-based = network nowadays. And it seems to me that SDN is becoming something = generally accepted despite the different nuances that needs to be = consider. In any case, what you mention is not ignored in our document = because it is included in the text we have in section 5.3 (see below) = where we highlight the complexity is shifted to the SC (that=E2=80=99s = clear). But as I mentioned, this is not specific to IKE-less case but = for any solution based on the pure SDN paradigm (such as Openflow = networks). In other words, the cases you well mention are applicable to = any SDN-based solution.





 

=

I didn't find this discussion in the draft = (sorry if I missed = it).

=

 

<= p class=3DMsoNormal>Your comments are somehow summarized in the = following text section = 5.3

 

"On the contrary, = the overload of creating fresh IPsec
   SAs is shifted to = the Security Controller since IKEv2 is not in the
   NSF. =  As a consequence, this may result in a more complex
  =  implementation in the controller side. =  This overload may create some
   scalability issues = when the number of NSFs is high.

In general, literature around SDN-based network = management using a

   centralized Security Controller is aware = about scalability issues = and

   solutions have been already provided = (e.g. hierarchical = Security

   Controllers; having multiple replicated = Security Controllers, = etc)."

 

=

I would add that a high-speed dedicated = management network between the SC and the NSFs can be also in place to = even limit reduce these delays between the SC and NSFs (this idea comes = again from Openflow networks). Also the SC can select more = =E2=80=9Cintelligent=E2=80=9D lifetime to orchestrate better when the = notifications may = appear.

 

<= p class=3DMsoNormal>In any case, we think we can improve that text as = follows: 

 

<= p class=3DMsoNormal>"On the contrary, the overload of creating and = managing IPsec

   SAs is shifted to the Security Controller = since IKEv2 is not in the
   NSF. As a consequence, this = may result in a more complex
   implementation in the = controller side in comparison = with

   IKE case.  For example, the = Security Controller have to deal = with 

   the latency existing in the = path between the Security = Controller 

   and the NSF in order to solve = tasks such as, rekey or creation = and 

   installation of new IPsec SAs. However, = this is not specific to = our 

   contribution but a general aspect in any = SDN-based = network. 

   In summary, this overload may create some = scalability and = performance 

   issues when the number of NSFs is = high.


   Nevertheless, literature around = SDN-based network management using a
   centralized = Security Controller is aware about scalability and
  =  performance issues and solutions have been already provided = and
   discussed (e.g.  hierarchical Security = Controllers; having multiple
   replicated Security = Controllers, dedicated high-speed management
   networks, = etc). In the context of SDN-based IPsec management, = one

   way to reduce the latency and alleviate = some performance issues = can

   be the installation of the IPsec policies = and IPsec SAs at the same = time

   (proactive mode, as described in Section = 7.1) instead of waiting = for

   notifications (e.g. a notification = sadb-acquire when a new IPsec = SA 

   is required) to proceed with the IPsec SA = installations (reactive = mode). 

   Another way to reduce the overhead and = the potential scalability = and

   performance issues in the Security = Controller is to apply the IKE
   case described in this = document, since the IPsec SAs are managed
   between NSFs = without the involvement of the Security Controller at
  =  all, except by the initial IKE configuration provided by the = Security
  =  Controller.=E2=80=9D

 

<= p class=3DMsoNormal>Please see also our comments to = Yoav.

 

<= p class=3DMsoNormal>Best = Regards.





 

=

Regards,

Valery.

 

=

 

=

 

=

 

=

Thanks = for getting this done and = published.

 

We will wait with requesting = publication until the I2NSF session next week.  Between now and = then, please re-read the draft and send a message to the list is = something is seriously = wrong.

 

=

Barring any such shouting, we will = request publication right after the = meeting.

 

=

Thanks = again,

 

=

Linda and = Yoav






On 16 Jul 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> = wrote:

 

<= div>

Dear all:

We submitted a new = version of the I-D (v05) where we have applied several changes. In = the following you have a summary of the main changes, which we will = expand/explain during our presentation: 

- We have dealt = with YANG doctors=E2=80=99 review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.

 

=

- We have added more specific text in the = descriptions.

- Notifications have a simpler format now since = most of the information that contained in the past is already handled by = the Security Controller.

- State data has been reduced. For = example, in IKE case, most of the information is related with IKE and = not with the specific details about IPsec SAs that IKE handles (after = all, IKE can abstract this information from the Security = Controller).

 

=

- We have included text in the security = section to discuss about the default IPsec policies that should be in = the NSF when it starts before contacting with the SC such as the IPsec = policies required to allow traffic between the SC and the = NSF.

 

=

- We have added a subsection 5.3.4 about = NSF discovery by the Security Controller.

- In order to specify = the crypto-algorithms we have used a simple approach by including an = integer and adding a text pointing the IANA in = the reference clause. For = example:


typedef encryption-algorithm-type = {
           ty= pe = uint32;
          &n= bsp;description 
        =        "The encryption algorithm = is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          = ;     values MUST follow the requirement levels = for
           =     encryption algorithms for ESP and = IKEv2.";
         &n= bsp; reference 
       &n= bsp;        "IANA Registry- = Transform Type 1 - = Encryption
          = ;      Algorithm Transform IDs. RFC 8221 - = Cryptographic
         &n= bsp;      Algorithm Implementation = Requirements and = Usage
          &nbs= p;     Guidance for Encapsulating Security = Payload = (ESP)
          &nbs= p;     and Authentication Header (AH) and RFC = 8247 = -
           &n= bsp;    Algorithm Implementation Requirements and = Usage
          &nbs= p;     Guidance for the Internet Key Exchange = Protocol
          &= nbsp;     Version 2 = (IKEv2).";
       }=

 

=

- We have included three additional = Annexes with examples in about the usage of the YANG = model.

 

=

- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without = warnings.

 

=

Best = Regards.






Inicio del mensaje = reenviado:

 

Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

Fecha: 7 de julio de 2019, = 23:34:03 = CEST

Responder a: i2nsf@ietf.org

 

<= div>


A New Internet-Draft is available from = the on-line Internet-Drafts directories.
This draft is a work item of = the Interface to Network Security Functions WG of the = IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow = Protection
       Authors =         : Rafa = Marin-Lopez
         &nbs= p;            = ;   Gabriel = Lopez-Millan
         &nb= sp;           &nbs= p;   Fernando Pereniguez-Garcia
        &n= bsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &n= bsp;  Pages =           : = 81
        &n= bsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how = providing IPsec-based flow protection by
  means of a = Software-Defined Network (SDN) controller (aka. =  Security
  Controller) and establishes the = requirements to support this service.
  It considers two = main well-known scenarios in IPsec: (i) = gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document allows the = distribution and monitoring of IPsec
  information from a = Security Controller to one or several flow-based
  Network = Security Function (NSF).  The NSFs implement IPsec to = protect
  data traffic between network = resources.

  The document focuses on the NSF Facing = Interface by providing models
  for configuration and state = data required to allow the Security
  Controller to = configure the IPsec databases (SPD, SAD, PAD) and = IKEv2
  to establish Security Associations with a reduced = intervention of the
  network administrator.


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-= sdn-ipsec-flow-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-i= psec-flow-protection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i= 2nsf-sdn-ipsec-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2n= sf-sdn-ipsec-flow-protection-05


Please note that = it may take a couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
=
_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf=

=

 

<= div>

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

 

 

=

 

=

 

=

_______________________________________________
I2ns= f mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf=

 

------=_NextPart_000_0414_01D5415A.E60CD380-- From nobody Tue Jul 23 12:56:47 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F181200E0 for ; Tue, 23 Jul 2019 12:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 WeiQIB3MsB_N for ; Tue, 23 Jul 2019 12:56:33 -0700 (PDT) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd00::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2828012031F for ; Tue, 23 Jul 2019 12:56:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dcRH5oEbEoyZ3I5ilHORnY1UqIQ3yZX5QfMG/oUH0BMyJ1fUM8IVJxw6nOFR6KI/8W+uIf+CwYKFupmn6pwNfmiw3r+9MgyEZ/24lDa/LC4deLvv2s9/FcwyLAvbDWYpus5EfFL7A+HACZiOHptxylNVHzi8hRbhGhbQCEqiPNoXftZKO5jUlCmsy3oS6VcUJsKWRkaSRcszE7OcXteUYPW+X7R/mI5MUsfnfkX2zH9lj1XjdG2jfJ0Lmma+yvsikmcla1ljWLSn6kJ4NYJbhvvB/nSZbLoqAtEH66MkHWiyXZaDo25/+zHmKJuRkIgDYzToxiX9vvONv4R4iNNBtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=99pjqKfj0JhmCyF980a5zfqqW7evZVVa3y7kFGGNBBY=; b=KHZNN0BSh3dkOyF3LAp2xDu6ArMmW4IPMbTQMQxnc9S6G2nuSrOrrKHMjxHe3WbgcIkvjVrsMKYBoESGK/nH6QcOFwNQclQfMY+ZH6LaqNS59Q026f2WZKGDhZTYm3jeGauVBmBtrXwv9aL6HApk6up9dkDzz+ncU2iQW/n5ZWRtwH6eXoV3+5jQyxkM0fdkOhw+eYbtGo6qjz/578HU+CUXP2QPQX1BQbuecx8SV0twFRLK9vn+Q2OIw7WeiqMH7Hc1cUhj++BBFQCh2lGD9Qatoym2s3DWIqgz5mxejiZqAXSW7pPZl9SEDfi0weIBqvTKn4+7AX6OpIowI8GjKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nist.gov;dmarc=pass action=none header.from=nist.gov;dkim=pass header.d=nist.gov;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=99pjqKfj0JhmCyF980a5zfqqW7evZVVa3y7kFGGNBBY=; b=rAGabUv3GVl2kOSbEQ3s6ro6fLUod2T3iTAJkXMxQJqKcDJyzsebELJ53nk8NqiyG/o6NN1OItujhRzIP0EqBRums0bRH/hTB6OjF8SgpNolTL6KPolSOWCbqbW5j6LL54x2Ejj6yiNpOfMZAIYrIMF50Kufru1Y/XeOJc9GPJM= Received: from CY4PR09MB2245.namprd09.prod.outlook.com (10.172.140.135) by CY4PR09MB2040.namprd09.prod.outlook.com (10.173.110.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.12; Tue, 23 Jul 2019 19:56:30 +0000 Received: from CY4PR09MB2245.namprd09.prod.outlook.com ([fe80::103a:14af:d29:ffba]) by CY4PR09MB2245.namprd09.prod.outlook.com ([fe80::103a:14af:d29:ffba%11]) with mapi id 15.20.2094.017; Tue, 23 Jul 2019 19:56:30 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-ipv6-ipv4-codes Thread-Index: AQHVQZCGkrzTCxVZJk2D7JC1eymvGw== Date: Tue, 23 Jul 2019 19:56:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [2610:20:6005:220::93] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42eb240f-07bb-40fa-b7a6-08d70fa7db3a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:CY4PR09MB2040; x-ms-traffictypediagnostic: CY4PR09MB2040: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39860400002)(366004)(136003)(199004)(189003)(9686003)(6916009)(55016002)(6306002)(52536014)(236005)(5660300002)(316002)(54896002)(6116002)(486006)(2906002)(4744005)(53936002)(6606003)(6436002)(19627405001)(71200400001)(71190400001)(66476007)(66946007)(99286004)(66446008)(64756008)(66556008)(186003)(606006)(68736007)(1015004)(8676002)(76116006)(256004)(7696005)(8936002)(46003)(81156014)(476003)(33656002)(478600001)(14454004)(81166006)(25786009)(7736002)(6506007)(74316002)(86362001)(91956017)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB2040; H:CY4PR09MB2245.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SfdVTXchtAvNDSIDLR4GSbSgsNMQS40qxB3c4TOlownHfHjW+WenPKe2FPscKptd2Or+D5RZyZQDnbd4azSXmJd4WARn2tOr+nmY3z7bGvC/PcIIko4xSuTmQNZFcTWgmp5yeGCP0uZ5e/11vU57y4QlxwW53q71sYk/lS27aIpZY6MPUFtemEvE6HcUDG4qCUepos49uQLHLK06LhChVG4ITrnlcL7qlXBNukuAREh4USr6MDGD/W5AiXRHKfFoAspBeXaI7yjiojxlgFm8r+ax0MG9Gg4K57cMHq4xG58LCZd867pY1Ac3hyhGNHNmGpp16LtFnDythbgB9aNxK2uJ6k/n7LjNQRqTgeUxVLtF6miB4JyP3lkXCR05UmFzp8FZN4ZIVaLDZgznWLcA4b0XMj167xmE3hblfXeR9nU= Content-Type: multipart/alternative; boundary="_000_CY4PR09MB2245B1A18CFDF76F435975CFF0C70CY4PR09MB2245namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 42eb240f-07bb-40fa-b7a6-08d70fa7db3a X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 19:56:30.6288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: davidwal@NIST.GOV X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB2040 Archived-At: Subject: [IPsec] WGLC on draft-ietf-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 19:56:45 -0000 --_000_CY4PR09MB2245B1A18CFDF76F435975CFF0C70CY4PR09MB2245namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This message starts a working group last call (WGLC) on draft-ietf-ipsecme-= ipv6-ipv4-codes, which will conclude on August 16, 2019 at 23:59 UTC . Please re= view and provide feedback on the -03 version (https://datatracker.ietf.org/doc/draft-ie= tf-ipsecme-ipv6-ipv4-codes/). Please indicate if you believe this draft is = ready for publication or if you have comments that must be addressed before= the draft progresses to the IESG. Regards, Dave and Tero --_000_CY4PR09MB2245B1A18CFDF76F435975CFF0C70CY4PR09MB2245namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This message starts a working group last call (WGLC) on draft-ietf-ipsecme-ipv6-ipv4-codes, which will conclude on Augus= t 16, 2019 at 23:59 UTC . Please review and provide feedback on the -03 version (https://datatracker.ietf.org/doc/draft-ietf-ipsec= me-ipv6-ipv4-codes/). Please indicate if you believe this draft is ready for publication or if y= ou have comments that must be addressed before the draft progresses to the = IESG.

Regards,
Dave and Tero

--_000_CY4PR09MB2245B1A18CFDF76F435975CFF0C70CY4PR09MB2245namp_-- From nobody Tue Jul 23 14:38:31 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6B11203C2 for ; Tue, 23 Jul 2019 14:38:29 -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=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 fsb4cHr0ehIG for ; Tue, 23 Jul 2019 14:38:26 -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 9AA1B1202C5 for ; Tue, 23 Jul 2019 14:38:25 -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 x6NLcMZB024426 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 24 Jul 2019 00:38:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6NLcLpv019861; Wed, 24 Jul 2019 00:38:21 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23863.32333.879285.318503@fireball.acr.fi> Date: Wed, 24 Jul 2019 00:38:21 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] IPsecME 105 Montreal preliminary minutes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 21:38:29 -0000 Here is preliminary minutes, if you have any comments, additions etc to them, send them to chairs. Thanks to mcr to taking the minutes. ---------------------------------------------------------------------- # IPsecME WG ## IETF 105, Montreal * Date: 2019-07-23 * Time: 15:20-16:50 (90 min) * Room: Sainte-Catherine * Chair: Tero Kivinen * Chair: David Waltermire --- ## Agenda ### Adminstrivia (5 min) * Agenda bashing, Logistics -- Chairs (5 min) 1) Paul asks about Graveyard draft, Chairs mention that authors need to push, chairs won't pull. Paul says that it is ready for WG Adoption Call. ### Draft status -- Chairs (10 min) * draft-ietf-ipsecme-implicit-iv - Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Already in publication requested * draft-ietf-ipsecme-ipv6-ipv4-codes - IKEv2 Notification Status Types for IPv4/IPv6 Coexistence WG LC will be issued shortly * draft-ietf-ipsecme-qr-ikev2 - Postquantum Preshared Keys for IKEv2 Already in publication requested state Apple is shipping Postquantum in iOS 13 ### Other issues --- call for experts for independent review of candidate/nominated specifications for PAKE for CFRG. Valery, framework for PAKE is RFC6467, integration for IKEv2 PAKE. Experimental RFC. ### Work Items (25 min) * draft-ietf-ipsecme-ikev2-intermediate -- Valery Smyslov (5 min) - Intermediate Exchange in the IKEv2 Protocol INTERMEDIATE->IKE_INTERMEDIATE. Thinks this is the last rename. It can not be resumed. How the IKE_INTERMEDIATE exchange is included in the AUTH has changed again. authenticated as if it were sent unfragmented peers may disagree on length field in the headers, e.g. by padding differences. -> remove the length fields. Should be ready for WG LC soon * draft-ietf-ipsecme-labeled-ipsec -- Paul Wouters (5 min) - Labeled IPsec Traffic Selector support for IKEv2 went back to previous version of the format. opaque blob with a >0 length Valery pointed out that the text restricts ability for a responder to select more than one TSi (if proposed). Paul replies that this was unintentional, and will be removed. Also should be ready for WG LC soon * draft-yeung-g-ikev2 -- Valery Smyslov (15 min) - Group Key Management using IKEv2 Is the GSA_REKEY signed (assymetrically) by Initiator? YES, there is this [AUTH] payload (optional, could be symmetric key only). Large step forward since IETF99, more implementations interoperated before, but significant changes which need to be retested. MCR asked if there was really the multicast expertise of implementors in the WG. Tobias Heider from U of Munich answers in Jabber. Should be ready for WG Adoption call. ### Other presentations (35 min) * draft-tjhai-ipsecme-hybrid-qske-ikev2 -- Valery Smyslov (10 min) - Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) Do we need fresh nonces in every IKE_INTERMEDIATE? Scott Fluhrer says that the nonces are for nonces, and we have already proved things by completing the first AUTH. Tero: Why are you using INFORMATIONAL for additional information? Valery: Because we want to have the same properties as the first, and INFORMATIONAL is wildcard. Paul suggests using new exchange called "SA_INTERMEDIATE" Tobias (jabber): +1 on Paul. MCR: asks about how the state machine can be verified without having some QSKE to chain to? Scott: Proposed they could use group 18, which is already big. Tero: There has also been some interest to add 12k and 16k DH keys, they would be even larger. Tobias Heider: mic: We at LMU Munich are actually working on a formal verification model to make sure the state machine is working Should be ready for WG Adoptation call. * draft-hopps-ipsecme-iptfs -- Christian Hopps (10 min) - IP Traffic Flow Security Added a don't fragment bit. moved congestion control from out-of-band to in-band. David Black: Transport experts were asked, and it looks like they got it right. Valery: the purpose is to fill as much data as possible? No: the purpose is to hide the data size. Valery: for a fixed packet size, you want to put as many data as possible? Did you consider to reduce the size of the reserved fields? Yes, considered ways to eliminate the header all-together. The implementations will either set to the largest MTU, or will do Path MTU in general.... but alignment is good. Paul: you are using a traffic selector to request this? No, it's a transform selector. Yoav: not only is this supposed to do, but IKEv2 was supposed to do this properly from the start. Tero: the measurement, was it done with real traffic, or ?? Chris: it was done with I-Mix traffic distribution? Tero: asks about latency? you can't wait for long time because of TCP ACKs Chris: yes, there is a latency problem, and so there is an challenge. This is not part of our charter, we need to recharter to include this. There seems to be enough interest for this work, so chairs will propose new charter item to ADs. * draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt -- Wei Pan/Sandeep Kampati (15 min) - IKEv2 Optional SA&TS Payloads in Child Exchange MCR: hypothesis that rekey situation 3 is not interesting, that most will just kill (IKE) SA and restart. Scott reports that his products will apply the new policy to the CHILD SA without killing IKE, i.e., using rekey. Bharath Meduri: For ACL Change Kill all and create new. but for crypto just allow after reky Paul points out that we should never have send the TSx on rekey, so that nobody could change them by mistake. Valery: suggest that it is not useful for IKE, and that maybe just do this for Traffic Selectors, and not SA properties. Tero: if you are rekeying that you are using the same thing, then this makes sense, just rekey, i.e., send REKEY_SA notify, and include new SPI there, and leave the SA and TS payloads out. Just do not bother rekeying the IKE SA, so what's the point of optimizing this. If you do so much that the algorithms or TS are changing, then it isn't a REKEY. Tero says that is in the charter, as it fits into compressing IKEv2. Tero suggests that there is enough interest. Document will get a WG Adoption Call. Other business: Paul: no-one from NIST is talking about new document. Revision-1 guide to deploying IPsec VPNs. -- kivinen@iki.fi From nobody Tue Jul 23 19:40:06 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C901F120046 for ; Tue, 23 Jul 2019 19:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SeecdUKuYP7j for ; Tue, 23 Jul 2019 19:40:02 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8B3120074 for ; Tue, 23 Jul 2019 19:40:02 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id a15so43987666qtn.7 for ; Tue, 23 Jul 2019 19:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=ikr+DcyJzGIH8MhjFyPCROhGhxoq1wn1gBEiZh4v9gQ=; b=PcYGUryr62azBTcDWDDyeVNRlCR1vFZkMHlbLiUJEUPAIqIFO3DoewcEocWnJn2BSj AimHkyrjXwpGVybjeH9jCQL/K//ZhTJfDb1ziYBwurKRPl1whed86FD+IySSmq05aibN cW6cNveWLxOAMUswHWnjs7y7Bv8qVHm/auCov+pQYAGHj6/Dfz/IBZLDcnvNzIYtOIOc 5LZ972EA1aEUGlSOpY/1Vg9utM3J/0WpTeidyvs202VeTZ0EPTOf26vb+zA8GezjGv4b kb3XnDNU+UHcrlhS8lMqj+XP+ti03a00y3iHHVuJOShVuTOJDjazQVnlYE1XBADHPfKA UvUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=ikr+DcyJzGIH8MhjFyPCROhGhxoq1wn1gBEiZh4v9gQ=; b=atZXyzahSN+6of5tj22pWDHWyFXuxTzjppsE+x71gCzCP+OBeijsYXgmgMbl+GaA8U rUcN+HuKVeI2qukbJRO3KYqqcYu4zRQ4c4EB9V4414qI7o+oPeId0QUr/2EGx4yEUnUf VP4mMjwxaslIPIIiyuDOduUmlYiq0tCj5gOIyG79rDvkp42NRMz6kYz86FxZyWeb3TCO myVQnVoxZXLQZD9KH8MrOV71XUtJzlUUgtDPgBA3OibebG5/5J1og7YmbUQnlmfe+inY DwSc5+VKYhdL+6Nk04FM0TAxsb7tmMoB3N06SpFpgZsLyybjyUfQnFt/NwmjmPcDA+gl DrxQ== X-Gm-Message-State: APjAAAVBSRex/ng0o1AhaY9bth78eiqYR+9MkIxssZURfNnkf85rillo g/AA5fPBDjN/tLZAGIyn9e82/PG2XQo= X-Google-Smtp-Source: APXvYqzv6RPc9BS02OBp/xb/gV/zAuBSk7szjbu0ATWN/0elAIn02ah0EHMGjMv3bGpi2GqNX9Cwow== X-Received: by 2002:a0c:bd91:: with SMTP id n17mr56070194qvg.128.1563936001649; Tue, 23 Jul 2019 19:40:01 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:9028:46f7:6f4:6ab0? ([2001:67c:1232:144:9028:46f7:6f4:6ab0]) by smtp.gmail.com with ESMTPSA id r40sm24849666qtr.57.2019.07.23.19.40.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 19:40:00 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_13FF6C6E-D7B0-474E-B578-7EDC453D12DA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <8998221B-165D-4A25-9023-BA2CAD9D193D@gmail.com> Date: Tue, 23 Jul 2019 22:40:00 -0400 To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [IPsec] Heads up: IDR meeting on Wednesday X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 02:40:05 -0000 --Apple-Mail=_13FF6C6E-D7B0-474E-B578-7EDC453D12DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi This may be of interest to IPsec folks. The IDR working group is = meeting tomorrow and has several IPsec-related items on its agenda: Secure EVPN - where BGP is used instead of IKEv2 to key IPsec and = distribute policy. BGP Signaled IPsec Tunnel Configuration - where IKEv2 is configured by = BGP to set up IPsec SAs. Subsequent Address Family Indicator for SDWAN Ports - which is something = about SD-WAN (with IPsec) So if you=E2=80=99re not doing anything interesting at 13:30, you might = want to go there. The agenda: = https://datatracker.ietf.org/meeting/105/materials/agenda-105-idr-02 = Yoav --Apple-Mail=_13FF6C6E-D7B0-474E-B578-7EDC453D12DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

This = may be of interest to IPsec folks.  The IDR working group is = meeting tomorrow and has several IPsec-related items on its = agenda:
  • Secure EVPN - where BGP is used instead of IKEv2 to key IPsec = and distribute policy.
  • BGP Signaled IPsec Tunnel Configuration - = where IKEv2 is configured by BGP to set up IPsec SAs.
  • Subsequent Address Family Indicator for SDWAN Ports - which = is something about SD-WAN (with IPsec)

So if = you=E2=80=99re not doing anything interesting at 13:30, you might want = to go there.

The agenda:  https://datatracker.ietf.org/meeting/105/materials/agenda-105-i= dr-02

Yoav

= --Apple-Mail=_13FF6C6E-D7B0-474E-B578-7EDC453D12DA-- From nobody Wed Jul 24 04:20:19 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FB412002E; Wed, 24 Jul 2019 04:20:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <156396721669.14579.7164691266695481843@ietfa.amsl.com> Date: Wed, 24 Jul 2019 04:20:16 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 11:20:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Intermediate Exchange in the IKEv2 Protocol Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-intermediate-02.txt Pages : 11 Date : 2019-07-24 Abstract: This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 24 04:27:36 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68A120181 for ; Wed, 24 Jul 2019 04:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pal6pWggWZeQ for ; Wed, 24 Jul 2019 04:27:32 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFCD120180 for ; Wed, 24 Jul 2019 04:27:32 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id x22so40135222qtp.12 for ; Wed, 24 Jul 2019 04:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=rvNN2uFOGjxWyF5f3Ep1ZN7OaQS2HW1YEQS8/BUcQdQ=; b=H8MgGfBdfqLQpBcSjBi4fSZlrHfOWlI4leK/SoWw1D8BXsUtSpzh3yZGS/5rTessKT d4E995P6eJiZZxZoQKyYgbF75OYxhs3UvBCIvPyCBHkAozmtR/ZEAFiJouGCFpmijA73 E9fUZbbDVnxKhTm4WkIDhyVikU2k2yFkXN8rQYz+2YLCX4VUD2ggPdlrJHrIwxtTHtFg /o9bJKaaN58JoNMGxSAyJkv8ZZf6eiiev5hazrAiYRS4jwotoBK0VWlRbqlESPjka9LM QyXD3o0dXk4cZpI6Y2PeJiM+l9j/0Y5N3n2vqea1ZSAHGSFiTvB6Zf7vWSERBxlrKa8l 2UFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=rvNN2uFOGjxWyF5f3Ep1ZN7OaQS2HW1YEQS8/BUcQdQ=; b=sJ9Pb5RZtKLcu5sa6/AHEXM4JXatstWIvpQj2j3zmlsvwLHDTowGotIE4txcYPmL9+ mR8MooGs+Lnt9gPhlgPo5xn+4jzpiCW9UzO5R8cz97fvo2CLk0lNwIF4FRZv1yQJLGzo psl8RZlUUNiqpgQn14BlHx7gP14+fAUjukWc8kqVONoiJNW7m656zlPqczRzPYfS+IdO ze3pp8GUwIM3/y7AiETB2+Nh9aDoAwSKP+7STp67IfRWbSFfngm1I/Ft4Y4s27cSqKbf 5XJM1LV+WABj2cSGWzIqpdJz0UxZm0yKH6VgP0zGUiY3jdykg7G8TYOWW3/fhPbfSQtv 1K1w== X-Gm-Message-State: APjAAAVgED8hkvzmW/NpyBrTBm50c/5kgvsBiDCMLZ/+yFsfIE+pHrey WGuBTqZNv4t0YUAmpDFvDBp69ZPh2Lw= X-Google-Smtp-Source: APXvYqyi2RPaSiSz0lptppYu6ff8tK9zaoN2Pq73tErxq2iSFNF073uU1Br9b0A9WtoYA8YNaagO9Q== X-Received: by 2002:aed:254c:: with SMTP id w12mr59220231qtc.127.1563967651386; Wed, 24 Jul 2019 04:27:31 -0700 (PDT) Received: from svannotebook (modemcable142.183-83-70.mc.videotron.ca. [70.83.183.142]) by smtp.gmail.com with ESMTPSA id d9sm20536227qke.136.2019.07.24.04.27.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 04:27:30 -0700 (PDT) From: "Valery Smyslov" To: References: <156396721669.14579.7164691266695481843@ietfa.amsl.com> In-Reply-To: <156396721669.14579.7164691266695481843@ietfa.amsl.com> Date: Wed, 24 Jul 2019 14:27:29 +0300 Message-ID: <061101d54212$c796c8d0$56c45a70$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHdP0C/dE8jBZfU6Q3cRhN0Cj/PC6bJpU4Q Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 11:27:34 -0000 Hi, a new version of the IKE_INTERMEDIATE draft is published. The way authentication data is calculated is changed as a result of a private conversation with one of implementers. Now the size of the crypto-related stuff (IV, ICV, padding) is no more included into the calculation (note, that the stuff itself wasn't included before, but its size was, and it was wrong). Please, review. Regards, Valery. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of > the IETF. > > Title : Intermediate Exchange in the IKEv2 Protocol > Author : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-intermediate-02.txt > Pages : 11 > Date : 2019-07-24 > > Abstract: > This documents defines a new exchange, called Intermediate Exchange, > for the Internet Key Exchange protocol Version 2 (IKEv2). This > exchange can be used for transferring large amount of data in the > process of IKEv2 Security Association (SA) establishment. > Introducing Intermediate Exchange allows re-using existing IKE > Fragmentation mechanism, that helps to avoid IP fragmentation of > large IKE messages, but cannot be used in the initial IKEv2 exchange. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-02 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate- > 02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jul 24 08:39:43 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679BB1202AE; Wed, 24 Jul 2019 08:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 oMKKK_cPMR74; Wed, 24 Jul 2019 08:39:33 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 3A72D120386; Wed, 24 Jul 2019 08:39:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45tzzk13NLzDK8; Wed, 24 Jul 2019 17:39:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1563982770; bh=MfvO0d4ysyg3eacVguzoPFEu2k0xLSc18gXbAu8le0c=; h=Date:From:To:cc:Subject; b=MgdG6c+p//vG4xHWKKU41bdwLUy1irC4IY5+nuuSH/ecbzEWiDyOYUcAS6kFjcORj K1AKez8r5+i0JwiAtLRaNhHsS2eK1Cq2c+T4JZYEM1asOH1MhAbsqwVZyQC1pVhqqH vXfHRkxnX89/veZ87diaQZAwRaG0GaApmKoHuBTw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GnH26DSaDZur; Wed, 24 Jul 2019 17:39:28 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 24 Jul 2019 17:39:27 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DAFAB353F94; Wed, 24 Jul 2019 11:39:26 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DAFAB353F94 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CDA6E40A6FFE; Wed, 24 Jul 2019 11:39:26 -0400 (EDT) Date: Wed, 24 Jul 2019 11:39:22 -0400 (EDT) From: Paul Wouters To: idr@ietf.org cc: "ipsec@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Review of draft-hujun-idr-bgp-ipsec-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 15:39:36 -0000 Hi, Note that I am an IPsec person and not a routing expert. The document's idea looks fine to me. It is using BGP messages to provision IKEv2 so that IPsec tunnels can be setup to protect packets as best as possible. That's great :) And unlike most proposals the IPsec WG sees, this document does not try to replace IKEv2 with its own smarter Key Exchange protocol, so that's a double plus :) Thanks for reaching out to the ipsec WG, we really appreciate the chance to read drafts that use IPsec to give advise. Below are some of my comments and questions I have: - Configuring large number of tunnels is error prone and not scalable * Only true to some extend * See AutoVPN, DMVPM, NHRP+IKE * Still, this provisioning system seems to fit your eco system. It's as simple as it can be and does not seem to introduce any new complexity or risks. - What is "color"? - Section 3, step 4: When a router need to forward a packet along a path is determined by a BGP UPDATE which has a tunnel encapsulation attribute that contains one or more IPsec TLV, and router decides use IPsec based on local policy, Required vs Optional IPsec issue. If only one end has "required" and the other end has "optional" then unencrypted packets will be dropped. Seeing IPsec tunnel TLV should probably mean it is mandatory to setup a tunnel? It can be done as "optional" but then the IPsec/kernel mechanisms cannot trigger an IKE/IPsec negotiation and this protocol needs to be responsible for not just configuring IKEv2/IPsec but also for bringing up the tunnels when needed. - Section 3, step 6: - signaling IPsec configuration Call it IPsec provisioning ? - Examples are using less prefered and slower algorithms * Change AES-CBC-256 with SHA-384. to AES-GCM-256 or CHACHA20_POLY1305 * Change NULL-SHA256 to NULL-AES-GMAC - 1/128 and 2/128 ? For 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), these NLRI has embedded label, which cause the payload packet can't be encapsulated in ESP packet, I don't understand why 1/128 or 2/128 are special ? Open questions: - If the IKEv2 protocol fails, what happens with packets? Release in clear or drop? Is this something the BGP should configure/provision ? If not, it should state which of the two is expected - If a router R1 and R2 have an ipsec tunnel for some traffic, and R1 crashes/reboots, how do things recover? R2 will send packets and might not know something is wrong, unless it is configured for liveness. What happens when R1 comes back up? If all BGP routes are taken away via another mechanism, then I guess R2 would simply delete its tunnel. - Performance: if routes are large (eg 0/128) then very few tunnels would cover lots of routes. In general, having more parallel smaller CHILD SA's outperforms a single or two CHILD SA's by far. This could introduce performance issues. - Some IPsec options not mentioned could prevent a tunnel from being setup, such as whether to use Extended Sequence Numbers (ESN), or Perfect Forward Secrecry (PFS). Some of these could be locked down in the document (PFS=yes) but things like ESN really depend on the bandwidth of the tunnel. - Maybe some advise on replay-window size would be good. Larger is better but takes more memory. Matters mostly for highspeed links. Paul From nobody Thu Jul 25 07:54:06 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14CD12036C; Thu, 25 Jul 2019 07:53:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 fp0WbUiIWvTi; Thu, 25 Jul 2019 07:53:47 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id EEB2E120347; Thu, 25 Jul 2019 07:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 9161220CBA; Thu, 25 Jul 2019 16:53:43 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon41.um.es Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5GNvfvuixJmQ; Thu, 25 Jul 2019 16:53:43 +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 xenon41.um.es (Postfix) with ESMTPSA id F2E49206A4; Thu, 25 Jul 2019 16:53:40 +0200 (CEST) From: Rafa Marin Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_46A1369C-EFA7-4609-9A39-8B85BF5E5A6F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 25 Jul 2019 16:53:39 +0200 In-Reply-To: <041301d54141$c0bae090$4230a1b0$@gmail.com> Cc: Rafa Marin Lopez , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , i2nsf@ietf.org, Gabriel Lopez , Yoav Nir , "ipsec@ietf.org WG" To: Valery Smyslov References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <422BC608-F527-4BFF-A04F-B8FE42CA3169@um.es> <030c01d540a3$9e7a74d0$db6f5e70$@gmail.com> <031f01d540a7$96424820$c2c6d860$@gmail.com> <041301d54141$c0bae090$4230a1b0$@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 14:53:59 -0000 --Apple-Mail=_46A1369C-EFA7-4609-9A39-8B85BF5E5A6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery: Great!. Thanks for these comments. Very valuable. Following your = suggestion we would like to add similar text to part of the I-D = describing the process of IPsec SA installation. This is inline with the = previous text about rekeying we sent: "Figure 4 describes the IKE-less case, when a data packet needs to be protected in the path between the NSF A and NSF B: 1. The administrator establishes the flow-based security policies, and the Security Controller looks for the involved NSFs. 2. The Security Controller translates the flow-based security policies into IPsec SPD and SAD entries. 3. The Security Controller inserts these entries in both NSF A and NSF B IPsec databases (SPD and SAD). The following text describes how this happens between two NSFs A and B: * The Security Controller chooses two random values as SPIs: for example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers MUST not be in conflict with any IPsec SA in NSF A or NSF B. It also generates fresh cryptographic material for the new inbound/outbound IPsec SAs and their parameters and send simultaneously the new inbound IPsec SA with SPIa1 and new outbound IPsec SAs with SPIb1 to NSF A; and the new inbound IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 to B, together with the corresponding IPsec policies. * Once the Security Controller receives confirmation from NSF A and NSF B, the controller knows that the IPsec SAs are correctly installed and ready. If some of the operations described above fails (e.g. the NSF A reports an error when the Security Controller is trying to install the SPD entry, the new inbound and outbound IPsec SAs) the Security Controller must perform rollback operations by deleting any new inbound or outbound SA and SPD entry that had been successfully installed in any of the NSFs (e.g NSF B) and stop the process (NOTE: the Security Controller may retry several times before giving up). Other alternative to this operation is: the Security Controller sends first the IPsec policies and new inbound IPsec SAs to A and B and once it obtains a successful confirmation of these operations from NSF A and NSF B, it proceeds with installing to the new outbound IPsec SAs. However, this may increase the latency to complete the process. As an advantage, no traffic is sent over the network until the IPsec SAs are completely operative. In any case other alternatives may be possible. Finally, it is worth mentioning that the Security Controller associates a lifetime to the new IPsec SAs. When this lifetime expires, the NSF will send a sadb-expire notification to the Security Controller in order to start the rekeying process. 4. The flow is protected with the IPsec SA established by the Security Controller. =E2=80=9C We have also clarified proactive and reactive and the operations = associated in a text below "Instead of installing IPsec policies in the SPD and IPsec SAs in the SAD in step 3 (proactive mode), it is also possible that the Security Controller only installs the SPD entries in step 3 (reactive mode). In such a case, when a data packet requires to be protected with IPsec, the NSF that saw first the data packet will send a sadb-acquire notification that informs the Security Controller that needs SAD entries with the IPsec SAs to process the data packet. In such as reactive mode, since IPsec policies are already installed in the SPD, the Security Controller installs first the new IPsec SAs in NSF A and B with the operations described in step 3 but without sending any IPsec policies. Again, if some of the operations installing=20 the new inbound/outbound IPsec SAs fail,=20 the Security Controller stops the process and performs a rollback operation by deleting any new inbound/outbound SAs =09 that had been successfully installed.=E2=80=9D We hope this text also helps. Thank you very much again. > El 23 jul 2019, a las 12:31, Valery Smyslov = escribi=C3=B3: >=20 > Hi Rafa, > =20 > =20 > Hi Valery: >=20 >=20 >> El 22 jul 2019, a las 18:07, Valery Smyslov > escribi=C3=B3: >> =20 >> Hi Yoav, >> =20 >> I think that it is not the performance of the SC that would matter, >> but the possible delays in the network. If we think of the network >> connecting the SC and the NSFs as of one close to "ideal", then we = have >> no problems. Otherwise the SC must be prepared to deal with=20 >> network issues. Note, that in case of reactive SA setup and in case >> of rekeying the SC must manage two NSFs in a synchronized manner, >> and any of these NSF can go offline or reboot or stop responding >> during this, and SC must properly deal with all this events, >> making proper roll-back on the other NSF. > =20 > Regarding this: steps 1, 2 and 3 in section 5.3.1 are lock-step. As = you may see we mention:=20 > =20 > "Once the Security Controller receives confirmation from A and B, the = controller knows that the inbound=20 > IPsec A are correctly installed.=E2=80=9D > =20 > Having said this. Maybe this text after the description of steps 1, 2 = and 3 may help: > =20 > =E2=80=9CIf some of the operations in step 1 fails (e.g. the NSF1 = reports an error when the Security Controller is trying to install anew = new inbound IPsec SA) the Security Controller must perform rollback = operations by removing any new inbound SA that had been successfully = installed during step 1.=20 > =20 > If step 1 is successful but some of the operations in step 2 fails = (e.g. the NSF1 reports an error when the Security Controller is trying = to install the new outbound IPsec SA), the Security Controller must = perform a rollback operation by deleting any new outbound SA that had = been successfully installed during step 2 and by deleting the inbound = SAs created in step 1.=20 > =20 > If the steps 1 an 2 are successful and the step 3 fails the Security = Controller will avoid any rollback of the operations carried out in step = 1 and step 2 since new and valid IPsec SAs were created and are = functional. The Security Controller may reattempt to remove the old = inbound and outbound SAs in NSF1 and NSF2 several times until it = receives a success or it gives up. In the last case, the old IPsec SAs = will be removed when the hard lifetime is reached."=20 > =20 > Yes, this text would help. > =20 > Thank you, > Valery. > =20 > Btw, you can also find some text about NSF state loss in section = 5.3.2.=20 >=20 >=20 >> =20 >> With IKE case RFC7296 contains very specific advices what >> to do in case of packet loss, delay etc (e.g in case of=20 >> simultaneous rekeying). I'd like to see the same advices >> for SC's behavior in case of network issues. >> =20 >> Regards, >> Valery. >> =20 >> =20 >> =20 >> =20 >> Hi, Valery >> =20 >> Obviously, you need a security controller that scales to the number = of SAs it needs to generate. But generating an SA in the IKE-less case = is just generating 72 random bytes (for AES-GCM-256) and packaging them. = I don=E2=80=99t think with a properly scaled SC this would produce more = latency than IKE between the nodes, which has 1/2 round-trips and = requires asymmetric operations. >> =20 >>=20 >>=20 >>=20 >>> On 22 Jul 2019, at 11:39, Valery Smyslov > wrote: >>> =20 >>> Hi Rafa, >>> =20 >>> sure this problem is general for any SDN solution. >>> My point was that if SC performs a lot of real-time=20 >>> (or near real-time) tasks as it may happen in IKE-less case,=20 >>> then this problem may become serious. >>> =20 >>> Anyway, I'm happy with the updated text, thank you. >>> However, in a following document(s), suggested by Yoav, >>> I'd like to see more concrete advices of how SC should >>> act in this situation to ensure that the consistence of the=20 >>> network is preserved despite all the possible delays etc. >>> =20 >>> Regards, >>> Valery. >>> =20 >>> =20 >>> From: Rafa Marin Lopez >=20 >>> Sent: Monday, July 22, 2019 6:11 PM >>> To: Valery Smyslov > >>> Cc: Rafa Marin Lopez >; Yoav Nir = >; i2nsf@ietf.org = ; ipsec@ietf.org ; = Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa = >; mbj@tail-f.com = ; Gabriel Lopez > >>> Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>> =20 >>> Hi Valery: >>> =20 >>> Thank you very much for your comments. Please see ours inside. >>>> El 20 jul 2019, a las 16:38, Valery Smyslov > escribi=C3=B3: >>>> =20 >>>> Hi, >>>> =20 >>>> thank you for updating the document. I still think that some aspect >>>> of IKE-less use case are not discussed yet (well, probably they are = not=20 >>>> "serious", depending on one's definition of "serious"). >>>> =20 >>>> Unlike IKE case. which we can consider as mostly static = configuration, >>>> the IKE-less case is a dynamic one. If IPsec SA are being created=20= >>>> on demand (via kernel-acquire) and the traffic volume is high, >>>> then depending on the IPsec policy IKE-less case can become=20 >>>> a highly dynamic, which implies additional requirement on both >>>> the network connecting SC and NSF and the performance of the = protocol used to=20 >>>> secure their communications. In other words, in IKE case the = communication >>>> between IKE daemon and kernel is seamless, while in IKE-less >>>> case the communication between NSF ("kernel") and SC adds >>>> noticeable delay (and can potentially add quite a long delay), >>>> which can influence total performance of the system. >>>> =20 >>>> Generally IKE-less case requires more communications between >>>> different nodes to establish or rekey IPsec SA, than IKE case >>>> (I assume that IKE SA is already established), that may have >>>> an impact on high-speed networks with short-lived IPsec SAs, >>>> especially if they are created per transport connection >>>> (say one IPsec SA for one TCP session). >>> =20 >>> [Authors] What you have just described is what happens in any = SDN-based network. In fact, your comment would be applicable to = practically any scenario based on the SDN paradigm. In the particular = case of the I-D, the IKE-less case is the most similar to case you can = see in, for example, Openflow networks where latency is also important = (just as an example : https://ieeexplore.ieee.org/document/6573052 = ) >>>=20 >>>=20 >>>=20 >>>=20 >>>> =20 >>>> I believe, that SC's task of managing IPsec SAs in IKE-less case=20 >>>> may become quite complex, especially because due to the >>>> additional delay, introduced by the network, the picture of the >>>> state of the SAs the SC has can become inaccurate (well,=20 >>>> it will always be inaccurate, but with short delays it doesn't = matter). >>>> Just an example. Consider an SC receives a signal from NSF that an = SA >>>> is soft expired and starts rekeying process by first installing a = new >>>> pair of inbound SAs. It successfully installs them on the NSF >>>> it receives notification from, but then it receives a notification >>>> that the other NSF has rebooted, so it must clear all the SAs on >>>> its peers, including the just installed new one (which is only >>>> half-done). There seems to be a lot of nuances, and the document=20 >>>> completely ignores them. Not that I think that the task >>>> is impossible, but the algorithm of managing the SAs can become >>>> quite complex and possibly unreliable. >>> =20 >>> [Authors] We largely thought about this kind of cases, although we = do not see any different that may happen in SDN-based network nowadays. = And it seems to me that SDN is becoming something generally accepted = despite the different nuances that needs to be consider. In any case, = what you mention is not ignored in our document because it is included = in the text we have in section 5.3 (see below) where we highlight the = complexity is shifted to the SC (that=E2=80=99s clear). But as I = mentioned, this is not specific to IKE-less case but for any solution = based on the pure SDN paradigm (such as Openflow networks). In other = words, the cases you well mention are applicable to any SDN-based = solution. >>>=20 >>>=20 >>>=20 >>>=20 >>>> =20 >>>> I didn't find this discussion in the draft (sorry if I missed it). >>> =20 >>> Your comments are somehow summarized in the following text section = 5.3 >>> =20 >>> "On the contrary, the overload of creating fresh IPsec >>> SAs is shifted to the Security Controller since IKEv2 is not in = the >>> NSF. As a consequence, this may result in a more complex >>> implementation in the controller side. This overload may create = some >>> scalability issues when the number of NSFs is high. >>>=20 >>> In general, literature around SDN-based network management using a >>> centralized Security Controller is aware about scalability issues = and >>> solutions have been already provided (e.g. hierarchical Security >>> Controllers; having multiple replicated Security Controllers, = etc)." >>> =20 >>> I would add that a high-speed dedicated management network between = the SC and the NSFs can be also in place to even limit reduce these = delays between the SC and NSFs (this idea comes again from Openflow = networks). Also the SC can select more =E2=80=9Cintelligent=E2=80=9D = lifetime to orchestrate better when the notifications may appear. >>> =20 >>> In any case, we think we can improve that text as follows:=20 >>> =20 >>> "On the contrary, the overload of creating and managing IPsec >>> SAs is shifted to the Security Controller since IKEv2 is not in = the >>> NSF. As a consequence, this may result in a more complex >>> implementation in the controller side in comparison with >>> IKE case. For example, the Security Controller have to deal with=20= >>> the latency existing in the path between the Security Controller=20= >>> and the NSF in order to solve tasks such as, rekey or creation = and=20 >>> installation of new IPsec SAs. However, this is not specific to = our=20 >>> contribution but a general aspect in any SDN-based network.=20 >>> In summary, this overload may create some scalability and = performance=20 >>> issues when the number of NSFs is high. >>>=20 >>> Nevertheless, literature around SDN-based network management = using a >>> centralized Security Controller is aware about scalability and >>> performance issues and solutions have been already provided and >>> discussed (e.g. hierarchical Security Controllers; having = multiple >>> replicated Security Controllers, dedicated high-speed management >>> networks, etc). In the context of SDN-based IPsec management, one >>> way to reduce the latency and alleviate some performance issues = can >>> be the installation of the IPsec policies and IPsec SAs at the = same time >>> (proactive mode, as described in Section 7.1) instead of waiting = for >>> notifications (e.g. a notification sadb-acquire when a new IPsec = SA=20 >>> is required) to proceed with the IPsec SA installations (reactive = mode).=20 >>> Another way to reduce the overhead and the potential scalability = and >>> performance issues in the Security Controller is to apply the IKE >>> case described in this document, since the IPsec SAs are managed >>> between NSFs without the involvement of the Security Controller = at >>> all, except by the initial IKE configuration provided by the = Security >>> Controller.=E2=80=9D >>> =20 >>> Please see also our comments to Yoav. >>> =20 >>> Best Regards. >>>=20 >>>=20 >>>=20 >>>=20 >>>> =20 >>>> Regards, >>>> Valery. >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> Thanks for getting this done and published. >>>> =20 >>>> We will wait with requesting publication until the I2NSF session = next week. Between now and then, please re-read the draft and send a = message to the list is something is seriously wrong. >>>> =20 >>>> Barring any such shouting, we will request publication right after = the meeting. >>>> =20 >>>> Thanks again, >>>> =20 >>>> Linda and Yoav >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez > wrote: >>>>> =20 >>>>> Dear all: >>>>>=20 >>>>> We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 >>>>>=20 >>>>> - We have dealt with YANG doctors=E2=80=99 review (Martin's) >>>>>=20 >>>>> - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99= s comments. >>>>> =20 >>>>> - We have added more specific text in the descriptions. >>>>>=20 >>>>> - Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller. >>>>>=20 >>>>> - State data has been reduced. For example, in IKE case, most of = the information is related with IKE and not with the specific details = about IPsec SAs that IKE handles (after all, IKE can abstract this = information from the Security Controller). >>>>> =20 >>>>> - We have included text in the security section to discuss about = the default IPsec policies that should be in the NSF when it starts = before contacting with the SC such as the IPsec policies required to = allow traffic between the SC and the NSF. >>>>> =20 >>>>> - We have added a subsection 5.3.4 about NSF discovery by the = Security Controller. >>>>>=20 >>>>> - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: >>>>>=20 >>>>> typedef encryption-algorithm-type { >>>>> type uint32; >>>>> description=20 >>>>> "The encryption algorithm is specified with a = 32-bit >>>>> number extracted from IANA Registry. The acceptable >>>>> values MUST follow the requirement levels for >>>>> encryption algorithms for ESP and IKEv2."; >>>>> reference=20 >>>>> "IANA Registry- Transform Type 1 - Encryption >>>>> Algorithm Transform IDs. RFC 8221 - Cryptographic >>>>> Algorithm Implementation Requirements and Usage >>>>> Guidance for Encapsulating Security Payload (ESP) >>>>> and Authentication Header (AH) and RFC 8247 - >>>>> Algorithm Implementation Requirements and Usage >>>>> Guidance for the Internet Key Exchange Protocol >>>>> Version 2 (IKEv2)."; >>>>> } >>>>> =20 >>>>> - We have included three additional Annexes with examples in about = the usage of the YANG model. >>>>> =20 >>>>> - We have performed pyang --lint --lint-ensure-hyphenated-names = and pyang -f yang --yang-line-length 69 in our model without warnings. >>>>> =20 >>>>> Best Regards. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Inicio del mensaje reenviado: >>>>>> =20 >>>>>> De: internet-drafts@ietf.org >>>>>> Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>>>> Fecha: 7 de julio de 2019, 23:34:03 CEST >>>>>> Para: > >>>>>> Cc: i2nsf@ietf.org >>>>>> Responder a: i2nsf@ietf.org >>>>>> =20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>> This draft is a work item of the Interface to Network Security = Functions WG of the IETF. >>>>>>=20 >>>>>> Title : Software-Defined Networking (SDN)-based = IPsec Flow Protection >>>>>> Authors : Rafa Marin-Lopez >>>>>> Gabriel Lopez-Millan >>>>>> Fernando Pereniguez-Garcia >>>>>> Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt >>>>>> Pages : 81 >>>>>> Date : 2019-07-07 >>>>>>=20 >>>>>> Abstract: >>>>>> This document describes how providing IPsec-based flow = protection by >>>>>> means of a Software-Defined Network (SDN) controller (aka. = Security >>>>>> Controller) and establishes the requirements to support this = service. >>>>>> It considers two main well-known scenarios in IPsec: (i) = gateway-to- >>>>>> gateway and (ii) host-to-host. The SDN-based service described = in >>>>>> this document allows the distribution and monitoring of IPsec >>>>>> information from a Security Controller to one or several = flow-based >>>>>> Network Security Function (NSF). The NSFs implement IPsec to = protect >>>>>> data traffic between network resources. >>>>>>=20 >>>>>> The document focuses on the NSF Facing Interface by providing = models >>>>>> for configuration and state data required to allow the Security >>>>>> Controller to configure the IPsec databases (SPD, SAD, PAD) and = IKEv2 >>>>>> to establish Security Associations with a reduced intervention = of the >>>>>> network administrator. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ = >>>>>>=20 >>>>>> There are also htmlized versions available at: >>>>>> = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 = >>>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection-05 = >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-05 = >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of = submission >>>>>> until the htmlized version and diff are available at = tools.ietf.org . >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ = >>>>>>=20 >>>>>> _______________________________________________ >>>>>> I2nsf mailing list >>>>>> I2nsf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2nsf = >>>>> =20 >>>>> ------------------------------------------------------- >>>>> 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:=C2=A0rafa@um.es = >>>>> ------------------------------------------------------- >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> _______________________________________________ >>>>> I2nsf mailing list >>>>> I2nsf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2nsf = > =20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf --Apple-Mail=_46A1369C-EFA7-4609-9A39-8B85BF5E5A6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Valery:

Great!. = Thanks for these comments. Very valuable. Following your suggestion we = would like to add similar text to part of the I-D describing the process = of IPsec SA installation. This is inline with the previous text about = rekeying we sent:


"Figure 4 describes the = IKE-less case, when a data packet needs to be
protected in the path between the NSF A and NSF B:

   1. =  The administrator establishes the flow-based security = policies,
       and the = Security Controller looks for the involved NSFs.

   2.  The Security = Controller translates the flow-based security
  =      policies into IPsec SPD and SAD entries.

   3. =  The Security Controller inserts these entries in both NSF A = and
       NSF B IPsec = databases (SPD and SAD).  The following = text
      =  describes how this happens between two NSFs A and B:

       *  The Security Controller = chooses two random values as SPIs: for
          example, SPIa1 for NSF A = and SPIb1 for NSF B.  These numbers
          MUST not be in conflict = with any IPsec SA in NSF A or NSF B.
          It also generates fresh = cryptographic material for the new
          inbound/outbound IPsec SAs = and their parameters and send
          simultaneously the new = inbound IPsec SA with SPIa1 and new
          outbound IPsec SAs with = SPIb1 to NSF A; and the new inbound
          IPsec SA with SPIb1 and = new outbound IPsec SAs with SPIa1 to
          B, together with the = corresponding IPsec policies.

      =  *  Once the Security Controller receives confirmation from = NSF A
        =   and NSF B, the controller knows that the IPsec SAs = are
        =   correctly installed and ready.

  =      If some of the operations described above fails = (e.g. the NSF A
    =    reports an error when the Security Controller is trying = to
      =  install the SPD entry, the new inbound and outbound IPsec = SAs)
      =  the Security Controller must perform rollback operations = by
      =  deleting any new inbound or outbound SA and SPD entry that = had
      =  been successfully installed in any of the NSFs (e.g NSF B) = and
      =  stop the process (NOTE: the Security Controller may retry = several
      =  times before giving up).  Other alternative to this operation = is:
      =  the Security Controller sends first the IPsec policies and = new
      =  inbound IPsec SAs to A and B and once it obtains a = successful
      =  confirmation of these operations from NSF A and NSF B, = it
      =  proceeds with installing to the new outbound IPsec SAs. =  However,
    =    this may increase the latency to complete the process. =  As an
      =  advantage, no traffic is sent over the network until the = IPsec
      =  SAs are completely operative.  In any case other alternatives = may
       be = possible.  Finally, it is worth mentioning that the = Security
      =  Controller associates a lifetime to the new IPsec SAs.  When = this
      =  lifetime expires, the NSF will send a sadb-expire notification = to
       the = Security Controller in order to start the rekeying = process.

   4.  The flow is protected with the IPsec SA = established by the
      =  Security Controller.
=E2=80=9C

We have also clarified proactive = and reactive and the operations associated in a text below

"Instead of installing = IPsec policies in the SPD and IPsec
SAs in the SAD = in step 3 (proactive mode), it is also
possible = that the Security Controller only installs the SPD
entries in step 3 (reactive mode). In such a case, when = a
data packet requires to be protected with IPsec, = the NSF
that saw first the data packet will send a = sadb-acquire
notification that informs the Security = Controller that needs
SAD entries with the IPsec = SAs to process the data
packet. In such as reactive = mode, since IPsec policies are
already installed in = the SPD, the Security Controller
installs first the = new IPsec SAs in NSF A and B with the
operations = described in step 3 but without sending any IPsec
policies. Again, if some of the operations = installing 
the new inbound/outbound IPsec SAs = fail, 
the Security Controller stops the = process and performs a
rollback operation by = deleting any new inbound/outbound SAs
that = had been successfully installed.=E2=80=9D

We hope this text also helps.

Thank you very much = again.

El 23 jul 2019, a las 12:31, Valery Smyslov = <smyslov.ietf@gmail.com> escribi=C3=B3:

Hi Rafa,
 
 
Hi Valery:


El 22 jul 2019, a las 18:07, Valery = Smyslov <smyslov.ietf@gmail.com> escribi=C3=B3:
 
Hi Yoav,
 
I think that it is not the = performance of the SC that would matter,
but = the possible delays in the network. If we think of the = network
connecting the SC and the NSFs as of one close to = "ideal", then we have
no problems. Otherwise the SC must = be prepared to deal with 
network issues. Note, that in case of reactive SA setup and = in case
of rekeying the SC must manage two NSFs in a = synchronized manner,
and any of these NSF can go = offline or reboot or stop responding
during this, and SC must properly deal with all this = events,
making proper roll-back on the other NSF.
 
Regarding this: steps 1, 2 and 3 in section 5.3.1 are = lock-step. As you may see we mention: 
 
"Once the Security = Controller receives confirmation from A and B, the controller knows = that the inbound 
IPsec A are correctly = installed.=E2=80=9D
 
Having said this. Maybe this text after the description of = steps 1, 2 and 3 may help:
 
=E2=80=9CIf some of the operations in step 1 fails = (e.g. the NSF1 reports an error when the Security Controller is = trying to install anew new inbound IPsec SA) the Security = Controller must perform rollback operations by removing any new = inbound SA that had been successfully installed during step 1. 
 
If step 1 is successful but some of the = operations in step 2 fails (e.g. the NSF1 reports an error when the = Security Controller is trying to install the new outbound IPsec SA), = the Security Controller must perform a rollback operation by = deleting any new outbound SA that had been successfully installed during = step 2 and by deleting the inbound SAs created in step 1. 
 
If the steps 1 an 2 are successful and = the step 3 fails the Security Controller will avoid any = rollback of the operations carried out in step 1 and step 2 since new = and valid IPsec SAs were created and are functional. The Security = Controller may reattempt to remove the old inbound and outbound SAs = in NSF1 and NSF2 several times until it receives a success or it gives = up. In the last case, the old IPsec SAs will be removed when the hard = lifetime is reached." 
 
          Yes, this text would help.
 
          Thank = you,
          = Valery.
 
Btw, you can also find some text about = NSF state loss in section 5.3.2. 


 
With IKE case RFC7296 contains = very specific advices what
to do in case of packet loss, = delay etc (e.g in case of 
simultaneous rekeying). I'd like to see the same = advices
for SC's behavior in case of network = issues.
 
Regards,
Valery.
 
 
 
 
Hi, Valery
 
Obviously, you need a security = controller that scales to the number of SAs it needs to generate. But = generating an SA in the IKE-less case is just generating 72 random bytes = (for AES-GCM-256) and packaging them.  I don=E2=80=99t think with a = properly scaled SC this would produce more latency than IKE between the = nodes, which has 1/2 round-trips and requires asymmetric operations.
 



On 22 Jul 2019, at 11:39, Valery Smyslov <smyslov.ietf@gmail.com> wrote:
 
Hi Rafa,
 
sure this problem is general for any SDN = solution.
My point was that = if SC performs a lot of real-time 
(or near real-time) tasks as it may happen in IKE-less = case, 
then this problem may become serious.
 
Anyway, I'm happy with the updated text, thank = you.
However, in a following = document(s), suggested by Yoav,
I'd like to see more concrete advices of how SC = should
act in this situation to ensure = that the consistence of the 
network is preserved despite all the possible delays = etc.
 
Regards,
Valery.
 
 
From: Rafa = Marin Lopez <rafa@um.es> 
Sent: Monday, July 22, 2019 6:11 = PM
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: Rafa = Marin Lopez <rafa@um.es>; Yoav Nir <ynir.ietf@gmail.com>; i2nsf@ietf.org; ipsec@ietf.org; Fernando Pere=C3=B1=C3=ADguez = Garc=C3=ADa <fernando.pereniguez@cud.upct.es>; mbj@tail-f.com; Gabriel Lopez <gabilm@um.es>
Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
 
Hi Valery:
 
Thank you = very much for your comments. Please see ours inside.
El 20 jul 2019, a las 16:38, Valery = Smyslov <smyslov.ietf@gmail.com> escribi=C3=B3:
 
Hi,
 
thank you for = updating the document. I still think that some aspect
of IKE-less use = case are not discussed yet (well, probably they are not 
"serious", = depending on one's definition of "serious").
 
Unlike IKE case. = which we can consider as mostly static configuration,
the IKE-less case = is a dynamic one. If IPsec SA are being created 
on demand (via = kernel-acquire) and the traffic volume is high,
then depending on = the IPsec policy IKE-less case can become 
a highly dynamic, = which implies additional requirement on both
the network = connecting SC and NSF and the performance of the protocol used to 
secure their = communications. In other words, in IKE case the communication
between IKE daemon = and kernel is seamless, while in IKE-less
case the = communication between NSF ("kernel") and SC adds
noticeable delay = (and can potentially add quite a long delay),
which can influence = total performance of the system.
 
Generally IKE-less = case requires more communications between
different nodes to = establish or rekey IPsec SA, than IKE case
(I assume that IKE = SA is already established), that may have
an impact on = high-speed networks with short-lived IPsec SAs,
especially if they = are created per transport connection
(say one IPsec SA = for one TCP session).
 
[Authors] What you have just described is what happens in any = SDN-based network. In fact, your comment would be applicable to = practically any scenario based on the SDN paradigm. In the particular = case of the I-D, the IKE-less case is the most similar to case you can = see in, for example, Openflow networks where latency is also important = (just as an example : https://ieeexplore.ieee.org/document/6573052 )




 
I = believe, that SC's task of managing IPsec SAs in IKE-less case 
may become quite = complex, especially because due to the
additional delay, = introduced by the network, the picture of the
state of the SAs = the SC has can become inaccurate (well, 
it will always be = inaccurate, but with short delays it doesn't matter).
Just an example. = Consider an SC receives a signal from NSF that an SA
is soft expired and = starts rekeying process by first installing a new
pair of inbound = SAs. It successfully installs them on the NSF
it receives = notification from, but then it receives a notification
that the other NSF = has rebooted, so it must clear all the SAs on
its peers, = including the just installed new one (which is only
half-done). There = seems to be a lot of nuances, and the document 
completely ignores = them. Not that I think that the task
is impossible, but = the algorithm of managing the SAs can become
quite complex and = possibly unreliable.
 
[Authors] We largely thought about this kind of cases, = although we do not see any different that may happen in SDN-based = network nowadays. And it seems to me that SDN is becoming something = generally accepted despite the different nuances that needs to be = consider. In any case, what you mention is not ignored in our document = because it is included in the text we have in section 5.3 (see below) = where we highlight the complexity is shifted to the SC (that=E2=80=99s = clear). But as I mentioned, this is not specific to IKE-less case but = for any solution based on the pure SDN paradigm (such as Openflow = networks). In other words, the cases you well mention are applicable to = any SDN-based solution.




 
I = didn't find this discussion in the draft (sorry if I missed = it).
 
Your comments are somehow summarized in the following text = section 5.3
 

"On the = contrary, the overload of creating fresh IPsec
  =  SAs is shifted to the Security Controller since IKEv2 is not in = the
   NSF.  As a consequence, this may = result in a more complex
  =  implementation in the controller side. =  This overload may create some
  =  scalability issues when the number of NSFs is high.

In general, literature around SDN-based = network management using a
  =  centralized Security Controller is aware about scalability issues = and
  =  solutions have been already provided (e.g. hierarchical = Security
  =  Controllers; having multiple replicated Security Controllers, = etc)."
 
I would = add that a high-speed dedicated management network between the SC and = the NSFs can be also in place to even limit reduce these delays between = the SC and NSFs (this idea comes again from Openflow networks). Also the = SC can select more =E2=80=9Cintelligent=E2=80=9D lifetime to orchestrate = better when the notifications may appear.
 
In any = case, we think we can improve that text as follows: 
 
"On the = contrary, the overload of creating and managing IPsec
   SAs is = shifted to the Security Controller since IKEv2 is not in the
   NSF. As a consequence, this may result in a more = complex
   implementation in the controller side = in comparison with
   IKE case.  For example, the = Security Controller have to deal with 
  =  the latency existing in the path between the Security = Controller 
   and the NSF in order to solve tasks such = as, rekey or creation and 
  =  installation of new IPsec SAs. However, this is not specific to = our 
   contribution but a general aspect in any = SDN-based network. 
   In summary, this overload may create some = scalability and performance 
  =  issues when the number of NSFs is high.

   Nevertheless, literature around SDN-based = network management using a
   centralized = Security Controller is aware about scalability and
  =  performance issues and solutions have been already provided and
   discussed (e.g.  hierarchical Security = Controllers; having multiple
   replicated = Security Controllers, dedicated high-speed management
 =  networks, etc). In the context of SDN-based IPsec management, = one
  =  way to reduce the latency and alleviate some performance issues = can
  =  be the installation of the IPsec policies and IPsec SAs at the = same time
   (proactive mode, as described in Section 7.1) = instead of waiting for
   notifications (e.g. a notification sadb-acquire = when a new IPsec SA 
  =  is required) to proceed with the IPsec SA installations (reactive = mode). 
   Another way to reduce the overhead and the = potential scalability and
  =  performance issues in the Security Controller is to apply the = IKE
   case described in this document, since = the IPsec SAs are managed
   between NSFs = without the involvement of the Security Controller at
 =  all, except by the initial IKE configuration provided by the = Security
   Controller.=E2=80=9D
 
Please = see also our comments to Yoav.
 
Best Regards.




 
Regards,
Valery.
 
 
 
 
Thanks for getting this done and published.
 
We will wait with requesting publication until the I2NSF = session next week.  Between now and then, please re-read the draft = and send a message to the list is something is seriously wrong.
 
Barring any such shouting, we will = request publication right after the meeting.
 
Thanks again,
 
Linda and Yoav




On 16 Jul 2019, at 15:42, = Rafa Marin-Lopez <rafa@um.es> wrote:
 
Dear all:

We= submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation: 

- We have dealt with YANG doctors=E2=80=99 = review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.
 
-= We have added more specific text in the descriptions.

- Notifications have a simpler format now since most of the = information that contained in the past is already handled by the = Security Controller.

- State data has been = reduced. For example, in IKE case, most of the information is related = with IKE and not with the specific details about IPsec SAs that IKE = handles (after all, IKE can abstract this information from the Security = Controller).
 
-= We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF.
 
- We have added a subsection 5.3.4 = about NSF discovery by the Security Controller.

- In order to specify the crypto-algorithms we have used a = simple approach by including an integer and adding a text pointing the = IANA in the reference clause. For = example:

typedef = encryption-algorithm-type {
          &nb= sp;type uint32;
          &nb= sp;description 
          &nb= sp;    "The encryption algorithm is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          &nb= sp;    values MUST follow the requirement levels = for
          &nb= sp;    encryption algorithms for ESP and IKEv2.";
          &nb= sp;reference 
          &nb= sp;     "IANA Registry- Transform Type 1 - = Encryption
          &nb= sp;     Algorithm Transform IDs. RFC 8221 - = Cryptographic
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for Encapsulating Security = Payload (ESP)
          &nb= sp;     and Authentication Header (AH) and RFC = 8247 -
          &nb= sp;     Algorithm Implementation Requirements = and Usage
          &nb= sp;     Guidance for the Internet Key Exchange = Protocol
          &nb= sp;     Version 2 (IKEv2).";
       }
 
- We have included three additional = Annexes with examples in about the usage of the YANG model.
 
- We have performed pyang --lint = --lint-ensure-hyphenated-names and pyang -f yang --yang-line-length 69 = in our model without warnings.
 
Best Regards.




Inicio del mensaje = reenviado:
 
De: internet-drafts@ietf.org
Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
Fecha: 7 de julio de = 2019, 23:34:03 CEST
Responder a: i2nsf@ietf.org
 

A New Internet-Draft is = available from the on-line Internet-Drafts directories.
This= draft is a work item of the Interface to Network Security Functions WG = of the IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow Protection
       Authors =         : Rafa Marin-Lopez
          &nb= sp;            = ;  Gabriel Lopez-Millan
          &nb= sp;            = ;  Fernando Pereniguez-Garcia
        &= nbsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &= nbsp;  Pages=           : 81
        &= nbsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how providing IPsec-based = flow protection by
  means of a Software-Defined = Network (SDN) controller (aka.  Security
  Controller) and establishes the requirements to = support this service.
  It considers two main = well-known scenarios in IPsec: (i) gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document = allows the distribution and monitoring of IPsec
  information from a Security Controller to one or = several flow-based
  Network Security Function = (NSF).  The NSFs implement IPsec to protect
  data traffic between network resources.

  The document focuses on the NSF = Facing Interface by providing models
  for = configuration and state data required to allow the Security
  Controller to configure the IPsec databases (SPD, = SAD, PAD) and IKEv2
  to establish Security = Associations with a reduced intervention of the
  network administrator.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/

There are also = htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection-05

A diff from = the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-05


Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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
-------------------------------------------------------<= o:p class=3D"">
 
 
 
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
 
_______________________________________________
I2nsf mailing = list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
= --Apple-Mail=_46A1369C-EFA7-4609-9A39-8B85BF5E5A6F-- From nobody Thu Jul 25 09:00:09 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26216120345; Thu, 25 Jul 2019 09:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nf2iuWM7hoIX; Thu, 25 Jul 2019 08:59:54 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4953812033D; Thu, 25 Jul 2019 08:59:49 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id s22so36833023qkj.12; Thu, 25 Jul 2019 08:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=VxwhmDCJXLHbSCgbYhtVP6hyn8cDVfIm+y727l9QtTI=; b=fKGn4pLVKV5VpKZZaREpv+nynh7MeLneiSsAHYzQst2g3Sh0SvMrOjAFOHw4SzOvbR IkO4DNgOxcLhsxZqLL8CNEcvc+MuaLYtgmS6f6fNBAksBFdD77RxdCYUAABKZ/6xqvwo cajS75wG1s3gvA4g6aRaRdhcPfLuZ1bGFEcr2CeWQPNav8pL7ZYrgT+BpQGTkKv3A2zZ 0zfJzJ0274KH5nNJJDaGZI1YDMR3l8pYFwm7Pzv+TD+Ed75luz2rp34hcFFP0eyodmJ2 ypF+mZ36qExqT/XxwgpFjOomZnQ0iudFNV/CKzXQDPBVF9QuLGD8oOIojpp0M7rNDjgS kiFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=VxwhmDCJXLHbSCgbYhtVP6hyn8cDVfIm+y727l9QtTI=; b=t+IMtqndwA1/3194vDhegI9DtBLK8RYAj9HBMVX/y7yx4rmfAXMJnKRqTC67t2bBxU Uj63gHLEdqsvGfl8X2I53On05DSoA0XwH4ScJddwGB/NhG5iAd4iMpl7pFdwShA4c621 KwfBQ0DiOXP2zlZHnMP5GwBvzYcLl8L0J/H8Rt51wgGuZIOTtdGTM20ZGcUVKR9TUN0Y +lO5dvoEX89IMtHReGs+xH+Fp7GUy07V8fMjktW3sFiCRz/ChyhQHZHDzBAmz85ZveE9 3pyS73g1nlwE0d6Z1Ik3QJjYyZopDQiVut7MqF9tmDNOWkiVU9d5jMdMxR7ceqo5VSsf 1oTA== X-Gm-Message-State: APjAAAXwd+wa9t3nlZ0A9i6U4YWDLBj6CSsLGbX2afuzTCHpUklz6dgz Oc030/cUFcPN3ogxJ7P2L1A= X-Google-Smtp-Source: APXvYqxz7ahVq1p5Y8dCCZ3FfrDnrXwEoi2BURPbhoQdJnMuixqeGE0lPmDHpZoiwB2ElEu5SPTnyg== X-Received: by 2002:ae9:ed4b:: with SMTP id c72mr55322828qkg.404.1564070388175; Thu, 25 Jul 2019 08:59:48 -0700 (PDT) Received: from svannotebook ([2001:67c:370:128:ddac:81c8:e980:82e6]) by smtp.gmail.com with ESMTPSA id r5sm22310402qkc.42.2019.07.25.08.59.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 08:59:47 -0700 (PDT) From: "Valery Smyslov" To: "'Rafa Marin Lopez'" Cc: =?utf-8?Q?'Fernando_Pere=C3=B1=C3=ADguez_Garc=C3=ADa'?= , =?utf-8?Q?'Martin_Bj=C3=B6rklund'?= , , "'Gabriel Lopez'" , "'Yoav Nir'" , References: <156253524318.473.14686910090362577746@ietfa.amsl.com> <4E36A715-3B6C-4BDF-A149-9E10574E3F96@um.es> <5758F23C-087D-49AB-87E0-FE7E0F6D15A1@gmail.com> <016c01d53f08$e0c2d1d0$a2487570$@gmail.com> <422BC608-F527-4BFF-A04F-B8FE42CA3169@um.es> <030c01d540a3$9e7a74d0$db6f5e70$@gmail.com> <031f01d540a7$96424820$c2c6d860$@gmail.com> <041301d54141$c0bae090$4230a1b0$@gmail.com> In-Reply-To: Date: Thu, 25 Jul 2019 18:59:45 +0300 Message-ID: <01d401d54301$fb50ea30$f1f2be90$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D5_01D5431B.20AB8FB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHCFNK4T/q9sOv9UIwCeVdICbA12QI+UTb7AODQKd0B9E5Q0QGsr2TdAnMulMEBTsRs2AIsVOg+AejEzsoBofPMzgHNPlmZpnGmBpA= Content-Language: ru Archived-At: Subject: Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 16:00:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D5_01D5431B.20AB8FB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Rafa, =20 thank you for adding this text. I think these are the very minimum recommendations that are needed to help implementers to handle various=20 error cases correctly. =20 Regards, Valery. =20 From: Rafa Marin Lopez =20 Sent: Thursday, July 25, 2019 5:54 PM To: Valery Smyslov Cc: Rafa Marin Lopez ; Fernando Pere=C3=B1=C3=ADguez = Garc=C3=ADa ; Martin Bj=C3=B6rklund = ; i2nsf@ietf.org; Gabriel Lopez ; Yoav Nir = ; ipsec@ietf.org WG Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt =20 Hi Valery: =20 Great!. Thanks for these comments. Very valuable. Following your = suggestion we would like to add similar text to part of the I-D = describing the process of IPsec SA installation. This is inline with the = previous text about rekeying we sent: =20 =20 "Figure 4 describes the IKE-less case, when a data packet needs to be protected in the path between the NSF A and NSF B: =20 1. The administrator establishes the flow-based security policies, and the Security Controller looks for the involved NSFs. =20 2. The Security Controller translates the flow-based security policies into IPsec SPD and SAD entries. =20 3. The Security Controller inserts these entries in both NSF A and NSF B IPsec databases (SPD and SAD). The following text describes how this happens between two NSFs A and B: =20 * The Security Controller chooses two random values as SPIs: for example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers MUST not be in conflict with any IPsec SA in NSF A or NSF B. It also generates fresh cryptographic material for the new inbound/outbound IPsec SAs and their parameters and send simultaneously the new inbound IPsec SA with SPIa1 and new outbound IPsec SAs with SPIb1 to NSF A; and the new inbound IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 to B, together with the corresponding IPsec policies. =20 * Once the Security Controller receives confirmation from NSF A and NSF B, the controller knows that the IPsec SAs are correctly installed and ready. =20 If some of the operations described above fails (e.g. the NSF A reports an error when the Security Controller is trying to install the SPD entry, the new inbound and outbound IPsec SAs) the Security Controller must perform rollback operations by deleting any new inbound or outbound SA and SPD entry that had been successfully installed in any of the NSFs (e.g NSF B) and stop the process (NOTE: the Security Controller may retry several times before giving up). Other alternative to this operation is: the Security Controller sends first the IPsec policies and new inbound IPsec SAs to A and B and once it obtains a successful confirmation of these operations from NSF A and NSF B, it proceeds with installing to the new outbound IPsec SAs. However, this may increase the latency to complete the process. As an advantage, no traffic is sent over the network until the IPsec SAs are completely operative. In any case other alternatives may be possible. Finally, it is worth mentioning that the Security Controller associates a lifetime to the new IPsec SAs. When this lifetime expires, the NSF will send a sadb-expire notification to the Security Controller in order to start the rekeying process. =20 4. The flow is protected with the IPsec SA established by the Security Controller. =E2=80=9C =20 We have also clarified proactive and reactive and the operations = associated in a text below =20 "Instead of installing IPsec policies in the SPD and IPsec SAs in the SAD in step 3 (proactive mode), it is also possible that the Security Controller only installs the SPD entries in step 3 (reactive mode). In such a case, when a data packet requires to be protected with IPsec, the NSF that saw first the data packet will send a sadb-acquire notification that informs the Security Controller that needs SAD entries with the IPsec SAs to process the data packet. In such as reactive mode, since IPsec policies are already installed in the SPD, the Security Controller installs first the new IPsec SAs in NSF A and B with the operations described in step 3 but without sending any IPsec policies. Again, if some of the operations installing=20 the new inbound/outbound IPsec SAs fail,=20 the Security Controller stops the process and performs a rollback operation by deleting any new inbound/outbound SAs = =20 that had been successfully installed.=E2=80=9D =20 We hope this text also helps. =20 Thank you very much again. =20 El 23 jul 2019, a las 12:31, Valery Smyslov > escribi=C3=B3: =20 Hi Rafa, =20 =20 Hi Valery: El 22 jul 2019, a las 18:07, Valery Smyslov < = smyslov.ietf@gmail.com> escribi=C3=B3: =20 Hi Yoav, =20 I think that it is not the performance of the SC that would matter, but the possible delays in the network. If we think of the network connecting the SC and the NSFs as of one close to "ideal", then we have no problems. Otherwise the SC must be prepared to deal with=20 network issues. Note, that in case of reactive SA setup and in case of rekeying the SC must manage two NSFs in a synchronized manner, and any of these NSF can go offline or reboot or stop responding during this, and SC must properly deal with all this events, making proper roll-back on the other NSF. =20 Regarding this: steps 1, 2 and 3 in section 5.3.1 are lock-step. As you = may see we mention:=20 =20 "Once the Security Controller receives confirmation from A and B, the = controller knows that the inbound=20 IPsec A are correctly installed.=E2=80=9D =20 Having said this. Maybe this text after the description of steps 1, 2 = and 3 may help: =20 =E2=80=9CIf some of the operations in step 1 fails (e.g. the NSF1 = reports an error when the Security Controller is trying to install anew = new inbound IPsec SA) the Security Controller must perform rollback = operations by removing any new inbound SA that had been successfully = installed during step 1.=20 =20 If step 1 is successful but some of the operations in step 2 fails (e.g. = the NSF1 reports an error when the Security Controller is trying to = install the new outbound IPsec SA), the Security Controller must perform = a rollback operation by deleting any new outbound SA that had been = successfully installed during step 2 and by deleting the inbound SAs = created in step 1.=20 =20 If the steps 1 an 2 are successful and the step 3 fails the Security = Controller will avoid any rollback of the operations carried out in step = 1 and step 2 since new and valid IPsec SAs were created and are = functional. The Security Controller may reattempt to remove the old = inbound and outbound SAs in NSF1 and NSF2 several times until it = receives a success or it gives up. In the last case, the old IPsec SAs = will be removed when the hard lifetime is reached."=20 =20 Yes, this text would help. =20 Thank you, Valery. =20 Btw, you can also find some text about NSF state loss in section 5.3.2.=20 =20 With IKE case RFC7296 contains very specific advices what to do in case of packet loss, delay etc (e.g in case of=20 simultaneous rekeying). I'd like to see the same advices for SC's behavior in case of network issues. =20 Regards, Valery. =20 =20 =20 =20 Hi, Valery =20 Obviously, you need a security controller that scales to the number of = SAs it needs to generate. But generating an SA in the IKE-less case is = just generating 72 random bytes (for AES-GCM-256) and packaging them. I = don=E2=80=99t think with a properly scaled SC this would produce more = latency than IKE between the nodes, which has 1/2 round-trips and = requires asymmetric operations. =20 On 22 Jul 2019, at 11:39, Valery Smyslov < = smyslov.ietf@gmail.com> wrote: =20 Hi Rafa, =20 sure this problem is general for any SDN solution. My point was that if SC performs a lot of real-time=20 (or near real-time) tasks as it may happen in IKE-less case,=20 then this problem may become serious. =20 Anyway, I'm happy with the updated text, thank you. However, in a following document(s), suggested by Yoav, I'd like to see more concrete advices of how SC should act in this situation to ensure that the consistence of the=20 network is preserved despite all the possible delays etc. =20 Regards, Valery. =20 =20 From: Rafa Marin Lopez < rafa@um.es>=20 Sent: Monday, July 22, 2019 6:11 PM To: Valery Smyslov < = smyslov.ietf@gmail.com> Cc: Rafa Marin Lopez < rafa@um.es>; Yoav Nir < = ynir.ietf@gmail.com>; = i2nsf@ietf.org; = ipsec@ietf.org; Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa < = = fernando.pereniguez@cud.upct.es>; = mbj@tail-f.com; Gabriel Lopez < gabilm@um.es> Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt =20 Hi Valery: =20 Thank you very much for your comments. Please see ours inside. El 20 jul 2019, a las 16:38, Valery Smyslov < = smyslov.ietf@gmail.com> escribi=C3=B3: =20 Hi, =20 thank you for updating the document. I still think that some aspect of IKE-less use case are not discussed yet (well, probably they are not=20 "serious", depending on one's definition of "serious"). =20 Unlike IKE case. which we can consider as mostly static configuration, the IKE-less case is a dynamic one. If IPsec SA are being created=20 on demand (via kernel-acquire) and the traffic volume is high, then depending on the IPsec policy IKE-less case can become=20 a highly dynamic, which implies additional requirement on both the network connecting SC and NSF and the performance of the protocol = used to=20 secure their communications. In other words, in IKE case the = communication between IKE daemon and kernel is seamless, while in IKE-less case the communication between NSF ("kernel") and SC adds noticeable delay (and can potentially add quite a long delay), which can influence total performance of the system. =20 Generally IKE-less case requires more communications between different nodes to establish or rekey IPsec SA, than IKE case (I assume that IKE SA is already established), that may have an impact on high-speed networks with short-lived IPsec SAs, especially if they are created per transport connection (say one IPsec SA for one TCP session). =20 [Authors] What you have just described is what happens in any SDN-based = network. In fact, your comment would be applicable to practically any = scenario based on the SDN paradigm. In the particular case of the I-D, = the IKE-less case is the most similar to case you can see in, for = example, Openflow networks where latency is also important (just as an = example : = https://ieeexplore.ieee.org/document/6573052 ) =20 I believe, that SC's task of managing IPsec SAs in IKE-less case=20 may become quite complex, especially because due to the additional delay, introduced by the network, the picture of the state of the SAs the SC has can become inaccurate (well,=20 it will always be inaccurate, but with short delays it doesn't matter). Just an example. Consider an SC receives a signal from NSF that an SA is soft expired and starts rekeying process by first installing a new pair of inbound SAs. It successfully installs them on the NSF it receives notification from, but then it receives a notification that the other NSF has rebooted, so it must clear all the SAs on its peers, including the just installed new one (which is only half-done). There seems to be a lot of nuances, and the document=20 completely ignores them. Not that I think that the task is impossible, but the algorithm of managing the SAs can become quite complex and possibly unreliable. =20 [Authors] We largely thought about this kind of cases, although we do = not see any different that may happen in SDN-based network nowadays. And = it seems to me that SDN is becoming something generally accepted despite = the different nuances that needs to be consider. In any case, what you = mention is not ignored in our document because it is included in the = text we have in section 5.3 (see below) where we highlight the = complexity is shifted to the SC (that=E2=80=99s clear). But as I = mentioned, this is not specific to IKE-less case but for any solution = based on the pure SDN paradigm (such as Openflow networks). In other = words, the cases you well mention are applicable to any SDN-based = solution. =20 I didn't find this discussion in the draft (sorry if I missed it). =20 Your comments are somehow summarized in the following text section 5.3 =20 "On the contrary, the overload of creating fresh IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side. This overload may create some scalability issues when the number of NSFs is high. In general, literature around SDN-based network management using a centralized Security Controller is aware about scalability issues and solutions have been already provided (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, etc)." =20 I would add that a high-speed dedicated management network between the = SC and the NSFs can be also in place to even limit reduce these delays = between the SC and NSFs (this idea comes again from Openflow networks). = Also the SC can select more =E2=80=9Cintelligent=E2=80=9D lifetime to = orchestrate better when the notifications may appear. =20 In any case, we think we can improve that text as follows:=20 =20 "On the contrary, the overload of creating and managing IPsec SAs is shifted to the Security Controller since IKEv2 is not in the NSF. As a consequence, this may result in a more complex implementation in the controller side in comparison with IKE case. For example, the Security Controller have to deal with=20 the latency existing in the path between the Security Controller=20 and the NSF in order to solve tasks such as, rekey or creation and=20 installation of new IPsec SAs. However, this is not specific to our=20 contribution but a general aspect in any SDN-based network.=20 In summary, this overload may create some scalability and performance = issues when the number of NSFs is high. Nevertheless, literature around SDN-based network management using a centralized Security Controller is aware about scalability and performance issues and solutions have been already provided and discussed (e.g. hierarchical Security Controllers; having multiple replicated Security Controllers, dedicated high-speed management networks, etc). In the context of SDN-based IPsec management, one way to reduce the latency and alleviate some performance issues can be the installation of the IPsec policies and IPsec SAs at the same = time (proactive mode, as described in Section 7.1) instead of waiting for notifications (e.g. a notification sadb-acquire when a new IPsec SA=20 is required) to proceed with the IPsec SA installations (reactive = mode).=20 Another way to reduce the overhead and the potential scalability and performance issues in the Security Controller is to apply the IKE case described in this document, since the IPsec SAs are managed between NSFs without the involvement of the Security Controller at all, except by the initial IKE configuration provided by the Security Controller.=E2=80=9D =20 Please see also our comments to Yoav. =20 Best Regards. =20 Regards, Valery. =20 =20 =20 =20 Thanks for getting this done and published. =20 We will wait with requesting publication until the I2NSF session next = week. Between now and then, please re-read the draft and send a message = to the list is something is seriously wrong. =20 Barring any such shouting, we will request publication right after the = meeting. =20 Thanks again, =20 Linda and Yoav On 16 Jul 2019, at 15:42, Rafa Marin-Lopez < = rafa@um.es> wrote: =20 Dear all: We submitted a new version of the I-D (v05) where we have applied = several changes. In the following you have a summary of the main = changes, which we will expand/explain during our presentation:=20 - We have dealt with YANG doctors=E2=80=99 review (Martin's) - We have dealt with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments. =20 - We have added more specific text in the descriptions. - Notifications have a simpler format now since most of the information = that contained in the past is already handled by the Security = Controller. - State data has been reduced. For example, in IKE case, most of the = information is related with IKE and not with the specific details about = IPsec SAs that IKE handles (after all, IKE can abstract this information = from the Security Controller). =20 - We have included text in the security section to discuss about the = default IPsec policies that should be in the NSF when it starts before = contacting with the SC such as the IPsec policies required to allow = traffic between the SC and the NSF. =20 - We have added a subsection 5.3.4 about NSF discovery by the Security = Controller. - In order to specify the crypto-algorithms we have used a simple = approach by including an integer and adding a text pointing the IANA in = the reference clause. For example: typedef encryption-algorithm-type { type uint32; description=20 "The encryption algorithm is specified with a 32-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference=20 "IANA Registry- Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } =20 - We have included three additional Annexes with examples in about the = usage of the YANG model. =20 - We have performed pyang --lint --lint-ensure-hyphenated-names and = pyang -f yang --yang-line-length 69 in our model without warnings. =20 Best Regards. Inicio del mensaje reenviado: =20 De: internet-drafts@ietf.org Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Fecha: 7 de julio de 2019, 23:34:03 CEST Para: < i-d-announce@ietf.org> Cc: i2nsf@ietf.org Responder a: i2nsf@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Interface to Network Security Functions = WG of the IETF. Title : Software-Defined Networking (SDN)-based IPsec = Flow Protection Authors : Rafa Marin-Lopez Gabriel Lopez-Millan Fernando Pereniguez-Garcia Filename : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt Pages : 81 Date : 2019-07-07 Abstract: This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources. The document focuses on the NSF Facing Interface by providing models for configuration and state data required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish Security Associations with a reduced intervention of the network administrator. The IETF datatracker status page for this draft is: = = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on/ There are also htmlized versions available at: = = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05= = = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-05 A diff from the previous version is available at: = = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-05 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: = ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 ------------------------------------------------------- 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 ------------------------------------------------------- =20 =20 =20 =20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org = https://www.ietf.org/mailman/listinfo/i2nsf =20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org =20 https://www.ietf.org/mailman/listinfo/i2nsf =20 ------=_NextPart_000_01D5_01D5431B.20AB8FB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Rafa,

 

thank you for = adding this text. I think these are the very = minimum

recommendations = that are needed to help implementers to handle various =

error cases = correctly.

 

Regards,=

Valery.<= /span>

 

From: Rafa Marin Lopez = <rafa@um.es>
Sent: Thursday, July 25, 2019 5:54 = PM
To: Valery Smyslov = <smyslov.ietf@gmail.com>
Cc: Rafa Marin Lopez = <rafa@um.es>; Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa = <fernando.pereniguez@cud.upct.es>; Martin Bj=C3=B6rklund = <mbj@tail-f.com>; i2nsf@ietf.org; Gabriel Lopez = <gabilm@um.es>; Yoav Nir <ynir.ietf@gmail.com>; = ipsec@ietf.org WG <ipsec@ietf.org>
Subject: Re: [I2nsf] = I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

 

Hi Valery:

 

Great!. Thanks for these comments. Very valuable. = Following your suggestion we would like to add similar text to part of = the I-D describing the process of IPsec SA installation. This is inline = with the previous text about rekeying we = sent:

 

 

"Figure 4 describes the IKE-less case, when a = data packet needs to be

protected in the path between the NSF A and NSF = B:

 

   1.  The administrator establishes = the flow-based security policies,

       and the Security Controller = looks for the involved NSFs.

 

   2.  The Security Controller = translates the flow-based security

       policies into IPsec SPD and = SAD entries.

 

   3.  The Security Controller inserts = these entries in both NSF A and

       NSF B IPsec databases (SPD = and SAD).  The following text

       describes how this = happens between two NSFs A and B:

 

       *  The Security = Controller chooses two random values as SPIs: = for

    =       example, SPIa1 for NSF A and SPIb1 for NSF B. =  These numbers

          MUST not be in = conflict with any IPsec SA in NSF A or NSF = B.

    =       It also generates fresh cryptographic material for = the new

  =         inbound/outbound IPsec SAs and their = parameters and send

          simultaneously = the new inbound IPsec SA with SPIa1 and = new

    =       outbound IPsec SAs with SPIb1 to NSF A; and the new = inbound

  =         IPsec SA with SPIb1 and new outbound IPsec = SAs with SPIa1 to

          B, together with = the corresponding IPsec policies.

 

       *  Once the = Security Controller receives confirmation from NSF = A

    =       and NSF B, the controller knows that the IPsec SAs = are

    =       correctly installed and = ready.

 

       If some of the = operations described above fails (e.g. the NSF = A

    =    reports an error when the Security Controller is trying = to

    =    install the SPD entry, the new inbound and outbound IPsec = SAs)

    =    the Security Controller must perform rollback operations = by

    =    deleting any new inbound or outbound SA and SPD entry that = had

    =    been successfully installed in any of the NSFs (e.g NSF B) = and

    =    stop the process (NOTE: the Security Controller may retry = several

  =      times before giving up).  Other alternative to = this operation is:

       the Security Controller = sends first the IPsec policies and new

       inbound IPsec SAs to A = and B and once it obtains a successful

       confirmation of these = operations from NSF A and NSF B, it

       proceeds with installing = to the new outbound IPsec SAs. =  However,

       this may increase the = latency to complete the process.  As = an

    =    advantage, no traffic is sent over the network until the = IPsec

    =    SAs are completely operative.  In any case other = alternatives may

       be possible. =  Finally, it is worth mentioning that the = Security

  =      Controller associates a lifetime to the new IPsec = SAs.  When this

       lifetime expires, the = NSF will send a sadb-expire notification = to

    =    the Security Controller in order to start the rekeying = process.

 

   4.  The flow is protected with the = IPsec SA established by the

       Security = Controller.

=E2=80=9C

 

We have also clarified proactive and reactive and the = operations associated in a text below

 

"Instead of installing IPsec policies in the SPD = and IPsec

SAs in the SAD = in step 3 (proactive mode), it is also

possible that the Security Controller only installs = the SPD

entries in step 3 = (reactive mode). In such a case, when a

data packet requires to be protected with IPsec, the = NSF

that saw first the = data packet will send a sadb-acquire

notification that informs the Security Controller that = needs

SAD entries with the = IPsec SAs to process the data

packet. In such as reactive mode, since IPsec policies = are

already installed in = the SPD, the Security Controller

installs first the new IPsec SAs in NSF A and B with = the

operations described = in step 3 but without sending any IPsec

policies. Again, if some of the operations = installing 

the new = inbound/outbound IPsec SAs fail, 

the Security Controller stops the process and performs = a

rollback operation by = deleting any new inbound/outbound SAs =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =

that had been = successfully installed.=E2=80=9D

 

We hope this text also = helps.

 

Thank you very much again.

 

El 23 jul 2019, a las 12:31, Valery Smyslov <smyslov.ietf@gmail.com> = escribi=C3=B3:

 

Hi = Rafa,

 

 

Hi = Valery:




El 22 jul 2019, a las 18:07, Valery Smyslov <smyslov.ietf@gmail.com> = escribi=C3=B3:

 

Hi = Yoav,

 

<= div>

I = think that it is not the performance of the SC that would = matter,

but the = possible delays in the network. If we think of the = network

connecting the SC and the NSFs as of one = close to "ideal", then we = have

no = problems. Otherwise the SC must be prepared to deal with 

network issues. Note, that in case of = reactive SA setup and in = case

of = rekeying the SC must manage two NSFs in a synchronized = manner,

and any = of these NSF can go offline or reboot or stop = responding

during = this, and SC must properly deal with all this = events,

making = proper roll-back on the other = NSF.

 

Regarding this: steps 1, 2 and 3 in section 5.3.1 are = lock-step. As you may see we = mention: 

 

"Once the Security Controller receives confirmation from = A and B, the controller knows that the = inbound 

IPsec A are correctly = installed.=E2=80=9D

 

Having said this. Maybe this text after the = description of steps 1, 2 and 3 may = help:

 

=E2=80=9CIf some of the operations in step 1 fails = (e.g. the NSF1 reports an error when the Security Controller is = trying to install anew new inbound IPsec SA) the Security = Controller must perform rollback operations by removing any new = inbound SA that had been successfully installed during step = 1. 

 

If step 1 is successful but some of the operations in = step 2 fails (e.g. the NSF1 reports an error when the Security = Controller is trying to install the new outbound IPsec SA), = the Security Controller must perform a rollback operation by = deleting any new outbound SA that had been successfully installed during = step 2 and by deleting the inbound SAs created in step = 1. 

 

If the steps 1 an 2 are successful and the step 3 = fails the Security Controller will avoid any rollback of the = operations carried out in step 1 and step 2 since new and valid IPsec = SAs were created and are functional. The Security = Controller may reattempt to remove the old inbound and outbound SAs = in NSF1 and NSF2 several times until it receives a success or it gives = up. In the last case, the old IPsec SAs will be removed when the hard = lifetime is reached." 

 

       &nbs= p;  Yes, this text would = help.

 

       &nbs= p;  Thank you,

       &nbs= p;  Valery.

 

Btw, you can also find some text about NSF state loss = in section 5.3.2. 




 

<= div>

With IKE case RFC7296 contains very specific = advices what

to do in = case of packet loss, delay etc (e.g in case of 

simultaneous rekeying). I'd like to see the = same advices

for SC's = behavior in case of network = issues.

 

<= div>

Regards,

Valery.

=

 

<= div>

 

<= div>

 

<= div>

 

Hi, = Valery

 

Obviously, you need a security controller that = scales to the number of SAs it needs to generate. But generating an SA = in the IKE-less case is just generating 72 random bytes (for = AES-GCM-256) and packaging them.  I don=E2=80=99t think with a = properly scaled SC this would produce more latency than IKE between the = nodes, which has 1/2 round-trips and requires asymmetric = operations.

 





On 22 Jul 2019, at 11:39, Valery Smyslov <smyslov.ietf@gmail.com> = wrote:

 

Hi = Rafa,

 

=

sure this problem is general for any SDN = solution.

My point = was that if SC performs a lot of real-time 

(or near real-time) tasks as it may happen in = IKE-less case, 

then this problem may become = serious.

 

=

Anyway, I'm happy with the updated text, = thank you.

However, = in a following document(s), suggested by = Yoav,

I'd like = to see more concrete advices of how SC = should

act in = this situation to ensure that the consistence of the 

network is preserved despite all the possible = delays etc.

 

=

Regards,

Valery.

 

=

 

=

From: Rafa Marin Lopez = <rafa@um.es> 
Sent: Monday, July 22, 2019 6:11 = PM
To: Valery = Smyslov <smyslov.ietf@gmail.com>
Cc: Rafa Marin Lopez = <rafa@um.es>; Yoav Nir <ynir.ietf@gmail.com>; i2nsf@ietf.org; ipsec@ietf.org; Fernando = Pere=C3=B1=C3=ADguez Garc=C3=ADa <fernando.pereniguez@cud.upct.es>; mbj@tail-f.com; Gabriel Lopez <gabilm@um.es>
Subject: Re: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

 

<= div>

Hi = Valery:

 

=

Thank you very much for your comments. = Please see ours inside.

El 20 jul 2019, a las 16:38, Valery Smyslov <smyslov.ietf@gmail.com> = escribi=C3=B3:

 

<= div>

Hi,

 

=

thank you for updating the document. I still = think that some = aspect

<= p class=3DMsoNormal>of = IKE-less use case are not discussed yet (well, probably they are = not 

"serious", depending = on one's definition of = "serious").

<= div>

 

=

Unlike IKE case. which we can consider as = mostly static = configuration,

the IKE-less case is a dynamic one. If IPsec = SA are being created 

on demand (via kernel-acquire) = and the traffic volume is = high,

then = depending on the IPsec policy IKE-less case can become 

a highly dynamic, which implies = additional requirement on = both

the = network connecting SC and NSF and the performance of the protocol used = to 

secure their communications. In = other words, in IKE case the = communication

between IKE daemon and kernel is seamless, = while in = IKE-less

case = the communication between NSF ("kernel") and SC = adds

noticeable delay (and can potentially add = quite a long = delay),

=

which = can influence total performance of the = system.

=

 

=

Generally IKE-less case requires more = communications = between

=

different nodes to establish or rekey IPsec = SA, than IKE = case

(I = assume that IKE SA is already established), that may = have

an = impact on high-speed networks with short-lived IPsec = SAs,

especially if they are created per transport = connection

(say one IPsec SA for one TCP = session).

 

=

[Authors] What you have just described is = what happens in any SDN-based network. In fact, your comment would be = applicable to practically any scenario based on the SDN paradigm. In the = particular case of the I-D, the IKE-less case is the most similar to = case you can see in, for example, Openflow networks where latency is = also important (just as an example : https://ieeexplore.ieee.org/document/6573052 )






<= p class=3DMsoNormal> 

=

I believe, that SC's task of managing IPsec = SAs in IKE-less case 

may become quite complex, = especially because due to = the

additional delay, introduced by the network, = the picture of = the

state of = the SAs the SC has can become inaccurate (well, 

it will always be inaccurate, = but with short delays it doesn't = matter).

Just = an example. Consider an SC receives a signal from NSF that an = SA

is soft = expired and starts rekeying process by first installing a = new

pair of = inbound SAs. It successfully installs them on the = NSF

it = receives notification from, but then it receives a = notification

=

that the other NSF has rebooted, so it must = clear all the SAs = on

its = peers, including the just installed new one (which is = only

half-done). There seems to be a lot of = nuances, and the document 

completely ignores them. Not = that I think that the = task

is = impossible, but the algorithm of managing the SAs can = become

<= p class=3DMsoNormal>quite = complex and possibly = unreliable.

 

=

[Authors] We largely thought about this = kind of cases, although we do not see any different that may happen in = SDN-based network nowadays. And it seems to me that SDN is becoming = something generally accepted despite the different nuances that needs to = be consider. In any case, what you mention is not ignored in our = document because it is included in the text we have in section 5.3 (see = below) where we highlight the complexity is shifted to the SC = (that=E2=80=99s clear). But as I mentioned, this is not specific to = IKE-less case but for any solution based on the pure SDN paradigm (such = as Openflow networks). In other words, the cases you well mention are = applicable to any SDN-based = solution.






<= p class=3DMsoNormal> 

=

I didn't find this discussion in the draft = (sorry if I missed = it).

 

=

Your comments are somehow summarized in = the following text section = 5.3

 

=

"On the = contrary, the overload of creating fresh IPsec
   SAs is = shifted to the Security Controller since IKEv2 is not in the
  =  NSF.  As a consequence, this may result in a more complex
  =  implementation in the controller side. =  This overload may create some
   scalability issues = when the number of NSFs is high.

In general, literature around SDN-based network = management using = a

   centralized Security Controller is aware = about scalability issues = and

   solutions have been already provided = (e.g. hierarchical = Security

   Controllers; having multiple replicated = Security Controllers, = etc)."

 

I would add that a high-speed = dedicated management network between the SC and the NSFs can be also in = place to even limit reduce these delays between the SC and NSFs (this = idea comes again from Openflow networks). Also the SC can select more = =E2=80=9Cintelligent=E2=80=9D lifetime to orchestrate better when the = notifications may = appear.

 

=

In any case, we think we can improve that = text as = follows: 

=

 

=

"On the contrary, the overload of = creating and managing = IPsec

   SAs is shifted to the Security Controller = since IKEv2 is not in the
   NSF. As a consequence, this = may result in a more complex
   implementation in the = controller side in comparison = with

   IKE case.  For example, the = Security Controller have to deal = with 

   the latency existing in the = path between the Security = Controller 

   and the NSF in order to solve = tasks such as, rekey or creation = and 

   installation of new IPsec SAs. However, = this is not specific to = our 

   contribution but a general aspect in any = SDN-based = network. 

=

   In summary, this overload may create = some scalability and = performance 

   issues when the number of NSFs is = high.


   Nevertheless, literature around = SDN-based network management using a
   centralized = Security Controller is aware about scalability and
  =  performance issues and solutions have been already provided = and
   discussed (e.g.  hierarchical Security = Controllers; having multiple
   replicated Security = Controllers, dedicated high-speed management
   networks, = etc). In the context of SDN-based IPsec management, = one

   way to reduce the latency and alleviate = some performance issues = can

   be the installation of the IPsec policies = and IPsec SAs at the same = time

   (proactive mode, as described in Section = 7.1) instead of waiting = for

   notifications (e.g. a notification = sadb-acquire when a new IPsec = SA 

   is required) to proceed with the IPsec SA = installations (reactive = mode). 

   Another way to reduce the overhead and = the potential scalability = and

   performance issues in the Security = Controller is to apply the IKE
   case described in this = document, since the IPsec SAs are managed
   between NSFs = without the involvement of the Security Controller at
  =  all, except by the initial IKE configuration provided by the = Security
  =  Controller.=E2=80=9D

 

=

Please see also our comments to = Yoav.

 

=

Best = Regards.






<= p class=3DMsoNormal> 

=

Regards,

Valery.

 

=

 

=

 

=

 

=

Thanks for getting this done and = published.

 

We will wait with requesting = publication until the I2NSF session next week.  Between now and = then, please re-read the draft and send a message to the list is = something is seriously = wrong.

 

Barring any such shouting, we = will request publication right after the = meeting.

=

 

Thanks = again,

 

Linda and = Yoav







<= p class=3DMsoNormal>On 16 Jul 2019, at 15:42, Rafa Marin-Lopez <rafa@um.es> = wrote:

 

=

Dear all:

We submitted a = new version of the I-D (v05) where we have applied several changes. = In the following you have a summary of the main changes, which we will = expand/explain during our presentation: 

- We have dealt = with YANG doctors=E2=80=99 review (Martin's)

- We have dealt = with Paul Wouters=E2=80=99 comments and Tero=E2=80=99s = comments.

=

 

- We have added more specific = text in the descriptions.

- Notifications have a simpler format = now since most of the information that contained in the past is already = handled by the Security Controller.

- State data has been = reduced. For example, in IKE case, most of the information is related = with IKE and not with the specific details about IPsec SAs that IKE = handles (after all, IKE can abstract this information from the Security = Controller).

<= div>

 

- We have included text in the = security section to discuss about the default IPsec policies that should = be in the NSF when it starts before contacting with the SC such as the = IPsec policies required to allow traffic between the SC and the = NSF.

 

- We have added a subsection = 5.3.4 about NSF discovery by the Security Controller.

- In order = to specify the crypto-algorithms we have used a simple approach by = including an integer and adding a text pointing the IANA in = the reference clause. For = example:

=


typedef encryption-algorithm-type = {
           ty= pe = uint32;
          &n= bsp;description 
        =        "The encryption algorithm = is specified with a = 32-bit
          &nb= sp;    number extracted from IANA Registry. The = acceptable
          = ;     values MUST follow the requirement levels = for
           =     encryption algorithms for ESP and = IKEv2.";
         &n= bsp; reference 
       &n= bsp;        "IANA Registry- = Transform Type 1 - = Encryption
          = ;      Algorithm Transform IDs. RFC 8221 - = Cryptographic
         &n= bsp;      Algorithm Implementation = Requirements and = Usage
          &nbs= p;     Guidance for Encapsulating Security = Payload = (ESP)
          &nbs= p;     and Authentication Header (AH) and RFC = 8247 = -
           &n= bsp;    Algorithm Implementation Requirements and = Usage
          &nbs= p;     Guidance for the Internet Key Exchange = Protocol
          &= nbsp;     Version 2 = (IKEv2).";
       }=

 

- We have included three = additional Annexes with examples in about the usage of the YANG = model.

 

- We have performed pyang = --lint --lint-ensure-hyphenated-names and pyang -f yang = --yang-line-length 69 in our model without = warnings.

 

Best = Regards.

=







<= p class=3DMsoNormal>Inicio del mensaje = reenviado:

 

Asunto: [I2nsf] I-D Action: = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

Fecha: 7 de julio de 2019, = 23:34:03 = CEST

Responder a: i2nsf@ietf.org

 

=


A New Internet-Draft is = available from the on-line Internet-Drafts directories.
This draft is = a work item of the Interface to Network Security Functions WG of the = IETF.

       Title =           : = Software-Defined Networking (SDN)-based IPsec Flow = Protection
       Authors =         : Rafa = Marin-Lopez
         &nbs= p;            = ;   Gabriel = Lopez-Millan
         &nb= sp;           &nbs= p;   Fernando Pereniguez-Garcia
        &n= bsp;  Filename =        : = draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
        &n= bsp;  Pages =           : = 81
        &n= bsp;  Date =            : = 2019-07-07

Abstract:
  This document describes how = providing IPsec-based flow protection by
  means of a = Software-Defined Network (SDN) controller (aka. =  Security
  Controller) and establishes the = requirements to support this service.
  It considers two = main well-known scenarios in IPsec: (i) = gateway-to-
  gateway and (ii) host-to-host.  The = SDN-based service described in
  this document allows the = distribution and monitoring of IPsec
  information from a = Security Controller to one or several flow-based
  Network = Security Function (NSF).  The NSFs implement IPsec to = protect
  data traffic between network = resources.

  The document focuses on the NSF Facing = Interface by providing models
  for configuration and state = data required to allow the Security
  Controller to = configure the IPsec databases (SPD, SAD, PAD) and = IKEv2
  to establish Security Associations with a reduced = intervention of the
  network administrator.


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-= sdn-ipsec-flow-protection/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-i= psec-flow-protection-05
https://datatracker.ietf.org/doc/html/draft-ietf-i= 2nsf-sdn-ipsec-flow-protection-05

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2n= sf-sdn-ipsec-flow-protection-05


Please note that = it may take a couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
=
_______________________________________________
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
------------= -------------------------------------------

 

 

 

 

_______________________________________________
I2ns= f mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf=

 

__________________________= _____________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org= /mailman/listinfo/i2nsf

 

------=_NextPart_000_01D5_01D5431B.20AB8FB0-- From nobody Thu Jul 25 19:04:12 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8622312024D; Thu, 25 Jul 2019 19:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 gWnHBu5l8y4q; Thu, 25 Jul 2019 19:04:03 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10096.outbound.protection.outlook.com [40.107.1.96]) (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 8D859120223; Thu, 25 Jul 2019 19:04:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mbvAsilpr6vsHigK8Ficz6tqT7scTXFkPgFoRc+WRq8tmKEexPvVs+PxJXvskpN3Mmv/TIQ0IpGr+9AUiR7MiWLX5i8jvNQ70yoZg5mZF5k043/hs6E3r0GoO1qIaEiQ9gtvwOyrHtzc7aUfVLhEafMssMWyz6ATZmdpLdUoS7TinrWEHhcFZDz2afNfLcsg5aK4FUqUnXCC3KYgz5S8/ZSw4K9vWnhLYWb5WVzhH6RyMlauborLloG6fTzEaQYu3a8pWEpymj8TmtfPHJyKpxc8K2p0Y3oAb0DwMxzMgOE0DR1R/IsQV+RpRsV9AmTlps8EtMlqG8bOPq9up8MvCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O/wCypnW9JTLuUeTnFl1J7iy87FM2haeY1zbL+o50UY=; b=g27ikLGfM/SGvRUVwEzFv53QcZk5gkwg4ATdvlwsi24stb8T7M+NeEjIBTCs3I/go4rs25NaRE+0CH5F7ut17G8DB/tx7fPPn20DLCsXoE5ijhxgSkmf7g5CHYl5fjK9Lt88V6aSzAVBgf59G/IIUxHC9pY3qeyuBVY6vwP6128p6n6V79GMKHeUVXImSXSLcqn3FYlLuM58R60pcxF2frtQ0Woq3ky9+YuZhu7uXJQCxp2z6bxuNLtYboq34HTf4JvVDLfbmEqBAMPO4De4+UmAAiGZqucFiXvDpoTcAzZbk9rt7ZGbSpVHSn8N/1vssdHxwzw6WprqjyLIyYLSww== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nokia.com;dmarc=pass action=none header.from=nokia.com;dkim=pass header.d=nokia.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O/wCypnW9JTLuUeTnFl1J7iy87FM2haeY1zbL+o50UY=; b=SKcH0e96e39kZkaQxrYdEeZKhyMM5ePPaIXvjnvyHWISOyHjyzMTPxzCJEfnZGbMcHDO6g0/qkMYeJO8vEDA4EM/ip6KOYv3O+68R5ZubefoNoWfdjHmrXx7iAESUjXEVrvqn/ykCAHniuQLq9Sy3qmXJ8OIfvmGL69BFes/QrI= Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com (10.169.150.18) by AM5PR0701MB2625.eurprd07.prod.outlook.com (10.173.92.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Fri, 26 Jul 2019 02:03:59 +0000 Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::b4b9:a6bd:67a4:95ae]) by AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::b4b9:a6bd:67a4:95ae%12]) with mapi id 15.20.2115.005; Fri, 26 Jul 2019 02:03:59 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters , "idr@ietf.org" CC: "ipsec@ietf.org WG" Thread-Topic: [Idr] Review of draft-hujun-idr-bgp-ipsec-00 Thread-Index: AQHVQjYIalbt7l4FGEij89onmXSJIqbcAJ4A Date: Fri, 26 Jul 2019 02:03:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-originating-ip: [2601:646:8500:5f0:dd04:fb6c:3016:ed3c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 899da0ee-db08-4965-2b46-08d7116d8625 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM5PR0701MB2625; x-ms-traffictypediagnostic: AM5PR0701MB2625: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01106E96F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(39860400002)(366004)(396003)(136003)(346002)(13464003)(199004)(51914003)(189003)(11346002)(5660300002)(25786009)(478600001)(8676002)(966005)(476003)(53936002)(305945005)(46003)(52536014)(186003)(6306002)(14454004)(7736002)(2501003)(55016002)(9686003)(446003)(68736007)(6246003)(71190400001)(102836004)(229853002)(76176011)(6506007)(6436002)(86362001)(4326008)(74316002)(7696005)(66476007)(66574012)(14444005)(66446008)(66556008)(76116006)(256004)(99286004)(66946007)(33656002)(64756008)(71200400001)(8936002)(19627235002)(2906002)(81156014)(316002)(110136005)(53546011)(81166006)(6116002)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2625; H:AM5PR0701MB2353.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mGoumThFBA2yULLGnZ037c+Xzab122mIbGLAwCO9/dHUpXxf/fAcYFkzDGRJeGtjnhsLXh69k3eC55O3iUZL2fUWjz70xqsuWrOXH4GL7RcIvQtiCjpNJBdanSUKdSLCixpknvyAW7+Ltr0QUggao8FiQQhJw88jFqjHBL76rythSaMfj5C1jycu1qfZgWyy9wG0BJLQVu7IPdqgy+IzXI8bUsKyjTFsIXpJ+/daXh6Gy7+450tueEb/iJi3ADwFiOA6jmmO85tDJ09u7x26OR5YBKxoAewkBPJyC8DnJNLM36xUQeEXgd9ekPYaA4B8iBqFNWAhltu0w09mMYFpvMr/SfDDYkoiw+T1MN0lW3EEsB23yNy+nIqS1YP6OGGQr4ENcKfUBYpFmRhjEKVyLWfFKePkRkyrOM8If/2yv0k= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 899da0ee-db08-4965-2b46-08d7116d8625 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2019 02:03:59.5125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jun.hu@nokia.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2625 Archived-At: Subject: Re: [IPsec] [Idr] Review of draft-hujun-idr-bgp-ipsec-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 02:04:06 -0000 Thanks for the thorough review, My comments in line as [Hu Jun] -----Original Message----- From: Idr On Behalf Of Paul Wouters Sent: Wednesday, July 24, 2019 8:39 AM To: idr@ietf.org Cc: ipsec@ietf.org WG Subject: [Idr] Review of draft-hujun-idr-bgp-ipsec-00 Hi, Note that I am an IPsec person and not a routing expert. The document's idea looks fine to me. It is using BGP messages to provision= IKEv2 so that IPsec tunnels can be setup to protect packets as best as pos= sible. That's great :) And unlike most proposals the IPsec WG sees, this document does not try to = replace IKEv2 with its own smarter Key Exchange protocol, so that's a doubl= e plus :) [Hu Jun] indeed, IKEv2 is a field proven mature/secure protocol, there is r= eally no need to re-invent a new way for key exchanging=20 Thanks for reaching out to the ipsec WG, we really appreciate the chance to= read drafts that use IPsec to give advise. Below are some of my comments and questions I have: - Configuring large number of tunnels is error prone and not scalable * Only true to some extend * See AutoVPN, DMVPM, NHRP+IKE * Still, this provisioning system seems to fit your eco system. It's as = simple as it can be and does not seem to introduce any new complexity or risks. [Hu Jun] All kinds of tunnel mechanism are used in large IP network where B= GP is heavily used, that's why ietf-idr-tunnel-encaps introduce a unified m= echanism for BGP to signal different type of tunnel config; my draft is jus= t extension of it to support IPsec tunnel; and I intentionally keep the cha= nges to BGP small and no change to IPsec, for easier adaption; - What is "color"? [Hu Jun] "color" is a general term used in routing to represent a set of ru= les or match criteria; for example color "red" means set-1 of rules, "yello= w" means a set-2 of rules; in my draft, color sub-TLV is used to signal a s= et of IPsec config that are not explicitly signaled by other BGP sub-TLVs (= like local/remote traffic selector prefix, public routing instance) ;=20 Following is an example: Color "red" maps to following IPsec config: - certificate auth - trust anchor CA-1 - ike-transform: sha256/aes-gcm-256/DH-Grp 15 - IKE_SA lifetime: 1 day - esp-transform: sha256/aes-gcm-256/Pfs-Grp 15 - CHILD_SA lifetime: 2 hours - ESN: yes - ... etc Color "yellow" maps to following IPsec config: - certificate auth - trust anchor CA-2 - ike-transform: sha128/aes-gcm-128/DH-Grp 15 - IKE_SA lifetime: 1 day - esp-transform: sha128/aes-gcm-128/Pfs-Grp 15 - CHILD_SA lifetime: 2 hours - ESN: No - ... etc =20 - Section 3, step 4: When a router need to forward a packet along a path is determined by a BGP UPDATE which has a tunnel encapsulation attribute that contains one or more IPsec TLV, and router decides use IPsec based on local policy, Required vs Optional IPsec issue. If only one end has "required" and the ot= her end has "optional" then unencrypted packets will be dropped. Seeing IPs= ec tunnel TLV should probably mean it is mandatory to setup a tunnel? [Hu Jun] A router could include multiple different tunnel type TLV in a BGP= update, which means there could be multiple tunnel type options for a give= n route; and a receiver of such route might chose one of them based on loca= l policy; this behavior is specified in section 5 of draft-ietf-idr-tunnel-= encaps It can be done as "optional" but then the IPsec/kernel mechanisms cannot tr= igger an IKE/IPsec negotiation and this protocol needs to be responsible fo= r not just configuring IKEv2/IPsec but also for bringing up the tunnels whe= n needed. [Hu Jun] yes, if the system decides to use IPsec tunnel to reach a route (b= ased on local policy), it needs to first to check if there is already an ex= isting CHILD_SA it could use, if not, system needs to use IKEv2 to create o= ne - Section 3, step 6: - signaling IPsec configuration Call it IPsec provisioning ? [Hu Jun] I don't have strong opinion on this, provision is also fine to me;= =20 - Examples are using less prefered and slower algorithms * Change AES-CBC-256 with SHA-384. to AES-GCM-256 or CHACHA20_POLY1305 * Change NULL-SHA256 to NULL-AES-GMAC [Hu Jun] ok, I will make the change=20 - 1/128 and 2/128 ? For 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), these NLRI has embedded label, which cause the payload packet can't be encapsulated in ESP packet, I don't understand why 1/128 or 2/128 are special ? [Hu Jun] because these routes include a MPLS label, so by default, a router= are supposed to add a MPLS label to the payload packet; but IPsec (ESP) on= ly supports IP packet as payload, so label can't be included during ESP enc= ryption/encapsulation; that's why a value 2 of Embedded Label Handling Sub-= TLV is used to signal ignoring the MPLS label during ESP processing Open questions: - If the IKEv2 protocol fails, what happens with packets? Release in clear = or drop? Is this something the BGP should configure/provision ? If not, it should= state which of the two is expected [Hu Jun] This depends if there is any other tunnels (signaled via other tun= nel encap TLV in BGP update) could be used; if there is, then use another o= ne based on local policy; if not, then drop the packet as no route availabl= e=20 - If a router R1 and R2 have an ipsec tunnel for some traffic, and R1 crash= es/reboots, how do things recover? R2 will send packets and might not know something= is wrong, unless it is configured for liveness. What happens when R1 comes back up? If al= l BGP routes are taken away via another mechanism, then I guess R2 would simply delet= e its tunnel. [Hu Jun] there need to some keepalive mechanism to detect if tunnel is up o= r not; this is not specific to IPsec, all stateful tunnel need such mechani= sm; for IPsec, DPD is one option; another faster option would be running BF= D over IPsec tunnel; after R2 detects tunnel is down, it has following opti= ons: 1. if there is another type of tunnel could use (as described as above), th= en use that tunnel 2. try re-create the tunnel for a few times, if still can't create the tunn= el, use other tunnel if available=20 Such case is also described in section 5 of draft-ietf-idr-tunnel-encaps - Performance: if routes are large (eg 0/128) then very few tunnels would c= over lots of routes. In general, having more parallel smaller CHILD SA's outperforms = a single or two CHILD SA's by far. This could introduce performance issues. [Hu Jun] agree, and user could freely choose between a few CHILD_SA or many= CHILD_SA based on traffic selector sub-TLV BGP signals=20 - Some IPsec options not mentioned could prevent a tunnel from being setup,= such as whether to use Extended Sequence Numbers (ESN), or Perfect Forward Secre= cry (PFS). Some of these could be locked down in the document (PFS=3Dyes) but thing= s like ESN really depend on the bandwidth of the tunnel. [Hu Jun] as mentioned above, all IPsec config that is not explicit signaled= by a sub-TLV, is indirectly signal by color - Maybe some advise on replay-window size would be good. Larger is better b= ut takes more memory. Matters mostly for highspeed links. [Hu Jun] this sound more like a general IPsec optimization suggestion; kind= orthogonal to the draft Paul _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 29 10:40:10 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5DD1201D7; Mon, 29 Jul 2019 10:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Tgzn-pgOiguf; Mon, 29 Jul 2019 10:40:05 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 2067A1203C0; Mon, 29 Jul 2019 10:40:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 02D9320813; Mon, 29 Jul 2019 19:40: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 4oIWATTs989Q; Mon, 29 Jul 2019 19:40:02 +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 09B5B1FEFE; Mon, 29 Jul 2019 19:40:00 +0200 (CEST) From: Rafa Marin-Lopez Content-Type: multipart/alternative; boundary="Apple-Mail=_A2E7B69F-7925-40B5-A0C5-A586788C6953" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 29 Jul 2019 19:39:59 +0200 References: <156442161237.1137.17328662456166692229.idtracker@ietfa.amsl.com> Cc: Rafa Marin-Lopez , Gabriel Lopez , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , "ipsec@ietf.org WG" To: i2nsf@ietf.org Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 17:40:09 -0000 --Apple-Mail=_A2E7B69F-7925-40B5-A0C5-A586788C6953 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all: We have just submitted v06 of our I-D, as promised. This is a summary = with the changes: - It includes last recent text we sent to the mailing list to consider = Valery=E2=80=99s comments (thank you again). - Replacement uint32 by uint16 in algorithms types from IANA. (thanks = Tero) - IANA Considerations section included. - Security section extended with subsection 9.3 about Security = considerations about YANG models as indicated in = https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines Best Regards. > Inicio del mensaje reenviado: >=20 > De: internet-drafts@ietf.org > Asunto: New Version Notification for = draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt > Fecha: 29 de julio de 2019, 19:33:32 CEST > Para: "Fernando Pereniguez-Garcia" , = "Rafa Marin-Lopez" , "Rafael Lopez" , "Gabriel = Lopez-Millan" >=20 >=20 > A new version of I-D, = draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt > has been successfully submitted by Rafa Marin-Lopez and posted to the > IETF repository. >=20 > Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection > Revision: 06 > Title: Software-Defined Networking (SDN)-based IPsec = Flow Protection > Document date: 2019-07-28 > Group: i2nsf > Pages: 86 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-06.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-06 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-06 >=20 > Abstract: > This document describes how providing IPsec-based flow protection by > means of a Software-Defined Network (SDN) controller (aka. Security > Controller) and establishes the requirements to support this = service. > It considers two main well-known scenarios in IPsec: (i) gateway-to- > gateway and (ii) host-to-host. The SDN-based service described in > this document allows the distribution and monitoring of IPsec > information from a Security Controller to one or several flow-based > Network Security Function (NSF). The NSFs implement IPsec to = protect > data traffic between network resources. >=20 > The document focuses on the NSF Facing Interface by providing models > for configuration and state data required to allow the Security > Controller to configure the IPsec databases (SPD, SAD, PAD) and = IKEv2 > to establish Security Associations with a reduced intervention of = the > network administrator. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 ------------------------------------------------------- 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 ------------------------------------------------------- --Apple-Mail=_A2E7B69F-7925-40B5-A0C5-A586788C6953 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = all:

We have just = submitted v06 of our I-D, as promised. This is a summary with the = changes:

- It = includes last recent text we sent to the mailing list to consider = Valery=E2=80=99s comments (thank you again).

- Replacement uint32 by uint16 in = algorithms types from IANA. (thanks Tero)

- IANA Considerations section = included.

- = Security section extended with subsection 9.3 about Security = considerations about YANG models as indicated in https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Best = Regards.

Inicio del mensaje reenviado:

De: = internet-drafts@ietf.org
Asunto: = New Version = Notification for = draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt
Fecha: = 29 de julio de 2019, 19:33:32 = CEST
Para: = "Fernando Pereniguez-Garcia" = <fernando.pereniguez@cud.upct.es>, "Rafa Marin-Lopez" = <rafa@um.es>, "Rafael = Lopez" <rafa@um.es>, = "Gabriel Lopez-Millan" <gabilm@um.es>


A new version = of I-D, draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt
has been successfully submitted by Rafa Marin-Lopez and = posted to the
IETF repository.

Name: = = draft-ietf-i2nsf-sdn-ipsec-flow-protection
Revision: 06
Title: = Software-Defined Networking (SDN)-based IPsec Flow Protection
Document date: 2019-07-28
Group:= = i2nsf
Pages: 86
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-i2nsf-sdn-ipsec= -flow-protection-06.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flo= w-protection/
Htmlized: =       https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-06
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipse= c-flow-protection
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-= flow-protection-06

Abstract:
  This document describes how providing = IPsec-based flow protection by
  means of a = Software-Defined Network (SDN) controller (aka.  Security
  Controller) and establishes the requirements to = support this service.
  It considers two main = well-known scenarios in IPsec: (i) gateway-to-
=   gateway and (ii) host-to-host.  The SDN-based service = described in
  this document allows the = distribution and monitoring of IPsec
=   information from a Security Controller to one or several = flow-based
  Network Security Function (NSF). =  The NSFs implement IPsec to protect
=   data traffic between network resources.

  The document focuses on the NSF Facing Interface = by providing models
  for configuration and = state data required to allow the Security
=   Controller to configure the IPsec databases (SPD, SAD, PAD) = and IKEv2
  to establish Security Associations = with a reduced intervention of the
  network = administrator.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat


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




= --Apple-Mail=_A2E7B69F-7925-40B5-A0C5-A586788C6953--