From nobody Wed Jul 5 13:46:01 2017 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 F1980131844 for ; Wed, 5 Jul 2017 13:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 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 urbv3Lk5sZmk for ; Wed, 5 Jul 2017 13:45:57 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392A1126B7F for ; Wed, 5 Jul 2017 13:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2630; q=dns/txt; s=iport; t=1499287557; x=1500497157; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZD9n0/cp7mPlxeDzefvJvmACvaHSJxIn3VbefJjXdqw=; b=XyiUf5rZYJ4wQp0p/csJjZsdfPR9coxn4zczRM6R0/j8YK0o9zMH/sFo HYvUX5dD5j/0RxzaRGi+xmmXYemxZL3rFRxWVSihwCKHSS3hSzdYFMaT5 zBZE1Q8JvBE4W+DC/RHdR4RmkEblY6jOjBLAY15dIQsMNgA5Bl4T/th/J E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAABRT11Z/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4rY4EQB44CkWiWAIIRIQuFcAKDHD8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDAQE4NBcEAgEIEQQBAR8JBycLFAkIAgQTCIgSAYIUELEqi0IBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgyeDTIUFgyaHOAWXKYddAodFjDWCFVaEdIpIiTWLfQE?= =?us-ascii?q?fOIEKdRUfKoUYF4Fmdod2gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,313,1496102400"; d="scan'208";a="264445834" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2017 20:45:56 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v65KjtBC031212 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Jul 2017 20:45:56 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 16:45:55 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Wed, 5 Jul 2017 16:45:55 -0400 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-04.txt Thread-Index: AQHSuT2m0AISfL9zckCPSlbERmt9x6JGK+7A Date: Wed, 5 Jul 2017 20:45:55 +0000 Message-ID: References: <149262774915.19228.16212136494185962079@ietfa.amsl.com> In-Reply-To: <149262774915.19228.16212136494185962079@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 20:45:59 -0000 We published this update to the working group item; I believe we incorporat= ed the various suggestions people have made. Are people happy with the state of the draft? Are there other revisions pe= ople would like to see? If there are further revisions, I would like to ge= t them in before the WG meeting in Prague. Thanks! > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Wednesday, April 19, 2017 2:49 PM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IP Security Maintenance and Extensions o= f the > IETF. >=20 > Title : Postquantum Preshared Keys for IKEv2 > Authors : Scott Fluhrer > David McGrew > Panos Kampanakis > Filename : draft-fluhrer-qr-ikev2-04.txt > Pages : 11 > Date : 2017-04-19 >=20 > Abstract: > The possibility of quantum computers pose a serious challenge to > cryptography algorithms widely today. IKEv2 is one example of a > cryptosystem that could be broken; someone storing VPN communications > today could decrypt them at a later time when a quantum computer is > available. It is anticipated that IKEv2 will be extended to support > quantum secure key exchange algorithms; however that is not likely to > happen in the near term. To address this problem before then, this > document describes an extension of IKEv2 to allow it to be resistant > to a Quantum Computer, by using preshared keys. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-04 > https://datatracker.ietf.org/doc/html/draft-fluhrer-qr-ikev2-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-fluhrer-qr-ikev2-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jul 6 02:31:28 2017 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 D5D431270A3 for ; Thu, 6 Jul 2017 02:31:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2wiycvbb6Zvp for ; Thu, 6 Jul 2017 02:31:25 -0700 (PDT) Received: from relay.ezis.com (relay.ezis.com [5.153.73.19]) by ietfa.amsl.com (Postfix) with ESMTP id E680A120721 for ; Thu, 6 Jul 2017 02:31:24 -0700 (PDT) Received: from unknown (HELO pqex01.post-quantum.com) ([192.168.142.3]) by ironport.ezis.com with ESMTP; 06 Jul 2017 10:31:23 +0100 Received: from PQEX02.post-quantum.com (192.168.142.18) by PQEX01.post-quantum.com (192.168.142.3) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 6 Jul 2017 10:31:22 +0100 Received: from PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3]) by PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3%13]) with mapi id 15.00.1263.000; Thu, 6 Jul 2017 10:31:22 +0100 From: Cen Jung Tjhai To: "ipsec@ietf.org" Thread-Topic: New draft on hybrid key-exchange for IKEv2 Thread-Index: AQHS9jqh6gUaasKwMkCtsRJVSN8jew== Date: Thu, 6 Jul 2017 09:31:22 +0000 Message-ID: <3068D3E0-E1FD-4911-AA7C-E8DC64A158D0@post-quantum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.3.255.7] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [IPsec] New draft on hybrid key-exchange for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 09:31:27 -0000 RGVhciBhbGwsDQoNCkxhc3QgbW9udGgsIHdlIHN1Ym1pdHRlZCBhIGRyYWZ0IG9uIG9wdGlvbmFs IGtleSBleGNoYW5nZSBwYXlsb2FkIGNhcnJ5aW5nIHF1YW50dW0tc2FmZSBwdWJsaWMgZGF0YSwg d2hpY2ggaXMgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIERIIGtleSBleGNoYW5nZSB0byBlc3Rh Ymxpc2ggYSBxdWFudHVtLXNhZmUgc2hhcmVkIHNlY3JldCBiZXR3ZWVuIElLRXYyIHBlZXJzLiBU aGUgZHJhZnQgY2FuIGJlIG9idGFpbmVkIGhlcmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL3N0YWdp bmcvZHJhZnQtaWV0Zi1pcHNlY21lLWh5YnJpZC1xc2tlLWlrZXYyLTAwLnR4dA0KDQpVbmZvcnR1 bmF0ZWx5LCBkdWUgdG8gaW5jb3JyZWN0IG5hbWluZyBjb252ZW50aW9uIG9mIHRoZSBkcmFmdCwg aXQgZGlkIG5vdCBtYWtlIGl0IHRocm91Z2ggdGhlIGZpbmFsIHByb2Nlc3MuIEhvd2V2ZXIsIERh dmlkIFdhbHRlcm1pcmUgaGFzIHN0ZWVyZWQgdXMgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBhbmQg d2Ugd2lsbCByZXN1Ym1pdCB0aGUgZHJhZnQgYWZ0ZXIgMTZ0aCBKdWx5Lg0KDQpJbiB0aGUgbWVh bnRpbWUsIHdlIHdvdWxkIGJlIGdyYXRlZnVsIHRvIGhlYXIgYW55IGZlZWRiYWNrcyBvciBjb21t ZW50cyBvbiB0aGlzLiBXZSB3b3VsZCBiZSBoYXBweSB0byBkaXNjdXNzIGl0IGluIFByYWd1ZSB0 b28uDQoNCldlIHdvdWxkIGxpa2UgdG8gYWRkIHRoYXQgd2UgYWxzbyBoYXZlIGFuIG9wZW4gc291 cmNlIGltcGxlbWVudGF0aW9uICh1c2luZyBzdHJvbmdTd2FuKSB0aGF0IGRlbW9uc3RyYXRlcyB0 aGlzIGV4dGVuc2lvbi4gVGhlIHNvdXJjZSBjb2RlIGlzIGF2YWlsYWJsZSBhdCB0aGlzIGZvcmtl ZCBzdHJvbmdTd2FuIHJlcG9zaXRvcnk6IGh0dHBzOi8vZ2l0aHViLmNvbS9wb3N0LXF1YW50dW0v c3Ryb25nc3dhbiwgYXQgInFza2UiIGJyYW5jaC4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vZ2l0 aHViLmNvbS9wb3N0LXF1YW50dW0vc3Ryb25nc3dhbi9ibG9iL3Fza2UvUkVBRE1FLlFTS0UubWQg Zm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uDQoNCg0KQmVzdCB3aXNoZXMsDQpDSg0KDQoNCg== From nobody Mon Jul 17 08:19:16 2017 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 32747131C7D; Mon, 17 Jul 2017 08:19:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org, David Waltermire , ekr@rtfm.com, The IESG , ipsecme-chairs@ietf.org, ipsec@ietf.org, david.waltermire@nist.gov, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150030474720.24501.15058045130579216582.idtracker@ietfa.amsl.com> Date: Mon, 17 Jul 2017 08:19:07 -0700 Archived-At: Subject: [IPsec] Protocol Action: 'Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)' to Proposed Standard (draft-ietf-ipsecme-rfc7321bis-06.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:19:07 -0000 The IESG has approved the following document: - 'Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)' (draft-ietf-ipsecme-rfc7321bis-06.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ Technical Summary This document is intended to obsolete the RFC7321 (Proposed Standard) and define a current mandatory to implement algorithms requirements and usage for IPsec traffic. There is another document draft-ietf-ipsecme-rfc4307bis which does the same changes to the IKEv2, and both of the documents are mostly aligned to be same, except where there are different requirements for algorithms in IKEv2 vs ESP. It is requested that this draft and draft-ietf-ipsecme-rfc4307bis be grouped for completing the publication process. Working Group Summary The draft had no controversy. The draft has been discussed frequently on the mailing list and a lot of comments have been provided on list by people other than the authors. In addition to mailing list discussions, the draft has been presented and discussed during IETF meetings at Berlin (IETF96) and briefly at Seoul (IETF97). Most of the decisions on the algorithm levels were done already when discussing the companion document rfc4307bis. Document Quality Yes, there are implementations and the document has has a fair amount of review. Personnel David Waltermire is the draft shepherd and Eric Rescorla is the responsible AD. From nobody Mon Jul 17 08:26:56 2017 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 A8171131C78; Mon, 17 Jul 2017 08:26:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Cc: David Waltermire , The IESG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-rfc4307bis@ietf.org, ekr@rtfm.com, ipsec@ietf.org, david.waltermire@nist.gov, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150030520868.24575.7776687064953083890.idtracker@ietfa.amsl.com> Date: Mon, 17 Jul 2017 08:26:48 -0700 Archived-At: Subject: [IPsec] Protocol Action: 'Algorithm Implementation Requirements and Usage Guidance for IKEv2' to Proposed Standard (draft-ietf-ipsecme-rfc4307bis-18.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:26:49 -0000 The IESG has approved the following document: - 'Algorithm Implementation Requirements and Usage Guidance for IKEv2' (draft-ietf-ipsecme-rfc4307bis-18.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ Technical Summary The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. Working Group Summary The draft has WG consensus, no concerns to note. Document Quality The document has support of vendors for their implementations. Personnel The Document Shepherd is David Waltermire. The responsible Area Director is Eric Rescorla. - No change in the Designated Expert for this existing registry. Note here as a result of shepherd report to avoid confusion. IANA Note This document renames some of the names in the "Transform Type 1 - Encryption Algorithm Transform IDs" registry of the "Internet Key Exchange Version 2 (IKEv2) Parameters". From nobody Tue Jul 18 01:29:22 2017 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 BDF6A131D6D for ; Tue, 18 Jul 2017 01:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 pl-sua1fQ2pV for ; Tue, 18 Jul 2017 01:29:19 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 C4F7613167B for ; Tue, 18 Jul 2017 01:29:18 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id a10so18283402wrd.0 for ; Tue, 18 Jul 2017 01:29:18 -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=iqJN6NSkLQVF+O7pAKc9ZJzcqFXTAy6S5gkx+mao5+A=; b=g/YX5zyz1BzKSppsfzxE4gIrbxfQJ9dll8UUTMMsDD7IYKamaFsneU7sTIJJDACKEM TSfD1PcpCBicRkpbfeuuvOfNoP33PnNfX+6Kirhbw44DNEt6Ii/TnZHzAJ1CbBZZfDnQ c0SGhuPbH4oJ8qse+n/dihev6mPfIVg9GhXcMyupOe7MrQKKaFFcPXDkGOJb5r0DTAuV FtEntMphBdpxUXHb0Bculh7P4j5xLCW92a3BP3xs1kQPp30VNbZX6NDtPrAYdnHSBeRp gmFM3G1hAwMXKEpruksiSOx+KyYlp3GSm5xvLRBGPQdS+Z8EONjJIHdYlmfOfK/oTWPK ecEA== 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=iqJN6NSkLQVF+O7pAKc9ZJzcqFXTAy6S5gkx+mao5+A=; b=E3jIGw1G5u9cG3lhFQwFXLujv9482T+WuCmG3pbBrpwfo8A8GstLt/4j+SIgmRPI+k mbJosoAmvb6LTJgzcCRouBBUPApXC+j1XB0/wKX00lV2ipe+HgIqhzW1EMGdFDZ77rGE CJ2fLsgOriCsORuzjki05BMRfHeMtc7ejRnXR8FoIP0LnaEAjYSrF93VMSTLPrHi8Uzt AQJOmNtx0nv8tTNxxXZ0pYG2bsVUdp4lK4loonPgxYoL727+3h3nzrnS8E2vKe8nqpJ/ LVSOKwEJQrsLm7JWEZFw8FtnWzgYxTB5yYRPSBa5l/IH632Ayu8TCbzVH07Sxo0Rx/bp 6RXA== X-Gm-Message-State: AIVw110cgh5FgqHH0zzNT7UkNNk0uQNj9trMvFcZUASCj+4HNO3ZoFz/ b4oZa1cJAX6SpNngEPw= X-Received: by 10.28.220.85 with SMTP id t82mr411284wmg.10.1500366557063; Tue, 18 Jul 2017 01:29:17 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:1897:39e1:cca0:3db0? ([2001:67c:370:128:1897:39e1:cca0:3db0]) by smtp.gmail.com with ESMTPSA id 49sm1352017wrt.36.2017.07.18.01.29.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 01:29:16 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_C4A46A2A-0A96-4D9E-BA59-AD596B4F73F4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <5028E793-16B0-4FB7-A3DD-CB2BA1135DA7@gmail.com> Date: Tue, 18 Jul 2017 10:29:14 +0200 To: "IPsecme WG (ipsec@ietf.org)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [IPsec] IPsec and SDN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:29:21 -0000 --Apple-Mail=_C4A46A2A-0A96-4D9E-BA59-AD596B4F73F4 Content-Type: multipart/alternative; boundary="Apple-Mail=_AF703295-2FD9-43A3-9E79-D4A0D494A4B7" --Apple-Mail=_AF703295-2FD9-43A3-9E79-D4A0D494A4B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. This may be of interest to this working group. The I2NSF working group is meeting this afternoon at 13:30 On the agenda ([1]) there=E2=80=99s a 10-minute slot for controlling = IPsec endpoints using SDN ([2]). I think this draft has two issues: Their IKE-less case (case #2) has session keys generated on the = controller and forwarded to the IPsec endpoints. IMO this introduces new = ways for the keys to leak. The information flow in the draft is all from the controller to the = endpoints. The controller is assumed to a-priori know the entire = topology of all endpoints. IMO this is not realistic for VPNs where = often the addresses are allocated by third party ISPs. I think any SDN or SDN-like solution for populating the SPD and PAD = would need to have information flowing from the endpoints to the = controller about the protected domain of that endpoint. Before that you = can=E2=80=99t generate the SPDs. OTOH this group failed in creating something like that in the AD-VPN = work item. Several companies are now offering their own =E2=80=9CSD-WAN=E2= =80=9D solution that is partly about automatic configuration of IPsec = tunnels. So in case you=E2=80=99re interested, you can come to the I2NSF meeting = and hear their presentation. Yoav [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt = [2] = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 = --Apple-Mail=_AF703295-2FD9-43A3-9E79-D4A0D494A4B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

This = may be of interest to this working group.

The I2NSF working group is meeting this = afternoon at 13:30

On the agenda ([1]) there=E2=80=99s a 10-minute slot for = controlling IPsec endpoints using SDN ([2]).

I think this draft has two = issues:
  1. Their IKE-less case (case #2) has session keys generated on = the controller and forwarded to the IPsec endpoints. IMO this introduces = new ways for the keys to leak.
  2. The information flow = in the draft is all from the controller to the endpoints. The controller = is assumed to a-priori know the entire topology of all endpoints. IMO = this is not realistic for VPNs where often the addresses are allocated = by third party ISPs. 

I think any SDN or SDN-like = solution for populating the SPD and PAD would need to have information = flowing from the endpoints to the controller about the protected domain = of that endpoint. Before that you can=E2=80=99t generate the = SPDs. 

OTOH= this group failed in creating something like that in the AD-VPN work = item. Several companies are now offering their own =E2=80=9CSD-WAN=E2=80=9D= solution that is partly about automatic configuration of IPsec = tunnels.

So in = case you=E2=80=99re interested, you can come to the I2NSF meeting and = hear their presentation.


Yoav

[1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.t= xt
[2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-pro= tection-03

= --Apple-Mail=_AF703295-2FD9-43A3-9E79-D4A0D494A4B7-- --Apple-Mail=_C4A46A2A-0A96-4D9E-BA59-AD596B4F73F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbcbaAAoJELhJCxUKWMyZ1A8IAIJgawqsRXRP0p+msHeVnfcU XWSoOAYt+TRYcIc8Ok95qrJHQ4ByISPmdEeQi4I13v5sao/H7HMZzRJzzpe89n4d 0iYrvC3rPWEvk9FFJ4/naOrOqPirOwpCjhZ50np8wfNsdxZRdop4LhBk86NOd9IT 8Pf1e8d3fxVCJ4hQQ+kjtnjWmHN1in6qgNHW440Qdr4cmoQ837N0CgxIi/cWzLod eyaviRmYQjS3sTYtCk2Ffbbd600E0iJ94DqLrCCH1R3hw+W2Q9xNyxhUttCapZol eGTQdRguvc7w7KVPDfrFAGjuBI7xysiLxzumK0/Hc2Qm6XRcRkq6EYxnJFKKxV0= =MW0P -----END PGP SIGNATURE----- --Apple-Mail=_C4A46A2A-0A96-4D9E-BA59-AD596B4F73F4-- From nobody Tue Jul 18 01:34:35 2017 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 4883D131A54 for ; Tue, 18 Jul 2017 01:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-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 2xH4zXzQPuAU for ; Tue, 18 Jul 2017 01:34:30 -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 0C48D120227 for ; Tue, 18 Jul 2017 01:34:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xBYNz0pxJzhy; Tue, 18 Jul 2017 10:34:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1500366867; bh=DKAfmagWq5mUJgNiraofCDE5IYElL8gnQiIlLvkdNN8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=qaL1rL4EWinp8va7qXLV6EDcJvDY3ZDx2TlpDUaqGAjzs3zItg8DPRKGJHlFrSvXA fWqrhFIUSIIKdZhGg9ZJS3KwblTWa/EnuZ+jDi+/KkMxJqB16AX56FQBzWts2nbElo WNWHlXrQY7SwXUgMjSsbGd+pfD4SVTw3eTdZH0ic= 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 a3qRtjOt9WsD; Tue, 18 Jul 2017 10:34:25 +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, 18 Jul 2017 10:34:25 +0200 (CEST) Received: from [31.133.130.128] (dhcp-8280.meeting.ietf.org [31.133.130.128]) (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 24D272D52D1; Tue, 18 Jul 2017 04:34:24 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 24D272D52D1 Content-Type: multipart/alternative; boundary=Apple-Mail-A1687A35-D424-46A6-BB21-619AB273E3D9 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14F89) In-Reply-To: <5028E793-16B0-4FB7-A3DD-CB2BA1135DA7@gmail.com> Date: Tue, 18 Jul 2017 10:34:22 +0200 Cc: "IPsecme WG (ipsec@ietf.org)" Content-Transfer-Encoding: 7bit Message-Id: <7182A0C4-3465-4080-924C-7DBD96B62BA1@nohats.ca> References: <5028E793-16B0-4FB7-A3DD-CB2BA1135DA7@gmail.com> To: Yoav Nir Archived-At: Subject: Re: [IPsec] IPsec and SDN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:34:33 -0000 --Apple-Mail-A1687A35-D424-46A6-BB21-619AB273E3D9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ACE on Monday also mentioned this "SPDs without IKE" option. I expressed my c= oncern that they believe IKE is only about sharing SPDs and keys and warned t= hem against things like devices without batteries restarting and getting the= same values and end up re-using the same counter for AEAD algorithms. Sent from my iPhone > On Jul 18, 2017, at 10:29, Yoav Nir wrote: >=20 > Hi. >=20 > This may be of interest to this working group. >=20 > The I2NSF working group is meeting this afternoon at 13:30 >=20 > On the agenda ([1]) there=E2=80=99s a 10-minute slot for controlling IPsec= endpoints using SDN ([2]). >=20 > I think this draft has two issues: > Their IKE-less case (case #2) has session keys generated on the controller= and forwarded to the IPsec endpoints. IMO this introduces new ways for the k= eys to leak. > The information flow in the draft is all from the controller to the endpoi= nts. The controller is assumed to a-priori know the entire topology of all e= ndpoints. IMO this is not realistic for VPNs where often the addresses are a= llocated by third party ISPs.=20 >=20 > I think any SDN or SDN-like solution for populating the SPD and PAD would n= eed to have information flowing from the endpoints to the controller about t= he protected domain of that endpoint. Before that you can=E2=80=99t generate= the SPDs.=20 >=20 > OTOH this group failed in creating something like that in the AD-VPN work i= tem. Several companies are now offering their own =E2=80=9CSD-WAN=E2=80=9D s= olution that is partly about automatic configuration of IPsec tunnels. >=20 > So in case you=E2=80=99re interested, you can come to the I2NSF meeting an= d hear their presentation. >=20 >=20 > Yoav >=20 > [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt > [2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection= -03 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-A1687A35-D424-46A6-BB21-619AB273E3D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
ACE on Monday also mentioned this "SPD= s without IKE" option. I expressed my concern that they believe IKE is only a= bout sharing SPDs and keys and warned them against things like devices witho= ut batteries restarting and getting the same values and end up re-using the s= ame counter for AEAD algorithms.

Sent from my iPhone

On= Jul 18, 2017, at 10:29, Yoav Nir <ynir.ietf@gmail.com> wrote:

<= div>= Hi.

This may be of inter= est to this working group.

The I2NSF working group is meeting this afternoon at 13:30

On the agenda ([1]) there=E2= =80=99s a 10-minute slot for controlling IPsec endpoints using SDN ([2]).

I think this draft h= as two issues:
  1. Their IKE-less case (case #2) has session keys generated on the controller a= nd forwarded to the IPsec endpoints. IMO this introduces new ways for the ke= ys to leak.
  2. The information flow in the draft is all from= the controller to the endpoints. The controller is assumed to a-priori know= the entire topology of all endpoints. IMO this is not realistic for VPNs wh= ere often the addresses are allocated by third party ISPs. 

I think any SDN or S= DN-like solution for populating the SPD and PAD would need to have informati= on flowing from the endpoints to the controller about the protected domain o= f that endpoint. Before that you can=E2=80=99t generate the SPDs. 

OTOH this group failed= in creating something like that in the AD-VPN work item. Several companies a= re now offering their own =E2=80=9CSD-WAN=E2=80=9D solution that is partly a= bout automatic configuration of IPsec tunnels.

So in case you=E2=80=99re interested, you can c= ome to the I2NSF meeting and hear their presentation.
<= br class=3D"">

Yoa= v

[1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt<= /div>
[2] https://tools.ietf.org/ht= ml/draft-abad-i2nsf-sdn-ipsec-flow-protection-03
_= ______________________________________________
IPsec mailing= list
IPsec@ietf.org
https= ://www.ietf.org/mailman/listinfo/ipsec
= --Apple-Mail-A1687A35-D424-46A6-BB21-619AB273E3D9-- From nobody Tue Jul 18 01:45:11 2017 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 1FA0C131A55 for ; Tue, 18 Jul 2017 01:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 W6nx-0ABJ5IC for ; Tue, 18 Jul 2017 01:45:08 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 25805131A76 for ; Tue, 18 Jul 2017 01:45:08 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id 12so18685608wrb.1 for ; Tue, 18 Jul 2017 01:45:08 -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=kOPmvaBvFJ5DRkeG9KCNIBL3UNnkcT8WCFIvE9yKIPk=; b=ZeaZa1BWS4aestMDeww5gml7xi8ZkMPoVS4En5rJ6uUQEbwlsfkD4N4nNClBn3K6qP 4GjoThJa/8mZIK73toZ/oH20dA0zxVJUiWbuGBCTOdqBYECUGz5cBG5seMPmefTZ86gs kcHWau/n7xOY1ZHVOxwt/fMlwza1addUnA/m5Rh0MUAjXpBpVdCABCTFMsw4gJzVtWp+ UZRU9MF/LRSfAZntd6FviD8jjWYwG1oBwq71mDlgyHvjvSRp79x2JD/5lsZ1XQgptvDw 4SPuf1xBckgTuVRNQtb+xRDAWxQNItIVxlBK1seDzr75PCozuRN8JeCQGXzz4xi5PgiY ptlQ== 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=kOPmvaBvFJ5DRkeG9KCNIBL3UNnkcT8WCFIvE9yKIPk=; b=dLwONnj4ZWI3YjBY4BiUFeapbXyMe8/wsFhjnBtDD8DOJBZB9GLmUJcbWqdAbplrbU 0NO/SCCoTSekdTB54Be+8Ua3Pgyx6zuc2jWUHB0q1iQ3xL+4jjgS0AjB6wpFb6NLQj+t 4EH+xm5U9GqY+hLGHl6deoNqbb1GwDeEhZdK9WP8C0APRa0XLWnWVDbQae9Xf2kzvklj DQFMxOfwG8zRsj8oIXOuU2kjwqQvrZdobkNHF0YS4H3W7P0fd48ipk7sa8F33oR2VLZR gJ8Z2KscG6ZMSx92HatTLbJMh+9fiXMIt8Bizz1xOAL8zz6ccOdSBzTugPCd+uAH0y/Q f9wA== X-Gm-Message-State: AIVw113+nLnImWCaeWHYB4k9KovD3Vd0fY3cOYIhrrgP5U6zgKNKL3Bm cB0YdJ7PNrz8nqpAsTA= X-Received: by 10.28.88.9 with SMTP id m9mr869008wmb.57.1500367506704; Tue, 18 Jul 2017 01:45:06 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:1897:39e1:cca0:3db0? ([2001:67c:370:128:1897:39e1:cca0:3db0]) by smtp.gmail.com with ESMTPSA id e21sm1000904wra.43.2017.07.18.01.45.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 01:45:06 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6750B931-E783-4C30-B91C-0B809267A8C6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 10:45:04 +0200 In-Reply-To: <7182A0C4-3465-4080-924C-7DBD96B62BA1@nohats.ca> Cc: "IPsecme WG (ipsec@ietf.org)" To: Paul Wouters References: <5028E793-16B0-4FB7-A3DD-CB2BA1135DA7@gmail.com> <7182A0C4-3465-4080-924C-7DBD96B62BA1@nohats.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] IPsec and SDN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:45:10 -0000 --Apple-Mail=_6750B931-E783-4C30-B91C-0B809267A8C6 Content-Type: multipart/alternative; boundary="Apple-Mail=_853B21D3-8D3D-467C-8AD5-E140DCB1BE5D" --Apple-Mail=_853B21D3-8D3D-467C-8AD5-E140DCB1BE5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We=E2=80=99re going to have a screaming match tomorrow at TLS about = forward secrecy. You don=E2=80=99t have forward secrecy if the session keys were = generated by a third party. You=E2=80=99re replacing IKE with a = three-party system. But I am more worried about the second issue. I=E2=80=99m not sure SDN = is the right model for configuring IPsec. Yoav > On 18 Jul 2017, at 10:34, Paul Wouters wrote: >=20 > ACE on Monday also mentioned this "SPDs without IKE" option. I = expressed my concern that they believe IKE is only about sharing SPDs = and keys and warned them against things like devices without batteries = restarting and getting the same values and end up re-using the same = counter for AEAD algorithms. >=20 > Sent from my iPhone >=20 > On Jul 18, 2017, at 10:29, Yoav Nir > wrote: >=20 >> Hi. >>=20 >> This may be of interest to this working group. >>=20 >> The I2NSF working group is meeting this afternoon at 13:30 >>=20 >> On the agenda ([1]) there=E2=80=99s a 10-minute slot for controlling = IPsec endpoints using SDN ([2]). >>=20 >> I think this draft has two issues: >> Their IKE-less case (case #2) has session keys generated on the = controller and forwarded to the IPsec endpoints. IMO this introduces new = ways for the keys to leak. >> The information flow in the draft is all from the controller to the = endpoints. The controller is assumed to a-priori know the entire = topology of all endpoints. IMO this is not realistic for VPNs where = often the addresses are allocated by third party ISPs. >>=20 >> I think any SDN or SDN-like solution for populating the SPD and PAD = would need to have information flowing from the endpoints to the = controller about the protected domain of that endpoint. Before that you = can=E2=80=99t generate the SPDs. >>=20 >> OTOH this group failed in creating something like that in the AD-VPN = work item. Several companies are now offering their own =E2=80=9CSD-WAN=E2= =80=9D solution that is partly about automatic configuration of IPsec = tunnels. >>=20 >> So in case you=E2=80=99re interested, you can come to the I2NSF = meeting and hear their presentation. >>=20 >>=20 >> Yoav >>=20 >> [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt = >> [2] = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 = >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_853B21D3-8D3D-467C-8AD5-E140DCB1BE5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We=E2=80=99re going to have a screaming match tomorrow at TLS = about forward secrecy.

You don=E2=80=99t have forward secrecy if the session keys = were generated by a third party. You=E2=80=99re replacing IKE with a = three-party system.

But I am more worried about the second issue. I=E2=80=99m not = sure SDN is the right model for configuring IPsec.

Yoav

On 18 Jul 2017, at 10:34, Paul = Wouters <paul@nohats.ca> wrote:

ACE on Monday = also mentioned this "SPDs without IKE" option. I expressed my concern = that they believe IKE is only about sharing SPDs and keys and warned = them against things like devices without batteries restarting and = getting the same values and end up re-using the same counter for AEAD = algorithms.

Sent from my iPhone

On Jul 18, 2017, at 10:29, Yoav Nir <ynir.ietf@gmail.com>= wrote:

Hi.

This may be of interest to this working = group.

The = I2NSF working group is meeting this afternoon at 13:30

On the agenda ([1]) = there=E2=80=99s a 10-minute slot for controlling IPsec endpoints using = SDN ([2]).

I = think this draft has two issues:
  1. Their IKE-less case (case #2) has = session keys generated on the controller and forwarded to the IPsec = endpoints. IMO this introduces new ways for the keys to leak.
  2. The information flow in the draft is all from the controller = to the endpoints. The controller is assumed to a-priori know the entire = topology of all endpoints. IMO this is not realistic for VPNs where = often the addresses are allocated by third party = ISPs. 

I think any SDN or SDN-like solution for populating the SPD = and PAD would need to have information flowing from the endpoints to the = controller about the protected domain of that endpoint. Before that you = can=E2=80=99t generate the SPDs. 

OTOH this group failed in creating = something like that in the AD-VPN work item. Several companies are now = offering their own =E2=80=9CSD-WAN=E2=80=9D solution that is partly = about automatic configuration of IPsec tunnels.

So in case you=E2=80=99re interested, = you can come to the I2NSF meeting and hear their presentation.


Yoav

[1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.t= xt
[2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-pro= tection-03

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

= --Apple-Mail=_853B21D3-8D3D-467C-8AD5-E140DCB1BE5D-- --Apple-Mail=_6750B931-E783-4C30-B91C-0B809267A8C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbcqRAAoJELhJCxUKWMyZDqYIAIxWZA40pEUmXLkH6Q1W8ZBM cm5ig+S/NRL0xR1vN+LUjrLB4aVJZ0N4v0LV8/0p2df861lBKTKsQvVxY7y1d+Kq 4uubbthLLEnr/u6oFKNNzDg4drAeyjgpdEU2I+XkiwaY4oQ2hZiUnvaH8eEiTWUk vHkj1PHxW/xrOfSXjEhYgWizrrKHJ7Y3LSsWqDblVC/8S75F64ajFcmgXXTlM8zG 8Pyij4VTiq86eV+IdLORDqlS//M/H8slyOiADELaJpJwu4sEDRwBFapQ4lxBs7cU nYYWWYOsZ8rYfSH6EUwsYscBEkbt/CUVxFpOZlTcOKR2R8zKibjKZEVQVsdoD/Y= =lQ4U -----END PGP SIGNATURE----- --Apple-Mail=_6750B931-E783-4C30-B91C-0B809267A8C6-- From nobody Tue Jul 18 04:10:57 2017 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 B1DE512F280 for ; Tue, 18 Jul 2017 04:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, 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 kkMaw5u-N79c for ; Tue, 18 Jul 2017 04:10:54 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 35BEF12EB99 for ; Tue, 18 Jul 2017 04:10:54 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id 12so24175991wrb.1 for ; Tue, 18 Jul 2017 04:10:54 -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-transfer-encoding:content-language; bh=T1wJDcqniPFmdbKWS2m5ALCjknPs0lsnF6d5GtQOEsA=; b=p7Iw3+5jX94/kcZ7QyC6GbDbzxSOCPZPum/gpM5nGSwO5Z9JqyvpAE3b4A5dW6Hg04 zhfSQb54fXYcFTbX047p2OX3GpZVX9hEZuLsIVRGP7uOaV1uABAYunrJYc+v/2e4iLdd skrkpdlC+uBUW/A4U4FplBX8+ZnEYv212vfuU1cbXdq/fl+t9nIB00BBzE4WLHEFOoZk Cx0qp+jTIBQgnbfKTp+g5BkU1BNqouHzqomAW0PWrQn0cB9Fvj3esXCzgeymaHbsyzWK aX71kZICytzZidVDDxeQITWxEMgdkTmLIVwgdUh0++P8MtA5kjAknYv+tZrueVjefQVZ 8OoA== 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-transfer-encoding :content-language; bh=T1wJDcqniPFmdbKWS2m5ALCjknPs0lsnF6d5GtQOEsA=; b=dRncH/NpgjfjsVxywzggh8zmyzj8O6q/GGzqq2782OyR2BesHg0xBCIet6v2usz5vG oyqdyVdtAF+SjQm4mvF0bMHolCYXGzXPzvf/RCnWbkLwWjtsIU1i5V4lJh422TPkRjU6 s9Z8qlJUrAhCfhSnLjel/tlab7rMMa7CqD81bCHgTzFJ4BuEvAKEGpQHUO/iAbuAPe9w kjYrb9J2Ms9b/y8xbqEbz9gVu/RgPLPNQQaHsvcCF0WRGR9gJwRh0dawgDQiZdo8l/jz 2bk26hOArm7imIP/hZbRXGPtbNRk432PKESFYK2Cr/05+KapsKGNkXGS8DGnT03LeuDj TH0g== X-Gm-Message-State: AIVw113MhWnDfn98Brc32VIVrsZcVRPItJP8/R5KLjMD6a6W8i9UjY6w Q8L4+amOsTETy2E4PDx4vQ== X-Received: by 10.28.134.11 with SMTP id i11mr1710318wmd.77.1500376252481; Tue, 18 Jul 2017 04:10:52 -0700 (PDT) Received: from [192.168.43.74] ([2.53.163.195]) by smtp.gmail.com with ESMTPSA id 21sm12943288wmo.16.2017.07.18.04.10.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 04:10:51 -0700 (PDT) To: Yoav Nir , Paul Wouters Cc: "IPsecme WG (ipsec@ietf.org)" References: <5028E793-16B0-4FB7-A3DD-CB2BA1135DA7@gmail.com> <7182A0C4-3465-4080-924C-7DBD96B62BA1@nohats.ca> From: Yaron Sheffer Message-ID: Date: Tue, 18 Jul 2017 13:10:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [IPsec] IPsec and SDN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:10:56 -0000 For key management you might want to refer them to the old but still useful RFC 4107 . Thanks, Yaron On 18/07/17 10:45, Yoav Nir wrote: > We’re going to have a screaming match tomorrow at TLS about forward > secrecy. > > You don’t have forward secrecy if the session keys were generated by a > third party. You’re replacing IKE with a three-party system. > > But I am more worried about the second issue. I’m not sure SDN is the > right model for configuring IPsec. > > Yoav > >> On 18 Jul 2017, at 10:34, Paul Wouters > > wrote: >> >> ACE on Monday also mentioned this "SPDs without IKE" option. I >> expressed my concern that they believe IKE is only about sharing SPDs >> and keys and warned them against things like devices without >> batteries restarting and getting the same values and end up re-using >> the same counter for AEAD algorithms. >> >> Sent from my iPhone >> >> On Jul 18, 2017, at 10:29, Yoav Nir > > wrote: >> >>> Hi. >>> >>> This may be of interest to this working group. >>> >>> The I2NSF working group is meeting this afternoon at 13:30 >>> >>> On the agenda ([1]) there’s a 10-minute slot for controlling IPsec >>> endpoints using SDN ([2]). >>> >>> I think this draft has two issues: >>> >>> 1. Their IKE-less case (case #2) has session keys generated on the >>> controller and forwarded to the IPsec endpoints. IMO this >>> introduces new ways for the keys to leak. >>> 2. The information flow in the draft is all from the controller to >>> the endpoints. The controller is assumed to a-priori know the >>> entire topology of all endpoints. IMO this is not realistic for >>> VPNs where often the addresses are allocated by third party ISPs. >>> >>> >>> I think any SDN or SDN-like solution for populating the SPD and PAD >>> would need to have information flowing from the endpoints to the >>> controller about the protected domain of that endpoint. Before that >>> you can’t generate the SPDs. >>> >>> OTOH this group failed in creating something like that in the AD-VPN >>> work item. Several companies are now offering their own “SD-WAN” >>> solution that is partly about automatic configuration of IPsec tunnels. >>> >>> So in case you’re interested, you can come to the I2NSF meeting and >>> hear their presentation. >>> >>> >>> Yoav >>> >>> [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt >>> [2] >>> https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jul 18 04:35:32 2017 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 B6716131B16 for ; Tue, 18 Jul 2017 04:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 COCoGEdMN0rG for ; Tue, 18 Jul 2017 04:35:27 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id DFC6A131B2B for ; Tue, 18 Jul 2017 04:35:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id EA68620040; Tue, 18 Jul 2017 13:35:22 +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 nclEdiRnWpRS; Tue, 18 Jul 2017 13:35:22 +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 EBB691FFB4; Tue, 18 Jul 2017 13:35:21 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0AB66289-15C3-4DA5-AF14-1F25CDEBA706" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 13:35:21 +0200 In-Reply-To: <5028E793-16B0-4FB7-A3DD-CB2BA1135DA7@gmail.com> Cc: Rafa Marin-Lopez , "IPsecme WG (ipsec@ietf.org)" To: Yoav Nir References: <5028E793-16B0-4FB7-A3DD-CB2BA1135DA7@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] IPsec and SDN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:35:30 -0000 --Apple-Mail=_0AB66289-15C3-4DA5-AF14-1F25CDEBA706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoav: Thank you for these comments and pointing out our work. We will have the = opportunity to discuss in the meeting. Nevertheless, since we are not sure if we will have time enough to = discuss, let me send some initial comments inline.=20 > El 18 jul 2017, a las 10:29, Yoav Nir escribi=C3=B3= : >=20 > Hi. >=20 > This may be of interest to this working group. >=20 > The I2NSF working group is meeting this afternoon at 13:30 >=20 > On the agenda ([1]) there=E2=80=99s a 10-minute slot for controlling = IPsec endpoints using SDN ([2]). >=20 > I think this draft has two issues: > Their IKE-less case (case #2) has session keys generated on the = controller and forwarded to the IPsec endpoints. IMO this introduces new = ways for the keys to leak. [Rafa] Regarding this, the SDN controller is considered to be a trust = party. In fact, the assumption is there is already a security = association (think about NETCONF+SSL/SSH) with the NSF.=20 > The information flow in the draft is all from the controller to the = endpoints. The controller is assumed to a-priori know the entire = topology of all endpoints. IMO this is not realistic for VPNs where = often the addresses are allocated by third party ISPs.=20 [Rafa] Basically in a SDN model , the SDN controller needs to have a = knowledge of the topology , specifically of those devices it configures. = In fact, there is a secure registration process of the NSF with the = controller previous to any management process. That is a basic in SDN = landscape. >=20 > I think any SDN or SDN-like solution for populating the SPD and PAD = would need to have information flowing from the endpoints to the = controller about the protected domain of that endpoint. Before that you = can=E2=80=99t generate the SPDs.=20 [Rafa] I think you are missing the fact the administrator will send a = general flow protection policy to the SDN controller using the = northbound interface of the SDN controller. Based on that information = the SDN will create the SPD and PAD entries. Thus, I do not see any = problem on creating the SPDs based on that information coming from the = administrator. >=20 > OTOH this group failed in creating something like that in the AD-VPN = work item. Several companies are now offering their own =E2=80=9CSD-WAN=E2= =80=9D solution that is partly about automatic configuration of IPsec = tunnels. [Rafa] That=E2=80=99s why we should think to standardize this. Best Regards. >=20 > So in case you=E2=80=99re interested, you can come to the I2NSF = meeting and hear their presentation. >=20 >=20 > Yoav >=20 > [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt = > [2] = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 = >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- 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=_0AB66289-15C3-4DA5-AF14-1F25CDEBA706 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Yoav:

Thank you for these comments and pointing out our work. We = will have the opportunity to discuss in the meeting.

Nevertheless, since we = are not sure if we will have time enough to discuss, let me send some = initial comments inline. 


El 18 jul 2017, a las 10:29, = Yoav Nir <ynir.ietf@gmail.com> escribi=C3=B3:

Hi.

This may be of interest = to this working group.

The I2NSF working group is meeting this afternoon at = 13:30

On the = agenda ([1]) there=E2=80=99s a 10-minute slot for controlling IPsec = endpoints using SDN ([2]).

I think this draft has two issues:
  1. Their IKE-less case (case #2) has = session keys generated on the controller and forwarded to the IPsec = endpoints. IMO this introduces new ways for the keys to = leak.

[Rafa] Regarding this, the SDN controller is = considered to be a trust party. In fact, the assumption is there is = already a security association (think about NETCONF+SSL/SSH) with the = NSF. 

  1. The = information flow in the draft is all from the controller to the = endpoints. The controller is assumed to a-priori know the entire = topology of all endpoints. IMO this is not realistic for VPNs where = often the addresses are allocated by third party = ISPs. 

[Rafa] Basically in a SDN model , the SDN = controller needs to have a knowledge of the topology , specifically of = those devices it configures. In fact, there is a secure registration = process of the NSF with the controller previous to any management = process. That is a basic in SDN landscape.


I think any SDN or SDN-like = solution for populating the SPD and PAD would need to have information = flowing from the endpoints to the controller about the protected domain = of that endpoint. Before that you can=E2=80=99t generate the = SPDs. 

[Rafa] I think you are missing the fact the = administrator will send a general flow protection policy to the SDN = controller using the northbound interface of the SDN controller. Based = on that information the SDN will create the SPD and PAD entries. Thus, I = do not see any problem on creating the SPDs based on that information = coming from the administrator.


OTOH this group failed in creating something like that in the = AD-VPN work item. Several companies are now offering their own = =E2=80=9CSD-WAN=E2=80=9D solution that is partly about automatic = configuration of IPsec tunnels.

[Rafa] That=E2=80=99s why we should think to = standardize this.

Best Regards.

So in case you=E2=80=99re interested, = you can come to the I2NSF meeting and hear their presentation.


Yoav

[1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.t= xt
[2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-pro= tection-03

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

-------------------------------------------------------
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=_0AB66289-15C3-4DA5-AF14-1F25CDEBA706-- From nobody Tue Jul 18 04:46:11 2017 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 E1D4213178E for ; Tue, 18 Jul 2017 04:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 dlGas7SSnptV for ; Tue, 18 Jul 2017 04:46:05 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 485BE131451 for ; Tue, 18 Jul 2017 04:46:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 636592038D; Tue, 18 Jul 2017 13:46:04 +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 bhHbhpVPJs5B; Tue, 18 Jul 2017 13:46:04 +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 xenon44.um.es (Postfix) with ESMTPSA id E0A2420375; Tue, 18 Jul 2017 13:46:02 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <6D6237B4-7453-4265-9BBE-02C84F683E86@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_583A3CD9-77ED-4491-BCD0-3B67DA4A1B23" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 13:46:02 +0200 In-Reply-To: <7182A0C4-3465-4080-924C-7DBD96B62BA1@nohats.ca> Cc: Rafa Marin-Lopez , Yoav Nir , "IPsecme WG (ipsec@ietf.org)" To: Paul Wouters References: <5028E793-16B0-4FB7-A3DD-CB2BA1135DA7@gmail.com> <7182A0C4-3465-4080-924C-7DBD96B62BA1@nohats.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] IPsec and SDN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:46:08 -0000 --Apple-Mail=_583A3CD9-77ED-4491-BCD0-3B67DA4A1B23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul: What are the same values you have in mind? and why is that the device = has to end up re-using the same counter? Best regards. > El 18 jul 2017, a las 10:34, Paul Wouters escribi=C3=B3= : >=20 > ACE on Monday also mentioned this "SPDs without IKE" option. I = expressed my concern that they believe IKE is only about sharing SPDs = and keys and warned them against things like devices without batteries = restarting and getting the same values and end up re-using the same = counter for AEAD algorithms. >=20 > Sent from my iPhone >=20 > On Jul 18, 2017, at 10:29, Yoav Nir > wrote: >=20 >> Hi. >>=20 >> This may be of interest to this working group. >>=20 >> The I2NSF working group is meeting this afternoon at 13:30 >>=20 >> On the agenda ([1]) there=E2=80=99s a 10-minute slot for controlling = IPsec endpoints using SDN ([2]). >>=20 >> I think this draft has two issues: >> Their IKE-less case (case #2) has session keys generated on the = controller and forwarded to the IPsec endpoints. IMO this introduces new = ways for the keys to leak. >> The information flow in the draft is all from the controller to the = endpoints. The controller is assumed to a-priori know the entire = topology of all endpoints. IMO this is not realistic for VPNs where = often the addresses are allocated by third party ISPs.=20 >>=20 >> I think any SDN or SDN-like solution for populating the SPD and PAD = would need to have information flowing from the endpoints to the = controller about the protected domain of that endpoint. Before that you = can=E2=80=99t generate the SPDs.=20 >>=20 >> OTOH this group failed in creating something like that in the AD-VPN = work item. Several companies are now offering their own =E2=80=9CSD-WAN=E2= =80=9D solution that is partly about automatic configuration of IPsec = tunnels. >>=20 >> So in case you=E2=80=99re interested, you can come to the I2NSF = meeting and hear their presentation. >>=20 >>=20 >> Yoav >>=20 >> [1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt = >> [2] = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 = >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- 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=_583A3CD9-77ED-4491-BCD0-3B67DA4A1B23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Paul:

What are the same values you have in mind? and why is that = the device has to end up re-using the same counter?

Best regards.

El 18 jul 2017, a las 10:34, Paul Wouters <paul@nohats.ca> = escribi=C3=B3:

ACE on Monday also mentioned this "SPDs without IKE" option. = I expressed my concern that they believe IKE is only about sharing SPDs = and keys and warned them against things like devices without batteries = restarting and getting the same values and end up re-using the same = counter for AEAD algorithms.

Sent from my = iPhone

On Jul 18, 2017, at 10:29, = Yoav Nir <ynir.ietf@gmail.com> wrote:

Hi.

This may be of interest to this working group.

The I2NSF working group = is meeting this afternoon at 13:30

On the agenda ([1]) there=E2=80=99s a = 10-minute slot for controlling IPsec endpoints using SDN = ([2]).

I think = this draft has two issues:
  1. Their IKE-less case (case #2) has = session keys generated on the controller and forwarded to the IPsec = endpoints. IMO this introduces new ways for the keys to leak.
  2. The information flow in the draft is all from the controller = to the endpoints. The controller is assumed to a-priori know the entire = topology of all endpoints. IMO this is not realistic for VPNs where = often the addresses are allocated by third party = ISPs. 

I think any SDN or SDN-like solution for populating the SPD = and PAD would need to have information flowing from the endpoints to the = controller about the protected domain of that endpoint. Before that you = can=E2=80=99t generate the SPDs. 

OTOH this group failed in creating = something like that in the AD-VPN work item. Several companies are now = offering their own =E2=80=9CSD-WAN=E2=80=9D solution that is partly = about automatic configuration of IPsec tunnels.

So in case you=E2=80=99re interested, = you can come to the I2NSF meeting and hear their presentation.


Yoav

[1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.t= xt
[2] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-pro= tection-03

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

-------------------------------------------------------
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=_583A3CD9-77ED-4491-BCD0-3B67DA4A1B23-- From nobody Tue Jul 18 05:14:08 2017 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 9E5D0131DB2 for ; Tue, 18 Jul 2017 05:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 3NBYnddlQy9K for ; Tue, 18 Jul 2017 05:14:04 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 6662D131461 for ; Tue, 18 Jul 2017 05:13:54 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id 12so26595774wrb.1 for ; Tue, 18 Jul 2017 05:13:54 -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=oPuQ3yXpEsAyAdFo0Q+3zpzErLOn39o2PhL4TKQoYaE=; b=IQZ3wM9PaVeFS6wEy53DSuZktBCE1pXtp4TiLf81//IQ2MlwXD+QOnmdjWiycRJeo7 C2M+LlX4KZQfGPfQOVoAVbqZUS8k05prvYgGuyjBejVzVotHqFDmVrAv6XZCEtQx8qLV apmhPTCp8vlVoeuG19cnO557rtwyRU75HAO8U9r1XFnb9hEExmlmOQ/GL6B8LYpP9ZPA 58nH5ay+uZH2rR7U1gDYHe/skOWVs4+K9dR3EpIlqPN3VvwgvPWC98CXRjn9bNMKvpHZ x1nzM4n43iX7d2oK7zDVSCo6wbBQfdohTE74h67bPOH8l+1vDsxQ5qLrbuSMQel5/+6O RvGw== 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=oPuQ3yXpEsAyAdFo0Q+3zpzErLOn39o2PhL4TKQoYaE=; b=PaqF+3PNfuH/5Q9W4mPlVmA3Be/eWNyEfn+CflXqA6fPlepmbs33ZNNGZN7a0C4Spw CUDYBllt8K9jeT35tjq94rpS1mJFo5C5d1BlOW41JRu4qor36PLETUBDJ2DcMtJq0iEJ r7fdOPyPY4/zuUq63zMPqsO7vqlyrkTa3xdkzDhjCIIo1ZnrfOZtdy0hHBmyMJfIj5y0 vuzQ2+xLDl1g3hlCGEACwyFurmwvW0xo0AK2MT5/hMyCRCoLqNe66mg2h2/Q0bdWyOx/ 6YmeF8L2e02aDReHZZQ2CqlaKVT6QMuc99FwkeDyJrvHdBnBWO0IKvc8rbuqe9g2SPo0 OcrA== X-Gm-Message-State: AIVw113PV8dEQ8gp51/c4CRzA1r4xSRIeW7s6wIT6jHf9AxxjNnSt/aZ qrMwV5OgZjjceVHvi9o= X-Received: by 10.223.173.235 with SMTP id w98mr1086121wrc.4.1500380032876; Tue, 18 Jul 2017 05:13:52 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:cdff:5c1a:87f0:2e96? ([2001:67c:370:128:cdff:5c1a:87f0:2e96]) by smtp.gmail.com with ESMTPSA id 70sm1475340wrm.62.2017.07.18.05.13.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 05:13:52 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4EA4EB16-1EC0-437F-97E6-EE7E0317D794"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 14:13:50 +0200 In-Reply-To: Cc: "IPsecme WG (ipsec@ietf.org)" To: Rafa Marin-Lopez References: <5028E793-16B0-4FB7-A3DD-CB2BA1135DA7@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] IPsec and SDN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:14:07 -0000 --Apple-Mail=_4EA4EB16-1EC0-437F-97E6-EE7E0317D794 Content-Type: multipart/alternative; boundary="Apple-Mail=_F743B395-96D1-49E6-B765-11636AFEC760" --Apple-Mail=_F743B395-96D1-49E6-B765-11636AFEC760 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi > On 18 Jul 2017, at 13:35, Rafa Marin-Lopez wrote: >=20 > Hi Yoav: >=20 > Thank you for these comments and pointing out our work. We will have = the opportunity to discuss in the meeting. >=20 > Nevertheless, since we are not sure if we will have time enough to = discuss, let me send some initial comments inline. >=20 >=20 >> El 18 jul 2017, a las 10:29, Yoav Nir > escribi=C3=B3: >>=20 >> Hi. >>=20 >> This may be of interest to this working group. >>=20 >> The I2NSF working group is meeting this afternoon at 13:30 >>=20 >> On the agenda ([1]) there=E2=80=99s a 10-minute slot for controlling = IPsec endpoints using SDN ([2]). >>=20 >> I think this draft has two issues: >> Their IKE-less case (case #2) has session keys generated on the = controller and forwarded to the IPsec endpoints. IMO this introduces new = ways for the keys to leak. >=20 > [Rafa] Regarding this, the SDN controller is considered to be a trust = party. In fact, the assumption is there is already a security = association (think about NETCONF+SSL/SSH) with the NSF. The old joke is that three people can keep a secret as long as two of = them are dead. Any three-party system is more fragile than a two party = system. Key transport also increases the attack surface. Yes, you can = make the claim that any vulnerability that would leak or compromise the = session key would just as easily be able to compromise long-term keys = (as in case 1), but the system does end up more fragile. >=20 >> The information flow in the draft is all from the controller to the = endpoints. The controller is assumed to a-priori know the entire = topology of all endpoints. IMO this is not realistic for VPNs where = often the addresses are allocated by third party ISPs. >=20 > [Rafa] Basically in a SDN model , the SDN controller needs to have a = knowledge of the topology , specifically of those devices it configures. = In fact, there is a secure registration process of the NSF with the = controller previous to any management process. That is a basic in SDN = landscape. Then perhaps an SDN model is not appropriate for VPNs. Imagine a = corporation with many branches, like Starbucks or the Gap. They open a = new store in some shopping center. Depending on how the network there is = organized, the new store gets its network configuration either from the = shopping center of from a local ISP. The automated way of doing things = (which is used in the SD-WAN products) is for the VPN gateway in the = store to send its routing information to the center (using a routing = protocol or some other protocol), which allows the center to build a = so-called big picture. This big picture can be the basis of the SPD = entries pushed by the center to the branch VPN gateway. >> I think any SDN or SDN-like solution for populating the SPD and PAD = would need to have information flowing from the endpoints to the = controller about the protected domain of that endpoint. Before that you = can=E2=80=99t generate the SPDs. >=20 > [Rafa] I think you are missing the fact the administrator will send a = general flow protection policy to the SDN controller using the = northbound interface of the SDN controller. Based on that information = the SDN will create the SPD and PAD entries. Thus, I do not see any = problem on creating the SPDs based on that information coming from the = administrator. Right. And the administrator doesn=E2=80=99t have that information. In = the Gap example, the center is in San Francisco. The routing information = exists in the router that is in the new location (say, Prague). If the = technology assumes that the administrator knows everything, we need to = make it happen by having the manager of the new store look at the = routing table on the VPN gateway and sending a screenshot to the = administrator. That is not automated. It=E2=80=99s fine to have the administrator tell the controller whether = branches should talk directly to each other or only directly to the = datacenter, but it doesn=E2=80=99t scale to have and maintain all the = relevant subnets at the center. That works within the datacenter where = the administrator actually controls things. >>=20 >> OTOH this group failed in creating something like that in the AD-VPN = work item. Several companies are now offering their own =E2=80=9CSD-WAN=E2= =80=9D solution that is partly about automatic configuration of IPsec = tunnels. >=20 > [Rafa] That=E2=80=99s why we should think to standardize this. I agree, but I=E2=80=99m not sure this is the right solution. Yoav --Apple-Mail=_F743B395-96D1-49E6-B765-11636AFEC760 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

On 18 Jul 2017, at 13:35, Rafa Marin-Lopez = <rafa@um.es> = wrote:

Hi Yoav:

Thank you for these = comments and pointing out our work. We will have the opportunity to = discuss in the meeting.

Nevertheless, since = we are not sure if we will have time enough to discuss, let me send some = initial comments inline. 


El 18 = jul 2017, a las 10:29, Yoav Nir <ynir.ietf@gmail.com> escribi=C3=B3:

Hi.

This may be of interest to this working = group.

The = I2NSF working group is meeting this afternoon at 13:30

On the agenda ([1]) = there=E2=80=99s a 10-minute slot for controlling IPsec endpoints using = SDN ([2]).

I = think this draft has two issues:
  1. Their IKE-less case (case #2) has = session keys generated on the controller and forwarded to the IPsec = endpoints. IMO this introduces new ways for the keys to = leak.

[Rafa] Regarding this, the SDN = controller is considered to be a trust party. In fact, the assumption is = there is already a security association (think about NETCONF+SSL/SSH) = with the NSF.

The old joke is that three people can keep a = secret as long as two of them are dead. Any three-party system is more = fragile than a two party system. Key transport also increases the attack = surface. Yes, you can make the claim that any vulnerability that would = leak or compromise the session key would just as easily be able to = compromise long-term keys (as in case 1), but the system does end up = more fragile.


  1. The information flow in = the draft is all from the controller to the endpoints. The controller is = assumed to a-priori know the entire topology of all endpoints. IMO this = is not realistic for VPNs where often the addresses are allocated by = third party ISPs. 

[Rafa] Basically in a = SDN model , the SDN controller needs to have a knowledge of the topology = , specifically of those devices it configures. In fact, there is a = secure registration process of the NSF with the controller previous to = any management process. That is a basic in SDN = landscape.

Then perhaps an SDN model is not appropriate for VPNs. = Imagine a corporation with many branches, like Starbucks or the Gap. = They open a new store in some shopping center. Depending on how the = network there is organized, the new store gets its network configuration = either from the shopping center of from a local ISP. The automated way = of doing things (which is used in the SD-WAN products) is for the VPN = gateway in the store to send its routing information to the center = (using a routing protocol or some other protocol), which allows the = center to build a so-called big picture. This big picture can be the = basis of the SPD entries pushed by the center to the branch VPN = gateway.

I think any SDN = or SDN-like solution for populating the SPD and PAD would need to have = information flowing from the endpoints to the controller about the = protected domain of that endpoint. Before that you can=E2=80=99t = generate the SPDs. 
[Rafa] I think you are missing the = fact the administrator will send a general flow protection policy to the = SDN controller using the northbound interface of the SDN controller. = Based on that information the SDN will create the SPD and PAD entries. = Thus, I do not see any problem on creating the SPDs based on that = information coming from the = administrator.

Right. And the administrator doesn=E2=80=99t have that = information. In the Gap example, the center is in San Francisco. The = routing information exists in the router that is in the new location = (say, Prague). If the technology assumes that the administrator knows = everything, we need to make it happen by having the manager of the new = store look at the routing table on the VPN gateway and sending a = screenshot to the administrator. That is not automated.

It=E2=80=99s fine to have the administrator tell = the controller whether branches should talk directly to each other or = only directly to the datacenter, but it doesn=E2=80=99t scale to have = and maintain all the relevant subnets at the center. That works within = the datacenter where the administrator actually controls = things.


OTOH this group failed in creating something like that in the = AD-VPN work item. Several companies are now offering their own = =E2=80=9CSD-WAN=E2=80=9D solution that is partly about automatic = configuration of IPsec tunnels.

[Rafa] That=E2=80=99s why we should = think to standardize this.

I agree, but I=E2=80=99m not sure this is the = right solution.

Yoav


= --Apple-Mail=_F743B395-96D1-49E6-B765-11636AFEC760-- --Apple-Mail=_4EA4EB16-1EC0-437F-97E6-EE7E0317D794 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbft+AAoJELhJCxUKWMyZP/YH/2l0WqgrXgpsQTdgUO5Ra16Y xJX8x+J1c6d0Y857SL33NFheYedvigZ7X1V4FjnkWKfyk1tHjhMo2d7Epyy2C7uj Nm1lKa5dxWDA811dIAKN/RDHPLKNadJktayHmNRiGewqByLTbb96I7iaperdclKH 1jw/wEtL2BOR1Op/brG7Ujq4DeUAEQcVtLRjXELmvu+PM5JLEV8buE8AhbboJTA2 Qm0eVm/pMNzonHd57uzyjFgMBNCfsLusRFRYsVhju4qmCJNpOMPENpmEPn5bbxBX nO6IQ/ixhcoEhtEd9Cpo4axXdTORbjyhsbgJaoeqUuBV2GRXpfG1WYPgvi4MS/4= =UlRu -----END PGP SIGNATURE----- --Apple-Mail=_4EA4EB16-1EC0-437F-97E6-EE7E0317D794-- From nobody Tue Jul 18 07:10:31 2017 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 1E769131B62; Tue, 18 Jul 2017 07:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 htJalNltSHY2; Tue, 18 Jul 2017 07:10:21 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 78670131B56; Tue, 18 Jul 2017 07:10:21 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id w198so14775682lff.2; Tue, 18 Jul 2017 07:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=xlLi/h8gu8+446MB5gCkMd0kuCkpzY3NOhYGHmuqT+8=; b=OdRI6oQBdhiWtDk5bCP3UAAs4AspN3FNV3P+ME+h9fXij9XX/gpXdwwFWp9T8g+gQX Yb2VUCwLMeXCjFQ0zaT1asMkokdBScfVLi5yBJs3SIfklbJJHFXAYnuRTLrZZjJ/GYk6 EfPd4RPNhAdezhgatb4JAWR1D2o9dvxlCJuNfSI1EwPO8xWRy5Tx3FBMe+8O4m4DzBAF SG24QRNK/HMEfRLvhs0QZnLcWpjYDwoc6IRDTjM0Cai88Bum/inFC6626ZTZOa2MIHnf mZV/KVCTMCyY1kGH37DZczvQxOULwsD0BXUntQErp3gbnKtkhFUFJ1mDhHx8+uXXz+AE JfDw== 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:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=xlLi/h8gu8+446MB5gCkMd0kuCkpzY3NOhYGHmuqT+8=; b=WiMc/fo1LIYL+bfeKxzpiMeg7g4/L1z+uzNx9Q3okZH12gUn00D1I2MsA3XVu2vO37 JvCXTgLSiYDiZxc65Tt5i08Pm9dWz7qZE8EoPbqzTCSL/Zp9G8K9AN3LQ1VTwvDXZJ3I HYRs0NPFtn82cxXwHf9bW6pANMsk7EOwoSr0D+D1Btr931NEKnfkfNvtySlqtP0fRwvI 1lCglBZh63ynGFqztxgfIzBEYfTkRhJW/mmgdXuofoIv2K3SrSWjp8T8eOWYcgAg85dQ nAFBX9t449DdxBcnbD2zHZ2bd6uIFZX8HaDubpx2LGC2+od5se5C5uZKWV7A7MepoR5O aVEg== X-Gm-Message-State: AIVw112uplxgDfPLxPGyUG/Drc8+YHF7E2gSgSBPRgbZ9HXcL8WPqh2/ k723XRslbwwgavFj X-Received: by 10.25.79.9 with SMTP id d9mr782503lfb.133.1500387017930; Tue, 18 Jul 2017 07:10:17 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id d15sm609237lfe.1.2017.07.18.07.10.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Jul 2017 07:10:17 -0700 (PDT) From: "Valery Smyslov" To: Cc: "IPsecME WG" , "'Rafa Marin-Lopez'" Date: Tue, 18 Jul 2017 17:10:17 +0300 Message-ID: <021c01d2ffcf$95f043b0$c1d0cb10$@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: AdL/zdLyioK6KpvdSXSAmrjFNg1nsA== Content-Language: ru Archived-At: Subject: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:10:23 -0000 Hi, I'm very much concerned with the IKE-less option presented in the draft. First, the Network Controller becomes a very attractive target for attacks in this case, since an attacker, if attack is successful, will gain all the keys for the whole system. Then, it is not clear for me how the keys are distributed in this case from the Network Controller to the End Entities. I presume that they are not sent in clear, so the End Entities must already have capabilities to run some security protocol (TLS, IPsec), and thus they must be already provisioned out of band with some security credentials (keys, certificates). So I don't understand what you gain in case you don't run IKEv2 on End Entities. In general, central distribution of session keys looks much less secure, than running IKEv2 on them. You loose PFS property, you loose the property that no one but the peers know the session keys etc. It is more fragile too. You must perform periodical rekey (update keys) and this must be done synchronously. All the rekey problems that were solved by IKE will arise again. Regards, Valery Smyslov. From nobody Tue Jul 18 07:32:28 2017 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 3FBD912F3CB; Tue, 18 Jul 2017 07:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 LP-YHLbDewlC; Tue, 18 Jul 2017 07:32:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 99402126C22; Tue, 18 Jul 2017 07:32:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xBjKy2xyVz8d; Tue, 18 Jul 2017 16:32:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1500388342; bh=u6/ftrga2WEyGp7eFT32pfhWkZzwP05WxwoMs6KgBCU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kP77A//RfZKAmurL0hD6uSCIyDtI3WYfV9R56YebuqqzZEqGtGgInOE/ujLV1/pNv pF/rhZZDitOp1XHuQ0UeBSSi4niDd1bPHRZPg75AyR+rCLL4t8Txn6g7PPA5nEng3R M7RxCmoV94x3nQ5qecepELAacLLd3/uXTy0xAzdM= 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 V-cu6qXGJQjd; Tue, 18 Jul 2017 16:32:21 +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, 18 Jul 2017 16:32:20 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1FDA72D52D1; Tue, 18 Jul 2017 10:32:20 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1FDA72D52D1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 180B940D3592; Tue, 18 Jul 2017 10:32:20 -0400 (EDT) Date: Tue, 18 Jul 2017 10:32:19 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: i2nsf@ietf.org, IPsecME WG , 'Rafa Marin-Lopez' In-Reply-To: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> Message-ID: References: <021c01d2ffcf$95f043b0$c1d0cb10$@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] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:32:27 -0000 On Tue, 18 Jul 2017, Valery Smyslov wrote: > I'm very much concerned with the IKE-less option presented in the draft. +1 > In general, central distribution of session keys looks much less secure, > than running IKEv2 on them. You loose PFS property, you loose > the property that no one but the peers know the session keys etc. It worries me too that we throw away the concept of end to end security. Endpoints needing to trust someone else that their keys are not leaked/malicious/compromised is generally not a good idea. > It is more fragile too. You must perform periodical rekey (update keys) > and this must be done synchronously. All the rekey problems that were > solved by IKE will arise again. Indeed! For example, if the ESP algorithm is an AEAD, and the endpoint reboots, and the central unit re-issues the same key, the endpoint will re-start the GCM counter at 1, thereby compromising the security and in effect leaking the private key. IKE is a lot more then just a channel to shove private keys and src/dst policies to endpoints. I would much rather see a minimal-IKEv2 implementation then this "non-IKE" style solution. Paul From nobody Tue Jul 18 08:06:15 2017 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 8FF4612EC5D; Tue, 18 Jul 2017 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 BPDyLcOYc1BL; Tue, 18 Jul 2017 08:06:12 -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 2D3E81204DA; Tue, 18 Jul 2017 08:06:11 -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 v6IF67UM013305 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Jul 2017 18:06:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v6IF677G023859; Tue, 18 Jul 2017 18:06:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22894.9183.134135.875338@fireball.acr.fi> Date: Tue, 18 Jul 2017 18:06:07 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: , IPsecME WG , "'Rafa Marin-Lopez'" In-Reply-To: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:06:14 -0000 Valery Smyslov writes: > I'm very much concerned with the IKE-less option presented in the > draft. > > First, the Network Controller becomes a very attractive target for > attacks in this case, since an attacker, if attack is successful, > will gain all the keys for the whole system. And it is big difference if you get the traffic keys, or if you get just the authentication keys used to authenticate the peers when creating traffic keys. I.e. any TLA would love to get their hands on all the traffic keys in one location, and then be able to decrypt any traffic going inside any of the IPsec tunnels. If controller only has the PSKs or similar to do the authentication between peers, then that means that the TLA needs to do active attack for each connection they want to break. Beause of this I think it is always best not to move the transport keys outside the boxes that needs them, i.e., keep them only on the nodes doing actual encryption / decryption. Also knowing that the controller most likely keeps all kind of logs and takes backup of the configurations it is keeping, this also makes the backups suitable targets for attacks, as they allow decryption previously stored flows of traffic, and this can be done years later when one of those backups accidently finds its way to wrong hands. > Then, it is not clear for me how the keys are distributed in this > case from the Network Controller to the End Entities. I presume that > they are not sent in clear, so the End Entities must already have > capabilities to run some security protocol (TLS, IPsec), and thus > they must be already provisioned out of band with some security > credentials (keys, certificates). So I don't understand what you > gain in case you don't run IKEv2 on End Entities. This I think is important question, i.e., what is the gain for not running IKEv2 between the nodes? > In general, central distribution of session keys looks much less secure, > than running IKEv2 on them. You loose PFS property, you loose > the property that no one but the peers know the session keys etc. > It is more fragile too. You must perform periodical rekey (update keys) > and this must be done synchronously. All the rekey problems that were > solved by IKE will arise again. And of course you do not know when to do rekey, as you do not know how many bytes each peers have been transmitting to be able to do rekey before there has been too much data encrypted with one key. -- kivinen@iki.fi From nobody Tue Jul 18 08:14:23 2017 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 00109128DE5; Tue, 18 Jul 2017 08:14:22 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pj-_N84hmvtH; Tue, 18 Jul 2017 08:14:22 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 AA60E1204DA; Tue, 18 Jul 2017 08:14:21 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id y43so4214369wrd.0; Tue, 18 Jul 2017 08:14:21 -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=jYNivFbmln4/QXxNixVLh8WvW8kReJs/j/BtL9gSP0Q=; b=taO+DbNwN8VZkdwbZXOrfs0rLyU/xOW3LHzaZsWXXV/+bb4sHgp4EaLBSrnPTUlFpt A3XGIZYNdhWDO15tvIzPoFQq+lcyzdt8ZOMen75dZ+3OKcKLZMP6HZuSDr82JLgcuY/X UjIl1wyKB4MEcTeziFMRXsE2EvmSrtKUKA29u7IdWXb4hjUcnagHk1YdDRz4AbTq8gFT knmyevfKw+WXmok7QZHPtTSvJ9QSbYW4YZdyvN9AR+HyXErLJXVTRBmZopWMp8eHb3iT B2gGj9kCzrYIuDA6TW6FLqwT3ZmOXTd3FwGxajOi6dZCjfJMJE/cXFNYZirlD8ZZVOnf 1W8g== 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=jYNivFbmln4/QXxNixVLh8WvW8kReJs/j/BtL9gSP0Q=; b=aL6SGm3N9CTMgOQ1APrLgPpJfNcUKYocQRm65zLZwyNQ4whXDmcjW5eoEdVZ2JU79c sIR2WYEQg+soo7ADX+jzblpzMzQBmqeW5ajjMGS4/sGsjg3FRO/+ncb7tQ6N1Bx2O5Ns 90ejqGKAS3jTjNCpKpF02n4hn/zqJNzUS2HBCoDEDV7Ua+u7WVhqjMvtzdZ9CLmjeybL ymkylXNG+x1bDsiRuWhOU9ARbR9ojJfaypPFvxTDTVGc5YL6NskwUxLTXgw2JvZ6+xrf vmf4SuooCSnAxBdSuIRXT0A6NZO0AS1E1FeHW8AOoXpMpTTq8Lc6BjMAvic0fnLeVxzj gu8A== X-Gm-Message-State: AIVw110qY5Q5yHxypLGjWBjs0YeDH/wHwd2Co5TUFefTauBSFv0fiAev svVOW8sjoGMiGKaBr4hG5w== X-Received: by 10.223.139.205 with SMTP id w13mr1566512wra.146.1500390860263; Tue, 18 Jul 2017 08:14:20 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:90bb:cb34:edfc:145b? ([2001:67c:370:128:90bb:cb34:edfc:145b]) by smtp.gmail.com with ESMTPSA id g63sm2836109wrd.11.2017.07.18.08.14.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 08:14:19 -0700 (PDT) From: Yoav Nir Message-Id: <35EBA0C1-B6C9-4DEE-B967-E98ACC2DEDD0@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A3424982-DA15-4FE4-A0CB-BFB8DF526F84"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 17:14:16 +0200 In-Reply-To: <22894.9183.134135.875338@fireball.acr.fi> Cc: Valery Smyslov , i2nsf@ietf.org, IPsecME WG , Rafa Marin-Lopez To: Tero Kivinen References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <22894.9183.134135.875338@fireball.acr.fi> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:14:23 -0000 --Apple-Mail=_A3424982-DA15-4FE4-A0CB-BFB8DF526F84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I mostly agree, but one point=E2=80=A6 > On 18 Jul 2017, at 17:06, Tero Kivinen wrote: > This I think is important question, i.e., what is the gain for not > running IKEv2 between the nodes? >=20 Simpler gateway, less code, no PK operations, no need for random number = generator. The counter-argument is that without all these you can=E2=80=99t setup a = TLS session to run netconf over. Yoav --Apple-Mail=_A3424982-DA15-4FE4-A0CB-BFB8DF526F84 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbiXJAAoJELhJCxUKWMyZM/cIAMlFff+YB3PqvnX4A2gtDg/l PGbZTYKC3vI0oQHibsQiO4IdowoDBJhSMJvPiK6gIE6hM61v8GZNJZIO8Zw18EKt eIh35jiUS19ld+4W1hZL8+zxpnq2Yr31jF7Esq69BLkL/FzZDZUuwvudNunVFJK2 9AlZWyvJlseLMiBsoIcAr0h4hNcg5+Ke0yp83rLpHDUQoCMnseI1JZhn+XiRv77d aQ2BMh0e2GA9wgVtxC85WTbt62BBHtABg0apQ0xpat5U+eu8HumvoIcll6n4r5wp nRHkJHZSt/2PUu3IECJvJzZcdhFJvX1mCHF6cm+fN4CPOTW8VG1NtJ0HiJqnSG4= =eShy -----END PGP SIGNATURE----- --Apple-Mail=_A3424982-DA15-4FE4-A0CB-BFB8DF526F84-- From nobody Tue Jul 18 08:34:43 2017 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 99DB4131B54; Tue, 18 Jul 2017 08:34: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Cy9zgHJ4DWWP; Tue, 18 Jul 2017 08:34:33 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 432BE131B26; Tue, 18 Jul 2017 08:34:33 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id 12so34529372wrb.1; Tue, 18 Jul 2017 08:34:33 -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-transfer-encoding:content-language; bh=4dqzSiKdZTMZ2BBBYoI3WUBL6Y53MiawNSHgfsOGn0M=; b=KzctQXH7y9yvnijwuU6gDs7LNVFwHp2rRWqDTbNtqXv3OdmoQd8d6eGGoNG7WNGy15 /+06B55hDZ63h+eEvVIGvJ3yvkAbtBjoKYZ6GJ0s3dMMy7CwIKYmdZPcTAFd/QB/ylUu qHthWe++D1LSXFzjcIFgQStzaSQeuTAxbbkQdUEufjOp0OY2TskSUYFlnQxeeyqzqbow 5U9ZnP51fxCUUOAWYCAokAbfvlitEhZoyxmMaazas80q3P8VEibdbLt2HwOPlzvqNB6O ZsHEfocxS1+qgHb0umiSE2+jaAN4Llo38EtVP7PMR9nksf6DxKwvZfn5VMm/3XMQfDO1 qsIQ== 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-transfer-encoding :content-language; bh=4dqzSiKdZTMZ2BBBYoI3WUBL6Y53MiawNSHgfsOGn0M=; b=cVwiBbeRx/A18F0lMArhjuSl3yfAuTkZNoKjee9pCdjz40+Fg3JFjA9xImyryRBm4R dAmWbj0yWv/94JNP5vEy7v2OLzeVhusINIFhmanUe7N7iESKZAJGA9hmYuRG4XkbzR4o 7iMF07APVDrWhZeG5TGTAAKi5MemFRxxrOY/kxk6wEkgp5iSJUUYFbjPiCqNlu9Q4QFu uanqQxtDRQilV/sPCvIYv3rxvgTHWLNN5Z9q7lUTmPAkBUdFAXP8ovWcq3EBAqz6rx3m NHvRlXqUFORc8EwyKcUX2/xeAiwE6w9uWpg4dd3Lnyzn5N09POBE9hqfoZIry5oVo7PU fUqw== X-Gm-Message-State: AIVw112eyFPHIBLPVxY0ujH3l/HcPm/g/giNpx5OVMwqoYYCF8f0wIhs w5r47q/QvpKcQkZCY8180A== X-Received: by 10.28.143.205 with SMTP id r196mr2288786wmd.69.1500392071848; Tue, 18 Jul 2017 08:34:31 -0700 (PDT) Received: from [31.133.143.161] (dhcp-8fa1.meeting.ietf.org. [31.133.143.161]) by smtp.gmail.com with ESMTPSA id y84sm13939362wmg.12.2017.07.18.08.34.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 08:34:31 -0700 (PDT) To: Yoav Nir , Tero Kivinen Cc: i2nsf@ietf.org, IPsecME WG , Valery Smyslov , Rafa Marin-Lopez References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <22894.9183.134135.875338@fireball.acr.fi> <35EBA0C1-B6C9-4DEE-B967-E98ACC2DEDD0@gmail.com> From: Yaron Sheffer Message-ID: Date: Tue, 18 Jul 2017 17:34:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <35EBA0C1-B6C9-4DEE-B967-E98ACC2DEDD0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:34:35 -0000 On 18/07/17 17:14, Yoav Nir wrote: > I mostly agree, but one point… > >> On 18 Jul 2017, at 17:06, Tero Kivinen wrote: > > >> This I think is important question, i.e., what is the gain for not >> running IKEv2 between the nodes? >> > Simpler gateway, less code, no PK operations, no need for random number generator. > > The counter-argument is that without all these you can’t setup a TLS session to run netconf over. > > Yoav > No random number generator? I don't think this is true even for a pure ESP endpoint. Thanks, Yaron From nobody Tue Jul 18 08:48:44 2017 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 40ADB127077; Tue, 18 Jul 2017 08:48:36 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5ZEV1S9YnmH9; Tue, 18 Jul 2017 08:48:34 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 A0735131B6E; Tue, 18 Jul 2017 08:48:33 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id y67so3641831wrb.3; Tue, 18 Jul 2017 08:48:33 -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=XEePghU/gsDMN2ANuE+npW2lkdzLeut4Ei7HjkXVEqQ=; b=PkjAEgIqnBW6MLgpnElzsdSMCzeva6GiObHOoajYdS+s1PRHpUQM9Sngdsa+uQRgc9 CAg/pUM3MuxDJMNLK0g58ol/qqDZr4CBXHD6Ba4nrgRzXBYqrw++WTfx+NIg8wxCZpxW uHydDsFKXTq9UnrV+PYpcPmtSGPWetZI7nbOCoCgmf/N60r+3KTHdQLPqEAr8IhXi4ZM cG+BRoKU60f12Z2vUkNkz4w8SmCTkWdPmegm7FPeN0AYOAvCKo4i1BL7Q+qdGzXn6Ng7 3priyp7WMiYVU2aC+0ko8DEh7sqVafWngwJlZL1YWf3qFIP3/+VhH3Qjl9d1wTL+j33X bu9g== 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=XEePghU/gsDMN2ANuE+npW2lkdzLeut4Ei7HjkXVEqQ=; b=OjVkBGgJkvzhjDz0KnUaLcBTa321vbu5pPoa4z2stYA/rD/I+uZNT0BYIVTBFPTHcK hBk3njwXV3eg4t3J1ocaXKqSaafQ55cSVxfkgh0/sBZgExorknZZ1LN/ONqDDwtHKkVF dvcRv7IQ2g17L26mYd8FErjiwn3BJetLvf+u+vn2GegyTy1vqZRPXLnw+w18liuhDvhk lTZGbqdX8Es3m2L9E03vwKEAx8mqWCxcPwphELiJoiS6r7YGg3L5ur/4AoeXhx1r/cE5 t/oyWk5mxPtdr3lo54b/H4awsqyhTNXsJsLvuO+jIjBBjjMPs0Ksr/vrYDnxKRKIvv8Z 3geQ== X-Gm-Message-State: AIVw113L5j8S3jnKKZGFN1k7sPq+YbBjMQ71svLiEwRbRGlIi51FFTYD aH1Ki+T9dFNJCg== X-Received: by 10.223.167.9 with SMTP id c9mr1495765wrd.163.1500392912234; Tue, 18 Jul 2017 08:48:32 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:90bb:cb34:edfc:145b? ([2001:67c:370:128:90bb:cb34:edfc:145b]) by smtp.gmail.com with ESMTPSA id d69sm13000928wmd.23.2017.07.18.08.48.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 08:48:31 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_80066D52-6E81-45C8-93C9-4F8B9D4BFE1B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 17:48:29 +0200 In-Reply-To: Cc: Tero Kivinen , i2nsf@ietf.org, IPsecME WG , Valery Smyslov , Rafa Marin-Lopez To: Yaron Sheffer References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <22894.9183.134135.875338@fireball.acr.fi> <35EBA0C1-B6C9-4DEE-B967-E98ACC2DEDD0@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:48:36 -0000 --Apple-Mail=_80066D52-6E81-45C8-93C9-4F8B9D4BFE1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 With AES-GCM, AES-CCM, ChaCha20-Poly1305 you don=E2=80=99t need a PRNG = at all. With AES-CBC you need an unpredictable IV, but you could generate them = by encrypting a counter with one AES key (that could be provided by the = controller) But you still need the TLS session. > On 18 Jul 2017, at 17:34, Yaron Sheffer wrote: >=20 > On 18/07/17 17:14, Yoav Nir wrote: >> I mostly agree, but one point=E2=80=A6 >>=20 >>> On 18 Jul 2017, at 17:06, Tero Kivinen wrote: >> >>=20 >>> This I think is important question, i.e., what is the gain for not >>> running IKEv2 between the nodes? >>>=20 >> Simpler gateway, less code, no PK operations, no need for random = number generator. >>=20 >> The counter-argument is that without all these you can=E2=80=99t = setup a TLS session to run netconf over. >>=20 >> Yoav >>=20 > No random number generator? I don't think this is true even for a pure = ESP endpoint. >=20 > Thanks, > Yaron --Apple-Mail=_80066D52-6E81-45C8-93C9-4F8B9D4BFE1B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZbi3OAAoJELhJCxUKWMyZdI0IAJU6N8RZfZ6z4nGnf3ltHKV3 NRnSl6Sc29i7AM6WnGD4BrUa8o5GvRhA+VfXPexNCOpASZJ1S0qgvLPw0H8NlJtW aqMgycv8g+f9GkrDWW5ili3NYD1rs2Ym9uq8q+PHcFNm+Zoki9eOUCKTPZuqlqTc KvhZ9rh9qOUUpjsta1vp/fIExWNoYky4mi+u0rufKfEUPmWcqZwLyvHFiQc30zOA IJ3mSRRVmvN0Rsdgfk5dOaJCM3OFqukCWqKFr/vto0L/WX/ywfB4AtGb8gER2ZxD pyUruBydAP3K0WQS4jjrJ7UwuU4erbbPNYZ1IOT/HwbAKdog0F4P1aU7UQuzG1M= =V+75 -----END PGP SIGNATURE----- --Apple-Mail=_80066D52-6E81-45C8-93C9-4F8B9D4BFE1B-- From nobody Tue Jul 18 08:56:48 2017 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 4828C131A54; Tue, 18 Jul 2017 08:56:47 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 mipUo3S_BXjK; Tue, 18 Jul 2017 08:56:45 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [IPv6:2001:720:1710:601::41]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42F131563; Tue, 18 Jul 2017 08:56:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 8AE8C20BED; Tue, 18 Jul 2017 17:56:41 +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 EilWx2cSFoxk; Tue, 18 Jul 2017 17:56:41 +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 21E4C208CB; Tue, 18 Jul 2017 17:56:39 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9A3867B6-63C9-40F8-B9CB-21EA706E36DB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 17:56:39 +0200 In-Reply-To: <22894.9183.134135.875338@fireball.acr.fi> Cc: Rafa Marin-Lopez , Valery Smyslov , i2nsf@ietf.org, IPsecME WG To: Tero Kivinen References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <22894.9183.134135.875338@fireball.acr.fi> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:56:47 -0000 --Apple-Mail=_9A3867B6-63C9-40F8-B9CB-21EA706E36DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tero, Valery: Please see inline. > El 18 jul 2017, a las 17:06, Tero Kivinen escribi=C3=B3= : >=20 > Valery Smyslov writes: >> I'm very much concerned with the IKE-less option presented in the >> draft. >>=20 >> First, the Network Controller becomes a very attractive target for >> attacks in this case, since an attacker, if attack is successful, >> will gain all the keys for the whole system. >=20 > And it is big difference if you get the traffic keys, or if you get > just the authentication keys used to authenticate the peers when > creating traffic keys. [Rafa] Overall, the SDN paradigm states the controller is a trusted = entity. The controller can generate session keys based on PNRG and sends = those keys and forget about them. No need to store any keys, just = generate them and distribute them. Having said this, in SDN paradigm, (and forgetting for a moment about = IPsec) , the SDN controller is ALWAYS a very attractive target. Reason: = if a SDN controller is attacked the attacker has the control over the = network (it can make the entire network no operative). Example: in the = SDN paradigm, for example, the =E2=80=9Crouter=E2=80=9D does not have = routing protocol, just routing/switching table. The SDN controller fills = tables. If the SDN is attacked the =E2=80=9Crouter=E2=80=9D does not = know how to react anymore.=20 Another conversation is if we like or dislike the SDN paradigm , in = general (regardless IPsec). >=20 > I.e. any TLA would love to get their hands on all the traffic keys in > one location, and then be able to decrypt any traffic going inside any > of the IPsec tunnels. >=20 > If controller only has the PSKs or similar to do the authentication > between peers, then that means that the TLA needs to do active attack > for each connection they want to break. >=20 > Beause of this I think it is always best not to move the transport > keys outside the boxes that needs them, i.e., keep them only on the > nodes doing actual encryption / decryption. >=20 > Also knowing that the controller most likely keeps all kind of logs > and takes backup of the configurations it is keeping, this also makes > the backups suitable targets for attacks, as they allow decryption > previously stored flows of traffic, and this can be done years later > when one of those backups accidently finds its way to wrong hands.=20 [Rafa] In reality, the controller can forget immediately the credentials = that has been generated.=20 As a security measure , the controller does not need to store any keys = it has distributed. >=20 >> Then, it is not clear for me how the keys are distributed in this >> case from the Network Controller to the End Entities. I presume that >> they are not sent in clear, so the End Entities must already have >> capabilities to run some security protocol (TLS, IPsec), and thus >> they must be already provisioned out of band with some security >> credentials (keys, certificates). So I don't understand what you >> gain in case you don't run IKEv2 on End Entities. >=20 > This I think is important question, i.e., what is the gain for not > running IKEv2 between the nodes? [Rafa] As Yoav mentioned, simpler devices.=20 >=20 >> In general, central distribution of session keys looks much less = secure, >> than running IKEv2 on them. You loose PFS property, you loose >> the property that no one but the peers know the session keys etc. >> It is more fragile too. You must perform periodical rekey (update = keys)=20 >> and this must be done synchronously. All the rekey problems that were=20= >> solved by IKE will arise again. >=20 > And of course you do not know when to do rekey, as you do not know how > many bytes each peers have been transmitting to be able to do rekey > before there has been too much data encrypted with one key. [Rafa] Basically, the SDN controller will know when to do the rekey. = Please, see the YANG model in our draft. There is notification = =E2=80=9Cexpire=E2=80=9D notifications: +---n spd-expire | +--ro index? uint64 +---n sadb_acquire | +--ro state uint32 +---n sadb_expire +--ro state uint32 Basically when the kernel sends an =E2=80=9Cexpire=E2=80=9D the NETCONF = server will capture it and sends the notification to the SDN controller. = The acquire is the same (our proof-of-concept does that) Best Regards. > --=20 > kivinen@iki.fi >=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=_9A3867B6-63C9-40F8-B9CB-21EA706E36DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Tero, Valery:

Please see inline.
El 18 jul 2017, a las 17:06, Tero Kivinen = <kivinen@iki.fi> = escribi=C3=B3:

Valery Smyslov writes:
I'm very much concerned = with the IKE-less option presented in the
draft.

First, the Network Controller becomes a very = attractive target for
attacks in this case, since an = attacker, if attack is successful,
will gain all the keys = for the whole system.

And it = is big difference if you get the traffic keys, or if you get
just the authentication keys used to authenticate the peers = when
creating traffic keys.

[Rafa] = Overall, the SDN paradigm states the controller is a trusted entity. The = controller can generate session keys based on PNRG and sends those keys = and forget about them. No need to store any keys, just generate them and = distribute them.

Having said this, = in SDN paradigm, (and forgetting for a moment about IPsec) , the SDN = controller is ALWAYS a very attractive target. Reason: if a SDN = controller is attacked the attacker has the control over the network (it = can make the entire network no operative). Example: in the SDN paradigm, = for example, the =E2=80=9Crouter=E2=80=9D does not have routing = protocol, just routing/switching table. The SDN controller fills tables. = If the SDN is attacked the =E2=80=9Crouter=E2=80=9D does not know how to = react anymore. 

Another = conversation is if we like or dislike the SDN paradigm , in general = (regardless IPsec).


I.e. any TLA would love to get their hands on all the traffic = keys in
one location, and then be able to decrypt any = traffic going inside any
of the IPsec tunnels.

If controller only has the PSKs or similar to = do the authentication
between peers, then that means that = the TLA needs to do active attack
for each connection they = want to break.


Beause of this I think it is always best not to move the = transport
keys outside the boxes that needs them, i.e., = keep them only on the
nodes doing actual encryption / = decryption.

Also knowing that the = controller most likely keeps all kind of logs
and takes = backup of the configurations it is keeping, this also makes
the backups suitable targets for attacks, as they allow = decryption
previously stored flows of traffic, and this = can be done years later
when one of those backups = accidently finds its way to wrong hands.

[Rafa] = In reality, the controller can forget immediately the credentials that = has been generated. 
As a security measure , the = controller does not need to store any keys it has distributed.


Then, it = is not clear for me how the keys are distributed in this
case from the Network Controller to the End Entities. I = presume that
they are not sent in clear, so the End = Entities must already have
capabilities to run some = security protocol (TLS, IPsec), and thus
they must be = already provisioned out of band with some security
credentials (keys, certificates). So I don't understand what = you
gain in case you don't run IKEv2 on End Entities.

This I think is important = question, i.e., what is the gain for not
running IKEv2 = between the nodes?

[Rafa] As Yoav mentioned, simpler devices. 

In = general, central distribution of session keys looks much less secure,
than running IKEv2 on them. You loose PFS property, you = loose
the property that no one but the peers know the = session keys etc.
It is more fragile too. You must perform = periodical rekey (update keys)
and this must be done = synchronously. All the rekey problems that were
solved by = IKE will arise again.

And of = course you do not know when to do rekey, as you do not know how
many bytes each peers have been transmitting to be able to do = rekey
before there has been too much data encrypted with = one key.

[Rafa] Basically, the SDN controller will know when to = do the rekey. Please, see the YANG model in our draft. There is = notification =E2=80=9Cexpire=E2=80=9D

 notifications:
       +---n spd-expire
       |  +--ro index?   = uint64
       +---n = sadb_acquire
       | =  +--ro state    uint32
    =    +---n sadb_expire
      =     +--ro state    uint32

Basically when the kernel sends an = =E2=80=9Cexpire=E2=80=9D the NETCONF server will capture it and sends = the notification to the SDN controller. The acquire is the same (our = proof-of-concept does that)

Best Regards.

--
kivinen@iki.fi

_______________________________________________
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=_9A3867B6-63C9-40F8-B9CB-21EA706E36DB-- From nobody Tue Jul 18 09:09:52 2017 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 6AE9C1287A0; Tue, 18 Jul 2017 09:09:45 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 mYRTDJJdyqrp; Tue, 18 Jul 2017 09:09:43 -0700 (PDT) Received: from xenon43.um.es (xenon43.um.es [155.54.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 58BC81200FC; Tue, 18 Jul 2017 09:09:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id 3C34E20BCF; Tue, 18 Jul 2017 18:09:42 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon43.um.es Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GK1u9hbaPNVs; Tue, 18 Jul 2017 18:09:42 +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 xenon43.um.es (Postfix) with ESMTPSA id A095D20BAB; Tue, 18 Jul 2017 18:09:39 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <2BB83398-20DA-49CD-8013-910C66A516E5@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_7A5B00D6-9599-4A94-B802-575CFB052CA4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 18:09:39 +0200 In-Reply-To: <35EBA0C1-B6C9-4DEE-B967-E98ACC2DEDD0@gmail.com> Cc: Rafa Marin-Lopez , Tero Kivinen , i2nsf@ietf.org, IPsecME WG , Valery Smyslov To: Yoav Nir References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <22894.9183.134135.875338@fireball.acr.fi> <35EBA0C1-B6C9-4DEE-B967-E98ACC2DEDD0@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 16:09:45 -0000 --Apple-Mail=_7A5B00D6-9599-4A94-B802-575CFB052CA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoav: > El 18 jul 2017, a las 17:14, Yoav Nir escribi=C3=B3= : >=20 > I mostly agree, but one point=E2=80=A6 >=20 >> On 18 Jul 2017, at 17:06, Tero Kivinen wrote: >=20 > >=20 >> This I think is important question, i.e., what is the gain for not >> running IKEv2 between the nodes? >>=20 >=20 > Simpler gateway, less code, no PK operations, no need for random = number generator. >=20 > The counter-argument is that without all these you can=E2=80=99t setup = a TLS session to run netconf over. [Rafa] The argument is the NSF will need this TLS/SSH session with the = controller regardless IPsec management. It will need it for routing = management, IDS, firewall, management etc=E2=80=A6 Since that TLS/SSH is = already there (regardless IPsec management) we can leverage this. Also = the implementation of the NETCONF server is required no matter if we = have IPsec management. Therefore if you have case 1 vs case 2 , case 1 = still needs the NETCONF server in addition to IKE implementation, case 2 = does not. Therefore, as you mention makes the NSF simpler, no doubt. >=20 > Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- 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=_7A5B00D6-9599-4A94-B802-575CFB052CA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Yoav:

El 18 jul 2017, a las 17:14, = Yoav Nir <ynir.ietf@gmail.com> escribi=C3=B3:

I = mostly agree, but one point=E2=80=A6

On 18 Jul 2017, at = 17:06, Tero Kivinen <kivinen@iki.fi> wrote:

<snip/>

This I think is important question, i.e., what = is the gain for not
running IKEv2 between the nodes?


Simpler gateway, = less code, no PK operations, no need for random number generator.

The counter-argument is that without all these = you can=E2=80=99t setup a TLS session to run netconf over.

[Rafa] = The argument is the NSF will need this TLS/SSH session with the = controller regardless IPsec management. It will need it for routing = management, IDS, firewall, management etc=E2=80=A6 Since that TLS/SSH is = already there (regardless IPsec management) we can leverage this. Also = the implementation of the NETCONF server is required no matter if we = have IPsec management. Therefore if you have case 1 vs case 2 , case 1 = still needs the NETCONF server in addition to IKE implementation, case 2 = does not. Therefore, as you mention makes the NSF simpler, no = doubt.



Yoav

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

-------------------------------------------------------
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=_7A5B00D6-9599-4A94-B802-575CFB052CA4-- From nobody Tue Jul 18 09:11:22 2017 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 DCA901287A0; Tue, 18 Jul 2017 09:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 wRP7WpsF2Z3j; Tue, 18 Jul 2017 09:11:19 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2231200FC; Tue, 18 Jul 2017 09:11:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 98F81201D1; Tue, 18 Jul 2017 18:11:17 +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 iS4nUpHLHYwn; Tue, 18 Jul 2017 18:11:17 +0200 (CEST) Received: from [192.168.100.23] (unknown [185.154.58.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon44.um.es (Postfix) with ESMTPSA id DB44D20128; Tue, 18 Jul 2017 18:11:16 +0200 (CEST) To: Valery Smyslov , i2nsf@ietf.org Cc: IPsecME WG , 'Rafa Marin-Lopez' References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= Message-ID: Date: Tue, 18 Jul 2017 18:11:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: es-ES Archived-At: Subject: Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 16:11:21 -0000 Hi Valery, all, > > In general, central distribution of session keys looks much less secure, > than running IKEv2 on them. That's arguable, yes. But being less secure does not mean being useless. Coming to my previous comment, we don't use RSA with 8192 bit keys for everything. Although it is more secure, there are scenarios were a lighter approach is enough. If running IKE is too much for your devices, the IKE-less option might work for you if your security contraints are fewer. This SDN-based approach does not need to solve everyone's problems for every possible scenario. Neither does Kerberos, IPsec itself nor any other security protocol. > You loose PFS property, I don't see why. Actually, keys on the controller are generated by a secure RNG so every key you generate is completely unrelated to the previous one. That's indeed an advantage, rather than the opposite. > you loose > the property that no one but the peers know the session keys etc. Right. > It is more fragile too. You must perform periodical rekey (update keys) > and this must be done synchronously. You have to do it by pairs, does not seem that difficult. And, as IKE does, you create the new ones and, once created, delete the old ones. I don't see the synchrony problem that important. > All the rekey problems that were > solved by IKE will arise again. Prior IKE we had a phone call / email / SSH based rekeying. I don't think having an automated central entity using a secure control protocol such as NETCONF over SSH/TLS is exactly the same. Regards, Alejandro > Regards, > Valery Smyslov. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jul 18 09:32:44 2017 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 3DDC7129B5E; Tue, 18 Jul 2017 09:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 GYbx8HkLJga4; Tue, 18 Jul 2017 09:32:35 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 849B21200C5; Tue, 18 Jul 2017 09:32:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 041A81FE16; Tue, 18 Jul 2017 18:32:33 +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 T1ESkLDdjIYt; Tue, 18 Jul 2017 18:32:32 +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 xenon44.um.es (Postfix) with ESMTPSA id 60BB620057; Tue, 18 Jul 2017 18:32:32 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1BF0FFC2-C7B3-4E1F-A249-2C2799D4B015" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 18:32:32 +0200 In-Reply-To: Cc: Rafa Marin-Lopez , Valery Smyslov , i2nsf@ietf.org, IPsecME WG To: Paul Wouters References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 16:32:37 -0000 --Apple-Mail=_1BF0FFC2-C7B3-4E1F-A249-2C2799D4B015 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Paul:=20 >> It is more fragile too. You must perform periodical rekey (update = keys) >> and this must be done synchronously. All the rekey problems that were >> solved by IKE will arise again. >=20 > Indeed! For example, if the ESP algorithm is an AEAD, and the endpoint > reboots, and the central unit re-issues the same key, [Rafa] Just a clarification, the central unit (Security Controller) will = never re-issue the same key (it is pseudo-randomly generated by the = controller) Moreover the controller will know when to do the rekey and the end point = the requires it. We have those notifications (expires) in our YANG model = for this reason. > the endpoint will > re-start the GCM counter at 1, thereby compromising the security and = in > effect leaking the private key. >=20 > IKE is a lot more then just a channel to shove private keys and > src/dst policies to endpoints. I would much rather see a minimal-IKEv2 > implementation then this "non-IKE" style solution. >=20 > Paul >=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=_1BF0FFC2-C7B3-4E1F-A249-2C2799D4B015 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Paul: 

It is more fragile too. = You must perform periodical rekey (update keys)
and this = must be done synchronously. All the rekey problems that were
solved by IKE will arise again.

Indeed! For example, if the ESP algorithm is an AEAD, and the = endpoint
reboots, and the central unit re-issues the same = key,

[Rafa] Just a clarification, the = central unit (Security Controller) will never re-issue the same key (it = is pseudo-randomly generated by the controller)

Moreover the controller will know when to do the rekey and = the end point the requires it. We have those notifications (expires) in = our YANG model for this reason.

the endpoint = will
re-start the GCM counter at 1, thereby compromising = the security and in
effect leaking the private key.

IKE is a lot more then just a channel to shove = private keys and
src/dst policies to endpoints. I would = much rather see a minimal-IKEv2
implementation then this = "non-IKE" style solution.

Paul

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

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_1BF0FFC2-C7B3-4E1F-A249-2C2799D4B015-- From nobody Tue Jul 18 09:35:27 2017 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 E3C1712700F; Tue, 18 Jul 2017 09:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 nCnf1LVJaGfG; Tue, 18 Jul 2017 09:35:19 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4F987131B90; Tue, 18 Jul 2017 09:35:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 9F15D1FE16; Tue, 18 Jul 2017 18:35:13 +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 1TTEgkJr6VMU; Tue, 18 Jul 2017 18:35:13 +0200 (CEST) Received: from [192.168.1.7] (135.red-83-36-225.dynamicip.rima-tde.net [83.36.225.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon44.um.es (Postfix) with ESMTPSA id 9265020057; Tue, 18 Jul 2017 18:35:10 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_108DC393-618A-4F3B-B669-A182B24825FE"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Gabriel Lopez In-Reply-To: Date: Tue, 18 Jul 2017 18:35:06 +0200 Cc: Yaron Sheffer , i2nsf@ietf.org, IPsecME WG , Valery Smyslov , Rafa Marin Lopez , Tero Kivinen Message-Id: References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <22894.9183.134135.875338@fireball.acr.fi> <35EBA0C1-B6C9-4DEE-B967-E98ACC2DEDD0@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 16:35:21 -0000 --Apple-Mail=_108DC393-618A-4F3B-B669-A182B24825FE Content-Type: multipart/alternative; boundary="Apple-Mail=_C11A5E75-41C8-4F5F-8CBE-3A392E82DF49" --Apple-Mail=_C11A5E75-41C8-4F5F-8CBE-3A392E82DF49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoav, > El 18 jul 2017, a las 17:48, Yoav Nir escribi=C3=B3= : >=20 > With AES-GCM, AES-CCM, ChaCha20-Poly1305 you don=E2=80=99t need a PRNG = at all. >=20 > With AES-CBC you need an unpredictable IV, but you could generate them = by encrypting a counter with one AES key (that could be provided by the = controller) As you know IPsec is independent of the key management protocol. What = the draft proposes is a way to allow the Controller (in case 2) to = provide the required information for IPsec and to allow the Controller = to receive the IPsec kernel notification regarding SA required, SA = expiration, etc, etc.., exactly as IKE does. These notification, as Rafa = says, are modelled by the YANG file and allow the Controller to have the = whole view of what is is happening in the NSFs. It allows the Controller = to refresh keys, SA information, etc, etc, Regards, Gabi. >=20 > But you still need the TLS session. >=20 >> On 18 Jul 2017, at 17:34, Yaron Sheffer = wrote: >>=20 >> On 18/07/17 17:14, Yoav Nir wrote: >>> I mostly agree, but one point=E2=80=A6 >>>=20 >>>> On 18 Jul 2017, at 17:06, Tero Kivinen wrote: >>> >>>=20 >>>> This I think is important question, i.e., what is the gain for not >>>> running IKEv2 between the nodes? >>>>=20 >>> Simpler gateway, less code, no PK operations, no need for random = number generator. >>>=20 >>> The counter-argument is that without all these you can=E2=80=99t = setup a TLS session to run netconf over. >>>=20 >>> Yoav >>>=20 >> No random number generator? I don't think this is true even for a = pure ESP endpoint. >>=20 >> Thanks, >> Yaron >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_C11A5E75-41C8-4F5F-8CBE-3A392E82DF49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Yoav,

El 18 jul 2017, a las 17:48, = Yoav Nir <ynir.ietf@gmail.com> escribi=C3=B3:

With = AES-GCM, AES-CCM, ChaCha20-Poly1305 you don=E2=80=99t need a PRNG at = all.

With AES-CBC you need an unpredictable = IV, but you could generate them by encrypting a counter with one AES key = (that could be provided by the controller)


As you know IPsec is independent of the key = management protocol. What the draft proposes is a way to allow the = Controller (in case 2) to provide the required information for IPsec and = to allow the Controller to receive the IPsec kernel notification = regarding SA required, SA expiration, etc, etc.., exactly as IKE does. = These notification, as Rafa says, are modelled by the YANG file and = allow the Controller to have the whole view of what is is happening in = the NSFs. It allows the Controller to refresh keys, SA information, etc, = etc, 

Regards, = Gabi. 



But you still need the TLS session.

On 18 Jul 2017, at = 17:34, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

On 18/07/17 17:14, Yoav Nir wrote:
I mostly agree, but one point=E2=80=A6

On 18 Jul = 2017, at 17:06, Tero Kivinen <kivinen@iki.fi> wrote:
<snip/>

This I think is = important question, i.e., what is the gain for not
running = IKEv2 between the nodes?

Simpler= gateway, less code, no PK operations, no need for random number = generator.

The counter-argument is that = without all these you can=E2=80=99t setup a TLS session to run netconf = over.

Yoav

No random number generator? I don't think this = is true even for a pure ESP endpoint.

Thanks,
  Yaron

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



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es




= --Apple-Mail=_C11A5E75-41C8-4F5F-8CBE-3A392E82DF49-- --Apple-Mail=_108DC393-618A-4F3B-B669-A182B24825FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJZbji7AAoJEMUYqoSNEZFTOK4IAKk0TT8wvcMPdK4fqIG9z++l JaSqAGiuXEU/cuiMXR9IDCBUNxqnO94aFym2tjDutENluDkoTae0I1qrS4jDvEym kU5VLL1KlQFjsfnBzA3rn3SlISwwhKaP4RUzpmTrfkJd0+sx7Kq5yhHAHArfMcC9 YoRJZyeJWn4WJEf0eliQgxBV28lfeptT4p7WEXHhEh8pRYz6UJqCyn7BxV2gn5lM zB/ZEkLIL+6DZM33d1k9d5lnfgI25+GKGO7993pXmByglV7O92l+sn8/hGiRqsts xB2PyKIFf6/lYXtiH2mvpV3IOpvjMWfzWwogIPoMHxXIlEXOP925kkkemLYGoQ4= =nAnV -----END PGP SIGNATURE----- --Apple-Mail=_108DC393-618A-4F3B-B669-A182B24825FE-- From nobody Tue Jul 18 23:19:49 2017 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 5F5C312EC44; Tue, 18 Jul 2017 23:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 stiDgWIyrkfn; Tue, 18 Jul 2017 23:19:43 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 6616212EB2B; Tue, 18 Jul 2017 23:19:42 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id l200so1591066lfb.2; Tue, 18 Jul 2017 23:19:42 -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=AT4ed6FsBc6j2BrQ0WTtoLX79LQjsgFVtq23S+Fhy+g=; b=ntcoqbDg2Ud9JSRMVkkWGwy6DTFFQJLkxHCiXF6PzXHH5xSddoPId2KZge3LHfUQv1 l4sT7TQ3BsY/O6TTIMxZur5p+vRaHNThvVDbs7qyK7ku7DSwYx+Dz12I0db9fXKt+Cf0 oy/5fqdsVVHHk9br2jBKFc4mDudGrbW3agWWJO5MW/vugUcID2mdEIKaOrZIRBZTjYAH uk564udG9/zGQTWSmhRzaC6BVcTs94FHUIQALIjImMXSXLmau3MRp3t6wB6y67F79v7A 3TEqdD+Y/snv6pROGKKCSoiBcE+UFQsEaZawFLmpX5d5QAvIiSu+XBQL7NLyM70xeDvA LWuQ== 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=AT4ed6FsBc6j2BrQ0WTtoLX79LQjsgFVtq23S+Fhy+g=; b=mg+PWJTUxNhQZZiJ6ju7IuvIPqk+fIbWPqgHWcd6e2dI3qgAy2nna1IFm6PGtT73vJ Rviqd8oq0Sn/kSFwR6lt91lMqyDz1N2Ur5fE3GmKfkWzry0zldQwpHph2vZ3fDFPHdrM 4cyQEqITtRv+/kto4ecBUmTOzhlZEQ/zgcabpS54ghkL7lorJfvT4Tj8riCNUCgybrVV tk7CfHeGsm/7oYRSjxraZbSmlDKirgz0Xje041BZZGFMpUdWhIh4boYPdji9K9qIWxJH EF2Twd9gIWJip40QO3FQtGM8GV9dkfY4p/xRc66WOY5u97WeIcO4Ehj+pVh7tWnMBfQY yNtA== X-Gm-Message-State: AIVw113GhxUC0Fln5qXs+oies9S8YPH3MTsqnV8BFLTeQHOVtrRaTfSV klL4uzDedqe7XcmM X-Received: by 10.46.82.23 with SMTP id g23mr1996542ljb.32.1500445180419; Tue, 18 Jul 2017 23:19:40 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id w3sm1078686ljd.35.2017.07.18.23.19.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Jul 2017 23:19:39 -0700 (PDT) From: "Valery Smyslov" To: "'Rafa Marin-Lopez'" , "'Tero Kivinen'" Cc: , "'IPsecME WG'" References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <22894.9183.134135.875338@fireball.acr.fi> In-Reply-To: Date: Wed, 19 Jul 2017 09:19:40 +0300 Message-ID: <02dd01d30057$01b63730$0522a590$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DE_01D30070.27067C70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKDIHC5dXDQzOp5aMUY5Ta8XNCy6AK2RBfzANbASFeg3f7ZgA== Content-Language: ru Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:19:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02DE_01D30070.27067C70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Rafa, =20 =20 Hi Tero, Valery: =20 Please see inline. El 18 jul 2017, a las 17:06, Tero Kivinen = escribi=C3=B3: =20 Valery Smyslov writes: I'm very much concerned with the IKE-less option presented in the draft. First, the Network Controller becomes a very attractive target for attacks in this case, since an attacker, if attack is successful, will gain all the keys for the whole system. And it is big difference if you get the traffic keys, or if you get just the authentication keys used to authenticate the peers when creating traffic keys. =20 [Rafa] Overall, the SDN paradigm states the controller is a trusted = entity. The controller can generate session keys based on PNRG and sends = those keys and forget about them. No need to store any keys, just = generate them and distribute them. =20 Having said this, in SDN paradigm, (and forgetting for a moment about = IPsec) , the SDN controller is ALWAYS a very attractive target. Reason: = if a SDN controller is attacked the attacker has the control over the = network (it can make the entire network no operative). Example: in the = SDN paradigm, for example, the =E2=80=9Crouter=E2=80=9D does not have = routing protocol, just routing/switching table. The SDN controller fills = tables. If the SDN is attacked the =E2=80=9Crouter=E2=80=9D does not = know how to react anymore. =20 [Valery] No, there situations are completely different. If attackers = hijacks SDN and makes the entire network no operative, this is an active attack and it is easy to detect = and take some measures. On the other hand, if an attacker hijacks SDN, learns all the keys and = then just passively eavesdrops all the traffic in the network =E2=80=93 you=E2=80=99ll never = know that you were really hijacked. That=E2=80=99s much more dangerous. =20 And another consideration. Did you see the ongoing discussion in the TLS = WG about the draft draft-green-tls-static-dh-in-tls13 that basically = suggests to hand over the TLS keys to some third party for later inspection of encrypted traffic? = Your proposal looks like more =E2=80=9Csuperior=E2=80=9D approach, since SDN can = collaborate with inspection devices handing them over the keys. And the large proportion of security = people in the TLS WG seem to find this idea inappropriate for IETF standards in = general. =20 Regards, Valery. =20 ------=_NextPart_000_02DE_01D30070.27067C70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Rafa,

 

 

Hi = Tero, Valery:

 

Please see inline.

El 18 jul 2017, a las 17:06, Tero Kivinen <kivinen@iki.fi> = escribi=C3=B3:

 

Valery Smyslov writes:

I'm very much concerned with the IKE-less option = presented in the
draft.

First, the Network Controller becomes = a very attractive target for
attacks in this case, since an attacker, = if attack is successful,
will gain all the keys for the whole = system.


And it is big difference = if you get the traffic keys, or if you get
just the authentication = keys used to authenticate the peers when
creating traffic = keys.

 

[Rafa] Overall, the SDN paradigm states the controller = is a trusted entity. The controller can generate session keys based on = PNRG and sends those keys and forget about them. No need to store any = keys, just generate them and distribute = them.

 

Having said this, in SDN paradigm, (and forgetting for = a moment about IPsec) , the SDN controller is ALWAYS a very attractive = target. Reason: if a SDN controller is attacked the attacker has the = control over the network (it can make the entire network no operative). = Example: in the SDN paradigm, for example, the =E2=80=9Crouter=E2=80=9D = does not have routing protocol, just routing/switching table. The SDN = controller fills tables. If the SDN is attacked the = =E2=80=9Crouter=E2=80=9D does not know how to react anymore.

 

[Valery] No, there situations are completely different. If attackers = hijacks SDN and makes the entire

network no operative, this is an active attack and it is easy to = detect and take some measures.

On the other hand, if an attacker hijacks SDN, learns all the keys = and then just passively

eavesdrops all the traffic in the network =E2=80=93 you=E2=80=99ll = never know that you were really hijacked.

That=E2=80=99s much more dangerous.

 

And another consideration. Did you see the ongoing discussion in the = TLS WG

about the draft draft-green-tls-static-dh-in-tls13 that basically = suggests to hand over the

TLS keys to some third party for later inspection of encrypted = traffic? Your proposal

looks like more =E2=80=9Csuperior=E2=80=9D approach, since SDN can = collaborate with inspection

devices handing them over the keys. And the large proportion of = security people

in the TLS WG seem to find this idea inappropriate for IETF standards = in general.

 

Regards,

Valery.

 

------=_NextPart_000_02DE_01D30070.27067C70-- From nobody Tue Jul 18 23:46:41 2017 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 AA42412ECC8; Tue, 18 Jul 2017 23:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 qaq37zroRBWl; Tue, 18 Jul 2017 23:46:32 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 255AA12ECB4; Tue, 18 Jul 2017 23:46:32 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id t72so28108635lff.1; Tue, 18 Jul 2017 23:46:32 -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=dOtlIXQlGt277QdjxJbWlab+LShgJb+mzFXuMhyD9AE=; b=KekisdVjjbPH9VTuUntndH23LuAEtBYflCOC0W2muh9mZssQW+MO3YqNtNwrIoLRIh GjbFgXFw6ZLlcQ/pyKRjlQGlYdpUFhj4JuVeMk4uIUHwrFJw8Y5Kb40qrKXQE8kPb+sv XaZvft6MFyFCbpDN/axVTRe88rHVbE0tQJK94q7dtSXVj0Gv2lXow6O3nKstTCHLkbmH 0dVnTgFNM7BXshJkNVT+sisgyHOY1AStG63GCZEqfaeMldUGVTVKHK08Q6O+YGZ1FTZG ruYwDr6l6/JYD3qACqZSYXzFD0C947sikVCR3YTrEGc0n4ovrDzhXcn7KlzMpeLyOBba wfmA== 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=dOtlIXQlGt277QdjxJbWlab+LShgJb+mzFXuMhyD9AE=; b=JTJp2XbeJzXrl66p2eyKY0Lr4gGd+m0n861QRgiBzArzKtsVdF9jcIO8icYDrCHTyc lHNRgJXluPQNF5s0h6hNoHd6MyXAqI9QuUdf1cs9ze1O1Ek6u6m/2a3QUKsHNNKU7v+d hU8U02X/wZZPl6BumlC1uzfnPQIsnYBOv4RbNjH+tTEINVbpUPLoRVoDIl3LlH2T/xbP uz4tz/qkab0zht8X/yCZ55890MRFr9WIjsIR45TcF+jg/Sq3LSKKGF9+BY6GL3wRfQDI LHXppi0NIehvA5VhSo1zOiIW6MMG2sPNAVrjkPmtujzYMkY5wt5cidqES4bw40w62SF1 ab6Q== X-Gm-Message-State: AIVw113N+MMDM20LVvDRroDF36RVPIZM5mL+HoLmhNPUOgGb5XEGNJdl JCbnajkIMKfbb0Wg X-Received: by 10.46.83.86 with SMTP id t22mr2180014ljd.24.1500446790464; Tue, 18 Jul 2017 23:46:30 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id i15sm1107265ljd.6.2017.07.18.23.46.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Jul 2017 23:46:29 -0700 (PDT) From: "Valery Smyslov" To: =?utf-8?Q?'Alejandro_P=C3=A9rez_M=C3=A9ndez'?= , Cc: "'IPsecME WG'" , "'Rafa Marin-Lopez'" References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> In-Reply-To: Date: Wed, 19 Jul 2017 09:46:30 +0300 Message-ID: <02e601d3005a$c1791170$446b3450$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKDIHC5dXDQzOp5aMUY5Ta8XNCy6AHIW25WoOwsABA= Content-Language: ru Archived-At: Subject: Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:46:34 -0000 Hi Alejandro, > Hi Valery, all, > > > > > In general, central distribution of session keys looks much less secure, > > than running IKEv2 on them. > That's arguable, yes. But being less secure does not mean being useless. > Coming to my previous comment, we don't use RSA with 8192 bit keys for > everything. Although it is more secure, there are scenarios were a > lighter approach is enough. If running IKE is too much for your devices, > the IKE-less option might work for you if your security contraints are > fewer. This SDN-based approach does not need to solve everyone's > problems for every possible scenario. Neither does Kerberos, IPsec > itself nor any other security protocol. OK, but then you should clearly state your requirement. Otherwise it is possible to drive situation to absurdum. For example, for a sake of device simplicity, you may get rid of IPsec at all and send all the traffic that needs protection to SDN via existing TLS connection/ The SDN then will route it to appropriate peer. It would work and will make devices even more dumber (to be clear - I don't propose this, it is just an example of corner case solution that in theory would work). > > You loose PFS property, > I don't see why. Actually, keys on the controller are generated by a > secure RNG so every key you generate is completely unrelated to the > previous one. That's indeed an advantage, rather than the opposite. It depends. If you use PRNG instead of true RNG, then you'll have no PFS. > > you loose > > the property that no one but the peers know the session keys etc. > Right. > > > It is more fragile too. You must perform periodical rekey (update keys) > > and this must be done synchronously. > You have to do it by pairs, does not seem that difficult. And, as IKE > does, you create the new ones and, once created, delete the old ones. I > don't see the synchrony problem that important. In ideal world - yes. In real world - I'm not so sure. Imagine you have an SA expired and the SDN installs a new SA on the peers, but one of SDN-peer TLS connection failed because off the temporary network problem, so you have a new SA partially installed. What is the peer that didn't receive a new SA supposed to do? Continue to use an old one despite the fact that it is expired? Block all traffic? Something else? How NAT traversal is to be done in IKE-less case? I understand, that NATs are also controlled by SDN, but does SDN pre-install NAT mappings? Regards, Valery. > Regards, > Alejandro > > > Regards, > > Valery Smyslov. > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jul 19 00:39:06 2017 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 B93FF12ECC3; Wed, 19 Jul 2017 00:38:59 -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, RP_MATCHES_RCVD=-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 kvMz6GYIeW2J; Wed, 19 Jul 2017 00:38:57 -0700 (PDT) Received: from xenon43.um.es (xenon43.um.es [155.54.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1C73A127337; Wed, 19 Jul 2017 00:38:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id 574C42097C; Wed, 19 Jul 2017 09:38:55 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon43.um.es Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4t53yxGOi8tj; Wed, 19 Jul 2017 09:38:55 +0200 (CEST) Received: from [192.168.100.23] (unknown [185.154.58.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon43.um.es (Postfix) with ESMTPSA id 41AF32032A; Wed, 19 Jul 2017 09:38:53 +0200 (CEST) To: Valery Smyslov , i2nsf@ietf.org Cc: 'IPsecME WG' , 'Rafa Marin-Lopez' References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <02e601d3005a$c1791170$446b3450$@gmail.com> From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= Message-ID: <1e2efa38-5b95-7685-8fb9-047b656f0e58@um.es> Date: Wed, 19 Jul 2017 09:38:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <02e601d3005a$c1791170$446b3450$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:39:00 -0000 Hi Valery, > Hi Alejandro, > >> Hi Valery, all, >> >> > >> > In general, central distribution of session keys looks much less secure, >> > than running IKEv2 on them. >> That's arguable, yes. But being less secure does not mean being useless. >> Coming to my previous comment, we don't use RSA with 8192 bit keys for >> everything. Although it is more secure, there are scenarios were a >> lighter approach is enough. If running IKE is too much for your devices, >> the IKE-less option might work for you if your security contraints are >> fewer. This SDN-based approach does not need to solve everyone's >> problems for every possible scenario. Neither does Kerberos, IPsec >> itself nor any other security protocol. > OK, but then you should clearly state your requirement. > Otherwise it is possible to drive situation to absurdum. > For example, for a sake of device simplicity, you may > get rid of IPsec at all and send all the traffic that needs protection > to SDN via existing TLS connection/ The SDN then will route > it to appropriate peer. It would work and will make devices > even more dumber (to be clear - I don't propose this, > it is just an example of corner case solution that in theory would work). I see your point and agree the document may need to state it if not completely clear implicitly. It's a trade-off between simplicity (use as few protocols/functionality as possible), performance (use as few memory/disk/CPU resources as possible, this includes not using SSH/TLS other than for the control channel), and security (be as secure as possible, but not overkilling for the requirements of the scenario). >> > You loose PFS property, >> I don't see why. Actually, keys on the controller are generated by a >> secure RNG so every key you generate is completely unrelated to the >> previous one. That's indeed an advantage, rather than the opposite. > It depends. If you use PRNG instead of true RNG, then you'll have no PFS. I think it is a fair assumption that an SDN controller, which is far from being a constrained device, will have a true RNG. > >> > you loose >> > the property that no one but the peers know the session keys etc. >> Right. >> >> > It is more fragile too. You must perform periodical rekey (update keys) >> > and this must be done synchronously. >> You have to do it by pairs, does not seem that difficult. And, as IKE >> does, you create the new ones and, once created, delete the old ones. I >> don't see the synchrony problem that important. > In ideal world - yes. In real world - I'm not so sure. > Imagine you have an SA expired and the SDN installs a new SA > on the peers, but one of SDN-peer TLS connection failed because off > the temporary network problem, so you have a new SA partially installed. > What is the peer that didn't receive a new SA supposed to do? > Continue to use an old one despite the fact that it is expired? > Block all traffic? Something else? In fact, I think the SDN-based approach performs even better than IKE in this regards. Imagine what happens if the corresponding IKE rekey process fails for the very same temporary network problem. In the best case, CHILD SAs are deleted after a hard expiration, and they will need to be re-created when triggered by the SPD again. This is roughly identical to the SDN approach. But, typically, when an IKE rekey fails, the initiator will likely close the entire IKE_SA thinking the other peer is down, which would result into having to recreate the IKE_SA (including the DH exchange), and all the associated CHILD_SAs afterwards. > How NAT traversal is to be done in IKE-less case? I understand, that > NATs are also controlled by SDN, but does SDN pre-install NAT mappings? That's a good question. I would say so, yes. But, would that generate problems if the NAT box is not included in your SDN (e.g. it belongs to the mall centre or similar)? These are exactly the sort of situations that need to be figured out. Regards, Alejandro > > Regards, > Valery. > >> Regards, >> Alejandro >> >> > Regards, >> > Valery Smyslov. >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jul 19 01:17:11 2017 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 98527131BFE; Wed, 19 Jul 2017 01:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, 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 JMrzcKewK28m; Wed, 19 Jul 2017 01:17:07 -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 8C785131C13; Wed, 19 Jul 2017 01:17:06 -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 v6J8H1XW020355 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Jul 2017 11:17:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v6J8H1Il013588; Wed, 19 Jul 2017 11:17:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22895.5501.430778.169927@fireball.acr.fi> Date: Wed, 19 Jul 2017 11:17:01 +0300 From: Tero Kivinen To: Rafa Marin-Lopez Cc: Valery Smyslov , i2nsf@ietf.org, IPsecME WG In-Reply-To: References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <22894.9183.134135.875338@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 31 min X-Total-Time: 31 min Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:17:09 -0000 Rafa Marin-Lopez writes: > I.e. any TLA would love to get their hands on all the traffic key= s in > one location, and then be able to decrypt any traffic going insid= e any > of the IPsec tunnels. > =20 > If controller only has the PSKs or similar to do the authenticati= on > between peers, then that means that the TLA needs to do active at= tack > for each connection they want to break. >=20 > Beause of this I think it is always best not to move the transpor= t > keys outside the boxes that needs them, i.e., keep them only on t= he > nodes doing actual encryption / decryption. > =20 > Also knowing that the controller most likely keeps all kind of lo= gs > and takes backup of the configurations it is keeping, this also m= akes > the backups suitable targets for attacks, as they allow decryptio= n > previously stored flows of traffic, and this can be done years la= ter > when one of those backups accidently finds its way to wrong hands= =2E >=20 > [Rafa] In reality, the controller can forget immediately the > credentials that has been generated. As a security measure , the > controller does not need to store any keys it has distributed. No it cannot. The keys needs to be installed in multiple nodes, which means that when it generates them it needs to store them until it is sure that every single device needing them has them. Also if any single device restarts, it will need new keys, and those keys again needs to be destributed to all other entities sharing SA keys with the node. Also even if if could remove the keys quite quickly after generating them, in practice I do not think that is going to happen, as operators want to be able to see what is the configuration that was sent to node, which then requires controller to keep configuration available.=20 > This I think is important question, i.e., what is the gain for no= t > running IKEv2 between the nodes=3F >=20 > [Rafa] As Yoav mentioned, simpler devices.=20 I do not really belive that. You need security protocol to be able to transmit the configuration to the nodes, and that security protocol will require similar resource than what IKEv2 needs. To be able to do the actual ESP traffic for links will require much more resources than running IKE to setting up the SA. Yes, you can leave few kilobytes of code out from the flash, as you do not need to implement IKEv2. Also you loose all kind of features too, like ability to spport roaming clients (i.e., laptop, or phone etc connecting to network through VPN, or actually connecting IPsec to any other node that is not directly controlled by the controller). Note, that the controller cannot run IKEv2 in behalf of any of nodes it is controlling, as that is forbidden by the IPsec (IKE and Child SA are tied together so that if one goes down, the other MUST go down too). See section 2.4 of RFC7296 end of 4th paragraph (line 14 of page 28).=20 Also if you are limiting yourself to the endpoint-to-endpoint transport mode (section 1.1.2 of RFC7296) with policy given by the controller, you do not need full IKEv2 implementation, you can implement minimal IKEv2 (RFC7815), with exception that you also need to implement the responder side also. Using the frequently generated PSKs distributed from the controller, and minimal IKEv2, will give you much better security than when you transport traffic keys from controller. Btw, on Friday there will be presentation in ipsecme where they implemented minimal IKEv2 with GDOI modifications (i.e., IKEv2 + multicast key distribution) in device which having 256 kB of flash, and 32 kB of ram, and that implementation included the full network support also, not only IKEv2... > [Rafa] Basically, the SDN controller will know when to do the rekey. = Please, > see the YANG model in our draft. There is notification =E2=80=9Cexpir= e=E2=80=9D Ah, sorry, I have not read the draft yet, as I have been too busy with other things, but if there is two way communication between the node and controller, than that works fine. --=20 kivinen@iki.fi From nobody Wed Jul 19 04:54:56 2017 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 CE047131CCC; Wed, 19 Jul 2017 04:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 ZAM8pVVEfDBv; Wed, 19 Jul 2017 04:54:53 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 42CFD131771; Wed, 19 Jul 2017 04:54:53 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id f18so1057712lfa.4; Wed, 19 Jul 2017 04:54:53 -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=yJE9aCfC+K/mVsMbrmK5y02glOaOJ3fJXBK33Z6Fq9s=; b=tL3EhrVtZ4JvOCuVB7csw7qCCsg1sJjImFH8jVh9mNykzwVd2sKKEdKE2eqV1Um5Yc IbfcedkUBS4byFGjayK0dDl5pXZ0New5vHO3U37fjuvwA6dIuSvWjkqvB/N2DpSq12V3 guxcJMsofNsT5VzUAiZB/K7TYBWm82KVtX6riFcgBRWLVHELd7PU67EY8AYq6DUWBm8Y pBR99lyinhFHYgYnvY/caU164ejP10s0OLjKxErJNTH1I0DGdNqzEgs+Q8eCHXPlNFH1 yv7xgNoEMZBWeEB+PFSXDwstyavFSnkflmzX+R5NG25ptVq5Ur/OVoPXBmxE4/QYbn7M Yysg== 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=yJE9aCfC+K/mVsMbrmK5y02glOaOJ3fJXBK33Z6Fq9s=; b=m05CaMpSZ3lXRMppe3E7021Mc8qJDOMShaTYVrQxnG7l31Dx8x681slYLYAeBBeTtM 1IY90IF3gcPAxshZdV8870SpkXVCDaRW5Iw3Z1SfW+2O0Ky/Zw0AYw8FESFZeWBsswMl sgcDtb7zfvibHpJHQiMnHOXXbXlpBUhvb+3Q2x3PU0ih/dg/QUvhfVid/Hk/zdUpMsnX tBPi8G49OXCgJF4PTdx+5Ez3I/ClKtPvf7Gk/RcdPhZ9vT90Tb0zPpU2efzwSlM68psP kDfowIg9Qu1ZwaiTSabXI2y7Hf402Xvy0qYq3NjUgm7XEGbVgB6XmVEds+ewa3QqRoXq 2sVA== X-Gm-Message-State: AIVw111Txr5UE0b+JWpjOQRvbEnPHPHH8sIY1q1RpxOaB/NjvNmv9gZN W3LQrDhDNkkG0K/y X-Received: by 10.46.88.3 with SMTP id m3mr2269847ljb.136.1500465291455; Wed, 19 Jul 2017 04:54:51 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id u8sm1256103ljd.34.2017.07.19.04.54.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 19 Jul 2017 04:54:50 -0700 (PDT) From: "Valery Smyslov" To: =?utf-8?Q?'Alejandro_P=C3=A9rez_M=C3=A9ndez'?= , Cc: "'IPsecME WG'" , "'Rafa Marin-Lopez'" References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <02e601d3005a$c1791170$446b3450$@gmail.com> <1e2efa38-5b95-7685-8fb9-047b656f0e58@um.es> In-Reply-To: <1e2efa38-5b95-7685-8fb9-047b656f0e58@um.es> Date: Wed, 19 Jul 2017 14:54:51 +0300 Message-ID: <031201d30085$d4cab0a0$7e6011e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKDIHC5dXDQzOp5aMUY5Ta8XNCy6AHIW25WAYFIQaEB358/j6DReJFw Content-Language: ru Archived-At: Subject: Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:54:55 -0000 Hi Alejandro, > >> > It is more fragile too. You must perform periodical rekey (update keys) > >> > and this must be done synchronously. > >> You have to do it by pairs, does not seem that difficult. And, as IKE > >> does, you create the new ones and, once created, delete the old ones. I > >> don't see the synchrony problem that important. > > In ideal world - yes. In real world - I'm not so sure. > > Imagine you have an SA expired and the SDN installs a new SA > > on the peers, but one of SDN-peer TLS connection failed because off > > the temporary network problem, so you have a new SA partially installed. > > What is the peer that didn't receive a new SA supposed to do? > > Continue to use an old one despite the fact that it is expired? > > Block all traffic? Something else? > In fact, I think the SDN-based approach performs even better than IKE in > this regards. > Imagine what happens if the corresponding IKE rekey process fails for > the very same temporary network problem. In the best case, CHILD SAs are > deleted after a hard expiration, and they will need to be re-created > when triggered by the SPD again. This is roughly identical to the SDN > approach. But, typically, when an IKE rekey fails, the initiator will > likely close the entire IKE_SA thinking the other peer is down, which > would result into having to recreate the IKE_SA (including the DH > exchange), and all the associated CHILD_SAs afterwards. Exactly, that's what IKE will do. But this is reasonable, because if IKE messages cannot go between peers, it is most probably that IPsec won't go either (especially in case of UDP encapsulation). With SDN the situation is a bit different. The network problem takes place on SDN-EE path, while EE-EE path works well, but the peers cannot communicate, because SDN fails to provide the keys in time. Note, that rekey may take place quite often, depending on the algorithms involved. > > How NAT traversal is to be done in IKE-less case? I understand, that > > NATs are also controlled by SDN, but does SDN pre-install NAT mappings? > > That's a good question. I would say so, yes. So, SDN needs to synchronously configure one more entity (NAT) for IPsec to start working? > But, would that generate problems if the NAT box is not included in your > SDN (e.g. it belongs to the mall centre or similar)? In this case you first need to use UDP encapsulation and second need to send NAT keepalive messages periodically. Usually it is IKE who sends these messages (I admit that you can also sends them from the kernel). IKE also determines if there is a NAT in between and which peer is behind the NAT. In case the NAT is out of SDN control, who will do this job? What is supposed to be done if packet with invalid AH/ESP SPI is received? Clearly, the packet itself is dropped, but later IKEv2 extensions (namely RFC6290, Quick Crash Detection) allows to send IKE notification to the peer with a security token to help peers quickly recover from the crash. What is supposed to be done in IKE-less case? Or do you think that with SDN such things like non-synchronized IPsec states never happen? Regards, Valery. > These are exactly the sort of situations that need to be figured out. I believe there are many of them. Regards, Valery. From nobody Wed Jul 19 06:25:15 2017 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 E10DC131B10; Wed, 19 Jul 2017 06:25:05 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150047070585.25387.15468602847343395125@ietfa.amsl.com> Date: Wed, 19 Jul 2017 06:25:05 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 13:25:06 -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 of the IETF. Title : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-01.txt Pages : 11 Date : 2017-07-19 Abstract: This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains should be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non-public DNS servers is referred to as "Split DNS". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-01 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-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 19 07:21:30 2017 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 6448A131D0B; Wed, 19 Jul 2017 07:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 N-EyI4OsEgxx; Wed, 19 Jul 2017 07:21:22 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [IPv6:2001:720:1710:601::41]) by ietfa.amsl.com (Postfix) with ESMTP id 5A837131A61; Wed, 19 Jul 2017 07:21:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 6300A20D1A; Wed, 19 Jul 2017 16:21:18 +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 JwktqPQbembW; Wed, 19 Jul 2017 16:21:18 +0200 (CEST) Received: from [192.168.1.7] (135.red-83-36-225.dynamicip.rima-tde.net [83.36.225.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon41.um.es (Postfix) with ESMTPSA id 8550320CB4; Wed, 19 Jul 2017 16:21:11 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6BA6C96F-9D50-4B7B-A13D-08410BCBD02A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Gabriel Lopez In-Reply-To: <031201d30085$d4cab0a0$7e6011e0$@gmail.com> Date: Wed, 19 Jul 2017 16:21:09 +0200 Cc: =?utf-8?Q?Alejandro_P=C3=A9rez_M=C3=A9ndez?= , i2nsf@ietf.org, IPsecME WG , Rafa Marin Lopez Message-Id: References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <02e601d3005a$c1791170$446b3450$@gmail.com> <1e2efa38-5b95-7685-8fb9-047b656f0e58@um.es> <031201d30085$d4cab0a0$7e6011e0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 14:21:29 -0000 --Apple-Mail=_6BA6C96F-9D50-4B7B-A13D-08410BCBD02A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery, > El 19 jul 2017, a las 13:54, Valery Smyslov = escribi=C3=B3: >=20 > Hi Alejandro, >=20 >>>>> It is more fragile too. You must perform periodical rekey (update = keys) >>>>> and this must be done synchronously. >>>> You have to do it by pairs, does not seem that difficult. And, as = IKE >>>> does, you create the new ones and, once created, delete the old = ones. I >>>> don't see the synchrony problem that important. >>> In ideal world - yes. In real world - I'm not so sure. >>> Imagine you have an SA expired and the SDN installs a new SA >>> on the peers, but one of SDN-peer TLS connection failed because off >>> the temporary network problem, so you have a new SA partially = installed. >>> What is the peer that didn't receive a new SA supposed to do? >>> Continue to use an old one despite the fact that it is expired? >>> Block all traffic? Something else? >> In fact, I think the SDN-based approach performs even better than IKE = in >> this regards. >> Imagine what happens if the corresponding IKE rekey process fails for >> the very same temporary network problem. In the best case, CHILD SAs = are >> deleted after a hard expiration, and they will need to be re-created >> when triggered by the SPD again. This is roughly identical to the SDN >> approach. But, typically, when an IKE rekey fails, the initiator will >> likely close the entire IKE_SA thinking the other peer is down, which >> would result into having to recreate the IKE_SA (including the DH >> exchange), and all the associated CHILD_SAs afterwards. >=20 > Exactly, that's what IKE will do. But this is reasonable, because if = IKE > messages cannot go between peers, it is most probably that=20 > IPsec won't go either (especially in case of UDP encapsulation). > With SDN the situation is a bit different. The network problem=20 > takes place on SDN-EE path, while EE-EE path works well, > but the peers cannot communicate, because SDN fails to provide > the keys in time. Note, that rekey may take place quite often, = depending=20 > on the algorithms involved.=20 [Gabi] This kind of strong requirements on the controller availability = and workload is assumed in the SDN paradigm. Let=E2=80=99s think in a L2 = OpenFlow controller for example, where the L2-switch has to forward a = copy of the incoming frame before to forward it. >=20 >>> How NAT traversal is to be done in IKE-less case? I understand, that >>> NATs are also controlled by SDN, but does SDN pre-install NAT = mappings? >>=20 >> That's a good question. I would say so, yes. >=20 > So, SDN needs to synchronously configure one more entity (NAT) > for IPsec to start working?=20 [Gabi] If NAT is required the controller should know that, the IPsec = configuration required to cross the NAT should be applied by the = Security Controller . The configuration of the NAT entity may be = configured independently (manually or not, note that there are Yang = models for NAT = (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07)). >=20 >> But, would that generate problems if the NAT box is not included in = your >> SDN (e.g. it belongs to the mall centre or similar)? >=20 > In this case you first need to use UDP encapsulation and second need = to send > NAT keepalive messages periodically. Usually it is IKE who sends > these messages (I admit that you can also sends them from the kernel). > IKE also determines if there is a NAT in between and which peer is=20 > behind the NAT. In case the NAT is out of SDN control, who will do = this job? [Gabi] the Controller should know that there is NAT in the scenario. >=20 > What is supposed to be done if packet with invalid AH/ESP SPI is = received? > Clearly, the packet itself is dropped, but later IKEv2 extensions = (namely > RFC6290, Quick Crash Detection) allows to send IKE notification > to the peer with a security token to help peers quickly recover from = the crash. > What is supposed to be done in IKE-less case? Or do you think that > with SDN such things like non-synchronized IPsec states never happen? [Gabi] If it is an audiatable event by the kernel, the peer can notify = the controller about that (some examples of notifications are already = included in the yang model) Thanks for the comments, this discussion is really interesting =E2=80=A6. Regards, Gabi. >=20 > Regards, > Valery.=20 >=20 >> These are exactly the sort of situations that need to be figured out. >=20 > I believe there are many of them. >=20 > Regards, > Valery. >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_6BA6C96F-9D50-4B7B-A13D-08410BCBD02A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Valery,

El 19 jul 2017, a las 13:54, = Valery Smyslov <svanru@gmail.com> escribi=C3=B3:

Hi = Alejandro,

It is more fragile too. = You must perform periodical rekey (update keys)
and this = must be done synchronously.
You have to do it = by pairs, does not seem that difficult. And, as IKE
does, = you create the new ones and, once created, delete the old ones. I
don't see the synchrony problem that important.
In ideal world - yes. In real world - I'm not so = sure.
Imagine you have an SA expired and the SDN installs = a new SA
on the peers, but one of SDN-peer TLS connection = failed because off
the temporary network problem, so you = have a new SA partially installed.
What is the peer that = didn't receive a new SA supposed to do?
Continue to use an = old one despite the fact that it is expired?
Block all = traffic? Something else?
In fact, I think the = SDN-based approach performs even better than IKE in
this = regards.
Imagine what happens if the corresponding IKE = rekey process fails for
the very same temporary network = problem. In the best case, CHILD SAs are
deleted after a = hard expiration, and they will need to be re-created
when = triggered by the SPD again. This is roughly identical to the SDN
approach. But, typically, when an IKE rekey fails, the = initiator will
likely close the entire IKE_SA thinking the = other peer is down, which
would result into having to = recreate the IKE_SA (including the DH
exchange), and all = the associated CHILD_SAs afterwards.

Exactly, that's what IKE will do. But this is reasonable, = because if IKE
messages cannot go between peers, it is = most probably that
IPsec won't go either (especially in = case of UDP encapsulation).
With SDN the situation is a = bit different. The network problem
takes place on SDN-EE = path, while EE-EE path works well,
but the peers cannot = communicate, because SDN fails to provide
the keys in = time. Note, that rekey may take place quite often, depending
on the algorithms involved.

[Gabi] = This kind of strong requirements on the controller availability and = workload is assumed in the SDN paradigm. Let=E2=80=99s think in a L2 = OpenFlow controller for example, where the L2-switch has to forward a = copy of the incoming frame before to forward it.

How NAT traversal is to be done in IKE-less case? I = understand, that
NATs are also controlled by SDN, but does = SDN pre-install NAT mappings?

That's a good question. I would say so, yes.

So, SDN needs to synchronously = configure one more entity (NAT)
for IPsec to start = working?

[Gabi] If NAT is required the controller should = know that, the IPsec configuration required to cross the NAT should be = applied by the Security Controller . The configuration of the NAT entity = may be configured independently (manually or not, note that there are = Yang models for NAT (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07)).<= /div>

But, would that generate problems if the NAT box is not = included in your
SDN (e.g. it belongs to the mall centre = or similar)?

In this case you = first need to use UDP encapsulation and second need to send
NAT keepalive messages periodically. Usually it is IKE who =  sends
these messages (I admit that you can also = sends them from the kernel).
IKE also determines if there = is a NAT in between and which peer is
behind the NAT. In = case the NAT is out of SDN control, who will do this job?

[Gabi] the = Controller should know that there is NAT in the scenario.

What is supposed to be done if packet with = invalid AH/ESP SPI is received?



Clearly, the packet itself is = dropped, but later IKEv2 extensions (namely
RFC6290, Quick = Crash Detection) allows to send IKE notification
to the = peer with a security token to help peers quickly recover from the = crash.
What is supposed to be done in IKE-less case? Or do = you think  that
with SDN such things like = non-synchronized IPsec states never happen?

[Gabi] = If it is an audiatable event by the kernel, the peer can notify the = controller about that (some examples of notifications are already = included in the yang model)

Thanks for the comments, this discussion is really = interesting =E2=80=A6.

Regards, Gabi.

Regards,
Valery. =

These = are exactly the sort of situations that need to be figured out.

I believe there are many of = them.

Regards,
Valery.

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



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es




= --Apple-Mail=_6BA6C96F-9D50-4B7B-A13D-08410BCBD02A-- From nobody Wed Jul 19 07:42:53 2017 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 088EE131C57; Wed, 19 Jul 2017 07:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 Yj-abjpV5aLz; Wed, 19 Jul 2017 07:42:47 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [IPv6:2001:720:1710:601::42]) by ietfa.amsl.com (Postfix) with ESMTP id 296F2131C08; Wed, 19 Jul 2017 07:42:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 091CB20B1E; Wed, 19 Jul 2017 16:42: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 S7RBPi6OrUpN; Wed, 19 Jul 2017 16:42:45 +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 6DBC020B18; Wed, 19 Jul 2017 16:42:43 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8DA084F7-8E63-471E-BD23-67AD5E8CDF7C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Jul 2017 16:42:41 +0200 In-Reply-To: Cc: Rafa Marin-Lopez , i2nsf@ietf.org, IPsecME WG , =?utf-8?Q?Alejandro_P=C3=A9rez_M=C3=A9ndez?= , gabriel Lopez To: Valery Smyslov References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <02e601d3005a$c1791170$446b3450$@gmail.com> <1e2efa38-5b95-7685-8fb9-047b656f0e58@um.es> <031201d30085$d4cab0a0$7e6011e0$@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 14:42:52 -0000 --Apple-Mail=_8DA084F7-8E63-471E-BD23-67AD5E8CDF7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery, Gabi: A couple of comments inline. > El 19 jul 2017, a las 16:21, Gabriel Lopez escribi=C3=B3:= >=20 > Hi Valery, >=20 >> El 19 jul 2017, a las 13:54, Valery Smyslov > escribi=C3=B3: >>=20 >> Hi Alejandro, >>=20 >>>>>> It is more fragile too. You must perform periodical rekey (update = keys) >>>>>> and this must be done synchronously. >>>>> You have to do it by pairs, does not seem that difficult. And, as = IKE >>>>> does, you create the new ones and, once created, delete the old = ones. I >>>>> don't see the synchrony problem that important. >>>> In ideal world - yes. In real world - I'm not so sure. >>>> Imagine you have an SA expired and the SDN installs a new SA >>>> on the peers, but one of SDN-peer TLS connection failed because off >>>> the temporary network problem, so you have a new SA partially = installed. >>>> What is the peer that didn't receive a new SA supposed to do? >>>> Continue to use an old one despite the fact that it is expired? >>>> Block all traffic? Something else? >>> In fact, I think the SDN-based approach performs even better than = IKE in >>> this regards. >>> Imagine what happens if the corresponding IKE rekey process fails = for >>> the very same temporary network problem. In the best case, CHILD SAs = are >>> deleted after a hard expiration, and they will need to be re-created >>> when triggered by the SPD again. This is roughly identical to the = SDN >>> approach. But, typically, when an IKE rekey fails, the initiator = will >>> likely close the entire IKE_SA thinking the other peer is down, = which >>> would result into having to recreate the IKE_SA (including the DH >>> exchange), and all the associated CHILD_SAs afterwards. >>=20 >> Exactly, that's what IKE will do. But this is reasonable, because if = IKE >> messages cannot go between peers, it is most probably that=20 >> IPsec won't go either (especially in case of UDP encapsulation). >> With SDN the situation is a bit different. The network problem=20 >> takes place on SDN-EE path, while EE-EE path works well, >> but the peers cannot communicate, because SDN fails to provide >> the keys in time. Note, that rekey may take place quite often, = depending=20 >> on the algorithms involved.=20 >=20 > [Gabi] This kind of strong requirements on the controller availability = and workload is assumed in the SDN paradigm. Let=E2=80=99s think in a L2 = OpenFlow controller for example, where the L2-switch has to forward a = copy of the incoming frame before to forward it. >>=20 >>>> How NAT traversal is to be done in IKE-less case? I understand, = that >>>> NATs are also controlled by SDN, but does SDN pre-install NAT = mappings? >>>=20 >>> That's a good question. I would say so, yes. >>=20 >> So, SDN needs to synchronously configure one more entity (NAT) >> for IPsec to start working?=20 >=20 > [Gabi] If NAT is required the controller should know that, the IPsec = configuration required to cross the NAT should be applied by the = Security Controller . The configuration of the NAT entity may be = configured independently (manually or not, note that there are Yang = models for NAT (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07 = )). >=20 >>=20 >>> But, would that generate problems if the NAT box is not included in = your >>> SDN (e.g. it belongs to the mall centre or similar)? >>=20 >> In this case you first need to use UDP encapsulation and second need = to send >> NAT keepalive messages periodically. Usually it is IKE who sends >> these messages (I admit that you can also sends them from the = kernel). >> IKE also determines if there is a NAT in between and which peer is=20 >> behind the NAT. In case the NAT is out of SDN control, who will do = this job? >=20 > [Gabi] the Controller should know that there is NAT in the scenario. [Rafa] As additional comment to Gabi=E2=80=99s e-mail related with NAT, = in our draft we have this text when IKE is not in the device (NSF): "Another example is the NAT traversal support. In general, the SDN paradigm assumes the SDN controller has a view of the network it controls. This view is built either requesting information to the NSFs under its control or because these NSFs inform the SDN controller. Based on this information, the SDN/security controller can guess if there is a NAT configured between two hosts, apply the required policies to both NSFs besides activating the usage of UDP encapsulation of ESP packets [RFC3948]. In those scenarios, the Controller could directly request the NSF for specific data such as networking configuration, NAT support, etc. Protocols such as NETCONF or SNMP can be used here. For example, RFC 7317 [RFC7317] provides a YANG data model for system management or [I-D.sivakumar-yang-nat] a data model for NAT management. >>=20 >> What is supposed to be done if packet with invalid AH/ESP SPI is = received? >=20 >=20 >=20 >> Clearly, the packet itself is dropped, but later IKEv2 extensions = (namely >> RFC6290, Quick Crash Detection) allows to send IKE notification >> to the peer with a security token to help peers quickly recover from = the crash. >> What is supposed to be done in IKE-less case? Or do you think that >> with SDN such things like non-synchronized IPsec states never happen? >=20 > [Gabi] If it is an audiatable event by the kernel, the peer can notify = the controller about that (some examples of notifications are already = included in the yang model) [Rafa] Regarding the quick recover, it is typical a keep alive mechanism = between the device and the SDN controller. So that the SDN controller = can react quickly when a device restart or crash. Best Regards. >=20 > Thanks for the comments, this discussion is really interesting =E2=80=A6= . >=20 > Regards, Gabi. >>=20 >> Regards, >> Valery.=20 >>=20 >>> These are exactly the sort of situations that need to be figured = out. >>=20 >> I believe there are many of them. >>=20 >> Regards, >> Valery. >>=20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf = >=20 >=20 >=20 > ----------------------------------------------------------- > Gabriel L=C3=B3pez Mill=C3=A1n > Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones > University of Murcia > Spain > Tel: +34 868888504 > Fax: +34 868884151 > email: gabilm@um.es >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = ------------------------------------------------------- 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=_8DA084F7-8E63-471E-BD23-67AD5E8CDF7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Valery, Gabi:

A couple of comments inline.

El 19 jul 2017, a las 16:21, Gabriel Lopez <gabilm@um.es> = escribi=C3=B3:

Hi Valery,

El 19 jul 2017, a las 13:54, Valery Smyslov <svanru@gmail.com> = escribi=C3=B3:

Hi Alejandro,

It is more fragile too. You must perform periodical rekey = (update keys)
and this must be done synchronously.
You have to do it by pairs, does not seem that = difficult. And, as IKE
does, you create the new ones and, = once created, delete the old ones. I
don't see the = synchrony problem that important.
In ideal = world - yes. In real world - I'm not so sure.
Imagine you = have an SA expired and the SDN installs a new SA
on the = peers, but one of SDN-peer TLS connection failed because off
the temporary network problem, so you have a new SA partially = installed.
What is the peer that didn't receive a new SA = supposed to do?
Continue to use an old one despite the = fact that it is expired?
Block all traffic? Something = else?
In fact, I think the SDN-based approach = performs even better than IKE in
this regards.
Imagine what happens if the corresponding IKE rekey process = fails for
the very same temporary network problem. In the = best case, CHILD SAs are
deleted after a hard expiration, = and they will need to be re-created
when triggered by the = SPD again. This is roughly identical to the SDN
approach. = But, typically, when an IKE rekey fails, the initiator will
likely close the entire IKE_SA thinking the other peer is = down, which
would result into having to recreate the = IKE_SA (including the DH
exchange), and all the associated = CHILD_SAs afterwards.

Exactly, = that's what IKE will do. But this is reasonable, because if IKE
messages cannot go between peers, it is most probably = that 
IPsec won't go either (especially in case of UDP = encapsulation).
With SDN the situation is a bit different. = The network problem 
takes place on SDN-EE path, while EE-EE path works well,
but the peers cannot communicate, because SDN fails to = provide
the keys in time. Note, that rekey may take place = quite often, depending 
on the = algorithms involved. 

[Gabi] This kind of strong requirements on the = controller availability and workload is assumed in the SDN paradigm. = Let=E2=80=99s think in a L2 OpenFlow controller for example, where the = L2-switch has to forward a copy of the incoming frame before to forward = it.

How NAT traversal is to = be done in IKE-less case? I understand, that
NATs are also = controlled by SDN, but does SDN pre-install NAT mappings?

That's a good question. I would = say so, yes.

So, SDN needs to = synchronously configure one more entity (NAT)
for IPsec to = start working? 

[Gabi] If NAT is required the = controller should know that, the IPsec configuration required to cross = the NAT should be applied by the Security Controller . The configuration = of the NAT entity may be configured independently (manually or not, note = that there are Yang models for NAT (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07)).<= /div>

But, would that generate problems if the NAT box is not = included in your
SDN (e.g. it belongs to the mall centre = or similar)?

In this case you = first need to use UDP encapsulation and second need to send
NAT keepalive messages periodically. Usually it is IKE who =  sends
these messages (I admit that you can also = sends them from the kernel).
IKE also determines if there = is a NAT in between and which peer is 
behind the = NAT. In case the NAT is out of SDN control, who will do this job?

[Gabi] the Controller should know that there is NAT in = the scenario.

[Rafa] As additional comment to Gabi=E2=80=99s = e-mail related with NAT, in our draft we have this text when IKE is not = in the device (NSF):

"Another example is the
   NAT = traversal support.  In general, the SDN paradigm assumes the = SDN
   controller has a view of the = network it controls.  This view is built
  =  either requesting information to the NSFs under its control = or
   because these NSFs inform the SDN = controller.  Based on this
  =  information, the SDN/security controller can guess if there is a = NAT
   configured between two hosts, = apply the required policies to both
  =  NSFs besides activating the usage of UDP encapsulation of ESP = packets
   [RFC3948].

   In those = scenarios, the Controller could directly request the NSF for
   specific data such as networking configuration, = NAT support, etc.
   Protocols such as = NETCONF or SNMP can be used here.  For example, RFC
   7317 [RFC7317] provides a YANG data model for = system management or
  =  [I-D.sivakumar-yang-nat] a data model for NAT = management.



What is supposed to be done if = packet with invalid AH/ESP SPI is received?



Clearly, the packet itself is dropped, but = later IKEv2 extensions (namely
RFC6290, Quick Crash = Detection) allows to send IKE notification
to the peer = with a security token to help peers quickly recover from the crash.
What is supposed to be done in IKE-less case? Or do you think =  that
with SDN such things like non-synchronized = IPsec states never = happen?


[Gabi] If it is an audiatable event by the kernel, the peer = can notify the controller about that (some examples of notifications are = already included in the yang = model)

[Rafa] Regarding the quick recover, it is typical = a keep alive mechanism between the device and the SDN controller. So = that the SDN controller can react quickly when a device restart or = crash.

Best Regards.


Thanks for the comments, this discussion is really = interesting =E2=80=A6.



Regards, Gabi.

Regards,
Valery. 

These are exactly the = sort of situations that need to be figured out.

I believe there are many of = them.

Regards,
Valery.

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



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es




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

-------------------------------------------------------
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=_8DA084F7-8E63-471E-BD23-67AD5E8CDF7C-- From nobody Wed Jul 19 08:23:24 2017 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 7B3CB131C6C; Wed, 19 Jul 2017 08:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 TcjmXibEuUpS; Wed, 19 Jul 2017 08:23:13 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 609C31315FE; Wed, 19 Jul 2017 08:23:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 44F1420B23; Wed, 19 Jul 2017 17:23:12 +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 pKnPgCdXqBYd; Wed, 19 Jul 2017 17:23:12 +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 E74E020AD3; Wed, 19 Jul 2017 17:23:09 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_57959AEC-EBBB-4D2B-A112-0B3FFAEEBEC0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Jul 2017 17:23:09 +0200 In-Reply-To: <22895.5501.430778.169927@fireball.acr.fi> Cc: Rafa Marin-Lopez , i2nsf@ietf.org, IPsecME WG , Valery Smyslov To: Tero Kivinen References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <22894.9183.134135.875338@fireball.acr.fi> <22895.5501.430778.169927@fireball.acr.fi> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:23:15 -0000 --Apple-Mail=_57959AEC-EBBB-4D2B-A112-0B3FFAEEBEC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tero: Thanks for this discussion. Really interesting and productive in my = opinion. My comments inline > El 19 jul 2017, a las 10:17, Tero Kivinen escribi=C3=B3= : >=20 > Rafa Marin-Lopez writes: >> I.e. any TLA would love to get their hands on all the traffic keys = in >> one location, and then be able to decrypt any traffic going inside = any >> of the IPsec tunnels. >>=20 >> If controller only has the PSKs or similar to do the = authentication >> between peers, then that means that the TLA needs to do active = attack >> for each connection they want to break. >>=20 >> Beause of this I think it is always best not to move the transport >> keys outside the boxes that needs them, i.e., keep them only on = the >> nodes doing actual encryption / decryption. >>=20 >> Also knowing that the controller most likely keeps all kind of = logs >> and takes backup of the configurations it is keeping, this also = makes >> the backups suitable targets for attacks, as they allow decryption >> previously stored flows of traffic, and this can be done years = later >> when one of those backups accidently finds its way to wrong hands. >>=20 >> [Rafa] In reality, the controller can forget immediately the >> credentials that has been generated. As a security measure , the >> controller does not need to store any keys it has distributed. >=20 > No it cannot. The keys needs to be installed in multiple nodes, which > means that when it generates them it needs to store them until it is > sure that every single device needing them has them. [Rafa] But that is clear, isn=E2=80=99t it?. If the controller generates = them then there is a short period of time where the key is there. No = doubt about it. My point is that the SDN controller does not need to store them once = they are distributed. >=20 > Also if any single device restarts, it will need new keys, and those > keys again needs to be destributed to all other entities sharing SA > keys with the node. Also even if if could remove the keys quite > quickly after generating them, in practice I do not think that is > going to happen, as operators want to be able to see what is the > configuration that was sent to node, which then requires controller to > keep configuration available.=20 [Rafa] One thing is to keep certain configuration about the SA and = another to store the keys in the controller. A good security practice is = to not store the keys.=20 Moreover the YANG model in the device may dictate that the variable with = the key has only writing permissions and it cannot be read posteriorly.=20= But, of course, if a centralized entity is taking control of everything = and that entity decides to not play nicely (storing keys for example), = we have a problem. That happens in SDN world regardless IPsec. If we do = not want to go to a centralized paradigm, it is fine. Get rid of SDN for = management and let stay in the distributed way.=20 But I think this is something general. If you do not trust in the = =E2=80=9Ctrusted=E2=80=9D entity then we have a problem. No doubt. In = fact, the area of securing the SDN controller itself is a vast area of = contribution and an important topic nowadays. >=20 >> This I think is important question, i.e., what is the gain for not >> running IKEv2 between the nodes? >>=20 >> [Rafa] As Yoav mentioned, simpler devices.=20 >=20 > I do not really belive that. You need security protocol to be able to > transmit the configuration to the nodes, and that security protocol > will require similar resource than what IKEv2 needs. [Rafa] The device needs to handle a single SA (TLS or SSH) with the = controller. As that will be happen regardless the management of IPsec = for tackling other aspects such as routing, IDS, firewalls, etc.=20 On the other hand, the number of IPsec SAs that device has to handle can = be many.=20 > To be able to do > the actual ESP traffic for links will require much more resources than > running IKE to setting up the SA. > Yes, you can leave few kilobytes of > code out from the flash, as you do not need to implement IKEv2. >=20 > Also you loose all kind of features too, like ability to spport > roaming clients (i.e., laptop, or phone etc connecting to network > through VPN, or actually connecting IPsec to any other node that is > not directly controlled by the controller). [Rafa] This is the reason we also have case 1 (ikev2 in the nsf). I = think it is important to note that we do not propose case 1 vs case 2.=20= We have two cases and depending on the deployment one may choose case 1 = or case 2.=20 In other words, we are not against on having IKEv2 in the NSF at all. On = the contrary it has clear advantages. We are just stating that there is = also another possibility (case 2) with advantages too. >=20 > Note, that the controller cannot run IKEv2 in behalf of any of nodes > it is controlling, as that is forbidden by the IPsec (IKE and Child SA > are tied together so that if one goes down, the other MUST go down > too). See section 2.4 of RFC7296 end of 4th paragraph (line 14 of page > 28).=20 [Rafa] In the case you mention, if an IKE SA is in the controller (this = case would be part of Road Warrior, which is TBD though), the controller = will know the IKE SA is down. As a consequence the Controller will = remove the child SAs.=20 Thus, if the IKE SA goes down the other goes down, correct? In any case, in my opinion, case 1 in our I-D could be better for Road = Warrior. No problem with that. >=20 > Also if you are limiting yourself to the endpoint-to-endpoint > transport mode (section 1.1.2 of RFC7296) with policy given by the > controller, you do not need full IKEv2 implementation, you can > implement minimal IKEv2 (RFC7815), with exception that you also need > to implement the responder side also. >=20 > Using the frequently generated PSKs distributed from the controller, > and minimal IKEv2, will give you much better security than when you > transport traffic keys from controller. [Rafa] Yes, that is one option. My comment here in the past was you = would=20 still need other features coming from the controller since minimal ikev2 = does not provide you all of them. As I see it, minimal ikev2 in the device is still case 1 somehow. But we = can introduce a note about minimal IKEv2 in our I-D as well, of course. >=20 > Btw, on Friday there will be presentation in ipsecme where they > implemented minimal IKEv2 with GDOI modifications (i.e., IKEv2 + > multicast key distribution) in device which having 256 kB of flash, > and 32 kB of ram, and that implementation included the full network > support also, not only IKEv2=E2=80=A6 [Rafa] Good to know.=20 >=20 >> [Rafa] Basically, the SDN controller will know when to do the rekey. = Please, >> see the YANG model in our draft. There is notification =E2=80=9Cexpire=E2= =80=9D >=20 > Ah, sorry, I have not read the draft yet, as I have been too busy with > other things, but if there is two way communication between the node > and controller, than that works fine. [Rafa] Yes, there is two way communication between the node and the = controller. Thanks. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- 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=_57959AEC-EBBB-4D2B-A112-0B3FFAEEBEC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Tero:

Thanks for this discussion. Really interesting and productive = in my opinion. My comments inline
El 19 jul 2017, a las 10:17, = Tero Kivinen <kivinen@iki.fi> escribi=C3=B3:

Rafa = Marin-Lopez writes:
=    I.e. any TLA would love to get their hands on all the = traffic keys in
   one location, and then = be able to decrypt any traffic going inside any
=    of the IPsec tunnels.

=    If controller only has the PSKs or similar to do the = authentication
   between peers, then that = means that the TLA needs to do active attack
=    for each connection they want to break.

   Beause of this I think it = is always best not to move the transport
=    keys outside the boxes that needs them, i.e., keep = them only on the
   nodes doing actual = encryption / decryption.

=    Also knowing that the controller most likely keeps all = kind of logs
   and takes backup of the = configurations it is keeping, this also makes
=    the backups suitable targets for attacks, as they = allow decryption
   previously stored = flows of traffic, and this can be done years later
=    when one of those backups accidently finds its way to = wrong hands.

[Rafa] In reality, the = controller can forget immediately the
credentials that has = been generated. As a security measure , the
controller = does not need to store any keys it has distributed.

No it cannot. The keys needs to = be installed in multiple nodes, which
means that when it = generates them it needs to store them until it is
sure = that every single device needing them has them.
[Rafa] But that is clear, = isn=E2=80=99t it?. If the controller generates them then there is a = short period of time where the key is there. No doubt about = it.

My point is that the SDN = controller does not need to store them once they are = distributed.


Also if any single device = restarts, it will need new keys, and those
keys again = needs to be destributed to all other entities sharing SA
keys with the node. Also even if if could remove the keys = quite
quickly after generating them, in practice I do not = think that is
going to happen, as operators want to be = able to see what is the
configuration that was sent to = node, which then requires controller to
keep configuration = available.

[Rafa] One thing is to keep certain configuration = about the SA and another to store the keys in the controller. A good = security practice is to not store the keys. 

Moreover the YANG model in the device may dictate = that the variable with the key has only writing permissions and it = cannot be read posteriorly. 

But,= of course, if a centralized entity is taking control of everything and = that entity decides to not play nicely (storing keys for example), we = have a problem. That happens in SDN world regardless IPsec. If we do not = want to go to a centralized paradigm, it is fine. Get rid of SDN for = management and let stay in the distributed way. 

But I think this is something general. If you do = not trust in the =E2=80=9Ctrusted=E2=80=9D entity then we have a = problem. No doubt. In fact, the area of securing the SDN controller = itself is a vast area of contribution and an important topic = nowadays.


   This I think is important = question, i.e., what is the gain for not
=    running IKEv2 between the nodes?

[Rafa] As Yoav mentioned, simpler devices.

I do not really belive that. You = need security protocol to be able to
transmit the = configuration to the nodes, and that security protocol
will = require similar resource than what IKEv2 needs. =

[Rafa] The device = needs to handle a single SA (TLS or SSH) with the controller. As that = will be happen regardless the management of IPsec for tackling other = aspects such as routing, IDS, firewalls, etc. 

On the other hand, the number of IPsec SAs that = device has to handle can be many. 

To be able to do
the actual ESP traffic for = links will require much more resources than
running IKE to = setting up the SA.
Yes, you can leave few = kilobytes of
code out from the flash, as you do not need = to implement IKEv2.

Also you loose = all kind of features too, like ability to spport
roaming = clients (i.e., laptop, or phone etc connecting to network
through VPN, or actually connecting IPsec to any other node = that is
not directly controlled by the controller).

[Rafa] = This is the reason we also have case 1 (ikev2 in the nsf). I think it is = important to note that we do not propose case 1 vs case = 2. 
We have two cases and depending on the deployment one = may choose case 1 or case 2. 

In = other words, we are not against on having IKEv2 in the NSF at all. On = the contrary it has clear advantages. We are just stating that there is = also another possibility (case 2) with advantages too.


Note, that the controller cannot run IKEv2 in = behalf of any of nodes
it is controlling, as that is = forbidden by the IPsec (IKE and Child SA
are tied together = so that if one goes down, the other MUST go down
too). See = section 2.4 of RFC7296 end of 4th paragraph (line 14 of page
28).

[Rafa] In the case you mention, if an IKE SA is in = the controller (this case would be part of Road Warrior, which is TBD = though), the controller will know the IKE SA is down. As a consequence = the Controller will remove the child SAs. 

Thus, if the IKE SA goes down the other goes down, = correct?

In any case, in my opinion, = case 1 in our I-D could be better for Road Warrior. No problem with = that.


Also if you = are limiting yourself to the endpoint-to-endpoint
transport = mode (section 1.1.2 of RFC7296) with policy given by the
controller, you do not need full IKEv2 implementation, you = can
implement minimal IKEv2 (RFC7815), with exception that = you also need
to implement the responder side also.

Using the frequently generated PSKs = distributed from the controller,
and minimal IKEv2, will = give you much better security than when you
transport = traffic keys from controller.

[Rafa] = Yes, that is one option. My comment here in the past was you = would 
still need other features coming from the = controller since minimal ikev2 does not provide you all of = them.

As I see it, minimal ikev2 in = the device is still case 1 somehow. But we can introduce a note about = minimal IKEv2 in our I-D as well, of course.


Btw, on Friday there will be presentation in = ipsecme where they
implemented minimal IKEv2 with GDOI = modifications (i.e., IKEv2 +
multicast key distribution) = in device which having 256 kB of flash,
and 32 kB of ram, = and that implementation included the full network
support = also, not only IKEv2=E2=80=A6

[Rafa] Good to know. 

[Rafa] Basically, the = SDN controller will know when to do the rekey. Please,
see = the YANG model in our draft. There is notification =E2=80=9Cexpire=E2=80=9D=

Ah, sorry, I have not read = the draft yet, as I have been too busy with
other things, = but if there is two way communication between the node
and = controller, than that works fine.

[Rafa] = Yes, there is two way communication between the node and the = controller.

Thanks.

--
kivinen@iki.fi

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

-------------------------------------------------------
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=_57959AEC-EBBB-4D2B-A112-0B3FFAEEBEC0-- From nobody Thu Jul 20 00:56:47 2017 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 56788126B72; Thu, 20 Jul 2017 00:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 o-x3zbyVklQ8; Thu, 20 Jul 2017 00:56:37 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 393C5126557; Thu, 20 Jul 2017 00:56:36 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id z78so9151779lff.0; Thu, 20 Jul 2017 00:56:36 -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=4Df3LOZfDX1XjCmAhpiiuoVGwbIs5Nnw2Aa9gBgL94A=; b=a5zIBl6wodYElojSEnHgobjL9ionnlHR0G7U2J8Peykd9hf4bLj6Yb/2WjzI79T8AU PFE4RxcRZ5fIMwQNjO46Z1oez2ceT471xp1i9+QhgfVMOtiaV0aBR6ArgSwGoCdD+BO7 0sZf8KzJ8hcpFb5esdTgtnN9eqbxnWGq0tUcTiDCdenGEJeTV/k9gJV5AM0hoSejzkE6 i5f4qNJ4kzMp7dNNcD4gM/Sa+1k+dUZkwZ/0/7+dVudW41w0nfGYQLf8EK9fbWN88YHU JLzWGd0wvDSW8RbQg8OKfL0xXYI5IYUyRZY7qTX4Hr+MTmYm3bpi9cUQtAuEElJB7dqi RGxg== 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=4Df3LOZfDX1XjCmAhpiiuoVGwbIs5Nnw2Aa9gBgL94A=; b=L1cGkwnC6sxqCFiB3Glk4UdhXAfuFUR3ZVq5nWWWGCZa9Gexi1NxHopoi3SWRFKmsh UEzXQj6GhLANe2X5l8WW8CUQhoOgyH57f1A80zWFkmqPB4ENlZSIfH47f66IdxVoMLxV 2mzfc/en9lxF5GEyrpA22mkU2X0ER6inAvGDNVD4OF4rHbDP9bd17YLow/owH9gxjUIm EZO023Kuo6RFRCKVlsR0qTrganfKU4zm2gaOp+gT5OhsJN8g8HOeQ+IxeN/eIBXb6JiY ZIZymcYm/yS86nccg/ow3Sis3qtmOtOZyDboYRPRoRQFhJHwGFMk2gZHTqJXv8WwIr1+ jTEQ== X-Gm-Message-State: AIVw111uu+kkUpnMSQjX+XgbhO1znrhaJFdqLW23ohDehNFemtkp+c++ ygy2in5VMXKzLQ== X-Received: by 10.25.198.211 with SMTP id w202mr938418lff.211.1500537394414; Thu, 20 Jul 2017 00:56:34 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id d62sm357479lfd.55.2017.07.20.00.56.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Jul 2017 00:56:33 -0700 (PDT) From: "Valery Smyslov" To: "'Gabriel Lopez'" Cc: =?utf-8?Q?'Alejandro_P=C3=A9rez_M=C3=A9ndez'?= , , "'IPsecME WG'" , "'Rafa Marin Lopez'" References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <02e601d3005a$c1791170$446b3450$@gmail.com> <1e2efa38-5b95-7685-8fb9-047b656f0e58@um.es> <031201d30085$d4cab0a0$7e6011e0$@gmail.com> In-Reply-To: Date: Thu, 20 Jul 2017 10:56:35 +0300 Message-ID: <04b701d3012d$b5f05920$21d10b60$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B8_01D30146.DB422500" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKDIHC5dXDQzOp5aMUY5Ta8XNCy6AHIW25WAYFIQaEB358/jwHmfx+UAaSah3SgtnEz4A== Content-Language: ru Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:56:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04B8_01D30146.DB422500 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Gabriel, =20 I think that at this point the discussion is not very productive. I admit that I=E2=80=99m not very familiar with SDNs, so I have to=20 blindly trust you when you state that the SDN Controller knows everything and is able to control everything, so it is like God. Probably this is true. =20 I just want to reiterate, that while security architecture with central key distribution is definitely feasible and it is feasible to make it secure, my strong opinion is that it is still a large step backward from End-to-End security model and it is much more fragile. And I agree with Tero that =E2=80=9CEE simplicity=E2=80=9D argument in most cases doesn=E2=80=99t = look=20 reasonable to buy. Probably you can add justifications to this argument, e.g. by providing estimates how much resources you are going to save on EE if you get rid of IKE (but leave IPsec, TLS and so on).=20 =20 Regards, Valery. =20 From: Gabriel Lopez [mailto:gabilm@um.es]=20 Sent: Wednesday, July 19, 2017 5:21 PM To: Valery Smyslov Cc: Alejandro P=C3=A9rez M=C3=A9ndez; i2nsf@ietf.org; IPsecME WG; Rafa = Marin Lopez Subject: Re: [I2nsf] [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection =20 Hi Valery, =20 El 19 jul 2017, a las 13:54, Valery Smyslov = escribi=C3=B3: =20 Hi Alejandro, It is more fragile too. You must perform periodical rekey (update keys) and this must be done synchronously. You have to do it by pairs, does not seem that difficult. And, as IKE does, you create the new ones and, once created, delete the old ones. I don't see the synchrony problem that important. In ideal world - yes. In real world - I'm not so sure. Imagine you have an SA expired and the SDN installs a new SA on the peers, but one of SDN-peer TLS connection failed because off the temporary network problem, so you have a new SA partially installed. What is the peer that didn't receive a new SA supposed to do? Continue to use an old one despite the fact that it is expired? Block all traffic? Something else? In fact, I think the SDN-based approach performs even better than IKE in this regards. Imagine what happens if the corresponding IKE rekey process fails for the very same temporary network problem. In the best case, CHILD SAs are deleted after a hard expiration, and they will need to be re-created when triggered by the SPD again. This is roughly identical to the SDN approach. But, typically, when an IKE rekey fails, the initiator will likely close the entire IKE_SA thinking the other peer is down, which would result into having to recreate the IKE_SA (including the DH exchange), and all the associated CHILD_SAs afterwards. Exactly, that's what IKE will do. But this is reasonable, because if IKE messages cannot go between peers, it is most probably that=20 IPsec won't go either (especially in case of UDP encapsulation). With SDN the situation is a bit different. The network problem=20 takes place on SDN-EE path, while EE-EE path works well, but the peers cannot communicate, because SDN fails to provide the keys in time. Note, that rekey may take place quite often, depending = on the algorithms involved.=20 =20 [Gabi] This kind of strong requirements on the controller availability = and workload is assumed in the SDN paradigm. Let=E2=80=99s think in a L2 = OpenFlow controller for example, where the L2-switch has to forward a = copy of the incoming frame before to forward it. How NAT traversal is to be done in IKE-less case? I understand, that NATs are also controlled by SDN, but does SDN pre-install NAT mappings? That's a good question. I would say so, yes. So, SDN needs to synchronously configure one more entity (NAT) for IPsec to start working?=20 =20 [Gabi] If NAT is required the controller should know that, the IPsec = configuration required to cross the NAT should be applied by the = Security Controller . The configuration of the NAT entity may be = configured independently (manually or not, note that there are Yang = models for NAT = (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07)). But, would that generate problems if the NAT box is not included in your SDN (e.g. it belongs to the mall centre or similar)? In this case you first need to use UDP encapsulation and second need to = send NAT keepalive messages periodically. Usually it is IKE who sends these messages (I admit that you can also sends them from the kernel). IKE also determines if there is a NAT in between and which peer is=20 behind the NAT. In case the NAT is out of SDN control, who will do this = job? =20 [Gabi] the Controller should know that there is NAT in the scenario. What is supposed to be done if packet with invalid AH/ESP SPI is = received? =20 =20 Clearly, the packet itself is dropped, but later IKEv2 extensions = (namely RFC6290, Quick Crash Detection) allows to send IKE notification to the peer with a security token to help peers quickly recover from the = crash. What is supposed to be done in IKE-less case? Or do you think that with SDN such things like non-synchronized IPsec states never happen? =20 [Gabi] If it is an audiatable event by the kernel, the peer can notify = the controller about that (some examples of notifications are already = included in the yang model) =20 Thanks for the comments, this discussion is really interesting = =E2=80=A6. =20 Regards, Gabi. Regards, Valery.=20 These are exactly the sort of situations that need to be figured out. I believe there are many of them. Regards, Valery. _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf =20 =20 ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es =20 =20 =20 ------=_NextPart_000_04B8_01D30146.DB422500 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Gabriel,

 

I think that at this point the discussion is not very = productive.

I admit that I=E2=80=99m not very familiar with SDNs, so I have to =

blindly trust you when you state that the SDN = Controller

knows everything and is able to control = everything,

so it is like God. Probably this is true.

 

I just want to reiterate, that while security = architecture

with central key distribution is definitely feasible = and

it is feasible to make it secure, my strong opinion is = that

it is still a large step backward from End-to-End = security

model and it is much more fragile. And I agree with Tero = that

=E2=80=9CEE simplicity=E2=80=9D argument in most cases = doesn=E2=80=99t look

reasonable to buy. Probably you can add = justifications

to this argument, e.g. by providing estimates how = much

resources you are going to save on EE if you get rid of = IKE

(but leave IPsec, TLS and so on).

 

Regards,

Valery.

 

From:= Gabriel = Lopez [mailto:gabilm@um.es]
Sent: Wednesday, July 19, 2017 = 5:21 PM
To: Valery Smyslov
Cc: Alejandro P=C3=A9rez = M=C3=A9ndez; i2nsf@ietf.org; IPsecME WG; Rafa Marin = Lopez
Subject: Re: [I2nsf] [IPsec] = draft-abad-i2nsf-sdn-ipsec-flow-protection

 

Hi = Valery,

 

El 19 jul 2017, a las 13:54, Valery Smyslov <svanru@gmail.com> = escribi=C3=B3:

 

Hi = Alejandro,


It = is more fragile too. You must perform periodical rekey (update = keys)
and this must be done = synchronously.

You have = to do it by pairs, does not seem that difficult. And, as IKE
does, = you create the new ones and, once created, delete the old ones. = I
don't see the synchrony problem that = important.

In ideal = world - yes. In real world - I'm not so sure.
Imagine you have an SA = expired and the SDN installs a new SA
on the peers, but one of = SDN-peer TLS connection failed because off
the temporary network = problem, so you have a new SA partially installed.
What is the peer = that didn't receive a new SA supposed to do?
Continue to use an old = one despite the fact that it is expired?
Block all traffic? Something = else?

In fact, I think = the SDN-based approach performs even better than IKE in
this = regards.
Imagine what happens if the corresponding IKE rekey process = fails for
the very same temporary network problem. In the best case, = CHILD SAs are
deleted after a hard expiration, and they will need to = be re-created
when triggered by the SPD again. This is roughly = identical to the SDN
approach. But, typically, when an IKE rekey = fails, the initiator will
likely close the entire IKE_SA thinking the = other peer is down, which
would result into having to recreate the = IKE_SA (including the DH
exchange), and all the associated CHILD_SAs = afterwards.


Exactly, that's what = IKE will do. But this is reasonable, because if IKE
messages cannot = go between peers, it is most probably that
IPsec won't go either = (especially in case of UDP encapsulation).
With SDN the situation is = a bit different. The network problem
takes place on SDN-EE path, = while EE-EE path works well,
but the peers cannot communicate, = because SDN fails to provide
the keys in time. Note, that rekey may = take place quite often, depending
on the algorithms involved. =

 

[Gabi] = This kind of strong requirements on the controller availability and = workload is assumed in the SDN paradigm. Let=E2=80=99s think in a L2 = OpenFlow controller for example, where the L2-switch has to forward a = copy of the incoming frame before to forward = it.



How = NAT traversal is to be done in IKE-less case? I understand, that
NATs = are also controlled by SDN, but does SDN pre-install NAT = mappings?


That's a = good question. I would say so, yes.


So, SDN needs to synchronously configure one more = entity (NAT)
for IPsec to start working? =

 

[Gabi] If NAT is required the controller should know = that, the IPsec configuration required to cross the NAT should be = applied by the Security Controller . The configuration of the NAT entity = may be configured independently (manually or not, note that there are = Yang models for NAT (https://= tools.ietf.org/html/draft-sivakumar-yang-nat-07)).





But, would = that generate problems if the NAT box is not included in your
SDN = (e.g. it belongs to the mall centre or similar)?


In this case you first need to use UDP = encapsulation and second need to send
NAT keepalive messages = periodically. Usually it is IKE who  sends
these messages (I = admit that you can also sends them from the kernel).
IKE also = determines if there is a NAT in between and which peer is
behind the = NAT. In case the NAT is out of SDN control, who will do this = job?

 

[Gabi] = the Controller should know that there is NAT in the = scenario.


What = is supposed to be done if packet with invalid AH/ESP SPI is = received?

 

 



Clearly, the packet itself is dropped, but later IKEv2 = extensions (namely
RFC6290, Quick Crash Detection) allows to send IKE = notification
to the peer with a security token to help peers quickly = recover from the crash.
What is supposed to be done in IKE-less case? = Or do you think  that
with SDN such things like non-synchronized = IPsec states never happen?

 

[Gabi] If it is an audiatable event by the kernel, the = peer can notify the controller about that (some examples of = notifications are already included in the yang = model)

 

Thanks for the comments, this discussion is really = interesting =E2=80=A6.

 

Regards, Gabi.


Regards,
Valery.


These are exactly the sort of situations that need to = be figured out.


I believe there = are many of = them.

Regards,
Valery.

_________________________________= ______________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org= /mailman/listinfo/i2nsf

 

 

-----------------------------------------------------------
Gabriel = L=C3=B3pez Mill=C3=A1n
Departamento de Ingenier=C3=ADa de la = Informaci=C3=B3n y las Comunicaciones
University of = Murcia
Spain
Tel: +34 868888504
Fax: +34 = 868884151
email: gabilm@um.es

=

 

 

 

------=_NextPart_000_04B8_01D30146.DB422500-- From nobody Thu Jul 20 01:12:58 2017 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 6DA2C129562; Thu, 20 Jul 2017 01:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mYu3dhhrsXCJ; Thu, 20 Jul 2017 01:12:54 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 3E5CF126557; Thu, 20 Jul 2017 01:12:54 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id 184so32635wmo.3; Thu, 20 Jul 2017 01:12:54 -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=4DBCINq4Kf9CsyPaLyok6mt71aWJjvPJRuOtPID8MZ0=; b=h79NIbEH8yNrkv8Mj1SeK8wxpSuDLY++xSXLmq774KGoJwgTlkBhB763XLCHums2X9 0YzX+5W2JMuEK8zlaY66u1aR3KeQRo+jykZlum1CkgCmdRRX0VUqy6qXJXHTFanTiLlb qo9bcbvY1/J9ml+FYOn0cVwMMCnlz4zCk3gIhKxsf9lDlOADUEH7lzsoHPPejT9GQNDY QfRc9Ta0JU2dH4+GsntGuejj50fg3VqMlQs8NVVRXOPG+cVwTwu7Xs8J9PNilqEX2W46 e3DMoSLIfcokcskUg5UzmrgaTCEuTwufNfrSp5ZVX2yy5NKaKjMLWMsLERzww4KTuvEo LQxQ== 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=4DBCINq4Kf9CsyPaLyok6mt71aWJjvPJRuOtPID8MZ0=; b=AfbZVjNFH+Ix3hgSEo6xDSHc/WNrSLqp+ARRiT21Qgmd1uso5E8E4nKzA1Rt9VNeS/ ROQPB2DrHVTpr/8T+KnpbCpsvR/NfpI50NWNgWFIcMTLJSSK3MyT7cna0Lbly2gUIv5n j9a8GFUch01NRRZ59pqCP0KAJvwe8FCYJkBawdqZKQkXulQy17XXHtC3H3nKAzJ5nuco Fto/gSkPSXcApXGsEEjH+J70J078GXdEMqAinzeZ1KGG9rMdss6SAbgRg0XsmonJWnc6 mji8avcYJWje+FAguiEtC+/Ufey0YHONelNu5KLKgIoaPr93V27jAqbXcfsDpeMHYkqU RjEg== X-Gm-Message-State: AIVw112PJlAFSSFCBfxS8vbOmg7KPRnJYRkl9LBhOUtXnnQ6f1Q5FGqc LDxKz82I9Owxjg== X-Received: by 10.28.51.5 with SMTP id z5mr1596713wmz.80.1500538372697; Thu, 20 Jul 2017 01:12:52 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:7059:801e:36de:6305? ([2001:67c:370:128:7059:801e:36de:6305]) by smtp.gmail.com with ESMTPSA id s2sm1776102wra.71.2017.07.20.01.12.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 01:12:51 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9867516A-B997-4AFC-B27F-EC935C2DCCDC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Jul 2017 10:12:50 +0200 In-Reply-To: <04b701d3012d$b5f05920$21d10b60$@gmail.com> Cc: Gabriel Lopez , i2nsf@ietf.org, IPsecME WG , Rafa Marin Lopez , =?utf-8?Q?Alejandro_P=C3=A9rez_M=C3=A9ndez?= To: Valery Smyslov References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <02e601d3005a$c1791170$446b3450$@gmail.com> <1e2efa38-5b95-7685-8fb9-047b656f0e58@um.es> <031201d30085$d4cab0a0$7e6011e0$@gmail.com> <04b701d3012d$b5f05920$21d10b60$@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:12:56 -0000 --Apple-Mail=_9867516A-B997-4AFC-B27F-EC935C2DCCDC Content-Type: multipart/alternative; boundary="Apple-Mail=_FEAD0259-5D6E-46BC-B034-6108C98AB4D7" --Apple-Mail=_FEAD0259-5D6E-46BC-B034-6108C98AB4D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Jul 2017, at 9:56, Valery Smyslov wrote: >=20 > Hi Gabriel, >=20 > I think that at this point the discussion is not very productive. > I admit that I=E2=80=99m not very familiar with SDNs, so I have to > blindly trust you when you state that the SDN Controller > knows everything and is able to control everything, > so it is like God. Probably this is true. That the controller (or its administrator) knows everything is part of = the model of SDN. SDN comes from datacenters and in datacenters the = administrators control everything and the protocol is used to configure = a whole bunch of routers and switches. I2NSF is extending this to security boxes such as firewalls, IDS, etc. = The context is still the data center. The firewalls are at the edge of = the datacenter and the intruder detection is either co-located with the = firewall or inside. VPN is different. While one or more box is within the datacenter, the = vast majority of boxes are out of the datacenter and located all over = the Internet. Their routing is usually not under the control of the = administrator, so we=E2=80=99d like to control just the IPsec = configuration. >=20 > I just want to reiterate, that while security architecture > with central key distribution is definitely feasible and > it is feasible to make it secure, my strong opinion is that > it is still a large step backward from End-to-End security > model and it is much more fragile. And I agree with Tero that > =E2=80=9CEE simplicity=E2=80=9D argument in most cases doesn=E2=80=99t = look > reasonable to buy. Probably you can add justifications > to this argument, e.g. by providing estimates how much > resources you are going to save on EE if you get rid of IKE > (but leave IPsec, TLS and so on). >=20 > Regards, > Valery. >=20 > From: Gabriel Lopez [mailto:gabilm@um.es ] > Sent: Wednesday, July 19, 2017 5:21 PM > To: Valery Smyslov > Cc: Alejandro P=C3=A9rez M=C3=A9ndez; i2nsf@ietf.org = ; IPsecME WG; Rafa Marin Lopez > Subject: Re: [I2nsf] [IPsec] = draft-abad-i2nsf-sdn-ipsec-flow-protection >=20 > Hi Valery, >=20 >> El 19 jul 2017, a las 13:54, Valery Smyslov > escribi=C3=B3: >>=20 >> Hi Alejandro, >>=20 >>=20 >>>>> It is more fragile too. You must perform periodical rekey (update = keys) >>>>> and this must be done synchronously. >>>> You have to do it by pairs, does not seem that difficult. And, as = IKE >>>> does, you create the new ones and, once created, delete the old = ones. I >>>> don't see the synchrony problem that important. >>> In ideal world - yes. In real world - I'm not so sure. >>> Imagine you have an SA expired and the SDN installs a new SA >>> on the peers, but one of SDN-peer TLS connection failed because off >>> the temporary network problem, so you have a new SA partially = installed. >>> What is the peer that didn't receive a new SA supposed to do? >>> Continue to use an old one despite the fact that it is expired? >>> Block all traffic? Something else? >> In fact, I think the SDN-based approach performs even better than IKE = in >> this regards. >> Imagine what happens if the corresponding IKE rekey process fails for >> the very same temporary network problem. In the best case, CHILD SAs = are >> deleted after a hard expiration, and they will need to be re-created >> when triggered by the SPD again. This is roughly identical to the SDN >> approach. But, typically, when an IKE rekey fails, the initiator will >> likely close the entire IKE_SA thinking the other peer is down, which >> would result into having to recreate the IKE_SA (including the DH >> exchange), and all the associated CHILD_SAs afterwards. >>=20 >> Exactly, that's what IKE will do. But this is reasonable, because if = IKE >> messages cannot go between peers, it is most probably that >> IPsec won't go either (especially in case of UDP encapsulation). >> With SDN the situation is a bit different. The network problem >> takes place on SDN-EE path, while EE-EE path works well, >> but the peers cannot communicate, because SDN fails to provide >> the keys in time. Note, that rekey may take place quite often, = depending >> on the algorithms involved. >=20 > [Gabi] This kind of strong requirements on the controller availability = and workload is assumed in the SDN paradigm. Let=E2=80=99s think in a L2 = OpenFlow controller for example, where the L2-switch has to forward a = copy of the incoming frame before to forward it. >=20 >=20 >=20 >> How NAT traversal is to be done in IKE-less case? I understand, that >> NATs are also controlled by SDN, but does SDN pre-install NAT = mappings? >=20 > That's a good question. I would say so, yes. >=20 > So, SDN needs to synchronously configure one more entity (NAT) > for IPsec to start working? >=20 > [Gabi] If NAT is required the controller should know that, the IPsec = configuration required to cross the NAT should be applied by the = Security Controller . The configuration of the NAT entity may be = configured independently (manually or not, note that there are Yang = models for NAT (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07 = )). >=20 >=20 >=20 >=20 > But, would that generate problems if the NAT box is not included in = your > SDN (e.g. it belongs to the mall centre or similar)? >=20 > In this case you first need to use UDP encapsulation and second need = to send > NAT keepalive messages periodically. Usually it is IKE who sends > these messages (I admit that you can also sends them from the kernel). > IKE also determines if there is a NAT in between and which peer is > behind the NAT. In case the NAT is out of SDN control, who will do = this job? >=20 > [Gabi] the Controller should know that there is NAT in the scenario. >=20 >=20 > What is supposed to be done if packet with invalid AH/ESP SPI is = received? >=20 >=20 >=20 >=20 > Clearly, the packet itself is dropped, but later IKEv2 extensions = (namely > RFC6290, Quick Crash Detection) allows to send IKE notification > to the peer with a security token to help peers quickly recover from = the crash. > What is supposed to be done in IKE-less case? Or do you think that > with SDN such things like non-synchronized IPsec states never happen? >=20 > [Gabi] If it is an audiatable event by the kernel, the peer can notify = the controller about that (some examples of notifications are already = included in the yang model) >=20 > Thanks for the comments, this discussion is really interesting =E2=80=A6= . >=20 > Regards, Gabi. >>=20 >> Regards, >> Valery. >>=20 >>=20 >> These are exactly the sort of situations that need to be figured out. >>=20 >> I believe there are many of them. >>=20 >> Regards, >> Valery. >>=20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf = >=20 >=20 >=20 > ----------------------------------------------------------- > Gabriel L=C3=B3pez Mill=C3=A1n > Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones > University of Murcia > Spain > Tel: +34 868888504 > Fax: +34 868884151 > email: gabilm@um.es >=20 >=20 >=20 >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf = --Apple-Mail=_FEAD0259-5D6E-46BC-B034-6108C98AB4D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 20 Jul 2017, at 9:56, Valery Smyslov <svanru@gmail.com> = wrote:

Hi = Gabriel,
 
I think that = at this point the discussion is not very productive.
I admit that I=E2=80=99m = not very familiar with SDNs, so I have to 
blindly trust you when = you state that the SDN Controller
knows everything and is able to control everything,
so it is like God. = Probably this is true.

That the controller (or its administrator) knows = everything is part of the model of SDN. SDN comes from datacenters and = in datacenters the administrators control everything and the protocol is = used to configure a whole bunch of routers and switches.

I2NSF is extending this to security boxes such as = firewalls, IDS, etc. The context is still the data center. The firewalls = are at the edge of the datacenter and the intruder detection is either = co-located with the firewall or inside.

VPN is different. While one or more box is within = the datacenter, the vast majority of boxes are out of the datacenter and = located all over the Internet. Their routing is usually not under the = control of the administrator, so we=E2=80=99d like to control just the = IPsec configuration.


I = just want to reiterate, that while security architecture
with central key = distribution is definitely feasible and
it is feasible to make = it secure, my strong opinion is that
it is still a large = step backward from End-to-End security
model and it is much = more fragile. And I agree with Tero that
=E2=80=9CEE = simplicity=E2=80=9D argument in most cases doesn=E2=80=99t look 
reasonable to buy. = Probably you can add justifications
to this argument, e.g. by providing estimates how much
resources you are going = to save on EE if you get rid of IKE
(but leave IPsec, TLS and so on). 
 
Regards,
Valery.
 
From: Gabriel = Lopez [mailto:gabilm@um.es] 
Sent: Wednesday, July 19, 2017 = 5:21 PM
To: Valery Smyslov
Cc: Alejandro P=C3=A9rez = M=C3=A9ndez; i2nsf@ietf.org; IPsecME WG; Rafa Marin = Lopez
Subject: Re: [I2nsf] [IPsec] = draft-abad-i2nsf-sdn-ipsec-flow-protection
 
Hi Valery,
 
El 19 jul 2017, a las 13:54, Valery Smyslov <svanru@gmail.com> = escribi=C3=B3:
 
Hi Alejandro,


It = is more fragile too. You must perform periodical rekey (update keys)
and this must be done synchronously.
You have to do it by pairs, does not seem that difficult. = And, as IKE
does, you create the new ones and, once = created, delete the old ones. I
don't see the synchrony = problem that important.
In ideal world - yes. In real world - I'm = not so sure.
Imagine you have an SA expired and the SDN = installs a new SA
on the peers, but one of SDN-peer TLS = connection failed because off
the temporary network = problem, so you have a new SA partially installed.
What is = the peer that didn't receive a new SA supposed to do?
Continue to use an old one despite the fact that it is = expired?
Block all traffic? Something else?
In fact, I think the SDN-based approach performs even better = than IKE in
this regards.
Imagine what = happens if the corresponding IKE rekey process fails for
the= very same temporary network problem. In the best case, CHILD SAs are
deleted after a hard expiration, and they will need to be = re-created
when triggered by the SPD again. This is = roughly identical to the SDN
approach. But, typically, = when an IKE rekey fails, the initiator will
likely close = the entire IKE_SA thinking the other peer is down, which
would result into having to recreate the IKE_SA (including = the DH
exchange), and all the associated CHILD_SAs = afterwards.

Exactly, that's what IKE will do. But this is = reasonable, because if IKE
messages cannot go between = peers, it is most probably that 
IPsec won't = go either (especially in case of UDP encapsulation).
With = SDN the situation is a bit different. The network problem 
takes place = on SDN-EE path, while EE-EE path works well,
but the peers = cannot communicate, because SDN fails to provide
the keys = in time. Note, that rekey may take place quite often, depending 
on the = algorithms involved. 
 
[Gabi] This kind of strong requirements on the controller = availability and workload is assumed in the SDN paradigm. Let=E2=80=99s = think in a L2 OpenFlow controller for example, where the L2-switch has = to forward a copy of the incoming frame before to forward it.



How NAT traversal is to be done in IKE-less case? I = understand, that
NATs are also controlled by SDN, but does = SDN pre-install NAT mappings?

That's a good question. I = would say so, yes.

So, SDN needs to synchronously configure one = more entity (NAT)
for IPsec to start working? 
 
[Gabi] If NAT is = required the controller should know that, the IPsec configuration = required to cross the NAT should be applied by the Security Controller . = The configuration of the NAT entity may be configured independently = (manually or not, note that there are Yang models for NAT (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07)).<= o:p class=3D"">




But, would that generate problems if the NAT box is not = included in your
SDN (e.g. it belongs to the mall centre = or similar)?

In this case you first need to use UDP = encapsulation and second need to send
NAT keepalive = messages periodically. Usually it is IKE who  sends
these messages (I admit that you can also sends them from the = kernel).
IKE also determines if there is a NAT in between = and which peer is 
behind the NAT. In case the NAT is out of SDN control, who = will do this job?
 
[Gabi] the Controller should know that there is NAT in the = scenario.


What is supposed to be done if packet with invalid AH/ESP SPI = is received?
 
 


Clearly, the packet = itself is dropped, but later IKEv2 extensions (namely
RFC6290, Quick Crash Detection) allows to send IKE = notification
to the peer with a security token to help = peers quickly recover from the crash.
What is supposed to = be done in IKE-less case? Or do you think  that
with = SDN such things like non-synchronized IPsec states never happen?
 
[Gabi] If it is an = audiatable event by the kernel, the peer can notify the controller about = that (some examples of notifications are already included in the yang = model)
 
Thanks for the comments, this discussion is really = interesting =E2=80=A6.
 
Regards, Gabi.

Regards,
Valery. 


These are exactly the sort of situations = that need to be figured out.

I believe there are many = of them.

Regards,
Valery.

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

 

-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es
 

 

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

= --Apple-Mail=_FEAD0259-5D6E-46BC-B034-6108C98AB4D7-- --Apple-Mail=_9867516A-B997-4AFC-B27F-EC935C2DCCDC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZcGYCAAoJELhJCxUKWMyZljMH/R/VTbLtSUHef+3HmJtHFciF leCVqD9lgr3sWGcUWk+JqgDFYPqF0Im2K0rpEF1ZWkI6Ydq5PZb6mqdldQpt0SaU o40s7k0qvJYmjVErba0aduyC5tg2pbum8VIJ24KgAj6X9ZTstQj+pXQuU1cwgQtq 7yT/ajeNHjFNKjD0dz6ltXofmQV8prMORrQepitKmsrVOdg4WMg2Tz0wPTtqT2ae 7Nb7Sq/1gbNKM5pfdz18XmbFtWbLcXloWIaRuz3mP+gM1Ej7Oxxf0HS37M3SC/IW 3PKK2bxurSYc4Dyr1341KU1UMh6B/vyMvzmdSIbO0E5LPyLFnSjKcQsdVcWkdRI= =IMZI -----END PGP SIGNATURE----- --Apple-Mail=_9867516A-B997-4AFC-B27F-EC935C2DCCDC-- From nobody Thu Jul 20 01:38:59 2017 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 F021D127869; Thu, 20 Jul 2017 01:38:52 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 DIK7pj25g_xs; Thu, 20 Jul 2017 01:38:50 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14732127735; Thu, 20 Jul 2017 01:38:47 -0700 (PDT) Received: from DESKTOP58DFL8T (unknown [IPv6:2001:67c:370:128:f52f:c23a:43d1:1a04]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 7860135C0E8; Thu, 20 Jul 2017 10:38:45 +0200 (CEST) From: "Tobias Guggemos" To: "'Raja ashok'" , Cc: , "IPsecme WG" References: In-Reply-To: Date: Thu, 20 Jul 2017 10:38:43 +0200 Message-ID: <002d01d30133$9895a460$c9c0ed20$@nm.ifi.lmu.de> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_002E_01D30144.5C232F50" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdL8rIhJZBwSrJwqQ9WHqW7lnBPV2wEhLe+A Content-Language: de Archived-At: Subject: Re: [IPsec] Suggestions in draft-mglt-lwig-minimal-esp X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:38:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002E_01D30144.5C232F50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002F_01D30144.5C232F50" ------=_NextPart_001_002F_01D30144.5C232F50 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hey Ashok, thanks for your feedback. For your first comment I tend to agree and I think we can add this to = the draft! For the second, I agree with your assumption that tunnels might appear = in constrained scenarios (it=A1=AFs actually one of our main goals for = ipsec/esp). However, I=A1=AFm not sure if this recommendation to not use = fragmentation is valid on a security side, why I=A1=AFd like to give the question to the = ipsecme WG, if that does not open any other security issues? Or if there is = anything else to consider on that? Thanks Tobias =20 Von: Raja ashok [mailto:raja.ashok@huawei.com]=20 Gesendet: Freitag, 14. Juli 2017 16:22 An: draft-mglt-lwig-minimal-esp@ietf.org Cc: lwip@ietf.org Betreff: Suggestions in draft-mglt-lwig-minimal-esp=20 =20 Hi Daniel & Tobias, =20 I gone through the lwIG draft for ESP. I am having some doubts and suggestions which are listed below. Please check and provide your = comments. =20 1) For replay protection, RFC 4303 suggests to use 32 or 64 bit = window. I feel in this draft, we can recommend to use 32 bit window for replay protection. =20 2) Tunneled ESP msg with fragmented IP header (in ESP payload) may = leads to DoS vulnerability for a constraint receiver. RFC 4303 is suggesting = this fragmentation as optional. So I feel we can mention as fragmentation and reassembly is not required to support in tunneled IP header. As it can = be handled by the IP header which carries ESP msg. I hope tunneled ESP msg might be required in some scenarios of constraint devices also. =20 Regards, Ashok =20 _____ =20 Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com=20 _____ =20 =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA =D7=E9=A1=A3=BD=FB =D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3= =C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6= =B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3= =CA =BC=FE=D6=D0 =B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC= =FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA= =B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1 This e-mail and its attachments contain confidential information from HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, total or partial=20 disclosure, reproduction, or dissemination) by persons other than the intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by=20 phone or email immediately and delete it! =20 ------=_NextPart_001_002F_01D30144.5C232F50 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hey = Ashok,

thanks for your = feedback.

For your first = comment I tend to agree and I think we can add this to the = draft!

For the second, I = agree with your assumption that tunnels might appear in constrained = scenarios (it=A1=AFs actually one of our main goals for ipsec/esp). = However, I=A1=AFm not sure if this recommendation to not use = fragmentation is valid on a security side, why I=A1=AFd like to give the = question to the ipsecme WG, if that does not open any other security = issues? Or if there is anything else to consider on = that?

Thanks

Tobias

 

Von: Raja = ashok [mailto:raja.ashok@huawei.com]
Gesendet: Freitag, 14. = Juli 2017 16:22
An: = draft-mglt-lwig-minimal-esp@ietf.org
Cc: = lwip@ietf.org
Betreff: Suggestions in = draft-mglt-lwig-minimal-esp

 

Hi Daniel & Tobias,

 

I gone through the lwIG draft for = ESP. I am having some doubts and suggestions which are listed below. = Please check and provide your comments.

 

1)     For replay protection, RFC 4303 suggests to use 32 or 64 = bit window. I feel in this draft, we can recommend to use 32 bit window = for replay protection.

 

2)     Tunneled ESP msg with fragmented IP header (in ESP payload) = may leads to DoS vulnerability for a constraint receiver. RFC 4303 is = suggesting this fragmentation as optional. So I feel we can mention as = fragmentation and reassembly is not required to support in tunneled IP = header. As it can be handled by the IP header which carries ESP msg. I = hope tunneled ESP msg might be required in some scenarios of constraint = devices also.

 

Regards,

Ashok

 

3D"Company_logo"

Raja Ashok V K
Huawei Technologies
Bangalore, = India
http://www.huawei.com

=B1=BE=D3=CA=BC=FE= =BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3= =DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8= =D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB<= /span>
=D6=B9=C8=CE=BA=CE= =C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0= =A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6= =A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0<= /span>
=B5=C4=D0=C5=CF=A2= =A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4= =FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB= =B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This = e-mail and its attachments contain confidential information from HUAWEI, = which
is intended only for the person or entity whose address is = listed above. Any use of the
information contained herein in any way = (including, but not limited to, total or partial
disclosure, = reproduction, or dissemination) by persons other than the intended =
recipient(s) is prohibited. If you receive this e-mail in error, = please notify the sender by
phone or email immediately and delete = it!

 

------=_NextPart_001_002F_01D30144.5C232F50-- ------=_NextPart_000_002E_01D30144.5C232F50 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------=_NextPart_000_002E_01D30144.5C232F50-- From nobody Thu Jul 20 02:25:43 2017 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 8206A13170E; Thu, 20 Jul 2017 02:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 AY6kucT1lhxq; Thu, 20 Jul 2017 02:25:39 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 DD413127735; Thu, 20 Jul 2017 02:25:38 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id m86so2666943lfi.4; Thu, 20 Jul 2017 02:25:38 -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=T1i4Y0mwbiItrBvNnkYpNF+H3oltPiOjGROoBuNbTpw=; b=EU3PgHk5nTUwJf18tR9lJOAP9W1mlAQc4UkBLNGEheXyi6ScoIuT45M2isnOBoIh4M XzSjhQZxPNJxvkIgvTRk+cKCxCSMyH+gSIiuQUISvsxNcvvAZP1DZPQg5eRDGV0b+qsm WluoemwjcyLDE8Ylzdmfnb7kF4rP10t8WVaCdNvbj+MEEdnfpjtJSRTuW06Atfb0+saq VKjXZunU6r24JfGXs2GjS0RxU5MTHrWT5iPH313QoP8NgYDxAQLS69YYl5OmYwdGKV7W czGceg5Bh75yg10gTHfYvKJrKFQ3FKsH44gEz4Q2htGqloEJ5iDZw8QANHMGmMqfy3pj iHbw== 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=T1i4Y0mwbiItrBvNnkYpNF+H3oltPiOjGROoBuNbTpw=; b=Ml9/mzVG+Pyt2b7WJ2WMDraF8tXJg+PK9O3FtZUi//fcxFKIGwU8audyDS+Op5mr9v jqrBUyBgPbLVw/BqyngzjtkY1sAvUPk/uXY6tzym33s6b1Ozc3chHPziB1af87wg3YPP EqDoZA/dsfyXvDZdGOcOrLH0eIKClPjd+Ro3RVGoa+u8t1guUYRmiaGwzpf7NqIWNJhf tJxUqaoqNQnX5hH2JtBnSh+nYyElJ1h6J+C8jdnXpRlmbA2Aq6YFK0H61v36kSlISArP WKiIHVb2Zo85MYeM41MU3WQJCz3C7O/h4B8LLc/PLo/uUSM0RfDIKvp5LUhB+IBQddhs bjeg== X-Gm-Message-State: AIVw111WOCbs5Wb8T/dn+Fr5RKm6LnbtngYPtSzX7xSe2FNY6xvtUP9y 7IjdqaPF9nI0DJra X-Received: by 10.25.150.130 with SMTP id y124mr1001719lfd.202.1500542736804; Thu, 20 Jul 2017 02:25:36 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o82sm388850lfb.85.2017.07.20.02.25.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Jul 2017 02:25:35 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Guggemos'" , "'Raja ashok'" , Cc: "'IPsecme WG'" , References: <002d01d30133$9895a460$c9c0ed20$@nm.ifi.lmu.de> In-Reply-To: <002d01d30133$9895a460$c9c0ed20$@nm.ifi.lmu.de> Date: Thu, 20 Jul 2017 12:25:37 +0300 Message-ID: <04ec01d3013a$2616dd80$72449880$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_04ED_01D30153.4B6BB6A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLaRXNs9kiJ+OmSgshTmcu8j2ZopAKlDwEdoDi64wA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Suggestions in draft-mglt-lwig-minimal-esp X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:25:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04ED_01D30153.4B6BB6A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_04EE_01D30153.4B6BB6A0" ------=_NextPart_001_04EE_01D30153.4B6BB6A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, =20 IP fragmentation is a Bad Thing in general and it is better to avoid it. With TCP traffic the TCP/IP stack usually sends only unfragmented IP packets, so this is usually not a problem (especially if you fool the stack that the MTU is a bit smaller than real, so the packet is still within real MTU size after applying ESP header/trailer/padding/ICV and external IP = header). =20 The problem is worse with UDP. In this case it is an application that decides how much data it wants to send in each datagram and there = could be fairly large UDP datagrams, that have to be IP fragmented. In tunnel mode they can be either pre-fragmnted (before applying IPsec), or post-fragmented (fragment the resulting ESP packet). In transport mode it is not possible to pre-fragment packets. =20 In general, I think that pre-fragmenting is a bit better, than = post-fragmenting. So you=A1=AFd better to apply ESP to each of IP fragments and send whole = IP packets, than apply ESP to a whole packet and then send it as a set of IP = fragments. In this case you at least verify each internal IP fragment on receiver, before sending it to IP stack. In the other case you have to reassemble=20 all the fragments before you can verify the ESP packet, and this gives an attacker a nice target for DoS attack. However, the justification=20 is weak, since the IP packets can always be fragmented en route (unless=20 you set Don=A1=AFt Fragment bit). =20 Regards, Valery. =20 =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tobias Guggemos Sent: Thursday, July 20, 2017 11:39 AM To: 'Raja ashok'; draft-mglt-lwig-minimal-esp@ietf.org Cc: IPsecme WG; lwip@ietf.org Subject: Re: [IPsec] Suggestions in draft-mglt-lwig-minimal-esp =20 Hey Ashok, thanks for your feedback. For your first comment I tend to agree and I think we can add this to = the draft! For the second, I agree with your assumption that tunnels might appear = in constrained scenarios (it=A1=AFs actually one of our main goals for ipsec/esp). However, I=A1=AFm not sure if this recommendation = to not use fragmentation is valid on a security side, why I=A1=AFd like to give the question to the ipsecme WG, if that does not open any = other security issues? Or if there is anything else to consider on that? Thanks Tobias =20 Von: Raja ashok [mailto:raja.ashok@huawei.com]=20 Gesendet: Freitag, 14. Juli 2017 16:22 An: draft-mglt-lwig-minimal-esp@ietf.org Cc: lwip@ietf.org Betreff: Suggestions in draft-mglt-lwig-minimal-esp=20 =20 Hi Daniel & Tobias, =20 I gone through the lwIG draft for ESP. I am having some doubts and = suggestions which are listed below. Please check and provide your comments. =20 1) For replay protection, RFC 4303 suggests to use 32 or 64 bit = window. I feel in this draft, we can recommend to use 32 bit window for replay protection. =20 2) Tunneled ESP msg with fragmented IP header (in ESP payload) may = leads to DoS vulnerability for a constraint receiver. RFC 4303 is suggesting this fragmentation as optional. So I feel we can = mention as fragmentation and reassembly is not required to support in tunneled IP header. As it can be handled by the IP header = which carries ESP msg. I hope tunneled ESP msg might be required in some scenarios of constraint devices also. =20 Regards, Ashok =20 _____ =20 Company_logo Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com=20 _____ =20 =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7= =E9=A1=A3=BD=FB =D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3= =C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6= =B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3= =CA=BC=FE=D6=D0 =B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC= =FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA= =B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1 This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ------=_NextPart_001_04EE_01D30153.4B6BB6A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 

IP fragmentation is a Bad Thing = in general and it is better to

avoid it. With TCP traffic the = TCP/IP stack

usually sends only = unfragmented IP packets, so this is usually

not a problem (especially if = you fool the stack that the MTU

is a bit smaller than real, so = the packet is still within real MTU

size after applying ESP = header/trailer/padding/ICV and external IP = header).

 

The problem is worse with UDP. = In this case it is an application

that decides how much data it = wants to send in each datagram and there could

be fairly large UDP datagrams, = that have to be IP fragmented.

In tunnel mode they can be = either pre-fragmnted (before applying IPsec),

or post-fragmented (fragment = the resulting ESP packet).

In transport mode it is not = possible to pre-fragment packets.

 

In general, I think that = pre-fragmenting is a bit better, than = post-fragmenting.

So you=A1=AFd = better to apply ESP to each of IP fragments and send whole IP = packets,

than apply ESP to a whole = packet and then send it as a set of IP = fragments.

In this case you at least = verify each internal IP fragment on receiver,

before sending it to IP stack. = In the other case you have to reassemble

all the fragments before you = can verify the ESP packet, and this gives

an attacker a nice target for = DoS attack. However, the justification

is weak, since the IP packets = can always be fragmented en route (unless

you set Don=A1=AFt Fragment = bit).

 

Regards,

Valery.

 

 

From:= IPsec = [mailto:ipsec-bounces@ietf.org] On Behalf Of Tobias = Guggemos
Sent: Thursday, July 20, 2017 11:39 AM
To: = 'Raja ashok'; draft-mglt-lwig-minimal-esp@ietf.org
Cc: IPsecme = WG; lwip@ietf.org
Subject: Re: [IPsec] Suggestions in = draft-mglt-lwig-minimal-esp

 

Hey = Ashok,

thanks for your = feedback.

For your first = comment I tend to agree and I think we can add this to the = draft!

For the second, I = agree with your assumption that tunnels might appear in constrained = scenarios (it=A1=AFs actually one of our main goals for ipsec/esp). = However, I=A1=AFm not sure if this recommendation to not use = fragmentation is valid on a security side, why I=A1=AFd like to give the = question to the ipsecme WG, if that does not open any other security = issues? Or if there is anything else to consider on = that?

Thanks

Tobias

 

Von: Raja ashok [mailto:raja.ashok@huawei.com] =
Gesendet: Freitag, 14. Juli 2017 16:22
An: draft-mglt-lwig-mini= mal-esp@ietf.org
Cc: lwip@ietf.org
Betreff: = Suggestions in draft-mglt-lwig-minimal-esp =

 

Hi Daniel & Tobias,

 

I gone through the lwIG draft for = ESP. I am having some doubts and suggestions which are listed below. = Please check and provide your comments.

 

1)     For = replay protection, RFC 4303 suggests to use 32 or 64 bit window. I feel = in this draft, we can recommend to use 32 bit window for replay = protection.

 

2)     Tunneled ESP msg with fragmented IP header (in ESP payload) = may leads to DoS vulnerability for a constraint receiver. RFC 4303 is = suggesting this fragmentation as optional. So I feel we can mention as = fragmentation and reassembly is not required to support in tunneled IP = header. As it can be handled by the IP header which carries ESP msg. I = hope tunneled ESP msg might be required in some scenarios of constraint = devices also.

 

Regards,

Ashok

 

3D"Company_logo"

Raja Ashok V = K
Huawei Technologies
Bangalore, = India
http://www.huawei.com

=B1=BE=D3=CA=BC=FE= =BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3= =DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8= =D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB<= /span>
=D6=B9=C8=CE=BA=CE= =C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0= =A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6= =A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0<= /span>
=B5=C4=D0=C5=CF=A2= =A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4= =FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB= =B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
Thi= s e-mail and its attachments contain confidential information from = HUAWEI, which
is intended only for the person or entity whose = address is listed above. Any use of the
information contained herein = in any way (including, but not limited to, total or partial =
disclosure, reproduction, or dissemination) by persons other than = the intended
recipient(s) is prohibited. If you receive this e-mail = in error, please notify the sender by
phone or email immediately and = delete it!

 

------=_NextPart_001_04EE_01D30153.4B6BB6A0-- ------=_NextPart_000_04ED_01D30153.4B6BB6A0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------=_NextPart_000_04ED_01D30153.4B6BB6A0 Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAoAIADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2LAAG KxPEPia08PRp5+Xkf7sa9TWL478W3GiTW1rZf60/vJCem30rlvGV2uqHTtWhOYZE2kf3W7iuarXS TUdz2MBljrShOp8Mj0mx12K+0ZL9VIB/g75q3ZahHeZAyrjkqa890XVAnheXLdJgK1dI1dVkuL2U 4it0+Y+p7Cs1XleIq+W8vPy9Gdx+NOriPCXi+bWdXuLS4xg/PER2HpXbZx1rqhOMleJ5+Iw88PPk qbjqKYsiuCVYNg9jmgyoCRvXI5Iz0qzAfRTFcOoZWDKehB4pFkD8owYdODQBJRTA6ltu8bhzgHmk EgYsFYEjrg5xQBJRUfmDdt3Dd6Z5/KlZwpALAE8AE9aAH0VG8ix/fdVz6nFJ5qFMiRcA4Jz3oA8l 1vUrHxqQ8Li01KHjypeBIPY1k6csiedo98jIJuY9/wDC/t9a2/G3gu0sdQOoQ6hHapO24xyjjd7G qOnfvpI7O5urfUAx+XZnzEPqDXn1INyPscJiYewUaeq7diCOC4t/Dk0KqwlW5EeMc5pNRlnSGLR7 QO8gIacL3f0/CvUk8P2v2IIV/fEBvMPXdjrXnmpxfZLiS1t7iG0OfmeQHzHPrmidFwROEx8cRUem z/pjtDurPwfKbm6YXGoyfKIIz/q8+pr1YSmaw83GN8RPHbivMfCHhG21DUBczX6XCwndsjHf3Neo vGTAyIOShUZ6dK3wycY2PJzmdOVVWd5dX+Vjx7wF46stBOrRas17M73bbCkZkAHpSaNrv9seJ/F1 1aTTrCbFjEsmQVP07V2Xw+8JXnhyHUV1JIGNzcGVCozgVDYeCrxPGWu31x5a2OoweUuw4I/Cuk8Y n+GU0k3w7tpJXeRz5hLMcmsH4b61/Z+geJL6+nd0tbt2y5zgegqXS9B8c+F9Pk0jTP7PurPc3lTS sQyA+1QSfDbWofC0ejQXMTm9uvP1CUnGB/dWgDntM1W/0jUtP8YXeoCS21G5ZJ7fzM+WhPHFdRBP J4c+LwjM7Np+sQ7o8sSoYDNXNR+Dugy6RLDZRyx3Xl4jcykgN64qjqfgXX9X8E6bbTSRJrWnuVjl V+qdOvrQBy41jUk8bnxR50g006ibMpuOMdOldRqV5JqvxSleOST7DoloZmVW+VnxkA1fT4fT/wDC sf7DZl/tEt5xkzkebnIOan+H/gu60PSr8a2VlvL47ZWVs5XGAM0AebaVrWl+IZbq/wDFV7q7SvLi GK1VtiL+Fb/iCbT7b4U3D+Hpr9IRdAF7kkSZ+vpWrY+EPFfhGa5t/Dz2F1p80hkVLleU9s1d13w5 4k8TeBZtPvks4b8zhlEJwmz/ABoA7LUtJs9YtGtr+BJYiMYYZxVPRvCuk6Ap/s+0RHPVyMsaKKXK ty1OVnFPQ1wPas3V/Dmm64m2+tVcjowGCPxoooautRRlKDvF6k2l6PZaNbeRYQLEg64HWtAdKKKE rCc3J3luLRRRTEFFFFABRRRQAUUUUAFFFFAH/9k= ------=_NextPart_000_04ED_01D30153.4B6BB6A0-- From nobody Fri Jul 21 05:34:09 2017 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 5FC1E131BB0 for ; Fri, 21 Jul 2017 05:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, 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 RJFAXtAo2ZuX for ; Fri, 21 Jul 2017 05:34:06 -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 ABF3212EAF0 for ; Fri, 21 Jul 2017 05:34:05 -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 v6LCXwlr003316 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 21 Jul 2017 15:33:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v6LCXwiv003266; Fri, 21 Jul 2017 15:33:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22897.62646.336585.715810@fireball.acr.fi> Date: Fri, 21 Jul 2017 15:33:58 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: [IPsec] Preliminary minutes of the IETF 99 IPsecME meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 12:34:08 -0000 Here are the minutes of the meeting (thanks Yaron), if you have fixes, additions etc to them send them to me. I will post these to the meeting materials next week. ---------------------------------------------------------------------- Minutes of the IETF 99 IPsecME WG meeting Prague 2017-07-21. -- Paul Wouters on Split DNS Francis: presentation format means textual. Wire format is just as easy. Said as a DNS person. Tero: MUST be uncompressed. So it can be easier to parse. Paul: most apps are using presentation format. Wire format rarely used. We have no precedent for wire format, so could use presentation format. Tommy: could go with either one. Prefer presentation format. We already have strings and FQDNs (Tero: no, not strings). Tero: we only send one item, no formatting/structure around these strings. Tommy: not a list of items, no spaces. Multiple properties if multiple values. Tero: do you have escaping, backslashes? Paul: you still need to have security checks after conversion from wire format, because it is untrusted. Tero: agree. Wireshark can "decode as DNS". Paul: finds the security format minor. Tommy: agrees with Paul. Paul: trust anchors are split on the field. Tero: "semi-wire format". Paul: would prefer presentation format there, too. Hum: don't care wins :-) The authors can go with presentation format. -- Daniel Migault on Implicit IV Dave: We will issue a WGLC on this after the meeting. -- Scott Fluhrer on PQ-hardening IKE Paul W.: they are working on an implementation. Valery: concerns with this approach. The PPK is used as an additional credential. From an operational point of view, this means 2 sets of security creds. A headache. People will probably get rid of certs as a result. Which really is "null authentication". The problem needs to be mentioned in the doc. Initial null authentication (RFC 7619) is problematic. Scott: please contribute text. Valery: I'll try. Paul: could say: MUST NOT use with auth-null. Valery: this is not appropriate, because [missed] Tero: ready for LC? Scott: yes. Dan Harkins: why a requirement on what the PPK is (base64)? Scott: suggestion from last WG meeting. Tero: good for interoperability of config files. Dan: or really to ease transport of PPKs? Key wrapping formats. In that case, why limit the format. Paul: easy to misinterpret if the format is more flexible. Michael Richardson: should be easy to use. Supports Paul. Valery: key distribution is out of scope of this protocol. Tommy: it should be easy to configure, but should be a strong key. Likes the current proposal. Up to implementation to make sure you can easily distribute. -- CJ Tjhai on Hybrid quantum safe key exchange Tero: what is large (payload)? More than 64KB? CJ : some of them are hundreds of KB. EKR: This is all hedge. Identity protection is secondary. Dan: this is ID protection for PQ passive attacks. Tero: multiple identities, renew them periodically. Payload size is limited, but not the IKE message. Valery: can the PK be compressed? CJ: no. Valery: why a new payload? CJ: could use KE. Valery: KE would be better. Assuming you trust the new method. Mark O.: [missed] Paul W.: wondering if this work is premature. Tero: we design algorithms for crypto-agility, so we want to design the hooks for experimentation. Paul: this is more than agility. Don't want to commit to experimental things. Tero: assumes these are plug-in replacements for DH. CJ: yes. Paul: adding a transform? Tero: the WG will decide on bits-on-the-wire. Brian: an IANA registry for algs that we may reject in the future? Philip Lafrance: supports the doc. Came up with similar solutions. Scott Fluhrer: complexity with having 2 algs when we don't fully trust the PQ alg. -- Kai Martius on EC+PQC EKR: if an alternative to DH, make sure to signal: I cannot use this alone. Dan: moving the payload to IKE-AUTH solves fragmentation and backward compatibility issues. And what we lose is PQ ID protection. Paul: if we add a new transform type, we are doubling size. Tero: it would take us back to IKEv1. This is currently out of charter, we might consider for rechartering. Hum: adding non-PSK PQ mechanism into the charter. Unanimous in favor. -- Tobias Heider on G-IKEv2 Implementation Brian Weis: mentions his outstanding G-IKEv2 draft. Draft was not intended for IOT to start with. Quynh: why implement both HMACs. Truncation of SHA to 96 bits is not good. Tobias: did not think of algs, they came from the OS. Tero: this is normal (not minimal) group ikev2. The draft is out there because MSEC is dead. Would prefer to advance it in the WG. EKR: as AD, prefers things to go through a WG. Hum: run g-IKEv2 in the WG? (Not "minimal"). Unanimous support in favor of adding to the next charter. -- Valery on responder-initiated IP address update in MOBIKE Tero: it's a bad idea to spoof packets. Packets will be dropped by 1st hop routers. Yoav: they don't drop in reality. Tero: they will in future. Protocol should not rely on these. Valery: these are not spoofed. Tero: OK if you own both interfaces, but can do it already without MOBIKE. The only problem is if you lose the address, and then you don't own it. Would not be treated well by IESG. Tero: the WG might want to take it on. MOBIKE is not in charter but is related to IPsec. Wants to talk to the AD before taking a hum. Bret Jordan: supports the draft provided no spoofed packets. -- Tobias Guggemos on Diet-ESP Tommy: supports moving forward with the draft. Tobias: complexity is currently low. Tommy: compression seems to be OK right now. Daniel: compression problems with IPv4-in-IPv6 or vice versa. Should we add complexity at this point? Tommy: leave that simple. Wants to see things converge to all-IPv6. This could incentivize this migration. Tero: this works changes payloads but not the protocol. Do we add to the charter? Hum unanimous in favor. -- Other issues Yoav: mentions thread around i2nsf and SDN control of IPsec endpoints. Planning a virtual interim meeting, attended by both groups. Sometime in the next few weeks. Sahana Prasad: negotiation of PSS vs legacy RSA. Tero: we might need to think of a charter item. Paul: agrees this is a problem, should be added to charter. -- kivinen@iki.fi From nobody Fri Jul 21 06:19:05 2017 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 5D88D131463; Fri, 21 Jul 2017 06:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 nHYBi6VIU9xp; Fri, 21 Jul 2017 06:18:55 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [IPv6:2001:720:1710:601::42]) by ietfa.amsl.com (Postfix) with ESMTP id 8845112F24E; Fri, 21 Jul 2017 06:18:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 1B32020B66; Fri, 21 Jul 2017 15:18:50 +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 h_NjmIrVuYiY; Fri, 21 Jul 2017 15:18:50 +0200 (CEST) Received: from inf-205-195.inf.um.es (inf-205-195.inf.um.es [155.54.205.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm@um.es) by xenon42.um.es (Postfix) with ESMTPSA id 91C0820C32; Fri, 21 Jul 2017 15:18:48 +0200 (CEST) From: Gabriel Lopez Message-Id: <1A477DD9-A41F-468E-9FF9-5D8000C13EB2@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_D9752EE0-992B-43F0-9D54-8A5B462A63DC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Jul 2017 15:18:48 +0200 In-Reply-To: Cc: Valery Smyslov , i2nsf@ietf.org, IPsecME WG , =?utf-8?Q?Alejandro_P=C3=A9rez_M=C3=A9ndez?= , Rafa Marin Lopez To: Yoav Nir References: <021c01d2ffcf$95f043b0$c1d0cb10$@gmail.com> <02e601d3005a$c1791170$446b3450$@gmail.com> <1e2efa38-5b95-7685-8fb9-047b656f0e58@um.es> <031201d30085$d4cab0a0$7e6011e0$@gmail.com> <04b701d3012d$b5f05920$21d10b60$@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:18:58 -0000 --Apple-Mail=_D9752EE0-992B-43F0-9D54-8A5B462A63DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoav, Valery, > El 20 jul 2017, a las 10:12, Yoav Nir escribi=C3=B3= : >=20 >>=20 >> On 20 Jul 2017, at 9:56, Valery Smyslov > wrote: >>=20 >> Hi Gabriel, >> =20 >> I think that at this point the discussion is not very productive. >> I admit that I=E2=80=99m not very familiar with SDNs, so I have to=20 >> blindly trust you when you state that the SDN Controller >> knows everything and is able to control everything, >> so it is like God. Probably this is true. >=20 > That the controller (or its administrator) knows everything is part of = the model of SDN. SDN comes from datacenters and in datacenters the = administrators control everything and the protocol is used to configure = a whole bunch of routers and switches. >=20 > I2NSF is extending this to security boxes such as firewalls, IDS, etc. = The context is still the data center. The firewalls are at the edge of = the datacenter and the intruder detection is either co-located with the = firewall or inside. Right. >=20 > VPN is different. While one or more box is within the datacenter, the = vast majority of boxes are out of the datacenter and located all over = the Internet. Their routing is usually not under the control of the = administrator, so we=E2=80=99d like to control just the IPsec = configuration. The idea of the draft is not to propose a solution to manage every = posible IPsec scenario, we understand that there are scenarios where it = could be more difficult to deploy a SDN solution. The idea is to provide = a tool that could be used when the security requirements could be met.=20= In the case of out of the datacenter scenarios I see your point, but in = the other side you can find thinks such as SD-WAN trying to provide = solutions for that. In the case of inside the datacenter there are some cases where it could = be useful. For example, suppose a cloud environment running hundred or = thousands of VMs requiring IPsec for internal communications.=20 Thanks again for the feedback. Best regards, Gabi. >=20 >>=20 >> I just want to reiterate, that while security architecture >> with central key distribution is definitely feasible and >> it is feasible to make it secure, my strong opinion is that >> it is still a large step backward from End-to-End security >> model and it is much more fragile. And I agree with Tero that >> =E2=80=9CEE simplicity=E2=80=9D argument in most cases doesn=E2=80=99t = look=20 >> reasonable to buy. Probably you can add justifications >> to this argument, e.g. by providing estimates how much >> resources you are going to save on EE if you get rid of IKE >> (but leave IPsec, TLS and so on).=20 >> =20 >> Regards, >> Valery. >> =20 >> From: Gabriel Lopez [mailto:gabilm@um.es ]=20 >> Sent: Wednesday, July 19, 2017 5:21 PM >> To: Valery Smyslov >> Cc: Alejandro P=C3=A9rez M=C3=A9ndez; i2nsf@ietf.org = ; IPsecME WG; Rafa Marin Lopez >> Subject: Re: [I2nsf] [IPsec] = draft-abad-i2nsf-sdn-ipsec-flow-protection >> =20 >> Hi Valery, >> =20 >>> El 19 jul 2017, a las 13:54, Valery Smyslov > escribi=C3=B3: >>> =20 >>> Hi Alejandro, >>>=20 >>>=20 >>>>>> It is more fragile too. You must perform periodical rekey (update = keys) >>>>>> and this must be done synchronously. >>>>> You have to do it by pairs, does not seem that difficult. And, as = IKE >>>>> does, you create the new ones and, once created, delete the old = ones. I >>>>> don't see the synchrony problem that important. >>>> In ideal world - yes. In real world - I'm not so sure. >>>> Imagine you have an SA expired and the SDN installs a new SA >>>> on the peers, but one of SDN-peer TLS connection failed because off >>>> the temporary network problem, so you have a new SA partially = installed. >>>> What is the peer that didn't receive a new SA supposed to do? >>>> Continue to use an old one despite the fact that it is expired? >>>> Block all traffic? Something else? >>> In fact, I think the SDN-based approach performs even better than = IKE in >>> this regards. >>> Imagine what happens if the corresponding IKE rekey process fails = for >>> the very same temporary network problem. In the best case, CHILD SAs = are >>> deleted after a hard expiration, and they will need to be re-created >>> when triggered by the SPD again. This is roughly identical to the = SDN >>> approach. But, typically, when an IKE rekey fails, the initiator = will >>> likely close the entire IKE_SA thinking the other peer is down, = which >>> would result into having to recreate the IKE_SA (including the DH >>> exchange), and all the associated CHILD_SAs afterwards. >>>=20 >>> Exactly, that's what IKE will do. But this is reasonable, because if = IKE >>> messages cannot go between peers, it is most probably that=20 >>> IPsec won't go either (especially in case of UDP encapsulation). >>> With SDN the situation is a bit different. The network problem=20 >>> takes place on SDN-EE path, while EE-EE path works well, >>> but the peers cannot communicate, because SDN fails to provide >>> the keys in time. Note, that rekey may take place quite often, = depending=20 >>> on the algorithms involved.=20 >> =20 >> [Gabi] This kind of strong requirements on the controller = availability and workload is assumed in the SDN paradigm. Let=E2=80=99s = think in a L2 OpenFlow controller for example, where the L2-switch has = to forward a copy of the incoming frame before to forward it. >>=20 >>=20 >>=20 >>> How NAT traversal is to be done in IKE-less case? I understand, that >>> NATs are also controlled by SDN, but does SDN pre-install NAT = mappings? >>=20 >> That's a good question. I would say so, yes. >>=20 >> So, SDN needs to synchronously configure one more entity (NAT) >> for IPsec to start working?=20 >> =20 >> [Gabi] If NAT is required the controller should know that, the IPsec = configuration required to cross the NAT should be applied by the = Security Controller . The configuration of the NAT entity may be = configured independently (manually or not, note that there are Yang = models for NAT (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07 = )). >>=20 >>=20 >>=20 >>=20 >> But, would that generate problems if the NAT box is not included in = your >> SDN (e.g. it belongs to the mall centre or similar)? >>=20 >> In this case you first need to use UDP encapsulation and second need = to send >> NAT keepalive messages periodically. Usually it is IKE who sends >> these messages (I admit that you can also sends them from the = kernel). >> IKE also determines if there is a NAT in between and which peer is=20 >> behind the NAT. In case the NAT is out of SDN control, who will do = this job? >> =20 >> [Gabi] the Controller should know that there is NAT in the scenario. >>=20 >>=20 >> What is supposed to be done if packet with invalid AH/ESP SPI is = received? >> =20 >> =20 >>=20 >>=20 >> Clearly, the packet itself is dropped, but later IKEv2 extensions = (namely >> RFC6290, Quick Crash Detection) allows to send IKE notification >> to the peer with a security token to help peers quickly recover from = the crash. >> What is supposed to be done in IKE-less case? Or do you think that >> with SDN such things like non-synchronized IPsec states never happen? >> =20 >> [Gabi] If it is an audiatable event by the kernel, the peer can = notify the controller about that (some examples of notifications are = already included in the yang model) >> =20 >> Thanks for the comments, this discussion is really interesting =E2=80=A6= . >> =20 >> Regards, Gabi. >>>=20 >>> Regards, >>> Valery.=20 >>>=20 >>>=20 >>> These are exactly the sort of situations that need to be figured = out. >>>=20 >>> I believe there are many of them. >>>=20 >>> Regards, >>> Valery. >>>=20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf = >> =20 >> =20 >>=20 >> ----------------------------------------------------------- >> Gabriel L=C3=B3pez Mill=C3=A1n >> Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones >> University of Murcia >> Spain >> Tel: +34 868888504 >> Fax: +34 868884151 >> email: gabilm@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 = ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_D9752EE0-992B-43F0-9D54-8A5B462A63DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Yoav, Valery,

El 20 jul 2017, a las 10:12, = Yoav Nir <ynir.ietf@gmail.com> escribi=C3=B3:


On 20 = Jul 2017, at 9:56, Valery Smyslov <svanru@gmail.com> wrote:

Hi = Gabriel,
 
I think that = at this point the discussion is not very productive.
I admit that I=E2=80=99m = not very familiar with SDNs, so I have to 
blindly trust you when = you state that the SDN Controller
knows everything and is able to control = everything,
so it = is like God. Probably this is = true.

That the controller (or its administrator) knows = everything is part of the model of SDN. SDN comes from datacenters and = in datacenters the administrators control everything and the protocol is = used to configure a whole bunch of routers and = switches.


I2NSF is extending this to security boxes such as = firewalls, IDS, etc. The context is still the data center. The firewalls = are at the edge of the datacenter and the intruder detection is either = co-located with the firewall or inside.

Right.


VPN is different. While one or more box is within the = datacenter, the vast majority of boxes are out of the datacenter and = located all over the Internet. Their routing is usually not under the = control of the administrator, so we=E2=80=99d like to control just the = IPsec configuration.

The idea of the draft is not to propose a solution = to manage every posible IPsec scenario, we understand that there are = scenarios where it could be more difficult to deploy a SDN solution. The = idea is to provide a tool that could be used when the security = requirements could be met. 

In = the case of out of the datacenter scenarios I see your point, but in the = other side you can find thinks such as SD-WAN trying to provide = solutions for that.
In the case of inside the datacenter there = are some cases where it could be useful. For example, suppose a cloud = environment running hundred or thousands of VMs requiring IPsec for = internal communications. 

Thanks = again for the feedback.

Best = regards, Gabi.



I just want to reiterate, = that while security architecture
with central key distribution is definitely feasible = and
it is = feasible to make it secure, my strong opinion is that
it is still a large step = backward from End-to-End security
model and it is much more fragile. And I agree with = Tero that
=E2=80=9C= EE simplicity=E2=80=9D argument in most cases doesn=E2=80=99t look 
reasonable to buy. = Probably you can add justifications
to this argument, e.g. by providing estimates how = much
resources = you are going to save on EE if you get rid of IKE
(but leave IPsec, TLS and = so on). 
 
Regards,
Valery.
 
From: Gabriel Lopez [mailto:gabilm@um.es] 
Sent: Wednesday, July 19, 2017 = 5:21 PM
To: Valery Smyslov
Cc: Alejandro P=C3=A9rez = M=C3=A9ndez; i2nsf@ietf.org; IPsecME WG; Rafa Marin = Lopez
Subject: Re: [I2nsf] [IPsec] = draft-abad-i2nsf-sdn-ipsec-flow-protection
 
Hi Valery,
 
El 19 jul 2017, a las = 13:54, Valery Smyslov <svanru@gmail.com> escribi=C3=B3:
 
Hi Alejandro,


It is more fragile too. You must perform periodical = rekey (update keys)
and this must be done = synchronously.
You have to do it by pairs, does not seem that = difficult. And, as IKE
does, you create the new ones and, = once created, delete the old ones. I
don't see the = synchrony problem that important.
In ideal world - yes. In real world - I'm not so sure.
Imagine you have an SA expired and the SDN installs a new = SA
on the peers, but one of SDN-peer TLS connection failed = because off
the temporary network problem, so you have a = new SA partially installed.
What is the peer that didn't = receive a new SA supposed to do?
Continue to use an old = one despite the fact that it is expired?
Block all = traffic? Something else?
In fact, I think the SDN-based = approach performs even better than IKE in
this regards.
Imagine what happens if the corresponding IKE rekey process = fails for
the very same temporary network problem. In the = best case, CHILD SAs are
deleted after a hard expiration, = and they will need to be re-created
when triggered by the = SPD again. This is roughly identical to the SDN
approach. = But, typically, when an IKE rekey fails, the initiator will
likely close the entire IKE_SA thinking the other peer is = down, which
would result into having to recreate the = IKE_SA (including the DH
exchange), and all the associated = CHILD_SAs afterwards.

Exactly, that's what IKE will do. But = this is reasonable, because if IKE
messages cannot go = between peers, it is most probably that 
IPsec won't = go either (especially in case of UDP encapsulation).
With = SDN the situation is a bit different. The network problem 
takes place = on SDN-EE path, while EE-EE path works well,
but the peers = cannot communicate, because SDN fails to provide
the keys = in time. Note, that rekey may take place quite often, depending 
on the = algorithms involved. 
 
[Gabi] This kind of strong requirements on the controller = availability and workload is assumed in the SDN paradigm. Let=E2=80=99s = think in a L2 OpenFlow controller for example, where the L2-switch has = to forward a copy of the incoming frame before to forward it.



How NAT traversal is to be = done in IKE-less case? I understand, that
NATs are also = controlled by SDN, but does SDN pre-install NAT mappings?

That's a good question. I would say so, yes.

So, SDN needs to synchronously configure one more entity = (NAT)
for IPsec to start working? 
 
[Gabi] If NAT is required = the controller should know that, the IPsec configuration required to = cross the NAT should be applied by the Security Controller . The = configuration of the NAT entity may be configured independently = (manually or not, note that there are Yang models for NAT (https://tools.ietf.org/html/draft-sivakumar-yang-nat-07)).=




But, would that generate problems if the NAT box is = not included in your
SDN (e.g. it belongs to the mall = centre or similar)?

In this case you first need to use = UDP encapsulation and second need to send
NAT keepalive = messages periodically. Usually it is IKE who  sends
these messages (I admit that you can also sends them from the = kernel).
IKE also determines if there is a NAT in between = and which peer is 
behind the NAT. In case the NAT is out of SDN control, who = will do this job?
 
[Gabi] the Controller should know that there is NAT in the = scenario.


What is supposed to be done if packet with invalid AH/ESP SPI = is received?
 
 


Clearly, the packet itself = is dropped, but later IKEv2 extensions (namely
RFC6290, = Quick Crash Detection) allows to send IKE notification
to = the peer with a security token to help peers quickly recover from the = crash.
What is supposed to be done in IKE-less case? Or do = you think  that
with SDN such things like = non-synchronized IPsec states never happen?
 
[Gabi] If it is an = audiatable event by the kernel, the peer can notify the controller about = that (some examples of notifications are already included in the yang = model)
 
Thanks for the comments, = this discussion is really interesting =E2=80=A6.
 
Regards, Gabi.

Regards,
Valery. 


These are exactly the sort of = situations that need to be figured out.

I believe there = are many of them.

Regards,
Valery.

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

 

-----------------------------------------------------------Gabriel L=C3=B3pez Mill=C3=A1n
Departamento = de Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es
 

 

 
_______________________________________________
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



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es




= --Apple-Mail=_D9752EE0-992B-43F0-9D54-8A5B462A63DC-- From nobody Thu Jul 27 07:38:34 2017 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 A64E3131D9F for ; Thu, 27 Jul 2017 07:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 k9221Cnnm0Pu for ; Thu, 27 Jul 2017 07:38:32 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 12494129B35 for ; Thu, 27 Jul 2017 07:38:32 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id t128so51050722lff.2 for ; Thu, 27 Jul 2017 07:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=I1ay7qyq7hetk/2cByj44e9ArG12+jQ+ikvUKrtocx4=; b=e5PVzQ6HlkLsvvNQpcuVd6uBreAGT1TRWA9Cr3JBA3tinGTr1UnJaeWlBE5yEvZ9D3 PYcVIXoIdAJeTgRbc0ToHv3tWSeugVKW634hCtGtO7W0P067J66SnjVvY8DDoVNudRxO dBdGaYggQ/UhioYYpMBB6tsRQuonULQJX/GaoG66q7Lx2gTXWyhqQ4AkE7OuzV0JPrYH i6XfolKf5dwM2s/YPA1FhBf5j7kNOv8J7q+y40aac7ClbCXNUGB3Ez3otgkGL6kqgbNn kHs91iOlsRTmRWwfiObxejoXAvvxSfE50H1PsXyt6W9g3mpbgoWbGVZjsWekRCp+2v7O enhw== 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:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=I1ay7qyq7hetk/2cByj44e9ArG12+jQ+ikvUKrtocx4=; b=amUuCEQlSxYjW18/KTcq/VxqBLoqYv20hJ8tGMeVKJaPbSz+N/fl/X4y5Jbyqgf0jc zigwDobn6j7dleZ9rf6UmWoj7LrHfX0cEkrcsQ/caMp8Mns286b5qk3BqzoMgKE7igEM nWP6O/eut6A+q0/cYC+0ZQhTkT/XmmUGv/U6HvY+L9yXE7HJZ/TuTahCtBoUEFmtBwPp PZt61EPYApfYc+7uyHhMDmO5yRIg41alMs2D0si3wIGTeGBSBsldU/ra8Lnn1otkxxxp NZryLF3B5G0HAWceZJavatnNrquZ+az1RGkcaL7+mdaU2fPNLvayVdvgEgXDQx8zCyNR AH1w== X-Gm-Message-State: AIVw112ohUrDc3kd4NfWCuufCvmXg2rRYr8M8tODZ6FJlRqDJBUfOeFi 5vSJb6yJIkRfUNj5 X-Received: by 10.25.15.152 with SMTP id 24mr1666866lfp.10.1501166309977; Thu, 27 Jul 2017 07:38:29 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e14sm3992392lji.53.2017.07.27.07.38.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Jul 2017 07:38:29 -0700 (PDT) From: "Valery Smyslov" To: "Scott Fluhrer \(sfluhrer\)" , , Cc: Date: Thu, 27 Jul 2017 17:38:30 +0300 Message-ID: <0b0101d306e6$0498e4d0$0dcaae70$@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: AdMGtJeA5KOJXoRBSEOTN8v5AhfcXA== Content-Language: ru Archived-At: Subject: [IPsec] Proposed text for the draft-fluhrer-qr-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 14:38:34 -0000 Hi, at the ipsecme meeting in Prague I was asked to contribute a text for the draft-fluhrer-qr-ikev2 about operational considerations. Here is my try. I think the text should be placed into a new section, "Operational Considerations". Any thoughts? Regards, Valery. X. Operational Considerations This document provides a solution that doesn't replace classical public key cryptographic mechanisms used in IKEv2, like (EC)DH or digital signatures . Instead, the proposed solution extends these mechanisms by using an additional security credential, namely PPK, to make IKEv2 secure against Quantum Computers. In practice it means, that each peer must possess two security credentials to successfully complete authentication - a classic one (like certificate private key) and a PPK. The need to maintain several independent sets of security credentials can significantly complicate security administrators job, and can potentially slow down widespread adoption of this solution. It is anticipated, that administrators will try to simplify their job by decreasing the number of credentials they need to maintain. Two possible approaches are given below. X.1 Group PPK This document doesn't explicitly require that PPK is unique for each pair of peers. If it is the case, then this solution provides full peer authentication, but it also means that each host must have that many independent PPKs, how many peers it is going to communicate with. As the number of hosts grows this will scale badly. It is possible to use a single PPK for a group of users. Since each peer uses classical public key cryptography in addition to PPK for key exchange and authentication, members of the group can neither impersonate each other nor read other's traffic, unless they use Quantum Computers to break public key operations. Although it's probably safe to use group PPK in short term, the fact, that the PPK is known to a (potentially large) group of users makes it more susceptible to a theft. If an attacker equipped with a Quantum Computer get access to a group PPK, then all the communications inside the group are revealed. X.2 PPK-only Authentication If Quantum Computers become a reality, classical public key cryptography will provide little security, so administrators may find it attractive not to use it at all for authentication. This will reduce the number of credentials they need to maintain to PPKs only. PPK-only authentication can be achieved in IKEv2 if NULL Authentication method [RFC7619] is employed. Without PPK the NULL Authentication method provides no authentication of peers, however since PPK is stirred into SK_pi and SK_pr, the peers become authenticated if PPK is in use. Note, that using PPK MUST be mandatory for both Initiator and Responder if PPK-only authentication (i.e. the NULL Authentication method + PPK) is employed. Combining group PPK and PPK-only authentication is NOT RECOMMENDED, since in this case any member of the group can impersonate any other member even without help of Quantum Computers. From nobody Fri Jul 28 03:02:49 2017 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 B99FD1322B5; Fri, 28 Jul 2017 03:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 QQ1pO2n4jHGE; Fri, 28 Jul 2017 03:02:45 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 9693213217D; Fri, 28 Jul 2017 03:02:45 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id m85so17487080wma.0; Fri, 28 Jul 2017 03:02:45 -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=BwVE1y1PidZ6EPYUZ9ejnkcOzQ8R9Q+pZxNrDQmGLVM=; b=Mf67Zd9WY2+AvSVSkXUnsGuLQ7dwjAj7sBSnAg6WoI6KpKMCbzfr0sRtTZ59Gi5v5p 3wizESjKz2iX1M1nWJl6t1nb4CkLTCpQ9BoRI9o1ST7nTvZXdaydaDrqGNGOUMykrQPP Ug1MYNbqw4Xt9BshRfsOLsAW6dGxJXqDc9wOM1OKOCOEED8SN6rZ0lS3/eEIW4AxCKwj hPuCV/BYELMM4SEq69mmWLeuBCkP0qem/4Z9PSyVCvZ5DmxuhME2T4tdBQX+eSrAaRUJ DFomgaCZavr56fClV//0sDLNkn79D4zWg7hfnBXMCR6aX4azNXSrJAPkSwIxdsApYKpa dOdg== 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=BwVE1y1PidZ6EPYUZ9ejnkcOzQ8R9Q+pZxNrDQmGLVM=; b=E1zWBzEkLBwYVIRxk/lvsDYBJEcQwXrHyxFmmHp7dXiGJL9wdvy83IPidE0Ikt2JgH L2C+dWjQ00WMsT35lxiRq3w4HYnBRaxwfffe2lUkL71kZLqk1UCTvFXQqxIevCsU+WNw 68PH4PiRf70YCVZnBaAF9PCcDTvy3N91Cra9A7MG2frK1oEj27rEywDZM9v5EtdJHE48 CM25BmVU00ASVZiWWhYYdxXdnDP+nmmw7inpwDjxKCI7riqVjNAzm0WzQBgnY3O/ocZr AUuMckM6jlKbr8whPnmXTcZZl5JOr+EKUfFHaUzoDM1+dHNtQCOfBFUe9bn8aFjwp7kc pnQA== X-Gm-Message-State: AIVw1128+O0dHzOYjamlnpJFiwv/TyPtxQ+sBz1gLZOaxWHDRBr/rM8l RQtQZWQhaoPsrmCIs9E= X-Received: by 10.80.173.99 with SMTP id z32mr6228375edc.140.1501236163947; Fri, 28 Jul 2017 03:02:43 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p10sm9656956edj.72.2017.07.28.03.02.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 03:02:43 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_A9974E86-4AF8-4ACD-9CEE-47AFF93257D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 28 Jul 2017 13:02:40 +0300 To: i2nsf@ietf.org, IPsecME WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [IPsec] I2NSF Virtual Interim meeting on IPsec and draft-abad X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 10:02:48 -0000 --Apple-Mail=_A9974E86-4AF8-4ACD-9CEE-47AFF93257D6 Content-Type: multipart/alternative; boundary="Apple-Mail=_75660B42-60E0-4664-A671-4152ADB2C849" --Apple-Mail=_75660B42-60E0-4664-A671-4152ADB2C849 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi folks. This message is cross-posted to both the IPsec list and the i2nsf list. During the F2F meeting in Prague it was apparent that there is a = disconnect between the SDN people and the VPN people. ISTM that the best = way to solve this is to hold a virtual interim meeting for longer than = the 10 minutes that I2NSF can allocate to non-WG drafts. An agenda and Webex details will be sent out following the selection of = a time slot. For now, if you=E2=80=99re interested in participating, = please follow the link below and indicate when you can make it. Please = note that the time was chosen so as to fit the 10 timezone range from = which participants are expected. I realize it is not idea for anybody. https://doodle.com/poll/crxhk94fcx3qmhks = Thanks, Linda and Yoav --Apple-Mail=_75660B42-60E0-4664-A671-4152ADB2C849 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi folks.

This message is cross-posted to both the IPsec list and the = i2nsf list. 

During the F2F meeting in Prague it was apparent that there = is a disconnect between the SDN people and the VPN people. ISTM that the = best way to solve this is to hold a virtual interim meeting for longer = than the 10 minutes that I2NSF can allocate to non-WG drafts.

An agenda and Webex = details will be sent out following the selection of a time slot. =  For now, if you=E2=80=99re interested in participating, please = follow the link below and indicate when you can make it. Please note = that the time was chosen so as to fit the 10 timezone range from which = participants are expected. I realize it is not idea for = anybody.

https://doodle.com/poll/crxhk94fcx3qmhks

Thanks,

Linda and = Yoav
= --Apple-Mail=_75660B42-60E0-4664-A671-4152ADB2C849-- --Apple-Mail=_A9974E86-4AF8-4ACD-9CEE-47AFF93257D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZewvBAAoJELhJCxUKWMyZJUAIAKRt4ZA4N9JWGdt6jXAc20B0 wAbO/uvcEtT87nCYEhoGGGlqZ0yKmHKip1T7xzfD8WlnY8sgmAp+HeqT2a6ZvCbl XklMAIXo4dghxdVRoBYFW0BLmZ/6k1CbDjtzugYVzO/X1qJnVRA27DF1VXdFvqCv qDrJ+HhlMJ/cxybAiLiqxkfwdj3IbX2cIa2y5mbxmERRtD2eGPSzYL5ENizLpQFO lKHwb1hJkX+NhmHjNwHfeW8pBmBIu3T1LGD5HNREEWXQyakUZZkrs9UXHhK+tc9/ 4TY7WBVVh5qsAdVX670slcNbPjPgVGL+Ii6aTjZLEh9PjGnIkqpTHrwbMW3EhzE= =lBCf -----END PGP SIGNATURE----- --Apple-Mail=_A9974E86-4AF8-4ACD-9CEE-47AFF93257D6-- From nobody Fri Jul 28 09:01:08 2017 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 6F730131CB7; Fri, 28 Jul 2017 09:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 Mw7H80SvVBcI; Fri, 28 Jul 2017 09:01:04 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 4EE1A1317B1; Fri, 28 Jul 2017 09:01:04 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id m85so25895300wma.0; Fri, 28 Jul 2017 09:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=EDpZNxGNG3fe/FjXKfxC4OoC0U+pnE4bJYFxkAlYtdg=; b=Yg6WnGFBamIPGercqxENqsVCGwMuoAMObaju4EKCuHJU9R6md+uvZfBsCrWDwJ8c0s xSJfcHnsZnFOAN7txnvDeleI119D3UnmlLYl7K+avtFS5ryZyGaTm3acSLTxWR/Fk1PO DmJLD+7w/tsNfoqSRfrIRP4MWSlSRXYSBjaqg1E+ydBQTRYI4CLRQwIZ1JmFmq69RA87 72H6VNK7r+WrPojJNSkdLGw1V+HZIrnq6cP8PGY5QeXV27NG3jB7dIXIUCbKHg/jmS4X 84N+FgZHjU5dHjaLOQ/8qS6c2u+JfTfg3rlJxIAEUIkMvEiYM1KXsh97PO6X5kMPKPDa IXaQ== 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:date:references:to :in-reply-to:message-id; bh=EDpZNxGNG3fe/FjXKfxC4OoC0U+pnE4bJYFxkAlYtdg=; b=fj2nKHQ9B4uDegijmmeDSZCXihfID5F4xwuMqFRrfKIzjcdDh+HORTXNvgfjZsu/n3 fMEySVvdBqvmwQjh4KNMWx+Ylr7eboMakQI2zoqoJzWeRIGKi60HLgXU2ktQOfA4o/eL v2i5mPFqhNGgd9vJoN/QuBryGQ/gLS3bMUFW3ZlPKiYaCkY7csfYPcJKwMXHI0BE6RvY P4JDNqUIDXkDDPRd15d40H0Ul2XTFzShc+RYLMI6m0x/fPjkLsAagWYyk4y14kIU9bvk LfSGunZM9l2M5EUUa63+E63qEGGLzHH19skovLtPwzWuXKv8SgpgAm+SHK+6kabg1xfA ihxA== X-Gm-Message-State: AIVw111zvj7Qu6ytE2RLUe0NcBIGKhv8bobe6Dh7S6mlmGOP0niqn00Q RCkpcmhZzCMvI7uQnJk= X-Received: by 10.80.221.2 with SMTP id t2mr7139720edk.134.1501257662700; Fri, 28 Jul 2017 09:01:02 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p10sm9989699edj.72.2017.07.28.09.01.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 09:01:01 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_1FBACE34-D3EE-42F5-8B0F-0F38AE303D63"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 28 Jul 2017 19:00:59 +0300 References: To: i2nsf@ietf.org, IPsecME WG In-Reply-To: Message-Id: <2805F703-FED5-4EB4-9CB5-D2AADAA2C888@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] I2NSF Virtual Interim meeting on IPsec and draft-abad X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:01:06 -0000 --Apple-Mail=_1FBACE34-D3EE-42F5-8B0F-0F38AE303D63 Content-Type: multipart/alternative; boundary="Apple-Mail=_F37563E8-0D00-43D0-BA03-EB92DDAE7282" --Apple-Mail=_F37563E8-0D00-43D0-BA03-EB92DDAE7282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry for the confusion, but it turns out that some key people can=E2=80=99= t make it in August. I=E2=80=99ve updated the poll with dates in September. Thanks > On 28 Jul 2017, at 13:02, Yoav Nir wrote: >=20 > Hi folks. >=20 > This message is cross-posted to both the IPsec list and the i2nsf = list. >=20 > During the F2F meeting in Prague it was apparent that there is a = disconnect between the SDN people and the VPN people. ISTM that the best = way to solve this is to hold a virtual interim meeting for longer than = the 10 minutes that I2NSF can allocate to non-WG drafts. >=20 > An agenda and Webex details will be sent out following the selection = of a time slot. For now, if you=E2=80=99re interested in participating, = please follow the link below and indicate when you can make it. Please = note that the time was chosen so as to fit the 10 timezone range from = which participants are expected. I realize it is not idea for anybody. >=20 > https://doodle.com/poll/crxhk94fcx3qmhks = >=20 > Thanks, >=20 > Linda and Yoav --Apple-Mail=_F37563E8-0D00-43D0-BA03-EB92DDAE7282 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry for the confusion, but it turns out that some key = people can=E2=80=99t make it in August.

I=E2=80=99ve updated the poll with = dates in September.

Thanks

On 28 Jul 2017, at 13:02, Yoav = Nir <ynir.ietf@gmail.com> wrote:

Hi folks.

This message is = cross-posted to both the IPsec list and the i2nsf list. 

During the F2F meeting = in Prague it was apparent that there is a disconnect between the SDN = people and the VPN people. ISTM that the best way to solve this is to = hold a virtual interim meeting for longer than the 10 minutes that I2NSF = can allocate to non-WG drafts.

An agenda and Webex details will be = sent out following the selection of a time slot.  For now, if = you=E2=80=99re interested in participating, please follow the link below = and indicate when you can make it. Please note that the time was chosen = so as to fit the 10 timezone range from which participants are expected. = I realize it is not idea for anybody.

https://doodle.com/poll/crxhk94fcx3qmhks

Thanks,

Linda and = Yoav

= --Apple-Mail=_F37563E8-0D00-43D0-BA03-EB92DDAE7282-- --Apple-Mail=_1FBACE34-D3EE-42F5-8B0F-0F38AE303D63 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZe1+7AAoJELhJCxUKWMyZ3NYH/j7+Na+0uCUt2E1Q3hc3vfOT iJvGobqy3j/Qya+E+kFKyXrdRX4Aodzbj/NLFa1wCx8s2BMLextb/WFQz5XtaU1J QLKM76h1P9r9CK8wALhvra6x8OeTPb19+yILkkU0I3JHHKXdg5JsZl2eyahU79VI B3QOsPP9EvIztNhjE/uTqyjlmlwAbyblfYTac2uGZgPeEa14yg3RATksfW7ijTqZ KJReuRn2iACrAxndTCRVTbv79m9SCBtNMWOZC7BHc1kozdHemZw9o+1VHxqfSQe/ UObzjW5fxWA8hdmVwuwSX/rMPMmvFkD6LV1OGz26ATXRO4fJBYyuIQwzDqorrTs= =rULA -----END PGP SIGNATURE----- --Apple-Mail=_1FBACE34-D3EE-42F5-8B0F-0F38AE303D63-- From nobody Sat Jul 29 06:16:38 2017 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 8DC5D1318A8; Sat, 29 Jul 2017 06:16:30 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150133419049.2991.14065819860228671050@ietfa.amsl.com> Date: Sat, 29 Jul 2017 06:16:30 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 13:16:30 -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 : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-02.txt Pages : 11 Date : 2017-07-29 Abstract: This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains should be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non-public DNS servers is referred to as "Split DNS". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-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 Sat Jul 29 06:20:41 2017 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 9C846131FE6 for ; Sat, 29 Jul 2017 06:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 DjAyO2GqQW82 for ; Sat, 29 Jul 2017 06:20:37 -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 933A81318A8 for ; Sat, 29 Jul 2017 06:20:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xKRD31S84z3Nw for ; Sat, 29 Jul 2017 15:20:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1501334435; bh=9CaGYFeUHLARi/ukPAFT1DPD9N2QNvHOHnxtEv/1u+4=; h=Date:From:To:Subject:In-Reply-To:References; b=m1gok6H4T/13R8cv4NT9PEY5+nO+SOJLHtt8bDXcXpJJje8srUDLc7XMfqkbrpZJx nHeYl5PksSO5ospqa3cKeiij70ruTrIXygTDXM3C4YdoizQZbgwrDRvOisz7ge7qub +5bJxJI4hB4edksFx+7dx3c9lhulI4bW05L8UWuU= 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 83SnczhOs25Y for ; Sat, 29 Jul 2017 15:20:34 +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 ; Sat, 29 Jul 2017 15:20:33 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 97E3930AFA9; Sat, 29 Jul 2017 09:20:32 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 97E3930AFA9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7FA1440D3592 for ; Sat, 29 Jul 2017 09:20:32 -0400 (EDT) Date: Sat, 29 Jul 2017 09:20:32 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <150133419049.2991.14065819860228671050@ietfa.amsl.com> Message-ID: References: <150133419049.2991.14065819860228671050@ietfa.amsl.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] I-D Action: draft-ietf-ipsecme-split-dns-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 13:20:38 -0000 On Sat, 29 Jul 2017, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-02.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-02 I've upated the draft to use presentation format for the INTERNAL_DNS_DOMAIN attribute as per WG recommendation at IETF99 (if you were not there and disagree, please post to the list!) I've added a note about not blindly passing this data without security checks in the Security Considerations section. I think that this document is ready for WGLC now. Paul From nobody Mon Jul 31 13:09:41 2017 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 2DBB31327B2 for ; Mon, 31 Jul 2017 13:09:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 NaA5K4cbWtyq for ; Mon, 31 Jul 2017 13:09:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61491131CA0 for ; Mon, 31 Jul 2017 13:09:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4D82DE200 for ; Mon, 31 Jul 2017 16:11:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A72CF80243 for ; Mon, 31 Jul 2017 16:09:36 -0400 (EDT) From: Michael Richardson to: ipsec@ietf.org In-Reply-To: <523.1501530916@obiwan.sandelman.ca> References: <523.1501530916@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+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] normative references to IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 20:09:39 -0000 --=-=-= Content-Type: text/plain I meant to CC ipsec@, but I'm not sure I actually succeeded. My email to ietf@ietf.org was really about doing this kind of thing in general, and having reference.*.xml files for the registries to make this easy. I noticed that actually in rfc7296, we actually have a reference: https://tools.ietf.org/html/rfc7296#ref-IKEV2IANA [IKEV2IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", . I wonder if adding such a reference (or references with #anchors) would be an acceptable AUTH48 addition. https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-6 Michael Richardson wrote: > I'm implementing draft-ietf-ipsecme-rfc4307bis. > It basically sets MUST/SHOULD/etc. values for various algorithms. The IPsec(ME) > WG updates things as the world evolves. > "References to the specification > defining these algorithms are in the IANA registry." > It would be nice if it gave the actual name of the Registry. > But, I think in this hyperlinked internet, it really should reference the > registry itself directly. > So I wonder out loud: shouldn't all of the IANA registries have clear > reference files that could be normatively referenced? > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAll/joAACgkQgItw+93Q 3WVMoQf9FEbXayijd35A5bm7QLSxVG30ZclEITVzQ0f//dVHXEWzppiT6bctzkLm R8KNihYEnlccGHqbJ2rsYsbJhQuzQdGg9icRpS+VPFvbEGfLib6jUCOPYWKN+2DS fFuPG2w+vZ2bASc+yLkeQL00qVO1odDNq8eGpNUHB5+4KliwCJdmUkv5bXTEiN9P +9xR4WFeeF1aq7IozPg6CW69tNwpLMzMw8ZrK6Idng98VZbfMVeWr0Qhz3WBgS0D rHYTN82gvLKGOk+3UwRzv4yMnMhpvKpa3FxSEuLQG6dcpBZ9GgV+yAf+k+fpRsi3 S5Pvphh4xH+60TGEatVISwa0jMkEiw== =k4oS -----END PGP SIGNATURE----- --=-=-=--