From ynir@checkpoint.com Wed May 2 12:32:42 2012 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 2ED5021E8056; Wed, 2 May 2012 12:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.341 X-Spam-Level: X-Spam-Status: No, score=-10.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnDEuEDbpDK6; Wed, 2 May 2012 12:32:41 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 44AD921E80B7; Wed, 2 May 2012 12:32:41 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q42JWdcd021686; Wed, 2 May 2012 22:32:39 +0300 X-CheckPoint: {4FA199B0-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 2 May 2012 22:32:38 +0300 From: Yoav Nir To: IPsecme WG Date: Wed, 2 May 2012 22:32:34 +0300 Thread-Topic: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.txt Thread-Index: Ac0omlSaYyDp9av3SUeV57mXxGXUuw== Message-ID: <0127FF5E-8F93-4348-B710-3D8924FC5769@checkpoint.com> References: <20120412103348.32017.74969.idtracker@ietfa.amsl.com> <8F2229FE-1995-41F5-AF49-FB5C221C9C85@vpnc.org> In-Reply-To: <8F2229FE-1995-41F5-AF49-FB5C221C9C85@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11488f28f29961c6a1c37def0c01acc4e86985d924 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hokey@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 19:32:42 -0000 Hi again. The response has so far been underwhelming. As I said in my previous messag= e, I'm perfectly willing to go the individual route, but I think this would= be a shame. The protocol extension described can have applications in both= remote access VPN (opening multiple tunnels with multiple gateways) and in= seamless roaming between remote access VPN and local area wireless network= s. I also think that it touches a lot of different areas, and would benefit fr= om the input of people better versed than me in the needs of cellular provi= ders and AAA. I am CC-ing the HOKEY mailing list (as I should have done earlier) because = this draft actually adapts IKE to work with their protocol, and they may be= willing to review and contribute, even if this is IPsecME work. So if any of you are interested, and are willing to review, please let us k= now. Yoav & Qin On Apr 12, 2012, at 10:31 PM, Paul Hoffman wrote: > On Apr 12, 2012, at 11:17 AM, Yoav Nir wrote: >=20 >> We would like this working group to accept this, and have it added to ch= arter. Of course, if it gets accepted, we volunteer to be authors. If it is= not accepted, we will try to progress it as an individual submission, but = we believe that this changes IKE enough that it should come from the workin= g group. >=20 >=20 > Statements of interest and disinterest on this document are welcome. If y= ou prefer to make such a statement off-list please send it to me or Yaron. >=20 > A statement of interest that include a promise to review in WG LC count f= or more than a bare statement of interest. From kivinen@iki.fi Fri May 4 05:16:59 2012 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 9757F21F85CD; Fri, 4 May 2012 05:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxug0dGCl53B; Fri, 4 May 2012 05:16:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E4621F85D2; Fri, 4 May 2012 05:16:58 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.3) with ESMTP id q44CGij8002801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 15:16:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q44CGhMu012556; Fri, 4 May 2012 15:16:43 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20387.51371.885520.98200@fireball.kivinen.iki.fi> Date: Fri, 4 May 2012 15:16:43 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <0127FF5E-8F93-4348-B710-3D8924FC5769@checkpoint.com> References: <20120412103348.32017.74969.idtracker@ietfa.amsl.com> <8F2229FE-1995-41F5-AF49-FB5C221C9C85@vpnc.org> <0127FF5E-8F93-4348-B710-3D8924FC5769@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: IPsecme WG , "hokey@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 12:16:59 -0000 Yoav Nir writes: > So if any of you are interested, and are willing to review, please > let us know. I am willing to review. -- kivinen@iki.fi From yaronf.ietf@gmail.com Tue May 8 12:46:29 2012 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 910169E8004 for ; Tue, 8 May 2012 12:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.98 X-Spam-Level: X-Spam-Status: No, score=-102.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYcMIQK+4kdV for ; Tue, 8 May 2012 12:46:28 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59D659E8002 for ; Tue, 8 May 2012 12:46:28 -0700 (PDT) Received: by bkty8 with SMTP id y8so5967905bkt.31 for ; Tue, 08 May 2012 12:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=rq7iKBy4DE3pFwwSZYTvGXyrD4jDhtoccr9IcmQZcyc=; b=KLq4GPhCmJwVMofb480q1B5f4Jyl/adGHerLe24h4WqXXy2f0cLRERYv0Lr6peOYH4 lYkX8NC0nPtyRTJwntY4kmbPldy+4n7T8ZEgwuaq0N2baBePrTy3ZdmvN0eaTnlJRzjt pyEXCUAOpu8EDCeI31kgmPlmTrvdwJvz0M4+sWh+h/ov6+YfNh4CKCh3KDMLgqmdGWMy /dyXe4hYUtY5rut3p34A7akpBMMHI/4fJr50R5wnlUe8PiA9eUmTiLyjvDu6ia5MYVcm 1Pu+PMW9iyctNR/xXgFE+YLIE5swmGaPMannnZIy94Xay9C5pcO/hQz5AIv6KZ0VUxXp zslQ== Received: by 10.204.155.139 with SMTP id s11mr2158168bkw.106.1336506387403; Tue, 08 May 2012 12:46:27 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-177-151-146.red.bezeqint.net. [79.177.151.146]) by mx.google.com with ESMTPS id e20sm412155bkv.10.2012.05.08.12.46.25 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 12:46:25 -0700 (PDT) Message-ID: <4FA97810.2070802@gmail.com> Date: Tue, 08 May 2012 22:46:24 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Mesh VPN I-D (temporary name) - new author X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 19:46:29 -0000 Hi everybody, Vishwas Manral has agreed to join Steve Hanna as co-author of this draft, now at -00 ( http://tools.ietf.org/html/draft-ietf-ipsecme-p2p-vpn-problem-00). I'd like to thank them both. While Vishwas and Steve are busy working on the next version, feel free to read and comment on the current version. Regards, Yaron From cuiyang@huawei.com Tue May 8 18:55:35 2012 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 9FE2321F84D9; Tue, 8 May 2012 18:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.943 X-Spam-Level: * X-Spam-Status: No, score=1.943 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtLIN-kCXpMW; Tue, 8 May 2012 18:55:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DF9DF21F84D8; Tue, 8 May 2012 18:55:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFR02754; Tue, 08 May 2012 21:55:34 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 18:52:42 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 18:52:45 -0700 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.215]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Wed, 9 May 2012 09:52:40 +0800 From: Cuiyang To: Yoav Nir , IPsecme WG Thread-Topic: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.txt Thread-Index: Ac0omlSaYyDp9av3SUeV57mXxGXUuwE61JdA Date: Wed, 9 May 2012 01:52:39 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2161F4876FC@SZXEML508-MBX.china.huawei.com> References: <20120412103348.32017.74969.idtracker@ietfa.amsl.com> <8F2229FE-1995-41F5-AF49-FB5C221C9C85@vpnc.org> <0127FF5E-8F93-4348-B710-3D8924FC5769@checkpoint.com> In-Reply-To: <0127FF5E-8F93-4348-B710-3D8924FC5769@checkpoint.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.93] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "hokey@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 01:55:35 -0000 SGksIGFsbA0KDQo+IFNvIGlmIGFueSBvZiB5b3UgYXJlIGludGVyZXN0ZWQsIGFuZCBhcmUgd2ls bGluZyB0byByZXZpZXcsIHBsZWFzZSBsZXQgdXMga25vdy4NCkkgd291bGQgbGlrZSB0byByZXZp ZXcgdGhpcyBkcmFmdC4NCg0KQ2hlZXJzLA0KWWFuZw0KPT09PT09PT09PT09PT09PT09DQogWWFu ZyBDdWksICBQaC5ELg0KIEh1YXdlaSBUZWNobm9sb2dpZXMNCiBjdWl5YW5nQGh1YXdlaS5jb20N Cg0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGlwc2VjLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFlvYXYNCj4gTmlyDQo+ILei y83KsbzkOiAyMDEyxOo11MIzyNUgMzozMw0KPiDK1bz+yMs6IElQc2VjbWUgV0cNCj4gs63LzTog aG9rZXlAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtJUHNlY10gTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1uaXItaXBzZWNtZS1lcngtMDMudHh0DQo+IA0KPiBIaSBhZ2Fpbi4NCj4g DQo+IFRoZSByZXNwb25zZSBoYXMgc28gZmFyIGJlZW4gdW5kZXJ3aGVsbWluZy4gQXMgSSBzYWlk IGluIG15IHByZXZpb3VzDQo+IG1lc3NhZ2UsIEknbSBwZXJmZWN0bHkgd2lsbGluZyB0byBnbyB0 aGUgaW5kaXZpZHVhbCByb3V0ZSwgYnV0IEkgdGhpbmsgdGhpcyB3b3VsZA0KPiBiZSBhIHNoYW1l LiBUaGUgcHJvdG9jb2wgZXh0ZW5zaW9uIGRlc2NyaWJlZCBjYW4gaGF2ZSBhcHBsaWNhdGlvbnMg aW4gYm90aA0KPiByZW1vdGUgYWNjZXNzIFZQTiAob3BlbmluZyBtdWx0aXBsZSB0dW5uZWxzIHdp dGggbXVsdGlwbGUgZ2F0ZXdheXMpIGFuZCBpbg0KPiBzZWFtbGVzcyByb2FtaW5nIGJldHdlZW4g cmVtb3RlIGFjY2VzcyBWUE4gYW5kIGxvY2FsIGFyZWEgd2lyZWxlc3MNCj4gbmV0d29ya3MuDQo+ IA0KPiBJIGFsc28gdGhpbmsgdGhhdCBpdCB0b3VjaGVzIGEgbG90IG9mIGRpZmZlcmVudCBhcmVh cywgYW5kIHdvdWxkIGJlbmVmaXQgZnJvbQ0KPiB0aGUgaW5wdXQgb2YgcGVvcGxlIGJldHRlciB2 ZXJzZWQgdGhhbiBtZSBpbiB0aGUgbmVlZHMgb2YgY2VsbHVsYXIgcHJvdmlkZXJzDQo+IGFuZCBB QUEuDQo+IA0KPiBJIGFtIENDLWluZyB0aGUgSE9LRVkgbWFpbGluZyBsaXN0IChhcyBJIHNob3Vs ZCBoYXZlIGRvbmUgZWFybGllcikgYmVjYXVzZSB0aGlzDQo+IGRyYWZ0IGFjdHVhbGx5IGFkYXB0 cyBJS0UgdG8gd29yayB3aXRoIHRoZWlyIHByb3RvY29sLCBhbmQgdGhleSBtYXkgYmUgd2lsbGlu Zw0KPiB0byByZXZpZXcgYW5kIGNvbnRyaWJ1dGUsIGV2ZW4gaWYgdGhpcyBpcyBJUHNlY01FIHdv cmsuDQo+IA0KPiBTbyBpZiBhbnkgb2YgeW91IGFyZSBpbnRlcmVzdGVkLCBhbmQgYXJlIHdpbGxp bmcgdG8gcmV2aWV3LCBwbGVhc2UgbGV0IHVzIGtub3cuDQo+IA0KPiBZb2F2ICYgUWluDQo+IA0K PiBPbiBBcHIgMTIsIDIwMTIsIGF0IDEwOjMxIFBNLCBQYXVsIEhvZmZtYW4gd3JvdGU6DQo+IA0K PiA+IE9uIEFwciAxMiwgMjAxMiwgYXQgMTE6MTcgQU0sIFlvYXYgTmlyIHdyb3RlOg0KPiA+DQo+ ID4+IFdlIHdvdWxkIGxpa2UgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGFjY2VwdCB0aGlzLCBhbmQg aGF2ZSBpdCBhZGRlZCB0bw0KPiBjaGFydGVyLiBPZiBjb3Vyc2UsIGlmIGl0IGdldHMgYWNjZXB0 ZWQsIHdlIHZvbHVudGVlciB0byBiZSBhdXRob3JzLiBJZiBpdCBpcyBub3QNCj4gYWNjZXB0ZWQs IHdlIHdpbGwgdHJ5IHRvIHByb2dyZXNzIGl0IGFzIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiwg YnV0IHdlDQo+IGJlbGlldmUgdGhhdCB0aGlzIGNoYW5nZXMgSUtFIGVub3VnaCB0aGF0IGl0IHNo b3VsZCBjb21lIGZyb20gdGhlIHdvcmtpbmcNCj4gZ3JvdXAuDQo+ID4NCj4gPg0KPiA+IFN0YXRl bWVudHMgb2YgaW50ZXJlc3QgYW5kIGRpc2ludGVyZXN0IG9uIHRoaXMgZG9jdW1lbnQgYXJlIHdl bGNvbWUuIElmDQo+IHlvdSBwcmVmZXIgdG8gbWFrZSBzdWNoIGEgc3RhdGVtZW50IG9mZi1saXN0 IHBsZWFzZSBzZW5kIGl0IHRvIG1lIG9yIFlhcm9uLg0KPiA+DQo+ID4gQSBzdGF0ZW1lbnQgb2Yg aW50ZXJlc3QgdGhhdCBpbmNsdWRlIGEgcHJvbWlzZSB0byByZXZpZXcgaW4gV0cgTEMgY291bnQg Zm9yDQo+IG1vcmUgdGhhbiBhIGJhcmUgc3RhdGVtZW50IG9mIGludGVyZXN0Lg0KPiANCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElQc2Vj IG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lwc2VjDQo= From bill.wu@huawei.com Tue May 8 18:59:02 2012 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 4384711E8080; Tue, 8 May 2012 18:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ea9HEOO89qc; Tue, 8 May 2012 18:59:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A905011E8074; Tue, 8 May 2012 18:59:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFY26259; Tue, 08 May 2012 21:59:01 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 18:56:31 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 May 2012 18:56:34 -0700 Received: from w53375 (10.138.41.149) by szxeml418-hub.china.huawei.com (10.82.67.157) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 May 2012 09:56:28 +0800 Message-ID: From: Qin Wu To: Tero Kivinen , Yoav Nir References: <20120412103348.32017.74969.idtracker@ietfa.amsl.com><8F2229FE-1995-41F5-AF49-FB5C221C9C85@vpnc.org><0127FF5E-8F93-4348-B710-3D8924FC5769@checkpoint.com> <20387.51371.885520.98200@fireball.kivinen.iki.fi> Date: Wed, 9 May 2012 09:56:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: IPsecme WG , hokey@ietf.org Subject: Re: [IPsec] New VersionNotification for draft-nir-ipsecme-erx-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 01:59:02 -0000 KzENCkkgc3VwcG9ydCB0aGlzIHdvcmsgYW5kIHdvdWxkIGxvdmUgdG8gc2VlIHRoaXMgZG9jdW1l bnQgcHJvZ3Jlc3MgZmFzdC4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiVGVybyBLaXZpbmVuIiA8a2l2aW5lbkBpa2kuZmk+DQpUbzogIllv YXYgTmlyIiA8eW5pckBjaGVja3BvaW50LmNvbT4NCkNjOiAiSVBzZWNtZSBXRyIgPGlwc2VjQGll dGYub3JnPjsgPGhva2V5QGlldGYub3JnPg0KU2VudDogRnJpZGF5LCBNYXkgMDQsIDIwMTIgODox NiBQTQ0KU3ViamVjdDogUmU6IFtJUHNlY10gTmV3IFZlcnNpb25Ob3RpZmljYXRpb24gZm9yIGRy YWZ0LW5pci1pcHNlY21lLWVyeC0wMy50eHQNCg0KDQo+IFlvYXYgTmlyIHdyaXRlczoNCj4+IFNv IGlmIGFueSBvZiB5b3UgYXJlIGludGVyZXN0ZWQsIGFuZCBhcmUgd2lsbGluZyB0byByZXZpZXcs IHBsZWFzZQ0KPj4gbGV0IHVzIGtub3cuDQo+IA0KPiBJIGFtIHdpbGxpbmcgdG8gcmV2aWV3Lg0K PiAtLSANCj4ga2l2aW5lbkBpa2kuZmkNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gSVBzZWMgbWFpbGluZyBsaXN0DQo+IElQc2VjQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM= From izaac@setec.org Tue May 8 19:17:10 2012 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 820BC11E808F for ; Tue, 8 May 2012 19:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTVbmTjuAaDl for ; Tue, 8 May 2012 19:17:10 -0700 (PDT) Received: from abbott.setec.org (abbott.setec.org [64.90.166.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0370811E8074 for ; Tue, 8 May 2012 19:17:10 -0700 (PDT) Received: from localhost ([::1]) by abbott.setec.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SRwSg-0000ij-9D for ipsec@ietf.org; Tue, 08 May 2012 22:17:06 -0400 Date: Tue, 8 May 2012 22:17:03 -0400 From: Izaac To: IPsecme WG Message-ID: <20120509T021122Z@localhost> References: <4FA97810.2070802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA97810.2070802@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [IPsec] Mesh VPN I-D (temporary name) - new author X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Izaac List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 02:17:10 -0000 On Tue, May 08, 2012 at 10:46:24PM +0300, Yaron Sheffer wrote: > While Vishwas and Steve are busy working on the next version, feel > free to read and comment on the current version. In what way is this "problem" not addressed by transport mode, despite it's being "far less commonly deployed?" But more generally speaking, what exactly is this document attempting to accomplish in is present form? -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From John.Leser@oracle.com Tue May 8 20:18:58 2012 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 2245C11E808E for ; Tue, 8 May 2012 20:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74zVInLfKOpR for ; Tue, 8 May 2012 20:18:57 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7B51611E8088 for ; Tue, 8 May 2012 20:18:57 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q493Iqu3020877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 May 2012 03:18:53 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q493Ip2E013089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 May 2012 03:18:52 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q493IprK008667 for ; Tue, 8 May 2012 22:18:51 -0500 Received: from [10.152.12.36] (/10.152.12.36) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 20:18:51 -0700 Message-ID: <4FA9E2DF.90302@oracle.com> Date: Tue, 08 May 2012 23:22:07 -0400 From: John Leser User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:9.0) Gecko/20120113 Thunderbird/9.0.1 MIME-Version: 1.0 To: IPsecme WG References: <4FA97810.2070802@gmail.com> <20120509T021122Z@localhost> In-Reply-To: <20120509T021122Z@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: Re: [IPsec] Mesh VPN I-D (temporary name) - new author X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: John.Leser@oracle.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 03:18:58 -0000 On 05/08/12 22:17, Izaac wrote: > On Tue, May 08, 2012 at 10:46:24PM +0300, Yaron Sheffer wrote: >> While Vishwas and Steve are busy working on the next version, feel >> free to read and comment on the current version. > > In what way is this "problem" not addressed by transport mode, despite > it's being "far less commonly deployed?" > > But more generally speaking, what exactly is this document attempting to > accomplish in is present form? > I agree with Izaac. Furthermore, a lot of the language in the draft is confusing (at least to me). You talk about point-to-point tunnel creation, but many of your use cases involve VPNs. Your use cases mostly describe configurations that are already solved today using existing transport mode IPsec (2.1) and VPN configurations (2.2 and 2.3). The idea of connecting to the VPN (section 2.3) gateway closest to a particular destination seems unworkable. It would be more reasonable, and probably more useful, for a client to automatically locate the nearest VPN server to itself (that alone would be an interesting and potentially useful problem). I think you need to narrow down the scope of the problem statement, and provide more careful analysis of why current methods are inadequate, before this draft is going to get you much useful feedback. As a side note, in general, the challenge in constructing large IPsec configurations across multiple administrative domains is getting the "trust relationship" in place to begin with, not the configuration of IPsec and key management policy. -John From zehn.cao@gmail.com Tue May 8 20:46:50 2012 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 D60FB21F856F; Tue, 8 May 2012 20:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7kqUD3bZ-EA; Tue, 8 May 2012 20:46:50 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF33521F856C; Tue, 8 May 2012 20:46:46 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2307195ggm.31 for ; Tue, 08 May 2012 20:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b5ambNA5lol8shKty0MPXJyg4HlmZ/iXM7euKww+4RQ=; b=B8Nwx0GsX+6mu4cSRSa+1uMiES2ZyISFLwzmvpgdizwIEBy/gzdzpHrIRYcI5E4iuv DGVAbMXbPzNGxz9kB1hq66jjcRT7pRWD0qYTdzXoC6FrLv/JKwCB4D65m1Fl3TlS+wZ2 +mrgf6drZwmnKCbGBQ0CXF98QL7jWXXGXZ0bokxltKxUBjaIH7DfgtPlmAvveTI0Z9xZ juPt8CW/uuPHh3KtlgxBp5QPArFGNtoWPefcoO2n4SKd7+deg0vlhihiJj/aZC64fIDf t4qKng/0dDtU5cBr9aoYaumu1xZJCze8BRjxBPLKpmcZZnE7+xWnadlbDTMwhPhSG65L AvDg== MIME-Version: 1.0 Received: by 10.50.183.198 with SMTP id eo6mr11785328igc.61.1336535206382; Tue, 08 May 2012 20:46:46 -0700 (PDT) Received: by 10.42.76.72 with HTTP; Tue, 8 May 2012 20:46:46 -0700 (PDT) In-Reply-To: References: <20120412103348.32017.74969.idtracker@ietfa.amsl.com> <8F2229FE-1995-41F5-AF49-FB5C221C9C85@vpnc.org> <0127FF5E-8F93-4348-B710-3D8924FC5769@checkpoint.com> <20387.51371.885520.98200@fireball.kivinen.iki.fi> Date: Wed, 9 May 2012 11:46:46 +0800 Message-ID: From: Zhen Cao To: Qin Wu Content-Type: text/plain; charset=ISO-8859-1 Cc: IPsecme WG , Yoav Nir , hokey@ietf.org, Tero Kivinen Subject: Re: [IPsec] [HOKEY] New VersionNotification for draft-nir-ipsecme-erx-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 03:46:51 -0000 +1 Willing to see this work progress. Thanks, Zhen On Wed, May 9, 2012 at 9:56 AM, Qin Wu wrote: > +1 > I support this work and would love to see this document progress fast. > > Regards! > -Qin > ----- Original Message ----- > From: "Tero Kivinen" > To: "Yoav Nir" > Cc: "IPsecme WG" ; > Sent: Friday, May 04, 2012 8:16 PM > Subject: Re: [IPsec] New VersionNotification for draft-nir-ipsecme-erx-03.txt > > >> Yoav Nir writes: >>> So if any of you are interested, and are willing to review, please >>> let us know. >> >> I am willing to review. >> -- >> kivinen@iki.fi >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www.ietf.org/mailman/listinfo/hokey -- Best regards, Zhen From izaac@setec.org Wed May 9 09:46:41 2012 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 A7A5811E80BF for ; Wed, 9 May 2012 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiHALIWvdooY for ; Wed, 9 May 2012 09:46:40 -0700 (PDT) Received: from abbott.setec.org (abbott.setec.org [64.90.166.179]) by ietfa.amsl.com (Postfix) with ESMTP id C15B911E80A0 for ; Wed, 9 May 2012 09:46:40 -0700 (PDT) Received: from localhost ([::1]) by abbott.setec.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SSA2A-0000OE-Kn for ipsec@ietf.org; Wed, 09 May 2012 12:46:39 -0400 Date: Wed, 9 May 2012 12:46:37 -0400 From: Izaac To: IPsecme WG Message-ID: <20120509T163822Z@localhost> References: <4FA97810.2070802@gmail.com> <20120509T021122Z@localhost> <4FA9E2DF.90302@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA9E2DF.90302@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [IPsec] Mesh VPN I-D (temporary name) - new author X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Izaac List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 16:46:41 -0000 On Tue, May 08, 2012 at 11:22:07PM -0400, John Leser wrote: > particular destination seems unworkable. It would be more > reasonable, and probably more useful, for a client to automatically > locate the nearest VPN server to itself (that alone would be an > interesting and potentially useful problem). Even this is better served by just letting IP routing handle it through the use of transport mode. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From vishwas.ietf@gmail.com Wed May 9 11:54:49 2012 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 0B56B21F8498 for ; Wed, 9 May 2012 11:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvAQcbG-MEsD for ; Wed, 9 May 2012 11:54:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7282C21F8494 for ; Wed, 9 May 2012 11:54:48 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so787092obb.31 for ; Wed, 09 May 2012 11:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tNcppgisR6eovmmSFyjnfwBqPX4svlc1SpOkpD764S8=; b=reDesVmz0V4qvfWjfvMGmOjmQwNWcdW/n9bxEk+iCYF6i0ypXzXhBG2BftjhxDhhSE XEn+tJHCc1jJf/9KJaA1kuP3zK0gzvhKWJWqhB7zNiBjYztde8Cdp8ZByCb1tNY+Kc2b bqR6UAPPFziipiWDw+q7gzSL4xa3zjN9qB6v+fYjSc1pFII6V4LPvn5sFZ4PGRGU56Xn aXCpstPKY3h9SPaOQqJj1q100ubo/2XFIkyFBLPrPzVeNRY4A4WKFml3K9yvoNYPfH5y nG/u0MBz3OfcBH3Da5CDLiIAixyBoB33flcrTKVjVYhaL00hDLCHHSrVogmYaehXOKEa Cd4w== MIME-Version: 1.0 Received: by 10.182.155.35 with SMTP id vt3mr1734966obb.63.1336589688031; Wed, 09 May 2012 11:54:48 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Wed, 9 May 2012 11:54:47 -0700 (PDT) In-Reply-To: <20120509T163822Z@localhost> References: <4FA97810.2070802@gmail.com> <20120509T021122Z@localhost> <4FA9E2DF.90302@oracle.com> <20120509T163822Z@localhost> Date: Wed, 9 May 2012 11:54:47 -0700 Message-ID: From: Vishwas Manral To: Izaac Content-Type: multipart/alternative; boundary=f46d0446326e90c83e04bf9f09e9 Cc: IPsecme WG Subject: Re: [IPsec] Mesh VPN I-D (temporary name) - new author X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 18:54:49 -0000 --f46d0446326e90c83e04bf9f09e9 Content-Type: text/plain; charset=ISO-8859-1 Hi Izaac/ John, Thanks for the great inputs you provide. I agree we may not see changes in the way packets would traverse the network in either the transport/ tunnel mode. Like you mention Routing in such topologies is an issue for sure (especially in the Hub and Spoke topology) and there are extensions being worked on to resolve those issues. However the above does not solve the problem of exhaustive IPsec database configurations. It also does not solve the issues of how to handle changing identifiers in the SPD either (as addresses of spokes change). Like the draft mentioned an exhaustive configuration could solve some of the issues, but that would lead to issues with the weakest link the the topology. Thanks, Vishwas On Wed, May 9, 2012 at 9:46 AM, Izaac wrote: > On Tue, May 08, 2012 at 11:22:07PM -0400, John Leser wrote: > > particular destination seems unworkable. It would be more > > reasonable, and probably more useful, for a client to automatically > > locate the nearest VPN server to itself (that alone would be an > > interesting and potentially useful problem). > > Even this is better served by just letting IP routing handle it through > the use of transport mode. > > --f46d0446326e90c83e04bf9f09e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Izaac/ John,

Thanks for the great inputs you provide. I agree we = may not see changes in the way packets would traverse the network in either= the transport/ tunnel mode.

Like you mention Routing in such topol= ogies is an issue for sure (especially in the Hub and Spoke topology) and t= here are extensions being worked on to resolve those issues. However the ab= ove does not solve the problem of exhaustive IPsec database configurations.= It also does not solve the issues of how to handle changing identifiers in= the SPD either (as addresses of spokes change).

Like the draft mentioned an exhaustive configuration could solve some o= f the issues, but that would lead to issues with the weakest link the the t= opology.

Thanks,
Vishwas

On Wed= , May 9, 2012 at 9:46 AM, Izaac <izaac@setec.org> wrote:
On Tue, May 08, 2012 at 11:22:07PM -040= 0, John Leser wrote:
> particular destination seems unworkable. =A0It would be more
> reasonable, and probably more useful, for a client to automatically > locate the nearest VPN server to itself (that alone would be an
> interesting and potentially useful problem).

Even this is better served by just letting IP routing handle it throu= gh
the use of transport mode.


--f46d0446326e90c83e04bf9f09e9-- From mikeb@openbsd.org Thu May 10 05:19:55 2012 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 37AC621F8665 for ; Thu, 10 May 2012 05:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q6+QgDrJnJb for ; Thu, 10 May 2012 05:19:54 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6921F865F for ; Thu, 10 May 2012 05:19:54 -0700 (PDT) Received: by gir.theapt.org (Postfix, from userid 1032) id EBAC478939; Thu, 10 May 2012 14:19:51 +0200 (CEST) Date: Thu, 10 May 2012 14:19:51 +0200 From: Mike Belopuhov To: ipsec@ietf.org Message-ID: <20120510121951.GA26064@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 10 May 2012 10:40:40 -0700 Cc: mikeb@openbsd.org Subject: [IPsec] ESP AAD construction for GCM with ESN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 12:23:08 -0000 Hi, The RFC 4106 "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)" doesn't explicitly state how are ESN octets distributed in the AAD. Given that SPI and low-order 32 bits are coming from the actual packet and most likely occupy one cache line, I'd expect AAD to look like this to exploit cache locality and simplify processing: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Low-order 32 bits (part of the packet) | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | High-order 32 bits (external memory buffer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Could you please confirm or disconfirm this observation. Thanks in advance, Mike From vishwas.ietf@gmail.com Fri May 11 15:11:53 2012 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 7D25521F8701 for ; Fri, 11 May 2012 15:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa3I8chWul0d for ; Fri, 11 May 2012 15:11:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE0B21F86F7 for ; Fri, 11 May 2012 15:11:52 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4577428obb.31 for ; Fri, 11 May 2012 15:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2x55v+MOYrahnx9t2FMVtx2Dxg8DWyKITo0t4qYE3bo=; b=L/CySy0K9f/4JSiE/BUBqdUzh8ZBhLnuo2rSEQ5Rdh8imv48bUJi/csYu2O0dHMpJS TEcdJUh9ATmlljit/TkGK8qVkHBWDJ4ULJtMdHNC8L6J7+nY+Pu3ESd61I/RR/TCs15L 2LqR5RACeHW1cChZVNojroq8bTMZpb6paAT2u41SBkNm5heE7KInbf9m8uBb1xTkirF0 u6xviYMF0UAc+JgW+Je8OkxcrXcDy4O0Igf9kVwD7pPQEDfP7r/yH41zT1L4V8W9L3wl lOANKEFPFGMdCfPCqXZ94mI68k131/6SFh8FrDk3hbmLTbcKJDAwyLDchS55ILwNZan3 VcOw== MIME-Version: 1.0 Received: by 10.60.0.193 with SMTP id 1mr14191169oeg.33.1336774311954; Fri, 11 May 2012 15:11:51 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Fri, 11 May 2012 15:11:51 -0700 (PDT) Date: Fri, 11 May 2012 15:11:51 -0700 Message-ID: From: Vishwas Manral To: IPsecme WG Content-Type: multipart/alternative; boundary=e89a8fb2011602496104bfca063b Subject: [IPsec] Issue #219 - Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 22:11:53 -0000 --e89a8fb2011602496104bfca063b Content-Type: text/plain; charset=ISO-8859-1 Hi, I would like to start off by trying to resolve the issue. The notes from the IETF are attached below. Description:Some admins prefer a star topology so they can inspect traffic. They may not want to use this technology. Detail arguments: My take is similar to what Yaron and Yaov seem to state. There is no reason to exclude star topology at all from the Problem statement/ requirements document. In fact both the proprietary solutions I know of allow for such a topology. I however understand that some of the functionality on the Hub (of the star) could be achieved by using PFP flags in the SPD entry. Suggested Resolution: State in the document that Star topology is not excluded from the solution. The problem of configuration is however mainly limited to the Hub. For every spoke added/ deleted/ modified the configuration on the Hub needs to be changed, which is not desirable. May be update Section 3.2 with the same too. Thanks, Vishwas =========================================================== Notes from meeting minutes: # 219 Star topology as an admin choice People don't need to use this if they don't want to Say this in the security considerations Yoav Nir: Has to be a requirement that any solution can implement different policies Yaron Sheffer: Agrees with Yoav, maybe becomes a use case Take this to the list --e89a8fb2011602496104bfca063b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I would like to start off by trying to resolve the issue. The no= tes from the IETF are attached below.

Description:Some admins prefer= a star topology so they can inspect traffic. They may not want to use this= technology.

Detail arguments: My take is similar to what Yaron and Yaov seem to sta= te. There is no reason to exclude star topology at all from the Problem sta= tement/ requirements document. In fact both the proprietary solutions I kno= w of allow for such a topology. I however understand that some of the funct= ionality on the Hub (of the star) could be achieved by using PFP flags in t= he SPD entry.

Suggested Resolution: State in the document that Star topology is not e= xcluded from the solution. The problem of configuration is however mainly l= imited to the Hub. For every spoke added/ deleted/ modified the configurati= on on the Hub needs to be changed, which is not desirable. May be update Se= ction 3.2 with the same too.

Thanks,
Vishwas
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Notes from meetin= g minutes:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 # 219= Star topology as an admin choice
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 People don't need to use this i= f they don't want to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Say this in the security considerations
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yoav Nir:
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Has to be a requirement that any solution can
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 implement different policies
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Yaron Sheffer:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Agrees with Yoav, maybe becom= es a use case
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Take this to the list
--e89a8fb2011602496104bfca063b-- From vishwas.ietf@gmail.com Fri May 11 16:03:08 2012 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 6146211E8083 for ; Fri, 11 May 2012 16:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uALP6tMR7zMi for ; Fri, 11 May 2012 16:03:07 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7A639E800A for ; Fri, 11 May 2012 16:03:07 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4634897obb.31 for ; Fri, 11 May 2012 16:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=l+NqkXMNAq6aOQaG57Nc0L+zkIzARqydGsvO6ZdI1zs=; b=FGFu0fZv5y5bSWR0yUakJo6CUg5Bt1VMlWgXZIpv4861NMRqc0Q9xFBZzLW7tjt2E/ 3i3eKJFke80KGmDD3ixtvLAFYG6YzSdWfQ6Wy9rA+7Mwbymh9tU9dXDnEUem0divSuHx voldpPpI4LSfsz7GgltJ6mUIPN3uMCmoa5kzVkwpkSjJi4x8lojAKITnAKUVMvya58Ta Gc+xreSIM3crVy9/iA8GiTQp2sIP+bEeC0AVQUY/sfmaQI32umNGVGL7fLpNk0T3N0/S CV7t22fSeiYRtZNi++Aq8dZx8a/tKNVVxKoERPUftWeQazn00MW9Kuoi1mduShh1Act8 F2bQ== MIME-Version: 1.0 Received: by 10.182.147.74 with SMTP id ti10mr2254405obb.35.1336777387318; Fri, 11 May 2012 16:03:07 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Fri, 11 May 2012 16:03:07 -0700 (PDT) Date: Fri, 11 May 2012 16:03:07 -0700 Message-ID: From: Vishwas Manral To: IPsecme WG Content-Type: multipart/alternative; boundary=f46d044472bf509e5104bfcabded Subject: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:03:08 -0000 --f46d044472bf509e5104bfcabded Content-Type: text/plain; charset=ISO-8859-1 Hi, Description: Direct endpoint-to-endpoint connectivity may not be possible. Should gateways figure things out completely or just punt endpoints to a closer gateway? Detail Arguments: As Izaac and John Lesser pointed out this is more of a routing issue. Though current solutions do not allow such connectivity unless through a hub, I think from the security plane, we should not preclude such connectivity. This could be achieved either transparently (no IPsec component except the SPD involved), or by stitching tunnel traffic. Suggested Resolutions: Specify explicitly that issues around direct connectivity between endpoints are more of a Routing issue. However IPsec should not prevent such a connectivity model. Thanks, Vishwas ======================================================= Meeting notes: # 213 In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible Need to mention challenges in use cases section Paul: reminded that there will be a separate requirement section # 214 Should gateways figure things out completely or just punt endpoints to a closer gateway? Core gateway configuring is a solution, so premature Also in #213 --f46d044472bf509e5104bfcabded Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Description: Direct endpoint-to-endpoint connectivity may not be= possible. Should gateways figure things out completely or just punt endpoi= nts to a closer gateway?

Detail Arguments: As Izaac and John Lesser = pointed out this is more of a routing issue. Though current solutions do no= t allow such connectivity unless through a hub, I think from the security p= lane, we should not preclude such connectivity. This could be achieved eith= er transparently (no IPsec component except the SPD involved), or by stitch= ing tunnel traffic.

Suggested Resolutions: Specify explicitly that issues around direct con= nectivity between endpoints are more of a Routing issue. However IPsec shou= ld not prevent such a connectivity model.

Thanks,
Vishwas
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Meeting notes:
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # = 213 In use case 2.1, direct endpoint-to-endpoint connectivity
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 may not be possible
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Need to = mention challenges in use cases section
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Paul: reminded that there will be a separate requirement
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 section
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 # 214 Should gateways f= igure things out completely or just punt
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 endpoints to a closer gateway?
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Core gateway configuring is a solution, so premature
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Also in #213
<= br> --f46d044472bf509e5104bfcabded-- From vishwas.ietf@gmail.com Fri May 11 16:34:08 2012 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 2BEAC21F8512 for ; Fri, 11 May 2012 16:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UKnwebyQigY for ; Fri, 11 May 2012 16:34:07 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE86321F84FF for ; Fri, 11 May 2012 16:34:07 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4670474obb.31 for ; Fri, 11 May 2012 16:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=idIIaJsKuxaqwrlhPyKFLhDbWS27/dCQX6eHuMVqG/E=; b=k7KYOnZy3uJQYL8bwtqW0qUNFPBtwpQAh1NXfrp/CiVQDLVc+5Q6KUiXtQ0XwfmBqf ae2NulWt86Ono+HTJ9Hg43O5dhXnw7cPHvcnFvazrNZfOWp+J+EkdZFUe/QUIQtSbxyK 3U92MyZrrma30gFfU60XjkJ990TSuqfNfZKMvZFh7Iyn4Hc4NdsXQAeihfZctiQtQPhP Z+woMzsPJMXApFroUfRGxlpRX42LQNGH3o9kbMAG/cNZVTlaZYAIlGBwxWA7bZ4TOwt5 p3vD0MndcGHvwlxr2kgjNpx7KbkR81Q25TENd5qzMKenRQb/B6sNGxkJcYf0z/hx0jTZ goYg== MIME-Version: 1.0 Received: by 10.182.172.100 with SMTP id bb4mr35606obc.22.1336779247373; Fri, 11 May 2012 16:34:07 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Fri, 11 May 2012 16:34:07 -0700 (PDT) Date: Fri, 11 May 2012 16:34:07 -0700 Message-ID: From: Vishwas Manral To: IPsecme WG Content-Type: multipart/alternative; boundary=e89a8f83a1dd2ecee204bfcb2c4e Subject: [IPsec] Issue #218 - Exhaustive configuration X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 23:34:08 -0000 --e89a8f83a1dd2ecee204bfcb2c4e Content-Type: text/plain; charset=ISO-8859-1 Hi, Description: Exhaustive configuration Detail Arguments:Tero rightly mentioned that the configuration is a proprietary issue. However there are a few things, that make the configuration hard. Change of IP address of a spoke, NAT, configuration limited by weakest link(device) in the chain. Suggested Resolution: In my view reducing configuration is a big issue. Point out issues with this in greater detail in the draft. Thanks, Vishwas =============================================== Meeting minutes: # 218 Exhaustive configuration Explain that this doesn't scale in 3.1. Tero: It is also proprietary and can't be interoperable Brian: We can push out configs if needed Paul: Remember the massive failure of the IPS WG Also issue with NATs if the endpoint hasn't talked first --e89a8f83a1dd2ecee204bfcb2c4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SGksPGJyPjxicj5EZXNjcmlwdGlvbjogRXhoYXVzdGl2ZSBjb25maWd1cmF0aW9uPGJyPjxicj5E ZXRhaWwgQXJndW1lbnRzOlRlcm8gcmlnaHRseSBtZW50aW9uZWQgdGhhdCB0aGUgY29uZmlndXJh dGlvbiBpcyBhIHByb3ByaWV0YXJ5IGlzc3VlLiBIb3dldmVyIHRoZXJlIGFyZSBhIGZldyB0aGlu Z3MsIHRoYXQgbWFrZSB0aGUgY29uZmlndXJhdGlvbiBoYXJkLiBDaGFuZ2Ugb2YgSVAgYWRkcmVz cyBvZiBhIHNwb2tlLCBOQVQsIGNvbmZpZ3VyYXRpb24gbGltaXRlZCBieSB3ZWFrZXN0IGxpbmso ZGV2aWNlKSBpbiB0aGUgY2hhaW4uPGJyPgo8YnI+U3VnZ2VzdGVkIFJlc29sdXRpb246IEluIG15 IHZpZXcgcmVkdWNpbmcgY29uZmlndXJhdGlvbiBpcyBhIGJpZyBpc3N1ZS4gUG9pbnQgb3V0IGlz c3VlcyB3aXRoIHRoaXMgaW4gZ3JlYXRlciBkZXRhaWwgaW4gdGhlIGRyYWZ0Ljxicj48YnI+VGhh bmtzLDxicj5WaXNod2FzPGJyPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PGJyPk1lZXRpbmcgbWludXRlczo8YnI+Cjxicj6goKCgoKCgoKCgoKCgoCAjIDIx OCBFeGhhdXN0aXZlIGNvbmZpZ3VyYXRpb248YnI+oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgRXhw bGFpbiB0aGF0IHRoaXMgZG9lc24mIzM5O3Qgc2NhbGUgaW4gMy4xLjxicj6goKCgoKCgoKCgoKCg oKCgoKCgoKCgoCBUZXJvOiBJdCBpcyBhbHNvIHByb3ByaWV0YXJ5IGFuZCBjYW4mIzM5O3QgYmUg aW50ZXJvcGVyYWJsZTxicj6goKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBCcmlhbjogV2UgY2FuIHB1 c2ggb3V0IGNvbmZpZ3MgaWYgbmVlZGVkPGJyPgqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBQYXVs OiBSZW1lbWJlciB0aGUgbWFzc2l2ZSBmYWlsdXJlIG9mIHRoZSBJUFMgV0c8YnI+oKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBBbHNvIGlzc3VlIHdpdGggTkFUcyBpZiB0aGUgZW5kcG9p bnQgaGFzbiYjMzk7dDxicj6goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHRhbGtlZCBm aXJzdDxicj48YnI+Cg== --e89a8f83a1dd2ecee204bfcb2c4e-- From ynir@checkpoint.com Sat May 12 11:34:40 2012 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 2F68521F8608 for ; Sat, 12 May 2012 11:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.42 X-Spam-Level: X-Spam-Status: No, score=-10.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtDKhkvHdek8 for ; Sat, 12 May 2012 11:34:39 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3403421F85E1 for ; Sat, 12 May 2012 11:34:38 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4CIYajl029911; Sat, 12 May 2012 21:34:36 +0300 X-CheckPoint: {4FAEBA88-1-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 12 May 2012 21:34:36 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 12 May 2012 21:34:34 +0300 From: Yoav Nir To: Vishwas Manral Date: Sat, 12 May 2012 21:34:37 +0300 Thread-Topic: [IPsec] Issue #219 - Star topology as an admin choice Thread-Index: Ac0wbeAquwi08x71SnitYEDsB5cOpQ== Message-ID: <376FC498-8F7F-4F11-9AED-43490EF654FB@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Cc: IPsecme WG Subject: Re: [IPsec] Issue #219 - Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 18:34:40 -0000 Hi. I think it should be more complicated than this. The suggested solution has= a dichotomy of either a full mesh or a start topology. The requirements sh= ould cover scenarios such as a mesh within an organization connecting to a = hub to gateways outside the organization, or multiple hubs connected among = themselves in either a star or a mesh, or even certain "routes" that are ma= nually configured along with all the auto-discovery stuff. Perhaps we can capture the needed complexity by talking about groups of nod= es, where nodes that belong to a single group attempt to create a mesh amon= g them, and packets can travel between nodes that do not belong to the same= group through group intersection. I'm not sure if this level of detail is = part of the problem statement, but it's more high level than a solution. On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: > Hi, >=20 > I would like to start off by trying to resolve the issue. The notes from = the IETF are attached below. >=20 > Description:Some admins prefer a star topology so they can inspect traffi= c. They may not want to use this technology. >=20 > Detail arguments: My take is similar to what Yaron and Yaov seem to state= . There is no reason to exclude star topology at all from the Problem state= ment/ requirements document. In fact both the proprietary solutions I know = of allow for such a topology. I however understand that some of the functio= nality on the Hub (of the star) could be achieved by using PFP flags in the= SPD entry. >=20 > Suggested Resolution: State in the document that Star topology is not exc= luded from the solution. The problem of configuration is however mainly lim= ited to the Hub. For every spoke added/ deleted/ modified the configuration= on the Hub needs to be changed, which is not desirable. May be update Sect= ion 3.2 with the same too. >=20 > Thanks, > Vishwas > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Notes from meeting minutes: >=20 > # 219 Star topology as an admin choice > People don't need to use this if they don't wan= t to > Say this in the security considerations > Yoav Nir: > Has to be a requirement that any soluti= on can > implement different policies > Yaron Sheffer: > Agrees with Yoav, maybe becomes a use c= ase > Take this to the list > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From vishwas.ietf@gmail.com Sat May 12 12:53:20 2012 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 97AB721F864B for ; Sat, 12 May 2012 12:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk6iS00d+7-R for ; Sat, 12 May 2012 12:53:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE03121F8596 for ; Sat, 12 May 2012 12:53:19 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so6096762obb.31 for ; Sat, 12 May 2012 12:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+iDk2U599r+DZ7tuvHtnCni5gBK1dru/mf3Ahmz1a1I=; b=zzF2Y2X8FB8AEdz1kY79HAPsQPwT4rIiwNmLZGU3c8oPnrbJNGB2dSg+KfeXW50YUV e6N2oAxWhfepOe1ECvBlYO5W5eiMY9N1KC2Lol9WEr1llVoESzAAAiQeO5zrdRnatqm7 mJUH5RD0pMyrwoUYAgE9KXXODFFHzszG9d8go1Yt7AF+G9hBY34mVqrhoQ5h1qMy7pT1 XG2CgsP4xFioeg6z8LCcNzDdvmESF0bsba4IBivvUCJWIvFJwb9jhj83o+TY1X4kjB8X otGd9Zf+DAk6HwaGonrYj6ECsl3SRC3Yu8yWrQF45QOGAxU2R6hGUcifCvxkkdo7WDlM G8wA== MIME-Version: 1.0 Received: by 10.182.154.73 with SMTP id vm9mr4180714obb.72.1336852397670; Sat, 12 May 2012 12:53:17 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Sat, 12 May 2012 12:53:17 -0700 (PDT) In-Reply-To: <376FC498-8F7F-4F11-9AED-43490EF654FB@checkpoint.com> References: <376FC498-8F7F-4F11-9AED-43490EF654FB@checkpoint.com> Date: Sat, 12 May 2012 12:53:17 -0700 Message-ID: From: Vishwas Manral To: Yoav Nir Content-Type: multipart/alternative; boundary=14dae939983347c06304bfdc34f1 Cc: IPsecme WG Subject: Re: [IPsec] Issue #219 - Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 19:53:20 -0000 --14dae939983347c06304bfdc34f1 Content-Type: text/plain; charset=ISO-8859-1 Hi Yaov, If I udnerstand correctly, what you seem to be talking about is a Star-of-meshes or a mesh-of-star topology. In my view this would be dealt with in 2 different iterations of the Mesh VPN topology. So there would be a Mesh VPN for the Star topology and a separate instance of the Mesh VPN for the mesh topology. Let me know if that makes sense. I think we can state that the requirement should allow for such iterative use cases, however at one instance we only look at star or mesh topology. Do I make sense? Thanks, Vishwas On Sat, May 12, 2012 at 11:34 AM, Yoav Nir wrote: > Hi. > > I think it should be more complicated than this. The suggested solution > has a dichotomy of either a full mesh or a start topology. The requirements > should cover scenarios such as a mesh within an organization connecting to > a hub to gateways outside the organization, or multiple hubs connected > among themselves in either a star or a mesh, or even certain "routes" that > are manually configured along with all the auto-discovery stuff. > > Perhaps we can capture the needed complexity by talking about groups of > nodes, where nodes that belong to a single group attempt to create a mesh > among them, and packets can travel between nodes that do not belong to the > same group through group intersection. I'm not sure if this level of detail > is part of the problem statement, but it's more high level than a solution. > > On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: > > > Hi, > > > > I would like to start off by trying to resolve the issue. The notes from > the IETF are attached below. > > > > Description:Some admins prefer a star topology so they can inspect > traffic. They may not want to use this technology. > > > > Detail arguments: My take is similar to what Yaron and Yaov seem to > state. There is no reason to exclude star topology at all from the Problem > statement/ requirements document. In fact both the proprietary solutions I > know of allow for such a topology. I however understand that some of the > functionality on the Hub (of the star) could be achieved by using PFP flags > in the SPD entry. > > > > Suggested Resolution: State in the document that Star topology is not > excluded from the solution. The problem of configuration is however mainly > limited to the Hub. For every spoke added/ deleted/ modified the > configuration on the Hub needs to be changed, which is not desirable. May > be update Section 3.2 with the same too. > > > > Thanks, > > Vishwas > > =========================================================== > > Notes from meeting minutes: > > > > # 219 Star topology as an admin choice > > People don't need to use this if they don't > want to > > Say this in the security considerations > > Yoav Nir: > > Has to be a requirement that any > solution can > > implement different policies > > Yaron Sheffer: > > Agrees with Yoav, maybe becomes a use > case > > Take this to the list > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > --14dae939983347c06304bfdc34f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yaov,

If I udnerstand correctly, what you seem to be talking abou= t is a Star-of-meshes or a mesh-of-star topology.

In my view this w= ould be dealt with in 2 different iterations of the Mesh VPN topology. So t= here would be a Mesh VPN for the Star topology and a separate instance of t= he Mesh VPN for the mesh topology.

Let me know if that makes sense. I think we can state that the requirem= ent should allow for such iterative use cases, however at one instance we o= nly look at star or mesh topology. Do I make sense?

Thanks,
Vishw= as

On Sat, May 12, 2012 at 11:34 AM, Yoav Nir <= span dir=3D"ltr"><ynir@checkpoint.com> wrote:
Hi.

I think it should be more complicated than this. The suggested solution has= a dichotomy of either a full mesh or a start topology. The requirements sh= ould cover scenarios such as a mesh within an organization connecting to a = hub to gateways outside the organization, or multiple hubs connected among = themselves in either a star or a mesh, or even certain "routes" t= hat are manually configured along with all the auto-discovery stuff.

Perhaps we can capture the needed complexity by talking about groups of nod= es, where nodes that belong to a single group attempt to create a mesh amon= g them, and packets can travel between nodes that do not belong to the same= group through group intersection. I'm not sure if this level of detail= is part of the problem statement, but it's more high level than a solu= tion.

On May 12, 2012, at 1:11 AM, Vishwas Manral wrote:

> Hi,
>
> I would like to start off by trying to resolve the issue. The notes fr= om the IETF are attached below.
>
> Description:Some admins prefer a star topology so they can inspect tra= ffic. They may not want to use this technology.
>
> Detail arguments: My take is similar to what Yaron and Yaov seem to st= ate. There is no reason to exclude star topology at all from the Problem st= atement/ requirements document. In fact both the proprietary solutions I kn= ow of allow for such a topology. I however understand that some of the func= tionality on the Hub (of the star) could be achieved by using PFP flags in = the SPD entry.
>
> Suggested Resolution: State in the document that Star topology is not = excluded from the solution. The problem of configuration is however mainly = limited to the Hub. For every spoke added/ deleted/ modified the configurat= ion on the Hub needs to be changed, which is not desirable. May be update S= ection 3.2 with the same too.
>
> Thanks,
> Vishwas
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Notes from meeting minutes:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # 219 Star topology as an admin ch= oice
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 People don't n= eed to use this if they don't want to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Say this in the se= curity considerations
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yoav Nir:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ha= s to be a requirement that any solution can
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 im= plement different policies
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yaron Sheffer:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ag= rees with Yoav, maybe becomes a use case
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ta= ke this to the list
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


--14dae939983347c06304bfdc34f1-- From ynir@checkpoint.com Sat May 12 12:58:56 2012 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 5831121F8645 for ; Sat, 12 May 2012 12:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJaGxC5xDIJP for ; Sat, 12 May 2012 12:58:55 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D71DD21F863B for ; Sat, 12 May 2012 12:58:54 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4CJwprJ001831; Sat, 12 May 2012 22:58:51 +0300 X-CheckPoint: {4FAECE47-1-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 12 May 2012 22:58:52 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 12 May 2012 22:58:49 +0300 From: Yoav Nir To: Vishwas Manral Date: Sat, 12 May 2012 22:58:51 +0300 Thread-Topic: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity Thread-Index: Ac0weaXFg2ETX/BTQpis8rUHw7fZzQ== Message-ID: <3B3F3DD4-4D25-4CE8-BE1A-0448E1E338B7@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Cc: IPsecme WG Subject: Re: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 19:58:56 -0000 I'm not sure I understand the suggested resolution. The biggest barrier to = direct connectivity is that the responder may be behind NAT. Is this consid= ered a "routing issue"? In any case, there are protocols for getting to a = responder behind a NAT. They work well enough that VoIP solutions work pret= ty much everywhere where there isn't a firewall that's specifically targeti= ng VoIP. I think we should user them, adapt therm or profile them for IKE/I= Psec, although this does not necessarily belong in the solution document. As for #214, I don't see how this is answered. If an gateway A would like t= o contact a host behind gateway Z, and does so through gateway B, must gate= way B provide the addresses for gateway Z, or can it give the address of ga= teway D, which will then provide the address of gateway Z? IOW, must redir= ection be 1-step? Yoav On May 12, 2012, at 2:03 AM, Vishwas Manral wrote: > Hi, >=20 > Description: Direct endpoint-to-endpoint connectivity may not be possible= . Should gateways figure things out completely or just punt endpoints to a = closer gateway? >=20 > Detail Arguments: As Izaac and John Lesser pointed out this is more of a = routing issue. Though current solutions do not allow such connectivity unle= ss through a hub, I think from the security plane, we should not preclude s= uch connectivity. This could be achieved either transparently (no IPsec com= ponent except the SPD involved), or by stitching tunnel traffic. >=20 > Suggested Resolutions: Specify explicitly that issues around direct conne= ctivity between endpoints are more of a Routing issue. However IPsec should= not prevent such a connectivity model. >=20 > Thanks, > Vishwas > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > Meeting notes:=20 > # 213 In use case 2.1, direct endpoint-to-endpoint conne= ctivity > may not be possible > Need to mention challenges in use cases section > Paul: reminded that there will be a separate re= quirement > section > # 214 Should gateways figure things out completely or j= ust punt > endpoints to a closer gateway? > Core gateway configuring is a solution, so prem= ature > Also in #213 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Sat May 12 13:16:41 2012 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 B71C721F854C for ; Sat, 12 May 2012 13:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.275 X-Spam-Level: X-Spam-Status: No, score=-9.275 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_WANT=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTRf27ofTS8Q for ; Sat, 12 May 2012 13:16:40 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68E21F8533 for ; Sat, 12 May 2012 13:16:39 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4CKGZAv002789; Sat, 12 May 2012 23:16:35 +0300 X-CheckPoint: {4FAED26F-0-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 12 May 2012 23:16:36 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 12 May 2012 23:16:34 +0300 From: Yoav Nir To: Vishwas Manral Date: Sat, 12 May 2012 23:16:34 +0300 Thread-Topic: [IPsec] Issue #219 - Star topology as an admin choice Thread-Index: Ac0wfCAVE6PejZ31TkWqkCAEimXeZw== Message-ID: <0970C053-2510-4B29-93F5-795C3A5A6A85@checkpoint.com> References: <376FC498-8F7F-4F11-9AED-43490EF654FB@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-cpdlp: 118fffac83867e0184ced8492c4224d435fed5f0ac Content-Type: multipart/alternative; boundary="_000_0970C05325104B2993F5795C3A5A6A85checkpointcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Cc: IPsecme WG Subject: Re: [IPsec] Issue #219 - Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 20:16:42 -0000 --_000_0970C05325104B2993F5795C3A5A6A85checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I might have put it like this if it wan't so similar to the way things are = configured on Check Point gateways :-) It makes sense to me, but I'm not sure it covers all the use cases. Imagine= a topology that is entirely mesh, except for HTTP(S) traffic that is route= d to a central site because they have some HTTP inspection gateway there. I= t's a requirement that came up a while ago. How does that fit the "either m= esh or star" topology? Also, a gateway that is part of more than one topologies (at Check Point we= call them "communities") would have to have a different view of the networ= k in these two contexts. As far as its peers in community A are concerned, = it is protecting all the networks behind any gateways in community B, but f= or members on community B, it is protecting all the addresses behind gatewa= ys in community A. On May 12, 2012, at 10:53 PM, Vishwas Manral wrote: Hi Yaov, If I udnerstand correctly, what you seem to be talking about is a Star-of-m= eshes or a mesh-of-star topology. In my view this would be dealt with in 2 different iterations of the Mesh V= PN topology. So there would be a Mesh VPN for the Star topology and a separ= ate instance of the Mesh VPN for the mesh topology. Let me know if that makes sense. I think we can state that the requirement = should allow for such iterative use cases, however at one instance we only = look at star or mesh topology. Do I make sense? Thanks, Vishwas On Sat, May 12, 2012 at 11:34 AM, Yoav Nir > wrote: Hi. I think it should be more complicated than this. The suggested solution has= a dichotomy of either a full mesh or a start topology. The requirements sh= ould cover scenarios such as a mesh within an organization connecting to a = hub to gateways outside the organization, or multiple hubs connected among = themselves in either a star or a mesh, or even certain "routes" that are ma= nually configured along with all the auto-discovery stuff. Perhaps we can capture the needed complexity by talking about groups of nod= es, where nodes that belong to a single group attempt to create a mesh amon= g them, and packets can travel between nodes that do not belong to the same= group through group intersection. I'm not sure if this level of detail is = part of the problem statement, but it's more high level than a solution. On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: > Hi, > > I would like to start off by trying to resolve the issue. The notes from = the IETF are attached below. > > Description:Some admins prefer a star topology so they can inspect traffi= c. They may not want to use this technology. > > Detail arguments: My take is similar to what Yaron and Yaov seem to state= . There is no reason to exclude star topology at all from the Problem state= ment/ requirements document. In fact both the proprietary solutions I know = of allow for such a topology. I however understand that some of the functio= nality on the Hub (of the star) could be achieved by using PFP flags in the= SPD entry. > > Suggested Resolution: State in the document that Star topology is not exc= luded from the solution. The problem of configuration is however mainly lim= ited to the Hub. For every spoke added/ deleted/ modified the configuration= on the Hub needs to be changed, which is not desirable. May be update Sect= ion 3.2 with the same too. > > Thanks, > Vishwas > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Notes from meeting minutes: > > # 219 Star topology as an admin choice > People don't need to use this if they don't wan= t to > Say this in the security considerations > Yoav Nir: > Has to be a requirement that any soluti= on can > implement different policies > Yaron Sheffer: > Agrees with Yoav, maybe becomes a use c= ase > Take this to the list > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --_000_0970C05325104B2993F5795C3A5A6A85checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I might have put it like t= his if it wan't so similar to the way things are configured on Check Point = gateways :-)

It makes sense to me, but I'm not sure it c= overs all the use cases. Imagine a topology that is entirely mesh, except f= or HTTP(S) traffic that is routed to a central site because they have some = HTTP inspection gateway there. It's a requirement that came up a while ago.= How does that fit the "either mesh or star" topology? 

=
Also, a gateway that is part of more than one topologies (at Che= ck Point we call them "communities") would have to have a different view of= the network in these two contexts. As far as its peers in community A are = concerned, it is protecting all the networks behind any gateways in communi= ty B, but for members on community B, it is protecting all the addresses be= hind gateways in community A. 

On May 12, 2012= , at 10:53 PM, Vishwas Manral wrote:

Hi Yaov,

If I udnerstand correctly,= what you seem to be talking about is a Star-of-meshes or a mesh-of-star to= pology.

In my view this would be dealt with in 2 different iteratio= ns of the Mesh VPN topology. So there would be a Mesh VPN for the Star topo= logy and a separate instance of the Mesh VPN for the mesh topology.

Let me know if that makes sense. I think we can state that the requirem= ent should allow for such iterative use cases, however at one instance we o= nly look at star or mesh topology. Do I make sense?

Thanks,
Vishw= as

On Sat, May 12, 2012 at 11:34 AM, Yoav Nir <= span dir=3D"ltr"><ynir@checkpoint.com> wrote:
Hi.

I think it should be more complicated than this. The suggested solution has= a dichotomy of either a full mesh or a start topology. The requirements sh= ould cover scenarios such as a mesh within an organization connecting to a = hub to gateways outside the organization, or multiple hubs connected among = themselves in either a star or a mesh, or even certain "routes" that are ma= nually configured along with all the auto-discovery stuff.

Perhaps we can capture the needed complexity by talking about groups of nod= es, where nodes that belong to a single group attempt to create a mesh amon= g them, and packets can travel between nodes that do not belong to the same= group through group intersection. I'm not sure if this level of detail is = part of the problem statement, but it's more high level than a solution.

On May 12, 2012, at 1:11 AM, Vishwas Manral wrote:

> Hi,
>
> I would like to start off by trying to resolve the issue. The notes fr= om the IETF are attached below.
>
> Description:Some admins prefer a star topology so they can inspect tra= ffic. They may not want to use this technology.
>
> Detail arguments: My take is similar to what Yaron and Yaov seem to st= ate. There is no reason to exclude star topology at all from the Problem st= atement/ requirements document. In fact both the proprietary solutions I kn= ow of allow for such a topology. I however understand that some of the func= tionality on the Hub (of the star) could be achieved by using PFP flags in = the SPD entry.
>
> Suggested Resolution: State in the document that Star topology is not = excluded from the solution. The problem of configuration is however mainly = limited to the Hub. For every spoke added/ deleted/ modified the configurat= ion on the Hub needs to be changed, which is not desirable. May be update S= ection 3.2 with the same too.
>
> Thanks,
> Vishwas
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Notes from meeting minutes:
>
>                   # 219 S= tar topology as an admin choice
>                     =       People don't need to use this if they don't want to >                     =       Say this in the security considerations
>                     =       Yoav Nir:
>                     =               Has to be a requirement th= at any solution can
>                     =               implement different polici= es
>                     =       Yaron Sheffer:
>                     =               Agrees with Yoav, maybe be= comes a use case
>                     =               Take this to the list
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec



= --_000_0970C05325104B2993F5795C3A5A6A85checkpointcom_-- From vishwas.ietf@gmail.com Sat May 12 13:20:45 2012 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 5680521F854C for ; Sat, 12 May 2012 13:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah00gniy8Yep for ; Sat, 12 May 2012 13:20:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A37221F8533 for ; Sat, 12 May 2012 13:20:44 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so6128727obb.31 for ; Sat, 12 May 2012 13:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ghQwhvXMyi5dGNZbW361a9cnZbNLZSJBbyWnEo2lc4=; b=LuH21bqUIOY4aHzvOPkLAVXf8+7s2Lo32WkZPdk+ciO/4x1ZvSwVql2e+kcFnR8coM jU9P/IBQYLwODug7Aj/XK2417++pAKfY0c8QarGixFl+7wGprOYQTMcic48pCLU88Xcp SA+Gwsssd32Z0pJU8kH2WApsTllFhguFs6ICGFKRkBMelpv4xNMZ5CGXgFp4MyF8LcjA FV95AznNs6+7O3LUaSXt58s6NoDN+w5J868WBE7LYG+Lt/hZdBo5pyh5NWM9HP0Hkn5T wMYH9bZ/reIBAJIvuBAxrRmYzEkE7mfkD2dt4YI1WSNyLeAJXu4ZHEsSSYOMQiTGGXI1 E3aA== MIME-Version: 1.0 Received: by 10.60.0.193 with SMTP id 1mr4159235oeg.33.1336854044108; Sat, 12 May 2012 13:20:44 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Sat, 12 May 2012 13:20:44 -0700 (PDT) In-Reply-To: <3B3F3DD4-4D25-4CE8-BE1A-0448E1E338B7@checkpoint.com> References: <3B3F3DD4-4D25-4CE8-BE1A-0448E1E338B7@checkpoint.com> Date: Sat, 12 May 2012 13:20:44 -0700 Message-ID: From: Vishwas Manral To: Yoav Nir Content-Type: multipart/alternative; boundary=e89a8fb201166a69b704bfdc96cc Cc: IPsecme WG Subject: Re: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 20:20:45 -0000 --e89a8fb201166a69b704bfdc96cc Content-Type: text/plain; charset=ISO-8859-1 Hi Yaov, I do see NAT traversal as a requirement and should be made part of the problem statement. I however do not see it as a resolution of #213 or #214. I see resolution for #218 and #211 talk about NAT. Routing is about how packet is sent to the nexthop closer to the destination, which is what this issue is about in my view. It is what determines if the destination and source are one hop away or can traverse multiple gateways along the way. So if you only allow direct routing (or through hubs), there is no way packets can traverse any other way. What you seem to suggest is that there are ways in which VoIP can traverse NAT at both the sender and the receiver. That in my view is a solution suggestion, that you seem to be giving. Can you give more details of what you mean by #214? Thanks, Vishwas On Sat, May 12, 2012 at 12:58 PM, Yoav Nir wrote: > I'm not sure I understand the suggested resolution. The biggest barrier to > direct connectivity is that the responder may be behind NAT. Is this > considered a "routing issue"? In any case, there are protocols for getting > to a responder behind a NAT. They work well enough that VoIP solutions work > pretty much everywhere where there isn't a firewall that's specifically > targeting VoIP. I think we should user them, adapt therm or profile them > for IKE/IPsec, although this does not necessarily belong in the solution > document. > > As for #214, I don't see how this is answered. If an gateway A would like > to contact a host behind gateway Z, and does so through gateway B, must > gateway B provide the addresses for gateway Z, or can it give the address > of gateway D, which will then provide the address of gateway Z? IOW, must > redirection be 1-step? > > Yoav > > On May 12, 2012, at 2:03 AM, Vishwas Manral wrote: > > > Hi, > > > > Description: Direct endpoint-to-endpoint connectivity may not be > possible. Should gateways figure things out completely or just punt > endpoints to a closer gateway? > > > > Detail Arguments: As Izaac and John Lesser pointed out this is more of a > routing issue. Though current solutions do not allow such connectivity > unless through a hub, I think from the security plane, we should not > preclude such connectivity. This could be achieved either transparently (no > IPsec component except the SPD involved), or by stitching tunnel traffic. > > > > Suggested Resolutions: Specify explicitly that issues around direct > connectivity between endpoints are more of a Routing issue. However IPsec > should not prevent such a connectivity model. > > > > Thanks, > > Vishwas > > ======================================================= > > Meeting notes: > > # 213 In use case 2.1, direct endpoint-to-endpoint > connectivity > > may not be possible > > Need to mention challenges in use cases section > > Paul: reminded that there will be a separate > requirement > > section > > # 214 Should gateways figure things out completely or > just punt > > endpoints to a closer gateway? > > Core gateway configuring is a solution, so > premature > > Also in #213 > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > --e89a8fb201166a69b704bfdc96cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yaov,

I do see NAT traversal as a requirement and should be made = part of the problem statement. I however do not see it as a resolution of #= 213 or #214. I see resolution for #218 and #211 talk about NAT.

Rout= ing is about how packet is sent to the nexthop closer to the destination, w= hich is what this issue is about in my view. It is what determines if the d= estination and source are one hop away or can traverse multiple gateways al= ong the way. So if you only allow direct routing (or through hubs), there i= s no way packets can traverse any other way.

What you seem to suggest is that there are ways in which VoIP can trave= rse NAT at both the sender and the receiver. That in my view is a solution = suggestion, that you seem to be giving.

Can you give more details of= what you mean by #214?

Thanks,
Vishwas

On Sat, May 12, 20= 12 at 12:58 PM, Yoav Nir <ynir@checkpoint.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I'm not sure I understand the suggested resolution. The biggest barrier= to direct connectivity is that the responder may be behind NAT. Is this co= nsidered a "routing issue"? =A0In any case, there are protocols f= or getting to a responder behind a NAT. They work well enough that VoIP sol= utions work pretty much everywhere where there isn't a firewall that= 9;s specifically targeting VoIP. I think we should user them, adapt therm o= r profile them for IKE/IPsec, although this does not necessarily belong in = the solution document.

As for #214, I don't see how this is answered. If an gateway A would li= ke to contact a host behind gateway Z, and does so through gateway B, must = gateway B provide the addresses for gateway Z, or can it give the address o= f gateway D, which will then provide the address of gateway Z? =A0IOW, must= redirection be 1-step?

Yoav

On May 12, 2012, at 2:03 AM, Vishwas Manral wrote:

> Hi,
>
> Description: Direct endpoint-to-endpoint connectivity may not be possi= ble. Should gateways figure things out completely or just punt endpoints to= a closer gateway?
>
> Detail Arguments: As Izaac and John Lesser pointed out this is more of= a routing issue. Though current solutions do not allow such connectivity u= nless through a hub, I think from the security plane, we should not preclud= e such connectivity. This could be achieved either transparently (no IPsec = component except the SPD involved), or by stitching tunnel traffic.
>
> Suggested Resolutions: Specify explicitly that issues around direct co= nnectivity between endpoints are more of a Routing issue. However IPsec sho= uld not prevent such a connectivity model.
>
> Thanks,
> Vishwas
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
> Meeting notes:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# 213 In use case 2.1, direct endpo= int-to-endpoint connectivity
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 may not be possible
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Need to mention ch= allenges in use cases section
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul: reminded tha= t there will be a separate requirement
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 section
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # 214 Should gateways figure thing= s out completely or just punt
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 endpoints to a closer gateway?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Core gateway confi= guring is a solution, so premature
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Also in #213
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


--e89a8fb201166a69b704bfdc96cc-- From vishwas.ietf@gmail.com Sat May 12 13:26:46 2012 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 414C321F857F for ; Sat, 12 May 2012 13:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_WANT=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8ctSv8pMW2b for ; Sat, 12 May 2012 13:26:45 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54A7E21F8546 for ; Sat, 12 May 2012 13:26:45 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so6135372obb.31 for ; Sat, 12 May 2012 13:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c2rzAoVCtc9+ClD0CXSt5WA87egaSPgAcFtyQpxMX4U=; b=rPASImqcG4HBu24vJkzc05rCSGVkpWFAuQ+kdhxKSGb02AI4+Yf/Ofj3CRlr8hqu5M fssckedJcMGLxpVHHrD3nMjbIv/T15FNE6vn366lHI6WsJy/Gb9/Wl95YgmpFarGPhWF Pg/p/rThi1mMDeXW3+XIqpFEoOM3e62G1ggmaOs7twMXKFivaFug2HibWIgFQHchbWYO Vtmd8aguCpoXneSk2w+doRzrcV78oQP46NhRZzIj2ARGRMq4PIBG+smQ4zujbAgryLju hgMklxbZ0lP3pKXhYHcgy1TYlNBua24Oz8T1zhrJTis0v2+3/EHliP4dsa/nX553e7f5 CBhg== MIME-Version: 1.0 Received: by 10.60.171.80 with SMTP id as16mr4064091oec.59.1336854404952; Sat, 12 May 2012 13:26:44 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Sat, 12 May 2012 13:26:44 -0700 (PDT) In-Reply-To: <0970C053-2510-4B29-93F5-795C3A5A6A85@checkpoint.com> References: <376FC498-8F7F-4F11-9AED-43490EF654FB@checkpoint.com> <0970C053-2510-4B29-93F5-795C3A5A6A85@checkpoint.com> Date: Sat, 12 May 2012 13:26:44 -0700 Message-ID: From: Vishwas Manral To: Yoav Nir Content-Type: multipart/alternative; boundary=bcaec54c5270ec735404bfdcab07 Cc: IPsecme WG Subject: Re: [IPsec] Issue #219 - Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 20:26:46 -0000 --bcaec54c5270ec735404bfdcab07 Content-Type: text/plain; charset=ISO-8859-1 Hi Yaov, Perfect. We are on the same page here. The way I see it is we treat it as a Mesh topology. The hub spoke tunnels are permanent, with temporary and on-demand (based on data/ time/ activity) spoke to spoke connectivity. This way we do not have the overload of excess configurations on the spoke, while still allowing mesh connectivity. I could specify that as a sub usecase of the Mesh Topology. Thanks, Vishwas On Sat, May 12, 2012 at 1:16 PM, Yoav Nir wrote: > I might have put it like this if it wan't so similar to the way things are > configured on Check Point gateways :-) > > It makes sense to me, but I'm not sure it covers all the use cases. > Imagine a topology that is entirely mesh, except for HTTP(S) traffic that > is routed to a central site because they have some HTTP inspection gateway > there. It's a requirement that came up a while ago. How does that fit the > "either mesh or star" topology? > > Also, a gateway that is part of more than one topologies (at Check Point > we call them "communities") would have to have a different view of the > network in these two contexts. As far as its peers in community A are > concerned, it is protecting all the networks behind any gateways in > community B, but for members on community B, it is protecting all the > addresses behind gateways in community A. > > On May 12, 2012, at 10:53 PM, Vishwas Manral wrote: > > Hi Yaov, > > If I udnerstand correctly, what you seem to be talking about is a > Star-of-meshes or a mesh-of-star topology. > > In my view this would be dealt with in 2 different iterations of the Mesh > VPN topology. So there would be a Mesh VPN for the Star topology and a > separate instance of the Mesh VPN for the mesh topology. > > Let me know if that makes sense. I think we can state that the requirement > should allow for such iterative use cases, however at one instance we only > look at star or mesh topology. Do I make sense? > > Thanks, > Vishwas > > On Sat, May 12, 2012 at 11:34 AM, Yoav Nir wrote: > >> Hi. >> >> I think it should be more complicated than this. The suggested solution >> has a dichotomy of either a full mesh or a start topology. The requirements >> should cover scenarios such as a mesh within an organization connecting to >> a hub to gateways outside the organization, or multiple hubs connected >> among themselves in either a star or a mesh, or even certain "routes" that >> are manually configured along with all the auto-discovery stuff. >> >> Perhaps we can capture the needed complexity by talking about groups of >> nodes, where nodes that belong to a single group attempt to create a mesh >> among them, and packets can travel between nodes that do not belong to the >> same group through group intersection. I'm not sure if this level of detail >> is part of the problem statement, but it's more high level than a solution. >> >> On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: >> >> > Hi, >> > >> > I would like to start off by trying to resolve the issue. The notes >> from the IETF are attached below. >> > >> > Description:Some admins prefer a star topology so they can inspect >> traffic. They may not want to use this technology. >> > >> > Detail arguments: My take is similar to what Yaron and Yaov seem to >> state. There is no reason to exclude star topology at all from the Problem >> statement/ requirements document. In fact both the proprietary solutions I >> know of allow for such a topology. I however understand that some of the >> functionality on the Hub (of the star) could be achieved by using PFP flags >> in the SPD entry. >> > >> > Suggested Resolution: State in the document that Star topology is not >> excluded from the solution. The problem of configuration is however mainly >> limited to the Hub. For every spoke added/ deleted/ modified the >> configuration on the Hub needs to be changed, which is not desirable. May >> be update Section 3.2 with the same too. >> > >> > Thanks, >> > Vishwas >> > =========================================================== >> > Notes from meeting minutes: >> > >> > # 219 Star topology as an admin choice >> > People don't need to use this if they don't >> want to >> > Say this in the security considerations >> > Yoav Nir: >> > Has to be a requirement that any >> solution can >> > implement different policies >> > Yaron Sheffer: >> > Agrees with Yoav, maybe becomes a use >> case >> > Take this to the list >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> >> > > --bcaec54c5270ec735404bfdcab07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yaov,

Perfect. We are on the same page here.

The way I see= it is we treat it as a Mesh topology. The hub spoke tunnels are permanent,= with temporary and on-demand (based on data/ time/ activity) spoke to spok= e connectivity. This way we do not have the overload of excess configuratio= ns on the spoke, while still allowing mesh connectivity.

I could specify that as a sub usecase of the Mesh Topology.

Than= ks,
Vishwas

On Sat, May 12, 2012 at 1:= 16 PM, Yoav Nir <ynir@checkpoint.com> wrote:
I might = have put it like this if it wan't so similar to the way things are conf= igured on Check Point gateways :-)

It makes sense to me, but I'm not sure it covers all the= use cases. Imagine a topology that is entirely mesh, except for HTTP(S) tr= affic that is routed to a central site because they have some HTTP inspecti= on gateway there. It's a requirement that came up a while ago. How does= that fit the "either mesh or star" topology?=A0

Also, a gateway that is part of more than one topologie= s (at Check Point we call them "communities") would have to have = a different view of the network in these two contexts. As far as its peers = in community A are concerned, it is protecting all the networks behind any = gateways in community B, but for members on community B, it is protecting a= ll the addresses behind gateways in community A.=A0

On May 12, 2012, at 10:53 PM, Vis= hwas Manral wrote:

Hi Yaov,

If I = udnerstand correctly, what you seem to be talking about is a Star-of-meshes= or a mesh-of-star topology.

In my view this would be dealt with in 2 different iterations of the Me= sh VPN topology. So there would be a Mesh VPN for the Star topology and a s= eparate instance of the Mesh VPN for the mesh topology.

Let me know if that makes sense. I think we can state that the requirem= ent should allow for such iterative use cases, however at one instance we o= nly look at star or mesh topology. Do I make sense?

Thanks,
Vishwas

On Sat, May 12, 2012 at 11:34 AM, Yoav Nir <= span dir=3D"ltr"><ynir@checkpoint.com> wrote:
Hi.

I think it should be more complicated than this. The suggested solution has= a dichotomy of either a full mesh or a start topology. The requirements sh= ould cover scenarios such as a mesh within an organization connecting to a = hub to gateways outside the organization, or multiple hubs connected among = themselves in either a star or a mesh, or even certain "routes" t= hat are manually configured along with all the auto-discovery stuff.

Perhaps we can capture the needed complexity by talking about groups of nod= es, where nodes that belong to a single group attempt to create a mesh amon= g them, and packets can travel between nodes that do not belong to the same= group through group intersection. I'm not sure if this level of detail= is part of the problem statement, but it's more high level than a solu= tion.

On May 12, 2012, at 1:11 AM, Vishwas Manral wrote:

> Hi,
>
> I would like to start off by trying to resolve the issue. The notes fr= om the IETF are attached below.
>
> Description:Some admins prefer a star topology so they can inspect tra= ffic. They may not want to use this technology.
>
> Detail arguments: My take is similar to what Yaron and Yaov seem to st= ate. There is no reason to exclude star topology at all from the Problem st= atement/ requirements document. In fact both the proprietary solutions I kn= ow of allow for such a topology. I however understand that some of the func= tionality on the Hub (of the star) could be achieved by using PFP flags in = the SPD entry.
>
> Suggested Resolution: State in the document that Star topology is not = excluded from the solution. The problem of configuration is however mainly = limited to the Hub. For every spoke added/ deleted/ modified the configurat= ion on the Hub needs to be changed, which is not desirable. May be update S= ection 3.2 with the same too.
>
> Thanks,
> Vishwas
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Notes from meeting minutes:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # 219 Star topology as an admin ch= oice
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 People don't n= eed to use this if they don't want to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Say this in the se= curity considerations
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yoav Nir:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ha= s to be a requirement that any solution can
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 im= plement different policies
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yaron Sheffer:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ag= rees with Yoav, maybe becomes a use case
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ta= ke this to the list
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/ipsec




--bcaec54c5270ec735404bfdcab07-- From vishwas.ietf@gmail.com Mon May 14 14:05:55 2012 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 CDE0021F88C0 for ; Mon, 14 May 2012 14:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cJVY1ytuif4 for ; Mon, 14 May 2012 14:05:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3865921F88BF for ; Mon, 14 May 2012 14:05:55 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so9644013obb.31 for ; Mon, 14 May 2012 14:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=t7ddDe9ZQLKwm/K2cB9DxozjzLEEODkztLZTW1UWl0k=; b=N8Nf01eqq1fAKZ0vd+fTDp+T4UDlIzbVkajyVYUnVAm1gde2d19fIHKXDDJAfQjd/W c2u6B8p9X1kMPY9e2ujAa4/9SOGxWWBq1gAA2VObQMBwUyyujUTo56LkRKrB28Z4a9Xu MXrm5/XhuErXX1GdV7jFl+Fdz/H8uS/o1Xdl6FFAab4CFnaUot5P/ot8DJwUF5mH5zjp 0X5wnpnAtv6WtMDQraMHKzBWCfNBHiCCfYBBT6Xit8lrCiBP5dV8+DYvCXLQNW1OMUS3 aTl/oYpoV5DG+tPBH+Ihd3aWCKmaTJMZAARkHoDmi8LJheL1lb9vmoqLxojGFN37jgTv TQNQ== MIME-Version: 1.0 Received: by 10.182.31.11 with SMTP id w11mr5040441obh.64.1337029554891; Mon, 14 May 2012 14:05:54 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Mon, 14 May 2012 14:05:54 -0700 (PDT) Date: Mon, 14 May 2012 14:05:54 -0700 Message-ID: From: Vishwas Manral To: IPsecme WG Content-Type: multipart/alternative; boundary=14dae93a1495ac6d3104c0057304 Subject: [IPsec] #213 - Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 21:05:56 -0000 --14dae93a1495ac6d3104c0057304 Content-Type: text/plain; charset=ISO-8859-1 Hi, Description: What if an endpoint has multiple interfaces and/or is mobile? Which tunnels should be torn down as this endpoint moves around, sometimes behind a gateway and sometimes not? Detail Arguments: From what I understand if we are talking of mobile end points, there are 2 ways we could have mobility: 1. Behind a gateway which is moving. 2. Device itself is moving. The current tunnel mechanisms I know of is tied to an interface. If there is a choice of multiple mobile endpoint interfaces, we should allow for the ability to maintain the tunnel. I am unsure of the above description of gateways? Could someone explain the same please? Suggested Resolution: We need to clarify what the gateway functionality in the description means. We then need to clarify the problem statement with the use cases. Thanks, Vishwas ========================================================== # 216 Multiple interfaces or mobile endpoint Solution-specific or requirement Tero: Is there a use case where the end point moves from outside the gateway to inside Paul: Mobility is a use case, but not just for multiple interfaces Steve: Either a new use case, or within the existing ones ========================================================== --14dae93a1495ac6d3104c0057304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Description: What if an endpoint has multiple interfaces and/or = is mobile? Which=20 tunnels should be torn down as this endpoint moves around, sometimes=20 behind a gateway and sometimes not?

Detail Arguments: From what I understand if we are talking of mob= ile end points, there are 2 ways we could have mobility:

=A0=A0= =A0 1. Behind a gateway which is moving.

=A0=A0=A0=A0 2. Device itsel= f is moving.=A0

The current tunnel mechanisms I know of is tied to an interface. If ther= e is a choice of multiple mobile endpoint interfaces, we should allow for t= he ability to maintain the tunnel.

I am unsure of the above descripti= on of gateways? Could someone explain the same please?

Suggested Resolution: We need to clarify what the gateway fun= ctionality in the description means. We then need to clarify the problem st= atement with the use cases.

Thanks,
Vishwas

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0 # 216 M= ultiple interfaces or mobile endpoint
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Sol= ution-specific or requirement
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tero: Is th= ere a use case where the end point moves from
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 outside the gateway = to inside
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Paul: Mobility is a use case, b= ut not just for multiple
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 interfaces
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Steve: Either a n= ew use case, or within the existing ones

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--14dae93a1495ac6d3104c0057304-- From ynir@checkpoint.com Mon May 14 14:14:31 2012 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 CBEF621F88DA for ; Mon, 14 May 2012 14:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.414 X-Spam-Level: X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cvlPu+lE7Zz for ; Mon, 14 May 2012 14:14:31 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E0DE921F88F2 for ; Mon, 14 May 2012 14:14:30 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4ELENuk021430; Tue, 15 May 2012 00:14:23 +0300 X-CheckPoint: {4FB182DE-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 15 May 2012 00:14:21 +0300 From: Yoav Nir To: Vishwas Manral Date: Tue, 15 May 2012 00:14:18 +0300 Thread-Topic: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity Thread-Index: Ac0yFoej/NRV4KjsRlCqi5Njd19QUA== Message-ID: References: <3B3F3DD4-4D25-4CE8-BE1A-0448E1E338B7@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 21:14:31 -0000 On May 12, 2012, at 11:20 PM, Vishwas Manral wrote: > Hi Yaov, >=20 > I do see NAT traversal as a requirement and should be made part of the pr= oblem statement. I however do not see it as a resolution of #213 or #214. I= see resolution for #218 and #211 talk about NAT. >=20 > Routing is about how packet is sent to the nexthop closer to the destinat= ion, which is what this issue is about in my view. It is what determines if= the destination and source are one hop away or can traverse multiple gatew= ays along the way. So if you only allow direct routing (or through hubs), t= here is no way packets can traverse any other way. >=20 > What you seem to suggest is that there are ways in which VoIP can travers= e NAT at both the sender and the receiver. That in my view is a solution su= ggestion, that you seem to be giving. >=20 > Can you give more details of what you mean by #214? #214 comes from a question that was raised. It assumes that part of the sol= ution would be nodes that learn about the topology from other nodes. The question was, is discovering the topology an iterative process, or a on= e-shot process. Suppose node A asks node B, but node B does not have the in= formation (but knows where to get it). Does node B tell node A to go ask no= de C, or does it ask node C itself, and relay the answer to node A? The text currently does not mandate one or the other. Yoav From vishwas.ietf@gmail.com Mon May 14 14:56:52 2012 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 9F9DF21F88ED for ; Mon, 14 May 2012 14:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbIo-BrECiZ9 for ; Mon, 14 May 2012 14:56:52 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A621D21F88EB for ; Mon, 14 May 2012 14:56:51 -0700 (PDT) Received: by yhq56 with SMTP id 56so5772932yhq.31 for ; Mon, 14 May 2012 14:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O6XVTKn9YPUD63I100GhDFrpbp+WfYp3sY6+cq5yP1E=; b=ltlDbM1wkqp1Ecao+Bw8W9H3Wz+LpXYVLTP0oI1pWRXGK1J3AGWBwqoVlfhXpymyJd J1n59NTNpJUz0uPa99JRlaG5PXkW0I+DBQ8Ny3ZmToIXCnmLWzczSGTHmT0skxoCGQ5B cZkX0tiCGwv6W7+NTOTXTTl8T6G8jXagIWKgKTRGGwgptHVFFW8/et7WDon14z/JPLj8 P2029pooIBeH9VJ3joU5QV0S4zQ4Syc4af5wyuX2fQPLTxX/qvBAXu7a6zLLFatYbLQ6 43P8cBk+d9A6UAB+OZlW8IeG1Nei4WrJVq/YWmbremWBJiRnKFMEjIra6QietJLHrYy0 NuWQ== MIME-Version: 1.0 Received: by 10.60.20.3 with SMTP id j3mr2130165oee.43.1337032609799; Mon, 14 May 2012 14:56:49 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Mon, 14 May 2012 14:56:49 -0700 (PDT) In-Reply-To: References: <3B3F3DD4-4D25-4CE8-BE1A-0448E1E338B7@checkpoint.com> Date: Mon, 14 May 2012 14:56:49 -0700 Message-ID: From: Vishwas Manral To: Yoav Nir Content-Type: multipart/alternative; boundary=e89a8fb20762c29f5c04c006290f Cc: IPsecme WG Subject: Re: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 21:56:52 -0000 --e89a8fb20762c29f5c04c006290f Content-Type: text/plain; charset=ISO-8859-1 Hi Yaov, Thanks for the information. What you seem to be talking about is iterative topology discovery, and not data plane packet forwarding. I will try to clarify it further. Thanks again, Vishwas On Mon, May 14, 2012 at 2:14 PM, Yoav Nir wrote: > > On May 12, 2012, at 11:20 PM, Vishwas Manral wrote: > > > Hi Yaov, > > > > I do see NAT traversal as a requirement and should be made part of the > problem statement. I however do not see it as a resolution of #213 or #214. > I see resolution for #218 and #211 talk about NAT. > > > > Routing is about how packet is sent to the nexthop closer to the > destination, which is what this issue is about in my view. It is what > determines if the destination and source are one hop away or can traverse > multiple gateways along the way. So if you only allow direct routing (or > through hubs), there is no way packets can traverse any other way. > > > > What you seem to suggest is that there are ways in which VoIP can > traverse NAT at both the sender and the receiver. That in my view is a > solution suggestion, that you seem to be giving. > > > > Can you give more details of what you mean by #214? > > #214 comes from a question that was raised. It assumes that part of the > solution would be nodes that learn about the topology from other nodes. > > The question was, is discovering the topology an iterative process, or a > one-shot process. Suppose node A asks node B, but node B does not have the > information (but knows where to get it). Does node B tell node A to go ask > node C, or does it ask node C itself, and relay the answer to node A? > > The text currently does not mandate one or the other. > > Yoav > > > --e89a8fb20762c29f5c04c006290f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yaov,

Thanks for the information.

What you seem to be talk= ing about is iterative topology discovery, and not data plane packet forwar= ding. I will try to clarify it further.

Thanks again,
Vishwas

On Mon, May 14, 2012 at 2:14 PM, Yoav Nir <ynir@checkpoint.com> wrote:

On May 12, 2012, at 11:20 PM, Vishwas Manral wrote:

> Hi Yaov,
>
> I do see NAT traversal as a requirement and should be made part of the= problem statement. I however do not see it as a resolution of #213 or #214= . I see resolution for #218 and #211 talk about NAT.
>
> Routing is about how packet is sent to the nexthop closer to the desti= nation, which is what this issue is about in my view. It is what determines= if the destination and source are one hop away or can traverse multiple ga= teways along the way. So if you only allow direct routing (or through hubs)= , there is no way packets can traverse any other way.
>
> What you seem to suggest is that there are ways in which VoIP can trav= erse NAT at both the sender and the receiver. That in my view is a solution= suggestion, that you seem to be giving.
>
> Can you give more details of what you mean by #214?

#214 comes from a question that was raised. It assumes that part of t= he solution would be nodes that learn about the topology from other nodes.<= br>
The question was, is discovering the topology an iterative process, or a on= e-shot process. Suppose node A asks node B, but node B does not have the in= formation (but knows where to get it). Does node B tell node A to go ask no= de C, or does it ask node C itself, and relay the answer to node A?

The text currently does not mandate one or the other.

Yoav



--e89a8fb20762c29f5c04c006290f-- From mcr@sandelman.ca Tue May 15 10:57:55 2012 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 9F77521F881C for ; Tue, 15 May 2012 10:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.212 X-Spam-Level: X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_11=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8admeSsz24tD for ; Tue, 15 May 2012 10:57:55 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0877721F8819 for ; Tue, 15 May 2012 10:57:55 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 9AB9D8398; Tue, 15 May 2012 13:56:37 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 057F098B98; Tue, 15 May 2012 13:57:54 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 029BB98281; Tue, 15 May 2012 13:57:54 -0400 (EDT) From: Michael Richardson To: Vishwas Manral In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 15 May 2012 13:57:53 -0400 Message-ID: <12713.1337104673@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IPsecme WG Subject: Re: [IPsec] #213 - Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 17:57:55 -0000 <#part sign=pgpmime> >>>>> "Vishwas" == Vishwas Manral writes: Vishwas> Hi, Vishwas> Description: What if an endpoint has multiple interfaces Vishwas> and/or is mobile? Which tunnels should be torn down as Vishwas> this endpoint moves around, sometimes behind a gateway and Vishwas> sometimes not? Vishwas> Detail Arguments: From what I understand if we are talking Vishwas> of mobile end points, there are 2 ways we could have Vishwas> mobility: Vishwas> 1. Behind a gateway which is moving. Vishwas> 2. Device itself is moving. I think the focus on "movement" and "mobility" is wrong. Instead, focus on connectivity. Tero (and I) asked the question about a device which was, from a topological point of view, originally connected to "outside" (on the public Internet, effectively), and had built up a mesh. There is a connectivity change (let's not worry about how, why, but I can describe a dozen ways if you like, and not all of them involve 3G or 802.11), and the device is now connected behind a gateway which is also part of the mesh. Let's assume a multiple star topology situation. (We draw these on napkins in Paris. I promise to re-read the problem statment to learn if this scenario has been named) Let's say that said device ("A") previously was part of VPN-Concentrator X. (It was perhaps part of that star via NAT-T transport). Packets flowed from A to device B. Device B is located on network B-location, and is served by B-gateway, and these packets flowed via VPN-Concentrator X. X attempts to ask A to connect directly to B-gateway so that packets from A<->B take the shortcut. A presently has connectivity *on* "network B-location". That is, A and B are in fact, co-located (but might not be on the same link). 1) Is there a requirement that B-gateway must be able to make a bypass connection to another spoke, from *behind* B? 2) Many would feel that actually there should be *no* IPsec tunnel between A and B, as they are presently co-located. Do we have a requirement that the policy between two spokes (a "bypass") could in fact be "clear"? -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From yaronf.ietf@gmail.com Sat May 19 05:53:10 2012 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 6D0D621F85A4 for ; Sat, 19 May 2012 05:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.885 X-Spam-Level: X-Spam-Status: No, score=-98.885 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MANGLED_WANT=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAEVgz7xKyvQ for ; Sat, 19 May 2012 05:53:09 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA3521F85B1 for ; Sat, 19 May 2012 05:53:09 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so803680wib.13 for ; Sat, 19 May 2012 05:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ddQCQjEHoCiBxhHmsiSEi/WeY7BuYFB55C9VqWnflJQ=; b=hH75uGevj3/9DZYvbvYfYAN8x6xLpCbIFSyHH39vviviBwiNFSqnQanbDl4HjNxot6 iHCPuOay/oqzdZnduLPhOWOd07+m9EbsBqLbQhEJbPfZBWGK93w4mmZ8RidSL7nLLLPa t8r7RizkFLtCzNepifQqBKL1w6cEyZMACflMapx3t2DqBgel/mfJXmOAdQRMKaDqnVh4 rKs/UJDnMgnX8DKV7DFoiBMEQRFc4tJTo8T4mF/u5MOrILfZ0U2EqNlt0AnCnBA6StR1 poh8GTz+JsgqvLGMpQiSQJDLLf+a1vC9cvz5Kev8PH6C/1IR6X3X4yXAK3uJ5CDgwJzw VjUw== Received: by 10.180.109.197 with SMTP id hu5mr10046560wib.8.1337431988533; Sat, 19 May 2012 05:53:08 -0700 (PDT) Received: from [10.0.0.3] ([109.64.171.110]) by mx.google.com with ESMTPS id eb8sm9191044wib.11.2012.05.19.05.53.07 (version=SSLv3 cipher=OTHER); Sat, 19 May 2012 05:53:07 -0700 (PDT) Message-ID: <4FB797B0.3050607@gmail.com> Date: Sat, 19 May 2012 15:53:04 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Vishwas Manral References: <376FC498-8F7F-4F11-9AED-43490EF654FB@checkpoint.com> <0970C053-2510-4B29-93F5-795C3A5A6A85@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Yoav Nir Subject: Re: [IPsec] Issue #219 - Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 12:53:10 -0000 Hi Vishwas, Yoav, Check Point (IIRC) supports "communities" of IPsec endpoints, arranged either as a star or a full mesh. This is nice and simple to configure but obviously does not cover all use cases. Some networks cannot be represented either as a full mesh or as a simple star. Trying to shoehorn the more complex networks into "star of meshes" or "mesh of stars" topologies would not solve the general problem either, and instead would complicate things greatly by having to deal with multi-layer routes. So stars and full meshes are OK as common use cases. But as/when we move into requirements, I would suggest that we abandon them in favor of generic networks/graphs of IPsec endpoints. And implicitly, generic routing within such networks. Thanks, Yaron On 05/12/2012 11:26 PM, Vishwas Manral wrote: > Hi Yaov, > > Perfect. We are on the same page here. > > The way I see it is we treat it as a Mesh topology. The hub spoke > tunnels are permanent, with temporary and on-demand (based on data/ > time/ activity) spoke to spoke connectivity. This way we do not have the > overload of excess configurations on the spoke, while still allowing > mesh connectivity. > > I could specify that as a sub usecase of the Mesh Topology. > > Thanks, > Vishwas > > On Sat, May 12, 2012 at 1:16 PM, Yoav Nir > wrote: > > I might have put it like this if it wan't so similar to the way > things are configured on Check Point gateways :-) > > It makes sense to me, but I'm not sure it covers all the use cases. > Imagine a topology that is entirely mesh, except for HTTP(S) traffic > that is routed to a central site because they have some HTTP > inspection gateway there. It's a requirement that came up a while > ago. How does that fit the "either mesh or star" topology? > > Also, a gateway that is part of more than one topologies (at Check > Point we call them "communities") would have to have a different > view of the network in these two contexts. As far as its peers in > community A are concerned, it is protecting all the networks behind > any gateways in community B, but for members on community B, it is > protecting all the addresses behind gateways in community A. > > On May 12, 2012, at 10:53 PM, Vishwas Manral wrote: > >> Hi Yaov, >> >> If I udnerstand correctly, what you seem to be talking about is a >> Star-of-meshes or a mesh-of-star topology. >> >> In my view this would be dealt with in 2 different iterations of >> the Mesh VPN topology. So there would be a Mesh VPN for the Star >> topology and a separate instance of the Mesh VPN for the mesh >> topology. >> >> Let me know if that makes sense. I think we can state that the >> requirement should allow for such iterative use cases, however at >> one instance we only look at star or mesh topology. Do I make sense? >> >> Thanks, >> Vishwas >> >> On Sat, May 12, 2012 at 11:34 AM, Yoav Nir > > wrote: >> >> Hi. >> >> I think it should be more complicated than this. The suggested >> solution has a dichotomy of either a full mesh or a start >> topology. The requirements should cover scenarios such as a >> mesh within an organization connecting to a hub to gateways >> outside the organization, or multiple hubs connected among >> themselves in either a star or a mesh, or even certain >> "routes" that are manually configured along with all the >> auto-discovery stuff. >> >> Perhaps we can capture the needed complexity by talking about >> groups of nodes, where nodes that belong to a single group >> attempt to create a mesh among them, and packets can travel >> between nodes that do not belong to the same group through >> group intersection. I'm not sure if this level of detail is >> part of the problem statement, but it's more high level than a >> solution. >> >> On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: >> >> > Hi, >> > >> > I would like to start off by trying to resolve the issue. >> The notes from the IETF are attached below. >> > >> > Description:Some admins prefer a star topology so they can >> inspect traffic. They may not want to use this technology. >> > >> > Detail arguments: My take is similar to what Yaron and Yaov >> seem to state. There is no reason to exclude star topology at >> all from the Problem statement/ requirements document. In fact >> both the proprietary solutions I know of allow for such a >> topology. I however understand that some of the functionality >> on the Hub (of the star) could be achieved by using PFP flags >> in the SPD entry. >> > >> > Suggested Resolution: State in the document that Star >> topology is not excluded from the solution. The problem of >> configuration is however mainly limited to the Hub. For every >> spoke added/ deleted/ modified the configuration on the Hub >> needs to be changed, which is not desirable. May be update >> Section 3.2 with the same too. >> > >> > Thanks, >> > Vishwas >> > =========================================================== >> > Notes from meeting minutes: >> > >> > # 219 Star topology as an admin choice >> > People don't need to use this if >> they don't want to >> > Say this in the security >> considerations >> > Yoav Nir: >> > Has to be a requirement >> that any solution can >> > implement different policies >> > Yaron Sheffer: >> > Agrees with Yoav, maybe >> becomes a use case >> > Take this to the list >> > _______________________________________________ >> > 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 ynir@checkpoint.com Sat May 19 11:47:12 2012 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 62A5021F85EF for ; Sat, 19 May 2012 11:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27QaQUkSnAcb for ; Sat, 19 May 2012 11:47:11 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBC021F850D for ; Sat, 19 May 2012 11:47:10 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4JIl6HL024269; Sat, 19 May 2012 21:47:06 +0300 X-CheckPoint: {4FB7F794-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 19 May 2012 21:47:04 +0300 From: Yoav Nir To: Yaron Sheffer Date: Sat, 19 May 2012 21:47:05 +0300 Thread-Topic: [IPsec] Issue #219 - Star topology as an admin choice Thread-Index: Ac0178h2cQWgIGdwTmaJN6RxwRfCNw== Message-ID: References: <376FC498-8F7F-4F11-9AED-43490EF654FB@checkpoint.com> <0970C053-2510-4B29-93F5-795C3A5A6A85@checkpoint.com> <4FB797B0.3050607@gmail.com> In-Reply-To: <4FB797B0.3050607@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Issue #219 - Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 18:47:12 -0000 On May 19, 2012, at 3:53 PM, Yaron Sheffer wrote: > Hi Vishwas, Yoav, >=20 > Check Point (IIRC) supports "communities" of IPsec endpoints, arranged=20 > either as a star or a full mesh. This is nice and simple to configure=20 > but obviously does not cover all use cases. Some networks cannot be=20 > represented either as a full mesh or as a simple star. More complex topologies can be achieved by having some IPsec endpoints be m= embers of more than one community. That way, traffic can go from any member= of one community to any member of another community through the common mem= ber. I think multiple communities with shared members does cover all the us= e cases, because taken to the edge case, an IPsec tunnel is a mesh with two= members. Of course, if you configure your VPN as a large number of communities, each= with two members, you've really lost all traces of simplicity, and you hav= e to configure as much as simple IPsec, but a more common case would be sev= eral large communities, each either a star or a mesh, and then either an en= dpoint that is shared between them, or tunnels (2-member communities) to co= nnect each pair of communities. While the configuration for a single star or mesh community is relatively s= imple, this moves the complexity to those "connecting members". They need t= o know what is allowed to pass between the different communities. Yoav From yaronf.ietf@gmail.com Sat May 19 12:23:57 2012 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 4B38E21F8648 for ; Sat, 19 May 2012 12:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.242 X-Spam-Level: X-Spam-Status: No, score=-101.242 tagged_above=-999 required=5 tests=[AWL=2.357, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngb3bCPUkrEL for ; Sat, 19 May 2012 12:23:56 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D26A21F8645 for ; Sat, 19 May 2012 12:23:56 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2614627wgb.13 for ; Sat, 19 May 2012 12:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dP/xFINi66PY1u9bDoLWm96DL133WTGm51Cw/DNC3D8=; b=aM7e9BCJ70k/I6PlgbRZdqpXlFfrjdElG0VRTPf/noUjcfVvrJBgWrhrUr4aY0Giz/ Hdve3+zrn9rmkxO2TwDoTcR7Hi2wom95BxkNwP1dROJxnDYWRDz4iUmof2gFb+irIchm nrzeIqfJygWve7J162pvkY9aezsfXAYcAnEMMR726JBctBUDygZoNcy6/74l7log93qk rlNjR5Xf06HbQgQjY4OqkOvWYBOqZLlh89uUtY8PixIPOjplnNAGaD/nglqkCLQ29+Nm e8HfzMaVS6O5nJ1ucONt5MyoSoia2Kr1rBffQPCoZme6aHG6gPbBk/14BQSEM2bhbZhH iOww== Received: by 10.216.134.41 with SMTP id r41mr6883256wei.13.1337455435773; Sat, 19 May 2012 12:23:55 -0700 (PDT) Received: from [10.0.0.3] ([109.64.171.110]) by mx.google.com with ESMTPS id fo7sm11832321wib.9.2012.05.19.12.23.54 (version=SSLv3 cipher=OTHER); Sat, 19 May 2012 12:23:55 -0700 (PDT) Message-ID: <4FB7F349.1090907@gmail.com> Date: Sat, 19 May 2012 22:23:53 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoav Nir References: <376FC498-8F7F-4F11-9AED-43490EF654FB@checkpoint.com> <0970C053-2510-4B29-93F5-795C3A5A6A85@checkpoint.com> <4FB797B0.3050607@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Issue #219 - Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 19:23:57 -0000 But this quickly reduces to hierarchical routing: consider 3 "communities", C1, C2, C3. Connectivity is C1 == C2 == C3 (i.e. no direct connectivity between C1 and C3). The "connecting member" between C1 and C2 needs to know everybody in C1 and C2 - that's clear. But it also needs to know endpoints in C3 in order to route traffic from C1 to C3 (assuming we prefer end-to-end protection of traffic). So these "connecting members" either need to know the complete topology, or you have some sort of routing/discovery between "connecting members". The end result is a 2-level hierarchy: community-internal traffic is managed by the community, while cross-community traffic is managed (somehow) between connecting members. To repeat: I suggest that we do *not* take this path. Thanks, Yaron On 05/19/2012 09:47 PM, Yoav Nir wrote: > > On May 19, 2012, at 3:53 PM, Yaron Sheffer wrote: > >> Hi Vishwas, Yoav, >> >> Check Point (IIRC) supports "communities" of IPsec endpoints, arranged >> either as a star or a full mesh. This is nice and simple to configure >> but obviously does not cover all use cases. Some networks cannot be >> represented either as a full mesh or as a simple star. > > More complex topologies can be achieved by having some IPsec endpoints be members of more than one community. That way, traffic can go from any member of one community to any member of another community through the common member. I think multiple communities with shared members does cover all the use cases, because taken to the edge case, an IPsec tunnel is a mesh with two members. > > Of course, if you configure your VPN as a large number of communities, each with two members, you've really lost all traces of simplicity, and you have to configure as much as simple IPsec, but a more common case would be several large communities, each either a star or a mesh, and then either an endpoint that is shared between them, or tunnels (2-member communities) to connect each pair of communities. > > While the configuration for a single star or mesh community is relatively simple, this moves the complexity to those "connecting members". They need to know what is allowed to pass between the different communities. > > Yoav > From ynir@checkpoint.com Sun May 20 23:49:11 2012 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 4C25221F84C8; Sun, 20 May 2012 23:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlxlP4V3gi+B; Sun, 20 May 2012 23:49:10 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C570B21F84B2; Sun, 20 May 2012 23:49:09 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4L6n7DO029256; Mon, 21 May 2012 09:49:07 +0300 X-CheckPoint: {4FB9F238-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 21 May 2012 09:49:04 +0300 From: Yoav Nir To: IPsecme WG , "hokey@ietf.org" Date: Mon, 21 May 2012 09:49:04 +0300 Thread-Topic: I-D Action: draft-nir-ipsecme-erx-04.txt Thread-Index: Ac03Hc9GIyqmViIcQiuYQ0FVCZM6Mg== Message-ID: <3FDFD074-2961-4261-86DD-474FDCF3D01C@checkpoint.com> References: <20120521055357.5840.39762.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11b486c5eb296ddb1bd8ccba9da6fa6393dc3ccd6f Content-Type: multipart/alternative; boundary="_000_3FDFD0742961426186DD474FDCF3D01Ccheckpointcom_" MIME-Version: 1.0 Subject: [IPsec] Fwd: I-D Action: draft-nir-ipsecme-erx-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 06:49:11 -0000 --_000_3FDFD0742961426186DD474FDCF3D01Ccheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I have just submitted a new version. This one contains some changes based o= n a review by Yaron Sheffer. It's mostly clarifications. The one bit-on-the-wire change is adding back t= he IDi payload (although it contains redundant information) to make the mod= ified handshake less different. Yoav Begin forwarded message: From: "internet-drafts@ietf.org" > Subject: I-D Action: draft-nir-ipsecme-erx-04.txt Date: May 21, 2012 8:53:57 AM GMT+03:00 To: "i-d-announce@ietf.org" > Reply-To: "internet-drafts@ietf.org" > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : An IKEv2 Extension for Supporting ERP Author(s) : Yoav Nir Qin Wu Filename : draft-nir-ipsecme-erx-04.txt Pages : 8 Date : 2012-05-20 This document describes an extension to the IKEv2 protocol that allows an IKE Security Association (SA) to be created and authenticated using the EAP Re-authentication Protocol extension as described in RFC 5296bis. NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with the RFC number assigned to draft-ietf-hokey-rfc5296bis (now in the RFC Editor queue) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Scanned by Check Point Total Security Gateway. --_000_3FDFD0742961426186DD474FDCF3D01Ccheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

I ha= ve just submitted a new version. This one contains some changes based on a = review by Yaron Sheffer.

It's mostly clarification= s. The one bit-on-the-wire change is adding back the IDi payload (although = it contains redundant information) to make the modified handshake less diff= erent.

Yoav


Begin forwarded message:

Subject: I-D Action: draft-nir-ipsecme-erx-04.txt=
Date: May 21, 2012 8:53:57 AM GMT+03= :00


A New Internet-Draft is a= vailable from the on-line Internet-Drafts directories.

Title   &nb= sp;       : An IKEv2 Extension for Suppo= rting ERP
Author(s)       : Yoav Nir
  = ;            &n= bsp;          Qin Wu
<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> Filename &n= bsp;      : draft-nir-ipsecme-erx-04.txt
<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> Pages  = ;         : 8
Date   &nbs= p;        : 2012-05-20

&nbs= p; This document describes an extension to the IKEv2 protocol that
=   allows an IKE Security Association (SA) to be created and
=   authenticated using the EAP Re-authentication Protocol extensio= n as
  described in RFC 5296bis.

  NOTE TO = RFC EDITOR: Replace 5296bis in the previous paragraph with
  = the RFC number assigned to draft-ietf-hokey-rfc5296bis (now in the
&nbs= p; RFC Editor queue)


A URL for this Internet-Draft is:
<= a href=3D"http://www.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt"= >http://www.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf= .org/internet-drafts/

This Internet-Draft can be retrieved at:
ft= p://ftp.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt

The IE= TF datatracker page for this Internet-Draft is:
https://datatracker.ietf= .org/doc/draft-nir-ipsecme-erx/

____________________________________= ___________
I-D-Announce mailing list
I-D-Announce@ietf.org
https:= //www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories:= http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-site= s.txt

Scanned by Check Point Total Security Gateway.

= --_000_3FDFD0742961426186DD474FDCF3D01Ccheckpointcom_-- From vishwas.ietf@gmail.com Mon May 21 16:13:11 2012 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 2D9D821F85A5 for ; Mon, 21 May 2012 16:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1M6CBTm5KQE for ; Mon, 21 May 2012 16:13:10 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5CC021F853E for ; Mon, 21 May 2012 16:13:10 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so10795512obb.31 for ; Mon, 21 May 2012 16:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=r3uDjS6EG2K+nHNNyl0iIArlxTJDRUU3ieKvGN5nR6Q=; b=qpZ82E7RvuvH3LLS2WLebOA0weoyRqL9ng+On+iznGEP3HRLBIE8flllu6QHIybos9 uCbWHCBQ+VTcSFeoT+nZbefcmCfB0yQIEOVxql5AlIrKJTYMevqJHSNmtfFm8UgT66jl 7+DOCSdr+vZUBACBqNLY+TssCOPyToREKZ8sgf4XAsiwALfAvyK3nWYU9jYxwH6LQVWZ CIMPSp1ixe5/9wsZR7OoKcqPIQQJqDJLxojiudgLiQWAZ0OOq0ElOE31bwJQjMGYUVvn YjLwdaH0uhbwsYXL+MLAt9+hGZYx5VI7XkFol+1q+4Nddc+rXO8LRpnGTGeyDMXYRrXY 0cJw== MIME-Version: 1.0 Received: by 10.60.20.3 with SMTP id j3mr20892429oee.43.1337641990340; Mon, 21 May 2012 16:13:10 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Mon, 21 May 2012 16:13:10 -0700 (PDT) Date: Mon, 21 May 2012 16:13:10 -0700 Message-ID: From: Vishwas Manral To: IPsecme WG Content-Type: multipart/alternative; boundary=e89a8fb20762abc11304c0940b4e Subject: [IPsec] auto-discovery VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 23:13:11 -0000 --e89a8fb20762abc11304c0940b4e Content-Type: text/plain; charset=ISO-8859-1 Hi Guys, We intend to be calling our effort formerly called Mesh VPN as "auto-discovery VPN". This name has been chosen based on discussions between the authors of the draft and verified with the co-chairs. :) Thanks, Vishwas --e89a8fb20762abc11304c0940b4e Content-Type: text/html; charset=ISO-8859-1 Hi Guys,

We intend to be calling our effort formerly called Mesh VPN as "auto-discovery VPN". This name has been chosen based on discussions between the authors of the draft and verified with the co-chairs. :)

Thanks,
Vishwas


--e89a8fb20762abc11304c0940b4e-- From vishwas.ietf@gmail.com Mon May 21 17:09:54 2012 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 7834821F84FD for ; Mon, 21 May 2012 17:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7TSAGW5cmUj for ; Mon, 21 May 2012 17:09:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF9F21F84E7 for ; Mon, 21 May 2012 17:09:53 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so10856896obb.31 for ; Mon, 21 May 2012 17:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q27Ko0a8eQQVuxaBU4PA+Wc3FrQj9cvPD3Ow9mG7OaQ=; b=ZNICdTKZiKaj0Gw4vybHqq+TzU8gNPQhXeP3q/F7mX9YWKYbEwWiDNTz4q530d79l8 wpED3MCGsFGKaCY0NrDUSKfm70ssFCvh1HDVqXpZff7zcCSaL5j7G8KPkh3sIcE92iLQ jAdz08XMEr0qqW9ZSMjz/mxPJNnzIXCKDInrJsReKNqECUwHj37t8xwc6Z2j+QkvKFKT ZD44OxXqtuYPHe9EZWN/T2ggdkBD1eqrOLnws9cmrZvWNFYn0huTf6EESZX4YOsJJB8A wBjNxM8IoErz3eqjpH7Pe7SsgheD3lnN78bHaJubaULIMe7w25l+f9Bzd+T/V6I2Bu7k myAA== MIME-Version: 1.0 Received: by 10.182.111.7 with SMTP id ie7mr20532689obb.14.1337645393068; Mon, 21 May 2012 17:09:53 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Mon, 21 May 2012 17:09:52 -0700 (PDT) In-Reply-To: <12713.1337104673@marajade.sandelman.ca> References: <12713.1337104673@marajade.sandelman.ca> Date: Mon, 21 May 2012 17:09:52 -0700 Message-ID: From: Vishwas Manral To: Michael Richardson Content-Type: multipart/alternative; boundary=14dae93998357d437404c094d6fa Cc: IPsecme WG Subject: Re: [IPsec] #213 - Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 00:09:54 -0000 --14dae93998357d437404c094d6fa Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, I am working on updating the text of the draft. I had a few doubts. > I think the focus on "movement" and "mobility" is wrong. > Instead, focus on connectivity. > > Tero (and I) asked the question about a device which was, from a > topological point of view, originally connected to "outside" (on the > public Internet, effectively), and had built up a mesh. > > Are you talking of a case where the device had Public internet connectivity and has now roamed to a place where it is inside the network, so the IPsec tunnel is not required. You are probably looking at a way to gracefully tear down the IPsec tunnel and use the native connectivity. Is the understanding of the usecase you had in mind correct? > There is a connectivity change (let's not worry about how, why, but I > can describe a dozen ways if you like, and not all of them involve 3G or > 802.11), and the device is now connected behind a gateway which is also > part of the mesh. > > Let's assume a multiple star topology situation. (We draw these on > napkins in Paris. I promise to re-read the problem statment to learn if > this scenario has been named) > > Let's say that said device ("A") previously was part of VPN-Concentrator X. > (It was perhaps part of that star via NAT-T transport). Packets flowed > from A to device B. Device B is located on network B-location, and is > served by B-gateway, and these packets flowed via VPN-Concentrator X. > > X attempts to ask A to connect directly to B-gateway so that packets > from A<->B take the shortcut. A presently has connectivity *on* > "network B-location". That is, A and B are in fact, co-located (but > might not be on the same link). > > 1) Is there a requirement that B-gateway must be able to make a bypass > connection to another spoke, from *behind* B? > > Let me see if I understood the question. We are talking of a gateway-B which is on the path between 2 spokes (A and B) which are talking via a VPN concentrator (X). You are asking if we allow the Gateway-B to allow for a bypass and if so can we allow for a "clear" bypass connectivity. Is my understanding correct? I agree there is a use case for this optimization, but do we want to tackle the use case as part of the base solution or as an extension once the base solution is created (so a future use case). Thanks, Vishwas 2) Many would feel that actually there should be *no* IPsec tunnel > between A and B, as they are presently co-located. > Do we have a requirement that the policy between two spokes > (a "bypass") could in fact be "clear"? > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > --14dae93998357d437404c094d6fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

I am working on updating the text of the draft. I had a = few doubts.

There is a connectivity change (let's not worry about how, why, but I can describe a dozen ways if you like, and not all of them involve 3G or 802.11), and the device is now connected behind a gateway which is also
part of the mesh.

Let's assume a multiple star topology situation. (We draw these on
napkins in Paris. I promise to re-read the problem statment to learn if
this scenario has been named)

Let's say that said device ("A") previously was part of VPN-C= oncentrator X.
(It was perhaps part of that star via NAT-T transport). =A0Packets flowed from A to device B. =A0Device B is located on network B-location, and is served by B-gateway, and these packets flowed via VPN-Concentrator X.

X attempts to ask A to connect directly to B-gateway so that packets
from A<->B take the shortcut. =A0A presently has connectivity *on* "network B-location". =A0That is, A and B are in fact, co-located= (but
might not be on the same link).

1) Is there a requirement that B-gateway must be able to make a bypass
=A0 connection to another spoke, from *behind* B?

Let me see if I understood the question. We are talki= ng of a gateway-B which is on the path between 2 spokes (A and B) which are= talking via a VPN concentrator (X). You are asking if we allow the Gateway= -B to allow for a bypass and if so can we allow for a "clear" byp= ass connectivity. Is my understanding correct?

I agree there is a use case for this optimization, but do we want to ta= ckle the use case as part of the base solution or as an extension once the = base solution is created (so a future use case).

Thanks,
Vishwas<= br>
2) Many would feel that actually there should be *no* IPsec tunnel
=A0 between A and B, as they are presently co-located.
=A0 Do we have a requirement that the policy between two spokes
=A0 (a "bypass") could in fact be "clear"?

=A0
--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/charter/<= /a>



--14dae93998357d437404c094d6fa-- From vishwas.ietf@gmail.com Mon May 21 17:14:59 2012 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 39D2121F845F for ; Mon, 21 May 2012 17:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyURebVFg4sy for ; Mon, 21 May 2012 17:14:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7D8721F845A for ; Mon, 21 May 2012 17:14:58 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so10862989obb.31 for ; Mon, 21 May 2012 17:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=AzX2RcV4NFBYYx/tGH9gatsaL8e06o96Q9zCCgrgxUM=; b=GtkUjc2/eX+oIfr6ZDazBz9w+O20gUDY2SVUE32ZOCW+d9ACtP4FP/JwCbg0+fvgnP TZbuqxHhmpYceKjlnlQzJGHvPfe/Ij89r3Ts7MhOfL6p4rxhOY8avg0a0Ho48CIFPiWR u6+xQRtnRzwvqf/TiqpANL1atBZlukV/Qatwh9URL6xt0lLMrHGEj514q8Xzsfpn44S4 dFuacyaVU4PDEo8DCcp4Tf/sMg2mOre/sK0elH98+IvB6I2S7AuFV0Ntfz/bD9fmp5Kx zairgS0MnXq0Yq3MNbl3N3fleKeN/4siMkk54JmF1mUVVQOBgAjbCHVDQN9nQOP+QwVq fjWA== MIME-Version: 1.0 Received: by 10.182.172.100 with SMTP id bb4mr20550496obc.22.1337645698284; Mon, 21 May 2012 17:14:58 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Mon, 21 May 2012 17:14:58 -0700 (PDT) Date: Mon, 21 May 2012 17:14:58 -0700 Message-ID: From: Vishwas Manral To: IPsecme WG Content-Type: multipart/alternative; boundary=e89a8f83a1ddae7cad04c094e80a Subject: [IPsec] Section 2.3: Endpoint-to-Gateway P2P VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 00:14:59 -0000 --e89a8f83a1ddae7cad04c094e80a Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I have been trying to understand the use case for End-point to Gateway use case as written in the current draft. Finding the closes gateway, seems to be rightly routing or ALTO (Application Level Transport Optimization) problem, rather than an IPsec one. Am I missing the point altogether? Thanks, Vishwas --e89a8f83a1ddae7cad04c094e80a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

I have been trying to understand the use case for End-poin= t to Gateway use case as written in the current draft.

Finding the c= loses gateway, seems to be rightly routing or ALTO (Application Level Trans= port Optimization) problem, rather than an IPsec one. Am I missing the poin= t altogether?

Thanks,
Vishwas


--e89a8f83a1ddae7cad04c094e80a-- From mcr@sandelman.ca Mon May 21 20:34:56 2012 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 3F58221F8525 for ; Mon, 21 May 2012 20:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.954 X-Spam-Level: X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_11=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7R1a4yA9KzH for ; Mon, 21 May 2012 20:34:55 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id A76EE21F84B2 for ; Mon, 21 May 2012 20:34:55 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id EFBD182E7; Mon, 21 May 2012 23:33:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 41DB598B98; Mon, 21 May 2012 23:34:53 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3CE5098470; Mon, 21 May 2012 23:34:53 -0400 (EDT) From: Michael Richardson To: Vishwas Manral In-Reply-To: References: <12713.1337104673@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 21 May 2012 23:34:53 -0400 Message-ID: <13325.1337657693@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IPsecme WG Subject: Re: [IPsec] #213 - Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 03:34:56 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Vishwas" =3D=3D Vishwas Manral writes: Vishwas> Hi Michael, Vishwas> I am working on updating the text of the draft. I had a few Vishwas> doubts. (fixing the quoting to clarify who said what) mcr> I think the focus on "movement" and "mobility" is wrong. mcr> Instead, focus on connectivity. mcr>=20 mcr> Tero (and I) asked the question about a device which was, from a mcr> topological point of view, originally connected to "outside" (on t= he mcr> public Internet, effectively), and had built up a mesh. =20 Vishwas> Are you talking of a case where the device had Public internet Vishwas> connectivity and has now roamed to a place where it is inside = the network, Vishwas> so the IPsec tunnel is not required. You are probably looking = at a way to Vishwas> gracefully tear down the IPsec tunnel and use the native conne= ctivity. Is Vishwas> the understanding of the usecase you had in mind correct? Yes, this is an example, but not the only situation. "Public internet connectivity" is not exactly the right term, because that almost implies that the device was never NAT'ed, but in fact it might have been. What matters is that it wasn't behind the home enterprises' security gateway(s). mcr> There is a connectivity change (let's not worry about how, why, bu= t I mcr> can describe a dozen ways if you like, and not all of them involve= 3G or mcr> 802.11), and the device is now connected behind a gateway which is= also mcr> part of the mesh. mcr>=20 mcr> Let's assume a multiple star topology situation. (We draw these on mcr> napkins in Paris. I promise to re-read the problem statment to lea= rn if mcr> this scenario has been named) mcr>=20 mcr> Let's say that said device ("A") previously was part of VPN-Concen= trator X. mcr> (It was perhaps part of that star via NAT-T transport). Packets f= lowed mcr> from A to device B. Device B is located on network B-location, an= d is mcr> served by B-gateway, and these packets flowed via VPN-Concentrator= X. mcr>=20 mcr> X attempts to ask A to connect directly to B-gateway so that packe= ts mcr> from A<->B take the shortcut. A presently has connectivity *on* mcr> "network B-location". That is, A and B are in fact, co-located (b= ut mcr> might not be on the same link). mcr>=20 mcr> 1) Is there a requirement that B-gateway must be able to make a by= pass mcr> connection to another spoke, from *behind* B? Vishwas> Let me see if I understood the question. We are talking of a g= ateway-B Vishwas> which is on the path between 2 spokes (A and B) which are talk= ing via a VPN Vishwas> concentrator (X). You are asking if we allow the Gateway-B to = allow for a Vishwas> bypass and if so can we allow for a "clear" bypass connectivit= y. Is my Vishwas> understanding correct? Yes. Just to be clear, A and B are *hosts* A was a "road warrior". Whether or not B is also a road warrior is not relevant, what's important is that B is behind B-gateway, and gets VPN service from B-gateway (and concentrator-X). Vishwas> I agree there is a use case for this optimization, but do we w= ant to tackle Vishwas> the use case as part of the base solution or as an extension o= nce the base Vishwas> solution is created (so a future use case). good enough. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT7sJXYqHRg3pndX9AQI20wP+M8bM4d65xzwgEeJG7x9orGGhz5Lg85iG cOGTy71lrPVtXH/w0cyHsH25PmFMIYIBBkr+D0f6MFs66/8hjU2T0hCdOB2BhziU qZSAteGyi+ll7Yhrq3iKvT8KK5lff4OPlZ+0sEB7LDWzLIem4tVjZ5Il7XQ780fu dyvky3EFWCg= =ECTh -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon May 21 20:39:26 2012 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 3E3DE21F85AE for ; Mon, 21 May 2012 20:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvrZ8f6O+5Ik for ; Mon, 21 May 2012 20:39:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id CCDE421F855B for ; Mon, 21 May 2012 20:39:25 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 7601382E7; Mon, 21 May 2012 23:37:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BA91298B98; Mon, 21 May 2012 23:39:24 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B401398470; Mon, 21 May 2012 23:39:24 -0400 (EDT) From: Michael Richardson To: Vishwas Manral In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 21 May 2012 23:39:24 -0400 Message-ID: <14169.1337657964@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IPsecme WG Subject: Re: [IPsec] auto-discovery VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 03:39:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Vishwas" =3D=3D Vishwas Manral writes: Vishwas> We intend to be calling our effort formerly called Mesh VPN as= "auto-discovery Vishwas> VPN". This name has been chosen based on discussions between t= he authors of Vishwas> the draft and verified with the co-chairs. :) okay. I can live with it. Please be prepared to deal with scope push from people who read the title and think it will help them configure the initial spoke of the VPN. I think that configuration of the spokes is out of scope. It's about configuration of the (partial) mesh of "rim" links. It's about the "Beltway" roads... perhaps someone can come up with a suitable reference to the Washington, DC politics for the protocol name. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT7sKbIqHRg3pndX9AQIAwQQApOkFEr5/k5CnPcHCwt11kZ12Pk0ih7id ZeJxQBJ/UTkyLCG5Ev/1xqUN0UAUXN5OQjFwkn8CGb+q+mJZOmu2fXKY4n+3AvPz cje0d9emxe6LzDho9S1B5JYgVvzO377YRMYF0WeqHMv/at7egaWneIcssz97knl0 hsAE3cfXs8g= =uQ+O -----END PGP SIGNATURE----- --=-=-=-- From yaronf.ietf@gmail.com Mon May 21 22:04:17 2012 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 274BD21F85D3 for ; Mon, 21 May 2012 22:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.836 X-Spam-Level: X-Spam-Status: No, score=-102.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_BEZEQINT_B=0.763, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krQ-0ab5H4AT for ; Mon, 21 May 2012 22:04:16 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6311821F852C for ; Mon, 21 May 2012 22:04:16 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3899048wgb.13 for ; Mon, 21 May 2012 22:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vxqn1OtIyDT+HwhFg68daKttLtId0HU+AbmDnfb2NAo=; b=kf7NYip4yz8E91G8+geP/tAe7jdw7evwZ6axLZ/RZtIeOOQQft0/eH5E/ZlN4w2LO8 isHJ4FiWrbjpdnpp6KaBM8x59NdxuuwcdlAztqU3UultGm67URkf1SD5C3GQlw8S3oeC 2eJ63HSx7O5NhFsZ2IiLtBBdqkIuVaDZXy8YSKd6gFgFcKuB3POXoDEJ0S22tx+qu0pt Faih6PDbbcrmXWI65AEkS9qHVeaKLb0A/bX7I8rSZKCTKMCA6RK6QEeYhe2x7jCkgHrN /4l+R0Y0WyDeh57Qu3Lg6Mr8pwBAltjXm99WDfdm0wKhgvmErrtD3Ml1w2InZ1WUwsyr y5Fw== Received: by 10.216.203.80 with SMTP id e58mr13867256weo.41.1337663055567; Mon, 21 May 2012 22:04:15 -0700 (PDT) Received: from [10.0.0.12] (bzq-218-172-211.red.bezeqint.net. [81.218.172.211]) by mx.google.com with ESMTPS id z8sm13221576wiy.1.2012.05.21.22.04.13 (version=SSLv3 cipher=OTHER); Mon, 21 May 2012 22:04:14 -0700 (PDT) Message-ID: <4FBB1E4C.6080309@gmail.com> Date: Tue, 22 May 2012 08:04:12 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Vishwas Manral References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Section 2.3: Endpoint-to-Gateway P2P VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 05:04:17 -0000 Hi Vishwas, First, existing products are doing that, which means this is at least somewhat useful :-) Making the decision on which gateway is closest seems to me out of scope. But informing the endpoint of which gateways are available to it can only be done at the IPsec-Discovery level, right? Thanks, Yaron On 05/22/2012 03:14 AM, Vishwas Manral wrote: > Hi folks, > > I have been trying to understand the use case for End-point to Gateway > use case as written in the current draft. > > Finding the closes gateway, seems to be rightly routing or ALTO > (Application Level Transport Optimization) problem, rather than an IPsec > one. Am I missing the point altogether? > > Thanks, > Vishwas > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From vishwas.ietf@gmail.com Mon May 21 22:10:34 2012 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 60EE321F84FB for ; Mon, 21 May 2012 22:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwM9G21y46IX for ; Mon, 21 May 2012 22:10:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC0321F84DE for ; Mon, 21 May 2012 22:10:33 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so11212016obb.31 for ; Mon, 21 May 2012 22:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q5L7OdhnvrChBZvu7XSkoAjvQ3OIuvVWelNChR40Cwc=; b=PXTrYsHzoCGf0hrcpA80fqtX1kMy4LtfiOuF2z2r2SdRN2pVRMO1HNEt3wRab2JqHA 1teGUL5fPIp3dhKIkdOWu++B+csNfpFWlpYhhJDXzmKAybuBsUwQj6nKXPXgUHshxVcz 2eQUqIwSWQd+TI2RrXfuuswFLrKrkZAst3P7aaoQjXzy1VLrUX2H6drFyLLD2x4gMStE 2mFrXk5Z80jXcxZ+0v7ndkdMQuIjKL9OyB16CqOrkuYbLWxQPHmjKz2iZoKHpMmMgqV2 Q2v5+PELFKJmNeUFZRwjFoSGGPn+72+clIpgZvRxsFENmMNJMqv1fKNfXsAzGhaNE2ht 3UVA== MIME-Version: 1.0 Received: by 10.182.111.7 with SMTP id ie7mr21100201obb.14.1337663433072; Mon, 21 May 2012 22:10:33 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Mon, 21 May 2012 22:10:33 -0700 (PDT) In-Reply-To: <4FBB1E4C.6080309@gmail.com> References: <4FBB1E4C.6080309@gmail.com> Date: Mon, 21 May 2012 22:10:33 -0700 Message-ID: From: Vishwas Manral To: Yaron Sheffer Content-Type: multipart/alternative; boundary=14dae9399835c1e14a04c099090d Cc: IPsecme WG Subject: Re: [IPsec] Section 2.3: Endpoint-to-Gateway P2P VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 05:10:34 -0000 --14dae9399835c1e14a04c099090d Content-Type: text/plain; charset=ISO-8859-1 Hi Yaron, I am not questioning the usefulness of the feature. I was just trying to figure what part is routing and which one can be dealt with in IPsec. I will put the Discovery part as the use case here. Thanks, Vishwas On Mon, May 21, 2012 at 10:04 PM, Yaron Sheffer wrote: > Hi Vishwas, > > First, existing products are doing that, which means this is at least > somewhat useful :-) > > Making the decision on which gateway is closest seems to me out of scope. > But informing the endpoint of which gateways are available to it can only > be done at the IPsec-Discovery level, right? > > Thanks, > Yaron > > > On 05/22/2012 03:14 AM, Vishwas Manral wrote: > >> Hi folks, >> >> I have been trying to understand the use case for End-point to Gateway >> use case as written in the current draft. >> >> Finding the closes gateway, seems to be rightly routing or ALTO >> (Application Level Transport Optimization) problem, rather than an IPsec >> one. Am I missing the point altogether? >> >> Thanks, >> Vishwas >> >> >> >> >> ______________________________**_________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/**listinfo/ipsec >> > --14dae9399835c1e14a04c099090d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yaron,

I am not questioning the usefulness of the feature. I was = just trying to figure what part is routing and which one can be dealt with = in IPsec.

I will put the Discovery part as the use case here.

Thanks,
Vishwas

On Mon, May 21, 20= 12 at 10:04 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wr= ote:
Hi Vishwas,

First, existing products are doing that, which means this is at least somew= hat useful :-)

Making the decision on which gateway is closest seems to me out of scope. B= ut informing the endpoint of which gateways are available to it can only be= done at the IPsec-Discovery level, right?

Thanks,
=A0 =A0 =A0 =A0Yaron


On 05/22/2012 03:14 AM, Vishwas Manral wrote:
Hi folks,

I have been trying to understand the use case for End-point to Gateway
use case as written in the current draft.

Finding the closes gateway, seems to be rightly routing or ALTO
(Application Level Transport Optimization) problem, rather than an IPsec one. Am I missing the point altogether?

Thanks,
Vishwas




_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--14dae9399835c1e14a04c099090d-- From ynir@checkpoint.com Mon May 21 23:16:44 2012 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 C4CF29E8011 for ; Mon, 21 May 2012 23:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n7GQrnW9S5y for ; Mon, 21 May 2012 23:16:44 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 088A29E800A for ; Mon, 21 May 2012 23:16:42 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4M6Gcfa000682; Tue, 22 May 2012 09:16:38 +0300 X-CheckPoint: {4FBB3C0D-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 22 May 2012 09:16:36 +0300 From: Yoav Nir To: Vishwas Manral Date: Tue, 22 May 2012 09:16:36 +0300 Thread-Topic: [IPsec] Section 2.3: Endpoint-to-Gateway P2P VPN Thread-Index: Ac034nCylcaPw147QrCOlc3mQi+GEA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Section 2.3: Endpoint-to-Gateway P2P VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 06:16:44 -0000 Hi Vishwas Especially for clients, routing doesn't always help. A lot of those corpora= te networks use non-routable IP addresses. Of course you can use routing pr= otocols once the client has connected to a gateway, but routing protocols d= on't help you choose the right gateway to reach 192.168.5.82. Even with routable addresses, routing tables and routing protocols pretty m= uch give you only the next hop at layer 3. They don't help you find the nex= t VPN hop - an IKE/IPsec endpoint. It is possible to connect to some (maybe pre-configured) gateway, and then = run (modified?) routing protocols over the tunnel and learn about more gate= ways through them. But this is getting deeply into the solution space. Yoav On May 22, 2012, at 3:14 AM, Vishwas Manral wrote: > Hi folks, >=20 > I have been trying to understand the use case for End-point to Gateway us= e case as written in the current draft. >=20 > Finding the closes gateway, seems to be rightly routing or ALTO (Applicat= ion Level Transport Optimization) problem, rather than an IPsec one. Am I m= issing the point altogether? >=20 > Thanks, > Vishwas From vishwas.ietf@gmail.com Tue May 22 10:39:30 2012 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 E743521F8694 for ; Tue, 22 May 2012 10:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQuQtxAYaTzz for ; Tue, 22 May 2012 10:39:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05C8A21F8693 for ; Tue, 22 May 2012 10:39:28 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so12188364obb.31 for ; Tue, 22 May 2012 10:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IsUW9yeCBqA22X1zmh+hYJgzPEX/f7yU/wbKvQSThYw=; b=vw0EaU6fm6Z4IbPDCmfIfBUdG8ZPeKQY9dak9h67S0bSCVImNCGULjfcli8KKg9D2w tRXPmLk+1CEtznf60d3000SpKPk3XRzl//WQBrVaqmuYl9tpT7E23d2W+xiSE2c/j7Gg pnKPGoC9xSK7jyfDsK3Uy8PeVamRYeUlv/XsNF6qEh/OhoRXhjWZFS6fKHY4GBo7OPRc zULbFOT0Q5k9iIFhpmbpukXF1QN/mOpAqdP4RxTukUXu901gzq1qXKKKJhi/jFFOEV+G 9SX/xj6XXNNDy9phdNHN0QKZxD7eOdLjgPV7kIYVbhD2Ct4k/gxyr/1K2uAvUjOw7s5z heRQ== MIME-Version: 1.0 Received: by 10.182.154.73 with SMTP id vm9mr23414148obb.72.1337708368555; Tue, 22 May 2012 10:39:28 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Tue, 22 May 2012 10:39:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 May 2012 10:39:28 -0700 Message-ID: From: Vishwas Manral To: Yoav Nir Content-Type: multipart/alternative; boundary=14dae93998331eedcd04c0a3803c Cc: IPsecme WG Subject: Re: [IPsec] Section 2.3: Endpoint-to-Gateway P2P VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 17:39:30 -0000 --14dae93998331eedcd04c0a3803c Content-Type: text/plain; charset=ISO-8859-1 Hi Yoav, I am sorry I was unclear. I wasn't just talking about IP Routing, but also Application level Routing (ALTO). As an example I know ALTO is used in content delivery to get the content from the best content server (best is based on numerous factors - like latency, bandwidth, Autonomous System etc). In my view the scenarios we talk about a host looking for the closest gateway are similar. I will add it to the document. As a solution we could look at ALTO as an option for the same. Thanks, Vishwas On Mon, May 21, 2012 at 11:16 PM, Yoav Nir wrote: > Hi Vishwas > > Especially for clients, routing doesn't always help. A lot of those > corporate networks use non-routable IP addresses. Of course you can use > routing protocols once the client has connected to a gateway, but routing > protocols don't help you choose the right gateway to reach 192.168.5.82. > > Even with routable addresses, routing tables and routing protocols pretty > much give you only the next hop at layer 3. They don't help you find the > next VPN hop - an IKE/IPsec endpoint. > > It is possible to connect to some (maybe pre-configured) gateway, and then > run (modified?) routing protocols over the tunnel and learn about more > gateways through them. But this is getting deeply into the solution space. > > Yoav > > On May 22, 2012, at 3:14 AM, Vishwas Manral wrote: > > > Hi folks, > > > > I have been trying to understand the use case for End-point to Gateway > use case as written in the current draft. > > > > Finding the closes gateway, seems to be rightly routing or ALTO > (Application Level Transport Optimization) problem, rather than an IPsec > one. Am I missing the point altogether? > > > > Thanks, > > Vishwas > > --14dae93998331eedcd04c0a3803c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoav,

I am sorry I was unclear.

I wasn't just talking about IP Routing, but also Application level=20 Routing (ALTO). As an example I know ALTO is used in content delivery to get the content from the best content server (best is based on numerous factors - like latency, bandwidth, Autonomous System etc). In my view the = scenarios we talk about a host looking for the closest gateway are similar.=

I will add it to the document. As a solution we could look at ALTO = as an option for the same.

Thanks,
Vishwas

On Mon, May 21, 2012 at 11:16 PM,= Yoav Nir <ynir@checkpoint.com> wrote:
Hi Vishwas

Especially for clients, routing doesn't always help. A lot of those cor= porate networks use non-routable IP addresses. Of course you can use routin= g protocols once the client has connected to a gateway, but routing protoco= ls don't help you choose the right gateway to reach 192.168.5.82.

Even with routable addresses, routing tables and routing protocols pretty m= uch give you only the next hop at layer 3. They don't help you find the= next VPN hop - an IKE/IPsec endpoint.

It is possible to connect to some (maybe pre-configured) gateway, and then = run (modified?) routing protocols over the tunnel and learn about more gate= ways through them. But this is getting deeply into the solution space.

Yoav

On May 22, 2012, at 3:14 AM, Vishwas Manral wrote:

> Hi folks,
>
> I have been trying to understand the use case for End-point to Gateway= use case as written in the current draft.
>
> Finding the closes gateway, seems to be rightly routing or ALTO (Appli= cation Level Transport Optimization) problem, rather than an IPsec one. Am = I missing the point altogether?
>
> Thanks,
> Vishwas


--14dae93998331eedcd04c0a3803c-- From internet-drafts@ietf.org Fri May 25 12:34:40 2012 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 E9E8121F87AA; Fri, 25 May 2012 12:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3riVAf0msHu; Fri, 25 May 2012 12:34:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B2021F85F8; Fri, 25 May 2012 12:34:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120525193440.18907.3418.idtracker@ietfa.amsl.com> Date: Fri, 25 May 2012 12:34:40 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-p2p-vpn-problem-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:34:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extension= s Working Group of the IETF. Title : Auto Discovery VPN Problem Statement Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-p2p-vpn-problem-01.txt Pages : 14 Date : 2012-05-25 This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of end points change or the end points may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution is chartered to address these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem-01.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-p2p-vpn-problem/ From vishwas.ietf@gmail.com Tue May 29 13:14:53 2012 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 26E0311E8168 for ; Tue, 29 May 2012 13:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps5ZHzcGPy0Q for ; Tue, 29 May 2012 13:14:52 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB9121F8498 for ; Tue, 29 May 2012 13:14:52 -0700 (PDT) Received: by yhq56 with SMTP id 56so3176433yhq.31 for ; Tue, 29 May 2012 13:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RZ25DlIbm+twMV5AsQgvxjeNr256QvaU6HbeiFzaPog=; b=w0+yusSq3mh266mx2PsaAUn+JTZGINiiT+eaBcAKtlVVzzqGhyW2P1t1Usw1AA1qfk M1DQYer/toNCLpjDX76l6xQQ3NWDqp8X3EpVndLC00Cfsxu2z2HrBjBgU3dKZJoF+AC4 CZNoZMaxJ8w7PSKgSAvR1o5Jgxvaeeycd5tS2gTbhIBuon0z2Kdp50fwOWW8zJ/9DDji uqrzoxt8l6SfiErv1n5a2EBbOsFJwb4rvzC4kRBFq/C6mEWOJ3DIBz1JTFGobsT84jRP Kq9VNgC3uzNLQ2zH/VrasWoggxhrmCAxjggGMYB4NWRkXf9LqpxdDlpICOjy+C8tag/1 XaDA== MIME-Version: 1.0 Received: by 10.60.28.162 with SMTP id c2mr12722077oeh.3.1338322487544; Tue, 29 May 2012 13:14:47 -0700 (PDT) Received: by 10.182.19.201 with HTTP; Tue, 29 May 2012 13:14:47 -0700 (PDT) Date: Tue, 29 May 2012 13:14:47 -0700 Message-ID: From: Vishwas Manral To: IPsecme WG Content-Type: multipart/alternative; boundary=e89a8ff1c762770d6b04c1327c7c Subject: [IPsec] Auto Discovery VPN Problem statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 20:14:53 -0000 --e89a8ff1c762770d6b04c1327c7c Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We published the draft on the updated problem statement: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem-01.txt I have tried my best to address most concerns here. Your reviews and discussions on this would be of great help. On another note I got interest from different folks, and Huawei-Symantec and NTT-MCL have published a draft on a similar use case earlier. http://tools.ietf.org/html/draft-ko-vaas-problem-statement-01 . We will work with them to see how we to update any new use cases/ requirements they may have. Thanks, Vishwas --e89a8ff1c762770d6b04c1327c7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi folks,

We publish= ed the draft on the updated problem statement:

http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-= vpn-problem-01.txt

I have tried my bes= t to address most concerns here. Your reviews and discussions on this would= be of great help.

On another note I got interest from different folks, and Huawei-Symantec= and NTT-MCL have published a draft on a similar use case earlier. http://tools.ietf.org/html/draft-ko-vaas-problem-statement-01 . We wi= ll work with them to see how we to update any new use cases/ requirements t= hey may have.

Thanks,

Vishwas

--e89a8ff1c762770d6b04c1327c7c--