From prvs=1045d51f8=patrick.harms@vwfs.com Mon Feb 3 06:05:34 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C847D1A021C for ; Mon, 3 Feb 2014 06:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3JakVKpyw0P for ; Mon, 3 Feb 2014 06:05:31 -0800 (PST) Received: from mx1.vwfsag.de (mx1.vwfsag.de [193.25.183.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3451A05C5 for ; Mon, 3 Feb 2014 04:35:36 -0800 (PST) Received: from unknown (HELO sr-web-vsmgw2.fs01.vwf.vwfs-ad) ([10.41.77.140]) by sr-web-mgw2.fs01.vwf.vwfs-ad with ESMTP; 03 Feb 2014 13:35:34 +0100 Received: from sr-web-vsmgw2.fs01.vwf.vwfs-ad (localhost [127.0.0.1]) by sr-web-vsmgw2.fs01.vwf.vwfs-ad (VWFS) with ESMTP id EDAB286075 for ; Mon, 3 Feb 2014 13:35:33 +0100 (CET) Received: from FSDEBSSXC003.fs01.vwf.vwfs-ad (fsdebssxc003.fs01.vwf.vwfs-ad [10.43.13.229]) by sr-web-vsmgw2.fs01.vwf.vwfs-ad (VWFS) with ESMTP id E0D9686067 for ; Mon, 3 Feb 2014 13:35:33 +0100 (CET) Received: from FSDEBSSXD111.fs01.vwf.vwfs-ad ([169.254.5.32]) by FSDEBSSXC003.fs01.vwf.vwfs-ad ([10.43.13.229]) with mapi id 14.03.0158.001; Mon, 3 Feb 2014 13:35:33 +0100 From: "Harms, Patrick" To: "'ipsec@ietf.org'" Thread-Topic: AD-VPN Protocol Selection Thread-Index: Ac8g29viSNWMxCSdS+mwPoqNzCPObQ== Date: Mon, 3 Feb 2014 12:35:33 +0000 Message-ID: <87BCDFB0B867FB4A85DB44EE8946E2458407E6F6@FSDEBSSXD111.fs01.vwf.vwfs-ad> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.43.0.124] Content-Type: multipart/alternative; boundary="_000_87BCDFB0B867FB4A85DB44EE8946E2458407E6F6FSDEBSSXD111fs0_" MIME-Version: 1.0 Subject: [IPsec] AD-VPN Protocol Selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:05:35 -0000 --_000_87BCDFB0B867FB4A85DB44EE8946E2458407E6F6FSDEBSSXD111fs0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCk15IG5hbWUgaXMgUGF0cmljayBhbmQgSSBhbSB3b3JraW5nIGFzIGEgc3lz dGVtIGFyY2hpdGVjdC4gT25lIG9mIG15IGN1cnJlbnQgam9icyBpcyB0byBidWlsZCBhIHZwbiBh cmNoaXRlY3R1cmUgdGhhdCBrZWVwcyB0aGUgbWFudWFsIGNvbmZpZ3VyYXRpb24gZWZmb3J0cyBh cyBsb3cgYXMgcG9zc2libGUgYW5kIGFzIHNpbXBsZSBhcyBwb3NzaWJsZS4gSSBoYXZlIHRlc3Rl ZCBhbmQgcGxheWVkIGFyb3VuZCB3aXRoIGEgcmFuZ2Ugb2YgdnBuIHNvbHV0aW9ucyBhbmQgd291 bGQgbGlrZSB0byBzaGFyZSBteSBwZXJzb25hbCBvcGluaW9uIHRvIHRoaXMgbWFpbGluZyBsaXN0 Lg0KDQpNeSBwcmVmZXJlbmNlIGlzIG9uIGRyYWZ0LWRldGllbm5lLWRtdnBuLTAwLiBCZWNhdXNl IG9mIGRtdnBuIGlzOg0KDQotIGlzIGFsbG93aW5nIHRvIGFkZCAnc3Bva2VzJyB3aXRob3V0IGNv bmZpZ3VyYXRpb24gY2hhbmdlcyBvbiB0aGUgJ2h1YicgZGV2aWNlcyAoOC4xIGRtdnBuIGRyYWZ0 KQ0KRm9yIG1lLCB0aGlzIGlzIGFuIGltcG9ydGFudCBwb2ludC4gQ2hhbmdpbmcgdGhlIGNvbmZp Z3VyYXRpb24gb24gdGhlIGh1YiByb3V0ZXJzLCBldmVyeXRpbWUgYSBzcG9rZSBpcyBhZGRlZCB0 byB0aGUgbmV0d29yaywgd291bGQgbWFrZSB0aGUgcm9sbG91dCBwcm9jZXNzIHRvIGNvbXBsZXgg YW5kIGlzIGEgcG9zc2libGUgc291cmNlIG9mIGZhaWx1cmVzLg0KDQotIHNjYWxlcyB3aXRoIG11 bHRpcGxlICdodWJzJyBsaW5lYXJseQ0KQWxzbyBhbiBpbXBvcnRhbnQgcG9pbnQuIEZvciBtZSwg aXQgaXMgZXNzZW50aWFsIHRvIHNjYWxlIG91dCB0aGUgcGxhdGZvcm0gd2hlbiB0aGUgYW1vdW50 IG9mIHNwb2tlcyBpcyBpbmNyZWFzaW5nLiBTbyBJIGFtIGFibGUgdG8gc3RhcnQgd2l0aCBhIHNp emUgb2YgdGhlIHBsYXRmb3JtIHRoYXQgZml0cyBteSBuZWVkcywgYnV0IEkgYW0gYWJsZSB0byBy YWlzZSB0aGUgYW1vdW50IG9mIHNwb2tlcyB3aXRob3V0IGNoYW5naW5nIHRoZSB3aG9sZSBkZXNp Z24uDQoNCg0KLSB1c2VzIHJvdXRpbmcgcHJvdG9jb2xzIGZvciByZWR1bmRhbmN5IGFuZCBwYXRo IG1hbmlwdWxhdGlvbnMgKDguMyBkbXZwbiBkcmFmdCkNClVzaW5nIHJvdXRpbmcgcHJvdG9jb2xz IG9yIHRoZSBpbnRlcmFjdGlvbiB3aXRoIHJvdXRpbmcgcHJvdG9jb2xzIGdpdmVzIG1lIHRoZSBw b3NzaWJpbGl0eSBmb3IgYSB0aWdodGVyIGludGVncmF0aW9uIGluIGV4aXN0aW5nIG5ldHdvcmtz LiBJIGFtIGFsc28gYWJsZSB0byB1c2UgZXhpc3RpbmcgdGVjaG5vbG9naWVzIGZvciByZWR1bmRh bmN5IGFuZCBwYXRoIG1hbmlwdWxhdGlvbnMuDQoNCg0KQmFzZWQgb24gdGhlIHRoZW9yaWVzIChh ZHZwbiBkcmFmdCBhbmQgZG12cG4pIGFuZCByZWFsIHdvcmxkIGV4cGVyaWVuY2UgKGRtdnBuKSwg SSB3b3VsZCBmYXZvciBkbXZwbiwgYmVjYXVzZSB0aGUgaGFuZGxpbmcgYW5kIG9wZXJhdGluZyBz b3VuZHMgbGVzcyBjb21wbGV4LiAoZWcuIGxvd2VyIGFtb3VudCBvZiBzdGVwcyBpbiB0dW5uZWwg aW5pdGlhdGlvbiwgc2luZ2xlIGxvZ2ljYWwgaW50ZXJmYWNlIGZvciB0dW5uZWwgdGVybWluYXRp b24gZXRjLikNCg0KDQpBZGRpdGlvbmFsIHBvaW50cyBvdXQgb2YgbXkgcGVyc3BlY3RpdmUsIGRt dnBuOg0KDQotIGhhcyBhbiBpbnN0YWxsZWQgYmFzaXMNCi0gaXMgc2NhbGFibGUgdXAgdG8gMTUu MDAwIHNwb2tlcyAodGVzdGVkIGJ5IG15IG93bikNCi0gaW50ZXJvcGVyYXRlcyB3aXRoIHRoZSBl eGlzdGluZyBpbmZyYXN0cnVjdHVyZSBkdWUgdG8gdXNlIG9mIGR5bmFtaWMgcm91dGluZyBwcm90 b2NvbHMgKHRlc3RlZCBieSBteSBvd24pDQotIGludGVyb3BlcmF0ZXMgd2l0aCBsb2FkIGJhbGFu Y2VycyBvZiBtdWx0aXBsZSB2ZW5kb3JzICh0ZXN0ZWQgYnkgbXkgb3duKSAobGluZWFybHkgaHVi IHNjYWxlIG91dCBzemVuYXJpbykNCg0KTWF5YmUgdGhlc2UgcG9pbnRzIGFyZSBmdWxmaWxsZWQg YnkgdGhlIGFkdnBuIGRyYWZ0IGFzIHdlbGwsIGJ1dCBJIGhhdmUgbm8gcGVyc29uYWwgZXhwZXJp ZW5jZS4NCg0KR2xvc3Nhcnk6DQpkbXZwbiAtIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWRldGllbm5lLWRtdnBuLTAxDQphZHZwbiAgIC0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc2F0aHlhbmFyYXlhbi1pcHNlY21lLWFkdnBuLTAzDQoNCg0KQmVzdCBSZWdhcmRz LA0KUGF0cmljaw0KDQoNCg0KDQpWb2xrc3dhZ2VuIEZpbmFuY2lhbCBTZXJ2aWNlcyBBRw0KU2l0 ei9SZWdpc3RlcmVkIHNlYXQ6IEJyYXVuc2Nod2VpZw0KUmVnaXN0ZXJnZXJpY2h0L1JlZ2lzdHJh dGlvbiBjb3VydDogQW10c2dlcmljaHQgQnJhdW5zY2h3ZWlnDQpIUkIgTnIuL0NvbW1lcmNpYWwg UmVnaXN0ZXIgTm8uOiAzNzkwDQpWb3JzaXR6ZW5kZXIgZGVzIEF1ZnNpY2h0c3JhdHMvQ2hhaXJt YW4gb2YgdGhlIFN1cGVydmlzb3J5IEJvYXJkOiBIYW5zIERpZXRlciBQw7Z0c2NoDQpWb3JzdGFu ZC9Cb2FyZCBvZiBNYW5hZ2VtZW50OiBGcmFuayBXaXR0ZXIgKFZvcnNpdHplbmRlci9DaGFpcm1h biksIERyLiBNYXJpbyBEYWJlcmtvdywgRnJhbmsgRmllZGxlciwgQ2hyaXN0aWFuZSBIZXNzZSwg RHIuIE1pY2hhZWwgUmVpbmhhcnQsIExhcnMtSGVubmVyIFNhbnRlbG1hbm4NCg0KV2ljaHRpZ2Vy IEhpbndlaXM6IERpZSB2b3JnZW5hbm50ZW4gQW5nYWJlbiB3ZXJkZW4gamVkZXIgRS1NYWlsIGF1 dG9tYXRpc2NoIGhpbnp1Z2Vmw7xndCB1bmQgbGFzc2VuIGtlaW5lIFLDvGNrc2NobMO8c3NlIGF1 ZiBkZW4gUmVjaHRzY2hhcmFrdGVyIGRlciBFLU1haWwgenUuDQpJbXBvcnRhbnQgbm90ZTogVGhl IGFib3ZlIGluZm9ybWF0aW9uIGlzIGF1dG9tYXRpY2FsbHkgYWRkZWQgdG8gdGhpcyBlLW1haWwu IFRoaXMgYWRkaXRpb24gZG9lcyBub3QgY29uc3RpdHV0ZSBhIHJlcHJlc2VudGF0aW9uIHRoYXQg dGhlIGNvbnRlbnQgb2YgdGhpcyBlLW1haWwgaXMgbGVnYWxseSByZWxldmFudCBhbmQvb3IgaXMg aW50ZW5kZWQgdG8gYmUgbGVnYWxseSBiaW5kaW5nIHVwb24gVm9sa3N3YWdlbiBGaW5hbmNpYWwg U2VydmljZXMgQUcuDQo= --_000_87BCDFB0B867FB4A85DB44EE8946E2458407E6F6FSDEBSSXD111fs0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYifQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmV9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2Ux Nw0KCXtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3Rl eHR9DQouTXNvQ2hwRGVmYXVsdA0KCXtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe21hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAu ODVwdH0NCmRpdi5Xb3JkU2VjdGlvbjENCgl7fQ0KLS0+DQo8L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFy IGFsbCw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+TXkgbmFtZSBpcyBQYXRyaWNrIGFuZCBJIGFtIHdvcmtpbmcgYXMgYSBzeXN0ZW0gYXJjaGl0 ZWN0LiBPbmUgb2YgbXkgY3VycmVudCBqb2JzIGlzIHRvIGJ1aWxkIGEgdnBuIGFyY2hpdGVjdHVy ZSB0aGF0IGtlZXBzIHRoZSBtYW51YWwgY29uZmlndXJhdGlvbiBlZmZvcnRzIGFzIGxvdyBhcyBw b3NzaWJsZSBhbmQgYXMgc2ltcGxlIGFzIHBvc3NpYmxlLiBJIGhhdmUgdGVzdGVkDQogYW5kIHBs YXllZCBhcm91bmQgd2l0aCBhIHJhbmdlIG9mIHZwbiBzb2x1dGlvbnMgYW5kIHdvdWxkIGxpa2Ug dG8gc2hhcmUgbXkgcGVyc29uYWwgb3BpbmlvbiB0byB0aGlzIG1haWxpbmcgbGlzdC48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TXkgcHJlZmVy ZW5jZSBpcyBvbiBkcmFmdC1kZXRpZW5uZS1kbXZwbi0wMC4gQmVjYXVzZSBvZiBkbXZwbiBpczo8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LSBp cyBhbGxvd2luZyB0byBhZGQgJ3Nwb2tlcycgd2l0aG91dCBjb25maWd1cmF0aW9uIGNoYW5nZXMg b24gdGhlICdodWInIGRldmljZXMgKDguMSBkbXZwbiBkcmFmdCk8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjI1cHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5Gb3IgbWUsIHRoaXMgaXMgYW4gaW1wb3J0YW50IHBvaW50LiBDaGFuZ2luZyB0aGUgY29u ZmlndXJhdGlvbiBvbiB0aGUgaHViIHJvdXRlcnMsIGV2ZXJ5dGltZSBhIHNwb2tlIGlzIGFkZGVk IHRvIHRoZSBuZXR3b3JrLCB3b3VsZCBtYWtlIHRoZSByb2xsb3V0IHByb2Nlc3MgdG8gY29tcGxl eCBhbmQgaXMgYSBwb3NzaWJsZSBzb3VyY2UNCiBvZiBmYWlsdXJlcy48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LSBzY2FsZXMgd2l0aCBtdWx0 aXBsZSAnaHVicycgbGluZWFybHk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbHNvIGFuIGltcG9y dGFudCBwb2ludC4gRm9yIG1lLCBpdCBpcyBlc3NlbnRpYWwgdG8gc2NhbGUgb3V0IHRoZSBwbGF0 Zm9ybSB3aGVuIHRoZSBhbW91bnQgb2Ygc3Bva2VzIGlzIGluY3JlYXNpbmcuIFNvIEkgYW0gYWJs ZSB0byBzdGFydCB3aXRoIGEgc2l6ZSBvZiB0aGUgcGxhdGZvcm0gdGhhdCBmaXRzIG15IG5lZWRz LCBidXQNCiBJIGFtIGFibGUgdG8gcmFpc2UgdGhlIGFtb3VudCBvZiBzcG9rZXMgd2l0aG91dCBj aGFuZ2luZyB0aGUgd2hvbGUgZGVzaWduLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIHVz ZXMgcm91dGluZyBwcm90b2NvbHMgZm9yIHJlZHVuZGFuY3kgYW5kIHBhdGggbWFuaXB1bGF0aW9u cyAoOC4zIGRtdnBuIGRyYWZ0KTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlVzaW5nIHJvdXRpbmcg cHJvdG9jb2xzIG9yIHRoZSBpbnRlcmFjdGlvbiB3aXRoIHJvdXRpbmcgcHJvdG9jb2xzIGdpdmVz IG1lIHRoZSBwb3NzaWJpbGl0eSBmb3IgYSB0aWdodGVyIGludGVncmF0aW9uIGluIGV4aXN0aW5n IG5ldHdvcmtzLiBJIGFtIGFsc28gYWJsZSB0byB1c2UgZXhpc3RpbmcgdGVjaG5vbG9naWVzIGZv ciByZWR1bmRhbmN5DQogYW5kIHBhdGggbWFuaXB1bGF0aW9ucy48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CYXNlZCBvbiB0aGUgdGhlb3Jp ZXMgKGFkdnBuIGRyYWZ0IGFuZCBkbXZwbikgYW5kIHJlYWwgd29ybGQgZXhwZXJpZW5jZSAoZG12 cG4pLCBJIHdvdWxkIGZhdm9yIGRtdnBuLCBiZWNhdXNlIHRoZSBoYW5kbGluZyBhbmQgb3BlcmF0 aW5nIHNvdW5kcyBsZXNzIGNvbXBsZXguIChlZy4gbG93ZXIgYW1vdW50IG9mIHN0ZXBzIGluIHR1 bm5lbCBpbml0aWF0aW9uLCBzaW5nbGUgbG9naWNhbA0KIGludGVyZmFjZSBmb3IgdHVubmVsIHRl cm1pbmF0aW9uIGV0Yy4pPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+QWRkaXRpb25hbCBwb2ludHMgb3V0IG9mIG15IHBlcnNwZWN0aXZlLCBk bXZwbjo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+LSBoYXMgYW4gaW5zdGFsbGVkIGJhc2lzPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIGlzIHNjYWxhYmxlIHVwIHRvIDE1LjAwMCBzcG9rZXMg KHRlc3RlZCBieSBteSBvd24pPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4tIGludGVyb3BlcmF0ZXMgd2l0aCB0aGUgZXhpc3RpbmcgaW5mcmFzdHJ1 Y3R1cmUgZHVlIHRvIHVzZSBvZiBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2xzICh0ZXN0ZWQgYnkg bXkgb3duKTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+LSBpbnRlcm9wZXJhdGVzIHdpdGggbG9hZCBiYWxhbmNlcnMgb2YgbXVsdGlwbGUgdmVuZG9y cyAodGVzdGVkIGJ5IG15IG93bikgKGxpbmVhcmx5IGh1YiBzY2FsZSBvdXQgc3plbmFyaW8pPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1heWJl IHRoZXNlIHBvaW50cyBhcmUgZnVsZmlsbGVkIGJ5IHRoZSBhZHZwbiBkcmFmdCBhcyB3ZWxsLCBi dXQgSSBoYXZlIG5vIHBlcnNvbmFsIGV4cGVyaWVuY2UuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkdsb3NzYXJ5Ojwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5kbXZwbiAtIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWRldGllbm5lLWRtdnBuLTAxIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWRldGllbm5lLWRtdnBuLTAxPC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5hZHZwbiAmbmJzcDsgLSA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1zYXRoeWFuYXJheWFuLWlwc2VjbWUtYWR2cG4tMDMiPg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2F0aHlhbmFyYXlhbi1pcHNlY21lLWFkdnBuLTAz PC9hPiA8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5CZXN0IFJlZ2FyZHMsPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5QYXRyaWNrPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IiI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzwvcD4NCjwvZGl2Pg0KPHA+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiI+PHN0cm9uZz5Wb2xrc3dhZ2VuIEZpbmFuY2lhbCBTZXJ2aWNlcyBBRzwv c3Ryb25nPjxicj4NClNpdHovUmVnaXN0ZXJlZCBzZWF0OiBCcmF1bnNjaHdlaWc8YnI+DQpSZWdp c3RlcmdlcmljaHQvUmVnaXN0cmF0aW9uIGNvdXJ0OiBBbXRzZ2VyaWNodCBCcmF1bnNjaHdlaWc8 YnI+DQpIUkIgTnIuL0NvbW1lcmNpYWwgUmVnaXN0ZXIgTm8uOiAzNzkwPGJyPg0KVm9yc2l0emVu ZGVyIGRlcyBBdWZzaWNodHNyYXRzL0NoYWlybWFuIG9mIHRoZSBTdXBlcnZpc29yeSBCb2FyZDog SGFucyBEaWV0ZXIgUMO2dHNjaDxicj4NClZvcnN0YW5kL0JvYXJkIG9mIE1hbmFnZW1lbnQ6Jm5i c3A7RnJhbmsgV2l0dGVyJm5ic3A7KFZvcnNpdHplbmRlci9DaGFpcm1hbiksJm5ic3A7RHIuIE1h cmlvIERhYmVya293LCZuYnNwO0ZyYW5rIEZpZWRsZXIsJm5ic3A7Q2hyaXN0aWFuZSBIZXNzZSwg RHIuIE1pY2hhZWwgUmVpbmhhcnQsIExhcnMtSGVubmVyIFNhbnRlbG1hbm48L2ZvbnQ+PC9wPg0K PHA+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PHU+ V2ljaHRpZ2VyIEhpbndlaXM6PC91PiBEaWUgdm9yZ2VuYW5udGVuIEFuZ2FiZW4gd2VyZGVuIGpl ZGVyIEUtTWFpbCBhdXRvbWF0aXNjaCBoaW56dWdlZsO8Z3QgdW5kIGxhc3NlbiBrZWluZSBSw7xj a3NjaGzDvHNzZSBhdWYgZGVuIFJlY2h0c2NoYXJha3RlciBkZXIgRS1NYWlsIHp1Ljxicj4NCjx1 PkltcG9ydGFudCBub3RlOjwvdT4gVGhlIGFib3ZlIGluZm9ybWF0aW9uIGlzIGF1dG9tYXRpY2Fs bHkgYWRkZWQgdG8gdGhpcyBlLW1haWwuIFRoaXMgYWRkaXRpb24gZG9lcyBub3QgY29uc3RpdHV0 ZSBhIHJlcHJlc2VudGF0aW9uIHRoYXQgdGhlIGNvbnRlbnQgb2YgdGhpcyBlLW1haWwgaXMgbGVn YWxseSByZWxldmFudCBhbmQvb3IgaXMgaW50ZW5kZWQgdG8gYmUgbGVnYWxseSBiaW5kaW5nIHVw b24gVm9sa3N3YWdlbiBGaW5hbmNpYWwgU2VydmljZXMNCiBBRy48L2ZvbnQ+PC9wPg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_87BCDFB0B867FB4A85DB44EE8946E2458407E6F6FSDEBSSXD111fs0_-- From mcr@sandelman.ca Mon Feb 3 07:02:38 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7551A00F4 for ; Mon, 3 Feb 2014 07:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.707 X-Spam-Level: *** X-Spam-Status: No, score=3.707 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, RDNS_NONE=1.274, SPF_SOFTFAIL=0.972, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OgcDheOanby for ; Mon, 3 Feb 2014 07:02:33 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 806091A00E1 for ; Mon, 3 Feb 2014 07:02:30 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4D61A20032; Mon, 3 Feb 2014 11:19:22 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7595664656; Mon, 3 Feb 2014 10:02:30 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 626BF63AD7; Mon, 3 Feb 2014 10:02:30 -0500 (EST) From: Michael Richardson To: "Harms\, Patrick" In-Reply-To: <87BCDFB0B867FB4A85DB44EE8946E2458407E6F6@FSDEBSSXD111.fs01.vwf.vwfs-ad> References: <87BCDFB0B867FB4A85DB44EE8946E2458407E6F6@FSDEBSSXD111.fs01.vwf.vwfs-ad> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] AD-VPN Protocol Selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:02:38 -0000 --=-=-= Harms, Patrick wrote: > - is allowing to add 'spokes' without configuration changes on the 'hub' > devices (8.1 dmvpn draft) > For me, this is an important point. Changing the configuration on the hub > routers, everytime a spoke is added to the network, would make the rollout > process to complex and is a possible source of failures. I don't see how you can add a spoke in any system without requiring some changes to at least one hub and/or the database/LDAP/etc. which keeps track of all the spokes. > Based on the theories (advpn draft and dmvpn) and real world experience > (dmvpn), I would favor dmvpn, because the handling and operating sounds less > complex. (eg. lower amount of steps in tunnel initiation, single logical > interface for tunnel termination etc.) Do you care about mobile (handheld) devices? -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUu+vhIqHRg3pndX9AQIZLAP+JOQSfW11c5hpEhpNXUDEXpEfAbY4KQFr Yy9qzvkRYwgNS6xJRCGAPjj0u8e0O9lQs4FKFWXg+Q4rQp7oM4aw0SW9oMWDN5Nr HOgZI9g1IgfJ2aXFYyhEGXrKjK6vtFNQVGNou+bdBpt12fFPOBWxoamNv4LNdygx c8wajmkQHEw= =aS7f -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Mon Feb 3 07:29:03 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D580B1A0140 for ; Mon, 3 Feb 2014 07:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.537 X-Spam-Level: X-Spam-Status: No, score=-5.537 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOie3N1u-QGJ for ; Mon, 3 Feb 2014 07:29:01 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 42F691A0158 for ; Mon, 3 Feb 2014 07:29:01 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s13FSrii008081; Mon, 3 Feb 2014 17:28:53 +0200 X-CheckPoint: {52EFAEEE-A-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 17:28:53 +0200 From: Yoav Nir To: Praveen Sathyanarayan , "Frederic Detienne (fdetienn)" Thread-Topic: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 Thread-Index: AQHPGFBiQcpc2q5lk0SS6Po9hK8PSZqYtBsAgAri6IA= Date: Mon, 3 Feb 2014 15:28:52 +0000 Message-ID: References: <88259CEC-4D10-48EC-8A21-0D2F348EEE3F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.37] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " WG" Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:29:04 -0000 In addition to what Praveen said, I'd like to point out that draft-sathyana= rayan defines a two-tier network. On the top tier are security gateways tha= t are (presumably) always-on and know the union protected domain of the VPN= . The second tier are devices that do not know the entire protected domain= . The group of first-tier nodes is not necessarily identical to the group "= hubs", but that is typical. Also typical is for that group to be relatively= small - 2-30 gateways in a network that contains 10s of thousands of nodes= . Second tier devices are typically remote access clients, home routers or sm= all office routers. Their initial configuration is simple - one peer, and c= redentials for connecting to that peer. First tier devices should know at all times what the union protected domain= is. It's possible that they won't know which peer gateways protects a part= icular address, but they have to know the difference between "send through = the VPN" and "send through the unprotected Internet". The PROTECTED_DOMAIN attribute described in section 3.9 is always sent from= a first-tier gateway to a second tier node, and includes the union protect= ed domain, unless policy requires something different: for example, remote = access clients are often required to send all their traffic (even google se= arches) through a center gateway. The PROTECTED_DOMAIN is a bootstrap mecha= nism for 2nd tier nodes. It is *not* part of the normal continuous operatio= n of the network, although 2nd tier nodes may use it periodically. The Shortcut exchange, described in most of section 3 is the one used among= all the nodes in the AD-VPN to tell each other where a particular part of = the union protected domain is protected. That *is* part of the normal oper= ation of the protocol.=20 When adding or deleting a spoke with a protected domain, two steps are requ= ired: 1. Configure the new spoke with the identity, address, and credentials for= a hub gateway 2. Configure the hub gateway with the identity, credentials and protected = domain of the new spoke.=20 You cannot omit step #2 in any solution unless you forego authentication. A= ccepting a protected domain from an unauthenticated node, whether the prote= cted domain is sent in a CFG payload, an HTTP resource, or a routing protoc= ol message is a security vulnerability. Accepting any valid certificate wit= hout pre-configuring the expected content (for example, "Subject must conta= in 'CN=3DTokyo Office' and Issuer must be xxxx") is no authentication at a= ll. The missing piece here is the propagation of the union protected domain inf= ormation among all the 1st tier nodes. This is fairly simple in a single en= terprise network where such nodes are managed centrally. I can also see how= in more heterogenous environments routing protocols could be used. Or the = WG can develop some new mechanism (although I don't think that's a good ide= a). I think this is more useful than requiring 2nd tier [1] devices to part= icipate in routing protocols. Yoav [1] I've often heard people use mobile phones as the ultimate example of lo= w-end, but looking at the specs of small-office gateways, many of them are = lower-spec than the average phone - under 1GB of memory, around 1GB of flas= h space, CPUs that are leftovers from last year's mobile phones.= From ynir@checkpoint.com Mon Feb 3 07:35:30 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DCB1A0153 for ; Mon, 3 Feb 2014 07:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psjWZsdYRftt for ; Mon, 3 Feb 2014 07:35:29 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A6FAC1A0137 for ; Mon, 3 Feb 2014 07:35:28 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s13FZQ87010178; Mon, 3 Feb 2014 17:35:26 +0200 X-CheckPoint: {52EFB077-2-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 17:35:26 +0200 From: Yoav Nir To: Michael Richardson Thread-Topic: [IPsec] AD-VPN Protocol Selection Thread-Index: Ac8g29viSNWMxCSdS+mwPoqNzCPObQABFYQAAAEmJwA= Date: Mon, 3 Feb 2014 15:35:25 +0000 Message-ID: <44042206-E996-487F-9451-F42643E2D823@checkpoint.com> References: <87BCDFB0B867FB4A85DB44EE8946E2458407E6F6@FSDEBSSXD111.fs01.vwf.vwfs-ad> <9636.1391439750@sandelman.ca> In-Reply-To: <9636.1391439750@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.37] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <0A428ADEE3871742926D7ACE76BED257@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Harms, Patrick" , "ipsec@ietf.org" Subject: Re: [IPsec] AD-VPN Protocol Selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:35:30 -0000 On Feb 3, 2014, at 5:02 PM, Michael Richardson wrot= e: >=20 > Harms, Patrick wrote: >> - is allowing to add 'spokes' without configuration changes on the 'hub' >> devices (8.1 dmvpn draft) >=20 >> For me, this is an important point. Changing the configuration on the hu= b >> routers, everytime a spoke is added to the network, would make the rollo= ut >> process to complex and is a possible source of failures. >=20 > I don't see how you can add a spoke in any system without requiring some > changes to at least one hub and/or the database/LDAP/etc. which keeps tra= ck > of all the spokes. 1. You set up a CA 2. You accept connections from anyone presenting a certificate from that C= A 3. You trust everything they tell you in routing protocols. As long as only well-behaved spokes get issued certificates, and they never= get compromised, everything is fine. >> Based on the theories (advpn draft and dmvpn) and real world experience >> (dmvpn), I would favor dmvpn, because the handling and operating sounds = less >> complex. (eg. lower amount of steps in tunnel initiation, single logical >> interface for tunnel termination etc.) >=20 > Do you care about mobile (handheld) devices? Hey, those are higher-specced than the dual-pentium III at 800MHz with 512 = MB or RAM that we were selling as a high-end gateway when I started working= at Check Point :-) Yoav From yaronf.ietf@gmail.com Mon Feb 3 19:37:04 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEC31A02E9 for ; Mon, 3 Feb 2014 19:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAFE1IJSzRbz for ; Mon, 3 Feb 2014 19:37:02 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B85271A0360 for ; Mon, 3 Feb 2014 19:37:02 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id uo5so7910723pbc.13 for ; Mon, 03 Feb 2014 19:37:02 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=OmLucGx/06iGLhhfKMPNorKwCAWgLT/JY6ERlhp0ejc=; b=TZSeqEWS5ltMlGJH9gTNsnlld/k7uG5h28TVLlQeGPm5EgpP9dJNWVUDkVoyO2A0na 8gQ5sTQSxWENZE9gG/RUc2zrd6lDCNGFUPKYGgyhXyvRVv/4PA8dJHtEC49MpBdKFvNx Td2P7rC0r13Qbsc/VAuFMpAlaAUTP/wt3HaOMBOpHn/Z+EKCso/4LBcDTV/KW4fJdziX 8kkPbCHmXXougXQwp5QDXuMrDIyuuwqEJiccC8bfPgmjqH4L4QvzL4lXaXTS+CG53LrY RIEwGe3Y7ccNh0DdELoFtjqPL/08RFBSAOv+Mn1UYNPqqj/qU8rgXCYe0p3TbX2KzFCZ decA== X-Received: by 10.68.183.228 with SMTP id ep4mr40865413pbc.67.1391485022590; Mon, 03 Feb 2014 19:37:02 -0800 (PST) Received: from [10.0.244.237] (205.158.165.68.ptr.us.xo.net. [205.158.165.68]) by mx.google.com with ESMTPSA id qw8sm61093477pbb.27.2014.02.03.19.37.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 19:37:01 -0800 (PST) Message-ID: <52F0605C.5020507@gmail.com> Date: Mon, 03 Feb 2014 19:37:00 -0800 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipsec References: <20140204033045.18512.74632.idtracker@ietfa.amsl.com> In-Reply-To: <20140204033045.18512.74632.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140204033045.18512.74632.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: New Version Notification for draft-sheffer-autovpn-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 03:37:04 -0000 Hi, Yoav and I just published this draft. The two main points are: - IPsec opportunistic encryption is also interesting between security gateways, not only between hosts. - With a bit of extra plumbing, opportunistic encryption can be "upgraded" post facto into full authentication. Comments are welcome on this list, but note that this is not proposed as a working group document. Thanks, Yaron -------- Original Message -------- Subject: New Version Notification for draft-sheffer-autovpn-00.txt Date: Mon, 03 Feb 2014 19:30:45 -0800 From: internet-drafts@ietf.org To: Yoav Nir , Yaron Sheffer , "Yaron Sheffer" , "Yoav Nir" A new version of I-D, draft-sheffer-autovpn-00.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-sheffer-autovpn Revision: 00 Title: The AutoVPN Architecture Document date: 2014-02-04 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-sheffer-autovpn-00.txt Status: https://datatracker.ietf.org/doc/draft-sheffer-autovpn/ Htmlized: http://tools.ietf.org/html/draft-sheffer-autovpn-00 Abstract: This document describes the AutoVPN architecture. AutoVPN allows IPsec security associations to be set up with no prior configuration, using the "leap of faith" paradigm. The document defines a lightweight protocol for negotiating such opportunistic encryption either directly between hosts or between two security gateways on the path. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From prvs=1055a6032=patrick.harms@vwfs.com Tue Feb 4 00:30:36 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252AF1A03A1 for ; Tue, 4 Feb 2014 00:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBGc6FRQUqie for ; Tue, 4 Feb 2014 00:30:33 -0800 (PST) Received: from mx1.vwfsag.de (mx1.vwfsag.de [193.25.183.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8331B1A018E for ; Tue, 4 Feb 2014 00:30:32 -0800 (PST) Received: from unknown (HELO gf-web-vsmgw2.fs01.vwf.vwfs-ad) ([10.41.77.141]) by sr-web-mgw2.fs01.vwf.vwfs-ad with ESMTP; 04 Feb 2014 09:30:32 +0100 Received: from gf-web-vsmgw2.fs01.vwf.vwfs-ad (localhost [127.0.0.1]) by gf-web-vsmgw2.fs01.vwf.vwfs-ad (VWFS) with ESMTP id C7D5222806E; Tue, 4 Feb 2014 09:30:31 +0100 (CET) Received: from FSDEBSSXC001.fs01.vwf.vwfs-ad (fsdebssxc001.fs01.vwf.vwfs-ad [10.43.13.175]) by gf-web-vsmgw2.fs01.vwf.vwfs-ad (VWFS) with ESMTP id B642522806D; Tue, 4 Feb 2014 09:30:31 +0100 (CET) Received: from FSDEBSSXD111.fs01.vwf.vwfs-ad ([169.254.5.32]) by FSDEBSSXC001.fs01.vwf.vwfs-ad ([10.43.13.175]) with mapi id 14.03.0158.001; Tue, 4 Feb 2014 09:30:31 +0100 From: "Harms, Patrick" To: 'Yoav Nir' , 'Michael Richardson' Thread-Topic: [IPsec] AD-VPN Protocol Selection Thread-Index: AQHPIPD5+kLkiqFxxkKIOq68LODxjZqjmHeAgAErH7A= Date: Tue, 4 Feb 2014 08:30:30 +0000 Message-ID: <87BCDFB0B867FB4A85DB44EE8946E2458407E7E9@FSDEBSSXD111.fs01.vwf.vwfs-ad> References: <87BCDFB0B867FB4A85DB44EE8946E2458407E6F6@FSDEBSSXD111.fs01.vwf.vwfs-ad> <9636.1391439750@sandelman.ca> <44042206-E996-487F-9451-F42643E2D823@checkpoint.com> In-Reply-To: <44042206-E996-487F-9451-F42643E2D823@checkpoint.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.43.0.124] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] AD-VPN Protocol Selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:30:36 -0000 Pj4NCj4+IEhhcm1zLCBQYXRyaWNrIDxQYXRyaWNrLkhhcm1zQHZ3ZnMuY29tPiB3cm90ZToNCj4+ PiAtIGlzIGFsbG93aW5nIHRvIGFkZCAnc3Bva2VzJyB3aXRob3V0IGNvbmZpZ3VyYXRpb24gY2hh bmdlcyBvbiB0aGUgJ2h1YicNCj4+PiBkZXZpY2VzICg4LjEgZG12cG4gZHJhZnQpDQo+Pg0KPj4+ IEZvciBtZSwgdGhpcyBpcyBhbiBpbXBvcnRhbnQgcG9pbnQuIENoYW5naW5nIHRoZSBjb25maWd1 cmF0aW9uIG9uIHRoZQ0KPj4+IGh1YiByb3V0ZXJzLCBldmVyeXRpbWUgYSBzcG9rZSBpcyBhZGRl ZCB0byB0aGUgbmV0d29yaywgd291bGQgbWFrZQ0KPj4+IHRoZSByb2xsb3V0IHByb2Nlc3MgdG8g Y29tcGxleCBhbmQgaXMgYSBwb3NzaWJsZSBzb3VyY2Ugb2YgZmFpbHVyZXMuDQo+Pg0KPj4gSSBk b24ndCBzZWUgaG93IHlvdSBjYW4gYWRkIGEgc3Bva2UgaW4gYW55IHN5c3RlbSB3aXRob3V0IHJl cXVpcmluZw0KPj4gc29tZSBjaGFuZ2VzIHRvIGF0IGxlYXN0IG9uZSBodWIgYW5kL29yIHRoZSBk YXRhYmFzZS9MREFQL2V0Yy4gd2hpY2gNCj4+IGtlZXBzIHRyYWNrIG9mIGFsbCB0aGUgc3Bva2Vz Lg0KPg0KPiAxLiBZb3Ugc2V0IHVwIGEgQ0ENCj4gMi4gWW91IGFjY2VwdCBjb25uZWN0aW9ucyBm cm9tIGFueW9uZSBwcmVzZW50aW5nIGEgY2VydGlmaWNhdGUgZnJvbSB0aGF0IENBICAzLiBZb3Ug dHJ1c3QgZXZlcnl0aGluZyB0aGV5IHRlbGwgeW91IGluIHJvdXRpbmcgcHJvdG9jb2xzLg0KDQpZ ZXMsIHRoYXQgaXMgb25lIG9mIG15IGlkZWFzLiBTZXQgdXAgYSBDQSB3aXRoIGFuIGF1dG8tZW5y b2xsbWVudCBwcm9jZXNzIGZvciB0aGUgY2VydGlmaWNhdGVzIChlZyBTQ0VQKS4NCk9mIGNvdXJz ZSwgaXQgaXMgdmVyeSBpbXBvcnRhbnQgdG8gaGF2ZSBhIHNvbGlkIHByb2Nlc3MgdG8gaGFuZGxl IHdpdGggY2VydGlmaWNhdGVzLCByb2xsb3V0cywgc3RvbGVuIGRldmljZXMsIG9wZXJhdGlvbnMg ZXRjLg0KDQo+QXMgbG9uZyBhcyBvbmx5IHdlbGwtYmVoYXZlZCBzcG9rZXMgZ2V0IGlzc3VlZCBj ZXJ0aWZpY2F0ZXMsIGFuZCB0aGV5IG5ldmVyIGdldCBjb21wcm9taXNlZCwgZXZlcnl0aGluZyBp cyBmaW5lLg0KPg0KPj4+IEJhc2VkIG9uIHRoZSB0aGVvcmllcyAoYWR2cG4gZHJhZnQgYW5kIGRt dnBuKSBhbmQgcmVhbCB3b3JsZA0KPj4+IGV4cGVyaWVuY2UgKGRtdnBuKSwgSSB3b3VsZCBmYXZv ciBkbXZwbiwgYmVjYXVzZSB0aGUgaGFuZGxpbmcgYW5kDQo+Pj4gb3BlcmF0aW5nIHNvdW5kcyBs ZXNzIGNvbXBsZXguIChlZy4gbG93ZXIgYW1vdW50IG9mIHN0ZXBzIGluIHR1bm5lbA0KPj4+IGlu aXRpYXRpb24sIHNpbmdsZSBsb2dpY2FsIGludGVyZmFjZSBmb3IgdHVubmVsIHRlcm1pbmF0aW9u IGV0Yy4pDQo+Pg0KPj4gRG8geW91IGNhcmUgYWJvdXQgbW9iaWxlIChoYW5kaGVsZCkgZGV2aWNl cz8NCj4NCj5IZXksIHRob3NlIGFyZSBoaWdoZXItc3BlY2NlZCB0aGFuIHRoZSBkdWFsLXBlbnRp dW0gSUlJIGF0IDgwME1IeiB3aXRoIDUxMiBNQiBvciBSQU0gdGhhdCB3ZSB3ZXJlIHNlbGxpbmcg YXMgYSBoaWdoLWVuZCBnYXRld2F5IHdoZW4gSSBzdGFydGVkIHdvcmtpbmcgYXQgQ2hlY2sgUG9p bnQgOi0pDQo+DQo+WW9hdg0KDQpJIGFtIG9uIHRoZSBsdWNreSBzaWRlLCBhbmQgZG8gbm90IGhh dmUgdG8gY2FyZSBhYm91dCBoYW5kaGVsZCBkZXZpY2VzLg0KDQoNClBhdHJpY2sNClZvbGtzd2Fn ZW4gRmluYW5jaWFsIFNlcnZpY2VzIEFHDQpTaXR6L1JlZ2lzdGVyZWQgc2VhdDogQnJhdW5zY2h3 ZWlnDQpSZWdpc3RlcmdlcmljaHQvUmVnaXN0cmF0aW9uIGNvdXJ0OiBBbXRzZ2VyaWNodCBCcmF1 bnNjaHdlaWcNCkhSQiBOci4vQ29tbWVyY2lhbCBSZWdpc3RlciBOby46IDM3OTANClZvcnNpdHpl bmRlciBkZXMgQXVmc2ljaHRzcmF0cy9DaGFpcm1hbiBvZiB0aGUgU3VwZXJ2aXNvcnkgQm9hcmQ6 IEhhbnMgRGlldGVyIFDDtnRzY2gNClZvcnN0YW5kL0JvYXJkIG9mIE1hbmFnZW1lbnQ6IEZyYW5r IFdpdHRlciAoVm9yc2l0emVuZGVyL0NoYWlybWFuKSwgRHIuIE1hcmlvIERhYmVya293LCBGcmFu ayBGaWVkbGVyLCBDaHJpc3RpYW5lIEhlc3NlLCBEci4gTWljaGFlbCBSZWluaGFydCwgTGFycy1I ZW5uZXIgU2FudGVsbWFubg0KDQpXaWNodGlnZXIgSGlud2VpczogRGllIHZvcmdlbmFubnRlbiBB bmdhYmVuIHdlcmRlbiBqZWRlciBFLU1haWwgYXV0b21hdGlzY2ggaGluenVnZWbDvGd0IHVuZCBs YXNzZW4ga2VpbmUgUsO8Y2tzY2hsw7xzc2UgYXVmIGRlbiBSZWNodHNjaGFyYWt0ZXIgZGVyIEUt TWFpbCB6dS4NCkltcG9ydGFudCBub3RlOiBUaGUgYWJvdmUgaW5mb3JtYXRpb24gaXMgYXV0b21h dGljYWxseSBhZGRlZCB0byB0aGlzIGUtbWFpbC4gVGhpcyBhZGRpdGlvbiBkb2VzIG5vdCBjb25z dGl0dXRlIGEgcmVwcmVzZW50YXRpb24gdGhhdCB0aGUgY29udGVudCBvZiB0aGlzIGUtbWFpbCBp cyBsZWdhbGx5IHJlbGV2YW50IGFuZC9vciBpcyBpbnRlbmRlZCB0byBiZSBsZWdhbGx5IGJpbmRp bmcgdXBvbiBWb2xrc3dhZ2VuIEZpbmFuY2lhbCBTZXJ2aWNlcyBBRy4NCg== From mcr@sandelman.ca Tue Feb 4 07:39:14 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F451A012A for ; Tue, 4 Feb 2014 07:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.009 X-Spam-Level: * X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMzLd2poDPte for ; Tue, 4 Feb 2014 07:39:12 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id F00F51A00E2 for ; Tue, 4 Feb 2014 07:39:11 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8E9AC2002F for ; Tue, 4 Feb 2014 11:56:06 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 22F22647C9; Tue, 4 Feb 2014 10:39:11 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0E6A9647C8 for ; Tue, 4 Feb 2014 10:39:11 -0500 (EST) From: Michael Richardson To: "'ipsec\@ietf.org'" In-Reply-To: <87BCDFB0B867FB4A85DB44EE8946E2458407E7E9@FSDEBSSXD111.fs01.vwf.vwfs-ad> References: <87BCDFB0B867FB4A85DB44EE8946E2458407E6F6@FSDEBSSXD111.fs01.vwf.vwfs-ad> <9636.1391439750@sandelman.ca> <44042206-E996-487F-9451-F42643E2D823@checkpoint.com> <87BCDFB0B867FB4A85DB44EE8946E2458407E7E9@FSDEBSSXD111.fs01.vwf.vwfs-ad> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [IPsec] AD-VPN Protocol Selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:39:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Harms, Patrick wrote: >>>> Based on the theories (advpn draft and dmvpn) and real world >>>> experience (dmvpn), I would favor dmvpn, because the handling and >>>> operating sounds less complex. (eg. lower amount of steps in tunnel >>>> initiation, single logical interface for tunnel termination etc.) >>> Do you care about mobile (handheld) devices? Yoav> Hey, those are higher-specced than the dual-pentium III at 800MHz with Yoav> 512 MB or RAM that we were selling as a high-end gateway when I Yoav> started working at Check Point :-) Yoav, your statement is nonsense. It tells me that you have done no mobile development at all. I have. I've done IPsec on them too. It's not about the amount of ram that they, or the speed of the device. It about the access to the kernel. Tell me, if I had you a corporate laptop computer (any specs you like), for you which you can not install any device drivers or do anything as root or "administrator", can you install your VPN software?=20=20=20 Now, if I give you just enough root so that you can have a PF_KEY socket, c= an you make something work? =2D-=20 Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUvEJnIqHRg3pndX9AQLi7AQAwa6IkV3D9u/yR08wWiTrzf31POjoN6jo tlkVvo4vPm4n5YpFN4e2gxCMhm8Qhrd51OrEuYFgAEpoIKDG2WUQh0flya7ciuIF MoDGkFb4+v1YDGPbWNjBkoTJxA8OY9Peixv5FepMgqjuzYzb7rER1fpHa6goiLw0 JHloF1566qg= =hwYQ -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Tue Feb 4 09:40:21 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C041E1A016A for ; Tue, 4 Feb 2014 09:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmsLDPKZBRnI for ; Tue, 4 Feb 2014 09:40:20 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A2A821A0135 for ; Tue, 4 Feb 2014 09:40:19 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s14HeF5J016596; Tue, 4 Feb 2014 19:40:16 +0200 X-CheckPoint: {52F11F28-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 19:40:15 +0200 From: Yoav Nir To: Michael Richardson Thread-Topic: [IPsec] AD-VPN Protocol Selection Thread-Index: Ac8g29viSNWMxCSdS+mwPoqNzCPObQABFYQAAAEmJwAAI3OzAAAO+LqAAAQ6RgA= Date: Tue, 4 Feb 2014 17:40:14 +0000 Message-ID: <848B3692-7B9A-4EE2-AFDE-81195849111C@checkpoint.com> References: <87BCDFB0B867FB4A85DB44EE8946E2458407E6F6@FSDEBSSXD111.fs01.vwf.vwfs-ad> <9636.1391439750@sandelman.ca> <44042206-E996-487F-9451-F42643E2D823@checkpoint.com> <87BCDFB0B867FB4A85DB44EE8946E2458407E7E9@FSDEBSSXD111.fs01.vwf.vwfs-ad> <3185.1391528351@sandelman.ca> In-Reply-To: <3185.1391528351@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.85] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <904726688063D347B04AE608B87BCC3F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD-VPN Protocol Selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 17:40:22 -0000 On Feb 4, 2014, at 5:39 PM, Michael Richardson wrot= e: >=20 > Harms, Patrick wrote: >>>>> Based on the theories (advpn draft and dmvpn) and real world >>>>> experience (dmvpn), I would favor dmvpn, because the handling and >>>>> operating sounds less complex. (eg. lower amount of steps in tunnel >>>>> initiation, single logical interface for tunnel termination etc.) >=20 >>>> Do you care about mobile (handheld) devices? >=20 > Yoav> Hey, those are higher-specced than the dual-pentium III at 800MHz w= ith > Yoav> 512 MB or RAM that we were selling as a high-end gateway when I > Yoav> started working at Check Point :-) >=20 > Yoav, your statement is nonsense. > It tells me that you have done no mobile development at all. > I have. I've done IPsec on them too. >=20 > It's not about the amount of ram that they, or the speed of the device. > It about the access to the kernel. Access to the kernel is at the discretion of the OS vendor. Both Microsoft = and Apple are increasingly limiting the access that application developers = have on so-called "desktop" operating systems. > Tell me, if I had you a corporate laptop computer (any specs you like), f= or > you which you can not install any device drivers or do anything as root o= r > "administrator", can you install your VPN software? I could not. Could you do it on Windows Phone 8 (that does not have its own= native IPsec)? > Now, if I give you just enough root so that you can have a PF_KEY socket,= can > you make something work? I could maybe make IPsec work, but not likely a GRE tunnel. However, Apple = can do it on iOS, Microsoft can do it on Windows Phone, and a bunch of vend= ors can do it on Android. Big vendors like Cisco could probably get their c= lient software to be blessed by the OS vendor. Tough? Yes, but it's gettin= g harder to develop for the likes of Mavericks and Windows 8.1 as well. I'm not sure where you see a fundamental difference between desktop operati= ng systems and mobile ones. They're all as locked down as the vendor wants = them to be, and getting more locked down. Yoav From timo.teras@gmail.com Wed Feb 5 03:50:18 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCAE1A00F2 for ; Wed, 5 Feb 2014 03:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kLZ8FuNBfe4 for ; Wed, 5 Feb 2014 03:50:15 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCB81A00B2 for ; Wed, 5 Feb 2014 03:50:15 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id p9so216650lbv.20 for ; Wed, 05 Feb 2014 03:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=f4UB1TwDN1okYlqUOk1Rt5aXKC8dgPftGThqTVhFhrk=; b=eLg5qTyP1DotCGdBkGlzohS0q3AKnsbovX2J4Xm+fwMxSyFBkjUdOESTPBpaU+m8II l+N96eUWq9SZKC/XZwcf96SFlnpw2/ONCC0fLuqwFzdQlvrTEQEtHokRA1DfQwSsD3Gz 52X00Eblo1ndzjBqQuUa8ktPGaiKjqr25bxh2h8kWZKYuweEMlPdtqbij95E75b6+bdW 4duqbCqWeeC8n93hFJ3JmErTXS+gDxc34cYuuexZXd2qbvjfIo3B+UwADP4phHQH0S6H MzZubkysvGo3bL1UchERblF27PTjq/mQt/kY8TSUz6kNKLLbbapMjsSYhn0qBWw6/TO9 81kA== X-Received: by 10.152.205.11 with SMTP id lc11mr761589lac.29.1391601013778; Wed, 05 Feb 2014 03:50:13 -0800 (PST) Received: from vostro ([2001:1bc8:101:f402:21c:23ff:fefc:bf0b]) by mx.google.com with ESMTPSA id ya9sm11545664lbb.2.2014.02.05.03.50.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Feb 2014 03:50:13 -0800 (PST) Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= Date: Wed, 5 Feb 2014 13:50:46 +0200 From: Timo Teras To: Praveen Sathyanarayan Message-ID: <20140205135046.61c4f7a5@vostro> In-Reply-To: References: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.20; i486-alpine-linux-uclibc) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: " WG" , "Frederic Detienne \(fdetienn\)" Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 11:50:18 -0000 On Mon, 20 Jan 2014 18:14:58 +0000 Praveen Sathyanarayan wrote: > 1.2 What happens when a prefix administratively changes from behind > one branch to another ? How do servers get notified about that ? >=20 > [PRAVEEN] That=E2=80=99s an interesting point Fred, and thanks for bringi= ng > it up. First, please refer the ADVPN_INFO Payload and > PROTECTED_DOMAIN sections (3.6 and 3.9, respectively) of > http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03. As a > general rule, each spoke can download updated PROTECTED_DOMAIN > information periodically, which advertises everything behind the hub > and all other spokes combined. Of course, this does not change if > some subnet has moved from behind spoke A to behind another spoke, B. > However, the Lifetime attribute of the ADVPN_INFO payload is key > here. We could see this being employed in a straightforward manner to > allow for this transition: a) the subnet can "disappear" and be > unreachable for one Lifetime, or b) the original spoke can redirect > to the new spoke. >=20 > We don't think this matters much in the real world, because people > don't just move entire subnets instantaneously. Typically, folks stop > using a subnet in one place, then begin using it in another. This > makes a lot of sense for several operational reasons, as you would > imagine. In fact, experience shows that since routing doesn't update > across the world immediately, best practice would, for instance, > indicate that it=E2=80=99s best to wait a day between stopping using the > subnet in one place and starting to use it in another place. In this > case, a Lifetime of one day or less should be just fine (and we=E2=80=99re > thinking that, in fact, an hour would be a reasonable Lifetime value > in practice). >=20 > We would indeed argue that using Lifetime allows us to make the basic > implementation of ADVPN handle a transition from one administrative > domain to another in a straightforward manner. A redirection based on > RFC5685 re-uses an already defined mechanism and makes the transition > immediate, if/when necessary. This is one more argument for > draft-sathyanarayan-ipsecme-advpn as it illustrates the modularity of > our ADVPN proposal _and_ keeps the implementation simple. I disagree. IMGO, dynamically routing subnets is a MUST. Multiple scenarios exist. But to name one: I have complex site with multiple internal links and dynamic internal routing connected to ADVPN via two or more spokes (connected via different ISP lines). All the spokes can route to all subnets inside that site to provide redundancy, and in some cases load balancing. If one spoke's ISP line dies, or if the internal routing protocol decides other wise (e.g. intra-site link fails), the spokes should dynamically move the subnet from one to another. Having a failover time of _a day_ is unacceptable. The redirect mechanism seems to be limited to client-gateway connections, and only the gateway can send it (rfc5685 point 10). This is not true in advpn context as any spoke may want to later on redirect the SA of subnet it originally initiated. Using redirect would need additional specifications to be usable. Then there is also the case of load balancing... etc. I do agree that subnets should be authorized to be routed. I do that in existing dmvpn install, by means of automatically filtering the announced routes based on the presented certificate. That is, the certificate tells which subnets it can announce. - Timo From fdetienn@cisco.com Wed Feb 5 05:42:34 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0061A014D for ; Wed, 5 Feb 2014 05:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFDK4AUv5XQS for ; Wed, 5 Feb 2014 05:42:32 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9B71A0121 for ; Wed, 5 Feb 2014 05:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2537; q=dns/txt; s=iport; t=1391607752; x=1392817352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qxYWASyQsEuIptHoe31g6Nb3lCPzrPLk1wrji89lLRU=; b=VqeAPnW9rCfR9wnKp2obW7bP8mlx4fGPbEj6SH5f2xpPWIJa+455kkNb isZpiq1/F41VEuChTIh1rnz/VYJm32KvxVGfPupquGCeaFqAnf/Wu9+Qd iRenhb8EC7YipRstMrCtQG4V2zAPWAD/MsM8yAdtjZfCS8zZNBQv9UWy0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFALM+8lKtJV2c/2dsb2JhbABZgww4V75DgQ8WdIImAQEEAQEBawsQAgEIRicLJQIEDgWIBQ3PKhMEjkIzB4MkgRQEiRGLMYNpkiGBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="scan'208";a="301828781" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 05 Feb 2014 13:42:31 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s15DgV7D009001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 13:42:31 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.227]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 07:42:31 -0600 From: "Frederic Detienne (fdetienn)" To: Praveen Sathyanarayan Thread-Topic: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 Thread-Index: AQHPG4MvdTmd1tpwSEqyl/V9y2lTr5qnHckA Date: Wed, 5 Feb 2014 13:42:30 +0000 Message-ID: <391C56E9-3E82-47BD-94E2-817105A06BEF@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.74.184] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " WG" Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 13:42:34 -0000 Hi Praveen, Sorry about the delay. I am just back from our EMEA company event and have = been a lot busier than I planned. > [PRAVEEN] For one-liner question, we could only imagine the scenario that > you are trying to solve. And this is what we could come up. May be you ca= n > provide more detailed question on what scenario you would like to solve. > We could help in answering those scenarios. >=20 > When admin changes the prefix of a spoke, spoke=B9s existing static tunne= l > with Hub, gets re-negotatiaged for updated prefix in Tsi/TSr payload. Thi= s > event updates the Hub about changed prefix information. Is that what you > wanted to know?=20 Yes, this is the information I was looking for. So in a nutshell, when a pr= efix in spoke network is changed, it takes an additional change in the cent= ral DB and a tear down of the tunnels. This is not very attractive compared to a routing protocol which can do it = instantly and without affecting the other prefixes. Especially in the prese= nce of a large number of prefixes behind spoke(s). Also, I am taking it that there is one such file per spoke ? Or is it one b= ig file containing all the spoke prefixes ? >>=20 >> Before going any further, is this resource exclusively exchanged between >> hub & spoke or also between spokes ? >=20 >=20 > [PRAVEEN] =B3resource=B2 you means ADVPN_INFO payload or Subnet informati= on? > ADVPN_INFO exchanged between spokes. Subnet information exchanged part of > Tsi and TSr during IKE negotiation (which means between hub & spoke and > between spokes as well). I mean the ADVPN_INFO pointing to the URL with the list of prefixes. The question is now: who has access to those resources ? Who can update the= file(s) on the fileserver(s) ? This raises the whole question about role b= ased management. It also means the change management is now quite complex since in order to = update spoke prefixes you also have to change the central prefix files. One of the requirements which was "no change on the central devices when ad= ding a branch" is in contradiction with this method. OTOH, I am pondering t= hat the spokes could automatically update the central file(s) in which case= it would not be very different from a routing protocol... thanks, fred >>=20 >> thanks, >>=20 >> fred >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >>=20 >=20 >=20 From fdetienn@cisco.com Wed Feb 5 05:45:20 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE731A012D for ; Wed, 5 Feb 2014 05:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMgxz8BUIQed for ; Wed, 5 Feb 2014 05:45:18 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id B350D1A0121 for ; Wed, 5 Feb 2014 05:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1964; q=dns/txt; s=iport; t=1391607918; x=1392817518; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BBhWHiL8XihotWcOaSq1gDvbiAtK4y1Htc5nydx9wPU=; b=CPtYv6w9jCQExDtDMta+pIAyNC6sF/HcJVPBtygsQolYQ3TsPJJJT53F BAJKlx/bzxgNOmKr/6jNf8H7hY6WQechvPJzE5xtA5QRhu6vxxVrDyFN4 PBksM41Xz5/CRbeobYvELwFZIXTIXPWx6zbpuiz5xALJqq8RMYj3mdzpu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAHw/8lKtJV2b/2dsb2JhbABZgwyBD75DgQ8WdIIlAQEBAwF5BQsCAQgOCi4yJQIEDgUbh2IIzzgXjkIzB4MkgRQBA5grkiGBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="scan'208";a="18134074" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 05 Feb 2014 13:45:17 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s15DjH8x019710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 13:45:17 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.227]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 07:45:17 -0600 From: "Frederic Detienne (fdetienn)" To: Yoav Nir Thread-Topic: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 Thread-Index: AQHPG4MvdTmd1tpwSEqyl/V9y2lTr5qkFtcAgAMHuAA= Date: Wed, 5 Feb 2014 13:45:16 +0000 Message-ID: <574468F8-9203-451C-A145-C9E1DD51D781@cisco.com> References: <88259CEC-4D10-48EC-8A21-0D2F348EEE3F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.74.184] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " WG" , Praveen Sathyanarayan Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 13:45:20 -0000 On 03 Feb 2014, at 16:28, Yoav Nir wrote: > [=85] > The missing piece here is the propagation of the union protected domain i= nformation among all the 1st tier nodes. This is fairly simple in a single = enterprise network where such nodes are managed centrally. I can also see h= ow in more heterogenous environments routing protocols could be used. Or th= e WG can develop some new mechanism (although I don't think that's a good i= dea). I think this is more useful than requiring 2nd tier [1] devices to pa= rticipate in routing protocols. this is precisely one of the major complains against draft-sathyanarayan. I= t translates into multiple forms at various levels. Some things can work in some use cases but it forever needs development for= other use cases. The changes between v0 and v3 are significant and they wi= ll keep augmenting. We can no longer call that a simple solution. There are pieces that meet so= me of the requirements but are in contradiction with others. Similarly, draft-sathyanarayan offers multiple implementation or deployment= systems (policy based or tunnel based) which are not compatible at protoco= l level. It means implementations have to cover BOTH methods to guarantee i= nteroperability. To take a practical example: one domain may initially be rule based, the ot= her tunnel based. What happens when those domains must now cooperate ? Both issues above will prevent proper cross-domain interoperability. In par= ticular, a "policy-based" spoke will not be able to talk to a "tunnel based= " hub as per this draft=85 it would take a decision as to which is the fall= back mode and a dual implementation on at least one of the devices. In draft-detienne, the tunnels between the hubs need to support one of the = existing routing protocols (we would recommend BGP for large domains). This= guarantees interoperability end-to-end. thanks, fred From Jim.Montgomery@eircomni.co.uk Wed Feb 5 10:08:27 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B94D1A0154 for ; Wed, 5 Feb 2014 10:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq6rJ7xa3qbP for ; Wed, 5 Feb 2014 10:08:23 -0800 (PST) Received: from mail.eircomni.co.uk (mail.eircomni.co.uk [86.47.140.229]) by ietfa.amsl.com (Postfix) with SMTP id 9920C1A01BB for ; Wed, 5 Feb 2014 10:08:21 -0800 (PST) Received: by mail.eircomni.co.uk (Postfix, from userid 110) id 44E33198520; Wed, 5 Feb 2014 18:08:20 +0000 (GMT) Received: from mail.eircomni.co.uk (localhost [127.0.0.1]) by mail.eircomni.co.uk (Postfix) with ESMTP id 1201419851C for ; Wed, 5 Feb 2014 18:08:20 +0000 (GMT) X-Virus-Scanned: by SpamTitan at eircomni.co.uk Received: from BA-CP-EX-1.eircomni.co.uk (ba-cp-ex-1.eircomni.co.uk [172.24.226.13]) by mail.eircomni.co.uk (Postfix) with ESMTP id 7B41F1984C4 for ; Wed, 5 Feb 2014 18:08:16 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF229D.3DEBD4A4" Date: Wed, 5 Feb 2014 18:08:15 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD-VPN Protocol Selection Thread-Index: Ac8inT1mikfisbEwQTC4KRsHx8Y9FQ== From: "Jim Montgomery" To: Subject: [IPsec] AD-VPN Protocol Selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 18:11:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF229D.3DEBD4A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I am the an Architect for a Service Provider and we commonly deploy large scale Encryption Domains for Government and Security conscious Enterprise customers over typically insecure mediums such as Microwave Radio, xDSL, EFM and FTTC type products. =20 Our preference is draft-detienne-dmvpn-00 to be used. Having multiple deployments of DMVPN, we find DMVPN a mature protocol with enhanced functionality required to deliver complex dynamic VPN networks. =20 We would have some functional requirements in any dynamic encryption protocol, including: * Layer 2 functionality - the lack Layer 2 connectivity within ADVPN means we cannot run MPLS over encryption mechanisms presents significant challenges in delivering full service provider and large scale VRF deployments across encryption domains. In addition the lack of support for VPLS and EoMPLS functionality would cause a concern. * Multicast - Full native support for Multicast, including routing protocols and RPF checks are essential. We have multiple customer deployments where multicast support is a critical requirement as many business critical application run over Multicast. * Dynamic Routing Protocol/Metrics - The ability to deploy dynamic routing protocols with routing metrics and route computation is a fundamental requirement. We have concerns over the support IGP protocols, routing metrics and VLSM within ADVPN. * Rapid Spoke to Spoke tunnels - The ability to deploy rapid spoke to spoke tunnels for real time applications is essential, especially in a multi tiered hub deployment. We don't believe the deployment of ADVPN meets this requirement suitably. =20 Our preference is clearly for DMVPN as it does not try to make IKE a routing protocol and supports all existing routing protocols, along with native Multicast Support and Layer 2 connectivity. DMVPN delivers all the functionality and protocol support we require to deploy dynamic VPN overlays. We would have concerns over any protocol that doesn't support these features. =20 Regards, Jim=20 The information contained in this e-mail and any files transmitted =0Awith = it is confidential and may be subject to legal professional =0Aprivilege. It= is intended solely for the use of the addressee(s). =0AIf you are not the i= ntended recipient of this e-mail, please note =0Athat any review, disseminat= ion, disclosure, alteration, printing, =0Acopying or transmission of this e-= mail and/or any file transmitted =0Awith it, is prohibited and may be unlawf= ul. =0AIf you have received this e-mail by mistake, please promptly =0Ainfor= m the sender by reply e-mail and delete the material. =0AWhilst this e-mail = message has been swept for the presence of =0Acomputer viruses, eircom (UK) = Limited does not, except as required by law, =0Arepresent, warrant and/or gu= arantee that the integrity =0Aof this communication has been maintained nor = that =0Athe communication is free of errors, viruses, interception or =0Aint= erference. =0A =0Aeircom (UK) Limited. Private Company Limited by Shares. = =0ARegistered in England and Wales. Registration Number 03478971. =0ARegiste= red Office - South Quay, Plaza 2, 183 Marsh Wall, London, E14 9SH. ------_=_NextPart_001_01CF229D.3DEBD4A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I am the an = Architect for a Service Provider and we commonly deploy large scale = Encryption Domains for Government and Security conscious Enterprise = customers over typically insecure mediums such as Microwave Radio, xDSL, = EFM and FTTC type products.

 

Our = preference is draft-detienne-dmvpn-00 to be used. Having multiple = deployments of DMVPN, we find DMVPN a mature protocol with enhanced = functionality required to deliver complex dynamic VPN = networks.

 

We would have some functional requirements in any = dynamic encryption protocol, including:

·         = Layer 2 functionality – the lack = Layer 2 connectivity within ADVPN means we cannot run MPLS over = encryption mechanisms presents significant challenges in delivering full = service provider and large scale VRF deployments across encryption = domains.  In addition the lack of support for VPLS and EoMPLS = functionality would cause a concern.

·         = Multicast – Full native support for = Multicast, including routing protocols and RPF checks are = essential.  We have multiple customer deployments where multicast = support is a critical requirement as many business critical application = run over Multicast.

·         = Dynamic Routing Protocol/Metrics – = The ability to deploy dynamic routing protocols with routing metrics and = route computation is a fundamental requirement.  We have concerns = over the support IGP protocols, routing metrics and VLSM within = ADVPN.

·         = Rapid Spoke to Spoke tunnels – The = ability to deploy rapid spoke to spoke tunnels for real time = applications is essential, especially in a multi tiered hub = deployment.  We don’t believe the deployment of ADVPN meets = this requirement suitably.

 

Our = preference is clearly for DMVPN as it does not try to make IKE a routing = protocol and supports all existing routing protocols, along with native = Multicast Support and Layer 2 connectivity.  DMVPN delivers all the = functionality and protocol support we require to deploy dynamic VPN = overlays.  We would have concerns over any protocol that = doesn’t support these features.

 

Regards,

Jim


= The information contained in this e-mail and any files transmitted =0Awith = it is confidential and may be subject to legal professional =0Aprivilege. It= is intended solely for the use of the addressee(s). =0AIf you are not the i= ntended recipient of this e-mail, please note =0Athat any review, disseminat= ion, disclosure, alteration, printing, =0Acopying or transmission of this e-= mail and/or any file transmitted =0Awith it, is prohibited and may be unlawf= ul. =0AIf you have received this e-mail by mistake, please promptly =0Ainfor= m the sender by reply e-mail and delete the material. =0AWhilst this e-mail = message has been swept for the presence of =0Acomputer viruses, eircom (UK) = Limited does not, except as required by law, =0Arepresent, warrant and/or gu= arantee that the integrity =0Aof this communication has been maintained nor = that =0Athe communication is free of errors, viruses, interception or =0Aint= erference. =0A =0Aeircom (UK) Limited. Private Company Limited by Shares. = =0ARegistered in England and Wales. Registration Number 03478971. =0ARegiste= red Office - South Quay, Plaza 2, 183 Marsh Wall, London, E14 9SH.
= ------_=_NextPart_001_01CF229D.3DEBD4A4-- From praveenys@juniper.net Wed Feb 5 11:27:57 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5441A0122 for ; Wed, 5 Feb 2014 11:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5NEGwfycDrP for ; Wed, 5 Feb 2014 11:27:55 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 13F3D1A0117 for ; Wed, 5 Feb 2014 11:27:54 -0800 (PST) Received: from mail145-tx2-R.bigfish.com (10.9.14.232) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Wed, 5 Feb 2014 19:27:54 +0000 Received: from mail145-tx2 (localhost [127.0.0.1]) by mail145-tx2-R.bigfish.com (Postfix) with ESMTP id 2008D2C02C6; Wed, 5 Feb 2014 19:27:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(z579ehzbb2dI98dI9371Ic89bh1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h942he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h1155h) Received-SPF: pass (mail145-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(189002)(199002)(51704005)(164054003)(479174003)(377454003)(59766001)(47446002)(86362001)(74662001)(74502001)(74876001)(47736001)(94316002)(80022001)(56816005)(54316002)(56776001)(65816001)(66066001)(90146001)(74366001)(74706001)(63696002)(69226001)(94946001)(81342001)(93136001)(81542001)(79102001)(76482001)(93516002)(31966008)(49866001)(36756003)(15975445006)(77982001)(85306002)(80976001)(19580395003)(85852003)(83506001)(92726001)(87266001)(92566001)(83072002)(87936001)(81816001)(81686001)(19580405001)(47976001)(50986001)(2656002)(76786001)(76796001)(53806001)(4396001)(51856001)(46102001)(54356001)(83322001)(95416001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB667; H:CO2PR05MB665.namprd05.prod.outlook.com; CLIP:66.129.239.15; FPR:EEF7C12E.AFB66110.37D0F1BB.48D6D149.2051D; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail145-tx2 (localhost.localdomain [127.0.0.1]) by mail145-tx2 (MessageSwitch) id 1391628471613787_6112; Wed, 5 Feb 2014 19:27:51 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.230]) by mail145-tx2.bigfish.com (Postfix) with ESMTP id 7EA8E60087; Wed, 5 Feb 2014 19:27:51 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 5 Feb 2014 19:27:50 +0000 Received: from CO2PR05MB667.namprd05.prod.outlook.com (10.141.230.23) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Wed, 5 Feb 2014 19:27:48 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB667.namprd05.prod.outlook.com (10.141.230.23) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 19:27:46 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 19:27:46 +0000 From: Praveen Sathyanarayan To: "Frederic Detienne (fdetienn)" Thread-Topic: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 Thread-Index: AQHPGFBmIvsjxkaNukGJzmUJkO7gl5qYT5OAgA5wBgD//9fIgA== Date: Wed, 5 Feb 2014 19:27:46 +0000 Message-ID: References: <391C56E9-3E82-47BD-94E2-817105A06BEF@cisco.com> In-Reply-To: <391C56E9-3E82-47BD-94E2-817105A06BEF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.15] x-forefront-prvs: 01136D2D90 Content-Type: text/plain; charset="euc-kr" Content-ID: <666FB6710722A04084045A4E9B8A99AD@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: " WG" Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 19:27:57 -0000 SGkgRnJlZCwNCg0KTXkgY29tbWVudHMgaW5saW5lLg0KDQpUaGFua3MsDQpQcmF2ZWVuDQoNCk9u IDIvNS8xNCwgNTo0MiBBTSwgIkZyZWRlcmljIERldGllbm5lIChmZGV0aWVubikiIDxmZGV0aWVu bkBjaXNjby5jb20+DQp3cm90ZToNCg0KSGkgUHJhdmVlbiwNCg0KU29ycnkgYWJvdXQgdGhlIGRl bGF5LiBJIGFtIGp1c3QgYmFjayBmcm9tIG91ciBFTUVBIGNvbXBhbnkgZXZlbnQgYW5kIGhhdmUN CmJlZW4gYSBsb3QgYnVzaWVyIHRoYW4gSSBwbGFubmVkLg0KDQo+IFtQUkFWRUVOXSBGb3Igb25l LWxpbmVyIHF1ZXN0aW9uLCB3ZSBjb3VsZCBvbmx5IGltYWdpbmUgdGhlIHNjZW5hcmlvIHRoYXQN Cj4geW91IGFyZSB0cnlpbmcgdG8gc29sdmUuIEFuZCB0aGlzIGlzIHdoYXQgd2UgY291bGQgY29t ZSB1cC4gTWF5IGJlIHlvdQ0KPmNhbg0KPiBwcm92aWRlIG1vcmUgZGV0YWlsZWQgcXVlc3Rpb24g b24gd2hhdCBzY2VuYXJpbyB5b3Ugd291bGQgbGlrZSB0byBzb2x2ZS4NCj4gV2UgY291bGQgaGVs cCBpbiBhbnN3ZXJpbmcgdGhvc2Ugc2NlbmFyaW9zLg0KPiANCj4gV2hlbiBhZG1pbiBjaGFuZ2Vz IHRoZSBwcmVmaXggb2YgYSBzcG9rZSwgc3Bva2Wp9nMgZXhpc3Rpbmcgc3RhdGljIHR1bm5lbA0K PiB3aXRoIEh1YiwgZ2V0cyByZS1uZWdvdGF0aWFnZWQgZm9yIHVwZGF0ZWQgcHJlZml4IGluIFRz aS9UU3IgcGF5bG9hZC4NCj5UaGlzDQo+IGV2ZW50IHVwZGF0ZXMgdGhlIEh1YiBhYm91dCBjaGFu Z2VkIHByZWZpeCBpbmZvcm1hdGlvbi4gSXMgdGhhdCB3aGF0IHlvdQ0KPiB3YW50ZWQgdG8ga25v dz8gDQoNClllcywgdGhpcyBpcyB0aGUgaW5mb3JtYXRpb24gSSB3YXMgbG9va2luZyBmb3IuIFNv IGluIGEgbnV0c2hlbGwsIHdoZW4gYQ0KcHJlZml4IGluIHNwb2tlIG5ldHdvcmsgaXMgY2hhbmdl ZCwgaXQgdGFrZXMgYW4gYWRkaXRpb25hbCBjaGFuZ2UgaW4gdGhlDQpjZW50cmFsIERCIGFuZCBh IHRlYXIgZG93biBvZiB0aGUgdHVubmVscy4NCg0KVGhpcyBpcyBub3QgdmVyeSBhdHRyYWN0aXZl IGNvbXBhcmVkIHRvIGEgcm91dGluZyBwcm90b2NvbCB3aGljaCBjYW4gZG8gaXQNCmluc3RhbnRs eSBhbmQgd2l0aG91dCBhZmZlY3RpbmcgdGhlIG90aGVyIHByZWZpeGVzLiBFc3BlY2lhbGx5IGlu IHRoZQ0KcHJlc2VuY2Ugb2YgYSBsYXJnZSBudW1iZXIgb2YgcHJlZml4ZXMgYmVoaW5kIHNwb2tl KHMpLg0KDQpBbHNvLCBJIGFtIHRha2luZyBpdCB0aGF0IHRoZXJlIGlzIG9uZSBzdWNoIGZpbGUg cGVyIHNwb2tlID8gT3IgaXMgaXQgb25lDQpiaWcgZmlsZSBjb250YWluaW5nIGFsbCB0aGUgc3Bv a2UgcHJlZml4ZXMgPw0KDQoNCltQUkFWRUVOXSBJIHRoaW5rIHlvdSBkaWRuoa90IGdldCBteSBh bnN3ZXIuIFdoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheSBpcywNCmlmIHRoZXJlIGlzIGEgbmV0d29y ayBwcmVmaXggY2hhbmdlIG9uIHRoZSBzcG9rZSBzaWRlLCBTcG9rZSByZW5lZ290aWF0ZXMNCndp dGggSHViIChDaGlsZCBTQSByZWtleSBoYXMgVFNpIGFuZCBUc3IgcGF5bG9hZCB0byBjb252ZXkg YWJvdXQgdGhlDQphZGRyZXNzIGNoYW5nZSkuIFRodXMgSHViIHdvdWxkIGtub3cgYWJvdXQgdGhl IGNoYW5nZSwgd2l0aG91dCBhbnkNCmFkbWluaXN0cmF0b3IgaW50ZXJ2ZW50aW9uLiBUaGVyZSBp cyBubyBmaWxlL2RhdGFiYXNlIHRvIGJlIGVkaXRlZC4gVGhpcw0KaXMgcXVpdGUgc2ltaWxhciB0 byB3aGF0IHJvdXRpbmcgcHJvdG9jb2wgd291bGQgZG8uDQoNCkkgd2FudCB0byByZS1zdHJlc3Mg dGhlIHBvaW50LiBPdXIgc29sdXRpb24gaXMgbm90IGFnYWluc3QgdXNpbmcgcm91dGluZw0KcHJv dG9jb2wuIElmIHZlbmRvciB0aGlua3MgdGhhdCBpcyB0aGUgYmVzdCBhcHByb2FjaCBkZXBsb3ks IGhlL3NoZSBjYW4gZG8NCnNvLCBqdXN0IGxpa2UgbWFueSB2ZW5kb3IgYWxyZWFkeSBkbyB0b2Rh eS4NCg0KDQoNCg0KPj4gDQo+PiBCZWZvcmUgZ29pbmcgYW55IGZ1cnRoZXIsIGlzIHRoaXMgcmVz b3VyY2UgZXhjbHVzaXZlbHkgZXhjaGFuZ2VkIGJldHdlZW4NCj4+IGh1YiAmIHNwb2tlIG9yIGFs c28gYmV0d2VlbiBzcG9rZXMgPw0KPiANCj4gDQo+IFtQUkFWRUVOXSCp+HJlc291cmNlqfcgeW91 IG1lYW5zIEFEVlBOX0lORk8gcGF5bG9hZCBvciBTdWJuZXQgaW5mb3JtYXRpb24/DQo+IEFEVlBO X0lORk8gZXhjaGFuZ2VkIGJldHdlZW4gc3Bva2VzLiBTdWJuZXQgaW5mb3JtYXRpb24gZXhjaGFu Z2VkIHBhcnQgb2YNCj4gVHNpIGFuZCBUU3IgZHVyaW5nIElLRSBuZWdvdGlhdGlvbiAod2hpY2gg bWVhbnMgYmV0d2VlbiBodWIgJiBzcG9rZSBhbmQNCj4gYmV0d2VlbiBzcG9rZXMgYXMgd2VsbCku DQoNCkkgbWVhbiB0aGUgQURWUE5fSU5GTyBwb2ludGluZyB0byB0aGUgVVJMIHdpdGggdGhlIGxp c3Qgb2YgcHJlZml4ZXMuDQoNClRoZSBxdWVzdGlvbiBpcyBub3c6IHdobyBoYXMgYWNjZXNzIHRv IHRob3NlIHJlc291cmNlcyA/IFdobyBjYW4gdXBkYXRlDQp0aGUgZmlsZShzKSBvbiB0aGUgZmls ZXNlcnZlcihzKSA/IFRoaXMgcmFpc2VzIHRoZSB3aG9sZSBxdWVzdGlvbiBhYm91dA0Kcm9sZSBi YXNlZCBtYW5hZ2VtZW50Lg0KDQpJdCBhbHNvIG1lYW5zIHRoZSBjaGFuZ2UgbWFuYWdlbWVudCBp cyBub3cgcXVpdGUgY29tcGxleCBzaW5jZSBpbiBvcmRlciB0bw0KdXBkYXRlIHNwb2tlIHByZWZp eGVzIHlvdSBhbHNvIGhhdmUgdG8gY2hhbmdlIHRoZSBjZW50cmFsIHByZWZpeCBmaWxlcy4NCg0K T25lIG9mIHRoZSByZXF1aXJlbWVudHMgd2hpY2ggd2FzICJubyBjaGFuZ2Ugb24gdGhlIGNlbnRy YWwgZGV2aWNlcyB3aGVuDQphZGRpbmcgYSBicmFuY2giIGlzIGluIGNvbnRyYWRpY3Rpb24gd2l0 aCB0aGlzIG1ldGhvZC4gT1RPSCwgSSBhbQ0KcG9uZGVyaW5nIHRoYXQgdGhlIHNwb2tlcyBjb3Vs ZCBhdXRvbWF0aWNhbGx5IHVwZGF0ZSB0aGUgY2VudHJhbCBmaWxlKHMpDQppbiB3aGljaCBjYXNl IGl0IHdvdWxkIG5vdCBiZSB2ZXJ5IGRpZmZlcmVudCBmcm9tIGEgcm91dGluZyBwcm90b2NvbKGm DQoNCltQUkFWRUVOXSBJdCBhbGwgZGVwZW5kcyBvbiBob3cgeW91IGltcGxlbWVudC4gSXQgY2Fu IGJlIGF1dG9tYXRlZCBhcw0Kd2VsbCwgaWYgeW91IGxpa2UgdG8gZG8gc28uIEZvciBleGFtcGxl LCBlYWNoIHNwb2tlIHdoZW4gZXN0YWJsaXNoZXMgYQ0KdHVubmVsIHdpdGggdGhlIEh1YiwgSHVi IGFscmVhZHkga25vd3MgYWJvdXQgdGhlIHByZWZpeGVzIHRoYXQgc3Bva2VzDQpwcm90ZWN0cy4g VGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUgcG9wdWxhdGVkIHRvIFBST1RFQ1RFRF9ET01BSU4gZGF0 YWJhc2UNCmF1dG9tYXRpY2FsbHkuIFlvdSBkb26hr3QgbmVlZCBhbnkgYWRtaW5pc3RyYXRvciBp bnRlcnZlbnRpb24sIGlmIHlvdQ0KcmVhbGx5IHdhbnQgdG8gdHJ1c3Qgc3VjaCBjaGFuZ2VzLg0K DQpBbHNvLCBpZiBhbiBhZG1pbmlzdHJhdG9yIHdvdWxkIGxpa2UgdG8gcHJldmVudCBzdWNoIGNo YW5nZXMsIGJlZm9yZQ0KcmV2aWV3aW5nIGl0LCB0aGF0IGNhbiBiZSBkb25lIGFzIHdlbGwuIEFn YWluIGl0IGRlcGVuZHMgb24gaG93IHZlbmRvcg0Kd2FudHMgcHJvZHVjdGl6ZSB0aGlzIG5lYXQg c2VjdXJpdHkgZmVhdHVyZS4gSGV5LCByZW1lbWJlciB0aGF0LCBhIHNvdXRoDQphc2lhbiBJU1Ag YWR2ZXJ0aXNpbmcgSSBoYXZlIFlvdVR1YmUgKGluIGludGVudGlvbiBvZiBibG9ja2luZyBZb3VU dWJlIGluDQpoaXMgY291bnRyeSksIHRoYXQgbGVhZCB0byBmYWxzZWx5IGFkdmVydGlzaW5nIHJl c3Qgb2YgdGhlIHdvcmxkPyBEb26hr3QNCnlvdSB0aGluayBhZG1pbmlzdHJhdG9yIG9mIGEgZG9t YWluIHdhbnQgdG8gcHJldmVudCBzdWNoIHRoaW5ncyBoYXBwZW5pbmcNCmluIGhpcy9oZXIgZG9t YWluPw0KDQpUaGUgcHJvYmxlbSB3aXRoIHJvdXRpbmcgcHJvdG9jb2wgaXMsIGl0IGNvbWVzIHdp dGggaW1wbGljaXQgYXNzdW1wdGlvbiBvZg0KdHJ1c3QuIFllcyB0aGlzIGdvb2QgdGhpbmcgaW4g bW9zdCBzY2VuYXJpbywgYnV0IG5vdCBhbHdheXMuIFRoZXJlIGFyZQ0KYWRtaW5pc3RyYXRvcnMg d2hvIHdvdWxkIGxpa2UgdG8gaGF2ZSBhIGJldHRlciBjb250cm9sIG92ZXIgdGhlaXIgbmV0d29y aw0KdGhhbiBqdXN0IGF1dG9tYXRlZCB3YXkgb2YgZGVwbG95aW5nLg0KDQpBZ2FpbiwgaWYgeW91 IGRvbqGvdCB0aGluayB0aGF0IGlzIHRoZSBjYXNlLCB5b3UgY2FuIGNob29zZSB0byBpbXBsZW1l bnQNCndpdGggb3VyIHNvbHV0aW9uIHdpdGggcm91dGluZyBwcm90b2NvbCwgc2ltaWxhciB0byBt b3N0IHZlbmRvciAoaW5jbHVkaW5nDQpDaXNjbyBhbmQgSnVuaXBlcikgd2hvIGFscmVhZHkgZG8g dGhhdCB3aXRoIElQU2VjIHRvZGF5LiBUaGF0IHByb3ZpZGVzDQpmbGV4aWJpbGl0eSB0aGF0IGFu IGFkbWluaXN0cmF0b3Igd2FudCBvdXQgb2Ygcm91dGluZyBwcm90b2NvbC4NCg0KDQp0aGFua3Ms DQoNCglmcmVkDQoNCg0KPj4gDQo+PiB0aGFua3MsDQo+PiANCj4+IAlmcmVkDQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSVBzZWMgbWFpbGlu ZyBsaXN0DQo+PiBJUHNlY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHNlYw0KPj4gDQo+PiANCj4gDQo+IA0KDQoNCg0KDQo= From fdetienn@cisco.com Wed Feb 5 15:08:31 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD521A015A for ; Wed, 5 Feb 2014 15:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhTt7pOPaAO6 for ; Wed, 5 Feb 2014 15:08:29 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD1C1A0224 for ; Wed, 5 Feb 2014 15:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2390; q=dns/txt; s=iport; t=1391641708; x=1392851308; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I3PaH/lCjjhLDm4JCdiBt49e0RtY+dF88tDz213t4Dw=; b=Pe4VzpRVSotpZK/7KE7+3P8PuPSP3Ep7Ve/cgvC6+Z3syL7oTNik0Srp FRAPLnpLW5wDBuYYD9CodmrRV9PTnO1l+nigvXn389hMKlBka5ThWpM// AepLDKVTPMdHeGBh6inaoWpGMCdYaFnFsF61h9ThV1Lk10bbHhaV2VCEQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAPjC8lKtJXG//2dsb2JhbABZgww4vzSBChZ0giUBAQEDAQEBAWsLBQsCAQhGJwslAgQOBRuHYggNzmgTBI5CMweDJIEUBJgrkiGBb4E+ X-IronPort-AV: E=Sophos;i="4.95,789,1384300800"; d="scan'208";a="302153281" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 05 Feb 2014 23:08:28 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s15N8Sh6010555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 23:08:28 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.227]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 17:08:27 -0600 From: "Frederic Detienne (fdetienn)" To: Praveen Sathyanarayan Thread-Topic: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 Thread-Index: AQHPG4MvdTmd1tpwSEqyl/V9y2lTr5qnHckAgABgdwD//9kU8Q== Date: Wed, 5 Feb 2014 23:08:27 +0000 Message-ID: <0C55C1CE-27E8-4A1D-A527-D4EFECF4593A@cisco.com> References: <391C56E9-3E82-47BD-94E2-817105A06BEF@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " WG" Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:08:31 -0000 Hi Praveen, Comments inline. Thanks, Fred (sent from mobile) >=20 > [PRAVEEN] I think you didn=92t get my answer. What I was trying to say is= , > if there is a network prefix change on the spoke side, Spoke renegotiates > with Hub (Child SA rekey has TSi and Tsr payload to convey about the > address change). Thus Hub would know about the change, without any > administrator intervention. There is no file/database to be edited. This > is quite similar to what routing protocol would do. I think this is getting clearer now. Thanks. So based on what you say above and below, when the spoke updates its new TS= i TSr, all traffic is potentially blocked until the admin vouches the chang= e in the protected domain list ? > [PRAVEEN] It all depends on how you implement. It can be automated as > well, if you like to do so. For example, each spoke when establishes a > tunnel with the Hub, Hub already knows about the prefixes that spokes > protects. This information can be populated to PROTECTED_DOMAIN database > automatically. You don=92t need any administrator intervention, if you > really want to trust such changes. Thanks for that. I meant the PROTECTED_DOMAIN list.=20 So how does the PROTECTED_DOMAIN list get updated from a protocol standpoin= t ? Specifically when there are multiple hubs to serve a domain ? > Again, if you don=92t think that is the case, you can choose to implement > with our solution with routing protocol, similar to most vendor (includin= g > Cisco and Juniper) who already do that with IPSec today. That provides > flexibility that an administrator want out of routing protocol. Well in fact, as draft-detienne-01 shows, we can also use IKE (config excha= nge) but regardless of the prefix transport method, it does not need the do= main list contraption to achieve that security level. Now it would be interesting that you specify how a routing protocol works i= n the context of draft- Also, how do two domains with different mode interoperate ? What happens wh= en a routed spoke talks to a PROTECTED_DOMAIN hub or spoke ? > thanks, >=20 > fred >=20 >=20 >>>=20 >>> thanks, >>>=20 >>> fred >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 >=20 From fdetienn@cisco.com Wed Feb 5 15:29:22 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D9C1A0224 for ; Wed, 5 Feb 2014 15:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nhs-nBOMY5Q5 for ; Wed, 5 Feb 2014 15:29:18 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id C52D51A0299 for ; Wed, 5 Feb 2014 15:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1499; q=dns/txt; s=iport; t=1391642957; x=1392852557; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hHLzuK0/h+JCESvY3d0ziOaNN3uFoGOKlk873IurFUk=; b=auwkoLsSLHXtIiams50H+Lhmh91sno7tonyuBDBoNaerUM0kMknIgU7d jNtxVq3rHihBuEvOWaQ8/qDvems+mF4wyxxLZLevHV/bgkw1uAemxQxVj rgm+WzE+XsD7mBwAjnF4I5KjU1kNeFKwB/aamMceoK+Iw4YrR/5wz6kh2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAIrI8lKtJXG8/2dsb2JhbABZgww4vzSBChZ0giUBAQEDAQEBATc0CwULAgEIGB4QJwslAQEEDgWHfQgNznATBI5CMweDJIEUBJgrkiGDLQ X-IronPort-AV: E=Sophos;i="4.95,789,1384300800"; d="scan'208";a="18307116" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-2.cisco.com with ESMTP; 05 Feb 2014 23:29:16 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s15NTGjR021177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 23:29:16 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.227]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 17:29:16 -0600 From: "Frederic Detienne (fdetienn)" To: Michael Richardson Thread-Topic: [IPsec] AD-VPN Protocol Selection Thread-Index: Ac8g29viSNWMxCSdS+mwPoqNzCPObQAR2Q0AAGm1W0U= Date: Wed, 5 Feb 2014 23:29:15 +0000 Message-ID: References: <87BCDFB0B867FB4A85DB44EE8946E2458407E6F6@FSDEBSSXD111.fs01.vwf.vwfs-ad>, <9636.1391439750@sandelman.ca> In-Reply-To: <9636.1391439750@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Harms, Patrick" , "ipsec@ietf.org" Subject: Re: [IPsec] AD-VPN Protocol Selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:29:22 -0000 > On 03 Feb 2014, at 16:02, "Michael Richardson" wr= ote: >=20 >=20 > Harms, Patrick wrote: >> - is allowing to add 'spokes' without configuration changes on the 'hub' >> devices (8.1 dmvpn draft) >=20 >> For me, this is an important point. Changing the configuration on the hu= b >> routers, everytime a spoke is added to the network, would make the rollo= ut >> process to complex and is a possible source of failures. >=20 > I don't see how you can add a spoke in any system without requiring some > changes to at least one hub and/or the database/LDAP/etc. which keeps tra= ck > of all the spokes. Not sure you have read the requirements but it is one of them. The difficulty if the exercise is to be able to support both static and dyn= amic policies with a single protocol. >> Based on the theories (advpn draft and dmvpn) and real world experience >> (dmvpn), I would favor dmvpn, because the handling and operating sounds = less >> complex. (eg. lower amount of steps in tunnel initiation, single logical >> interface for tunnel termination etc.) >=20 > Do you care about mobile (handheld) devices? Somehow you must be mistaken in believing it can't be done. >=20 > -- > Michael Richardson , Sandelman Software Works >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From praveenys@juniper.net Wed Feb 5 15:31:41 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD4B1A0224 for ; Wed, 5 Feb 2014 15:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpDXFG303w1F for ; Wed, 5 Feb 2014 15:31:39 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id AE6491A021F for ; Wed, 5 Feb 2014 15:31:38 -0800 (PST) Received: from mail97-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE021.bigfish.com (10.3.207.143) with Microsoft SMTP Server id 14.1.225.22; Wed, 5 Feb 2014 23:31:37 +0000 Received: from mail97-am1 (localhost [127.0.0.1]) by mail97-am1-R.bigfish.com (Postfix) with ESMTP id 3515A4404A1; Wed, 5 Feb 2014 23:31:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(z579ehzbb2dI98dI9371Ic89bh4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h1155h) Received-SPF: pass (mail97-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(189002)(24454002)(199002)(164054003)(479174003)(377454003)(59766001)(47446002)(86362001)(74662001)(74502001)(74876001)(47736001)(94316002)(80022001)(65816001)(54316002)(56776001)(56816005)(66066001)(90146001)(74366001)(74706001)(63696002)(69226001)(94946001)(81342001)(93136001)(81542001)(79102001)(93516002)(31966008)(76482001)(85306002)(49866001)(36756003)(77982001)(80976001)(85852003)(19580395003)(83506001)(92726001)(92566001)(87266001)(83072002)(87936001)(81816001)(81686001)(19580405001)(47976001)(50986001)(2656002)(76786001)(76796001)(53806001)(4396001)(51856001)(46102001)(54356001)(83322001)(95416001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB667; H:CO2PR05MB665.namprd05.prod.outlook.com; CLIP:66.129.239.15; FPR:FCD4F3A5.A4CA97D8.FDF31C7B.C6F93871.203D9; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail97-am1 (localhost.localdomain [127.0.0.1]) by mail97-am1 (MessageSwitch) id 1391643094889937_16450; Wed, 5 Feb 2014 23:31:34 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.253]) by mail97-am1.bigfish.com (Postfix) with ESMTP id CAE92C00D9; Wed, 5 Feb 2014 23:31:34 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS018.bigfish.com (10.3.207.156) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 5 Feb 2014 23:31:34 +0000 Received: from CO2PR05MB667.namprd05.prod.outlook.com (10.141.230.23) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Wed, 5 Feb 2014 23:31:26 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB667.namprd05.prod.outlook.com (10.141.230.23) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 23:31:12 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 23:31:12 +0000 From: Praveen Sathyanarayan To: "Frederic Detienne (fdetienn)" , Yoav Nir Thread-Topic: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 Thread-Index: AQHPGFBmIvsjxkaNukGJzmUJkO7gl5qYT5OAgAtpFQCAAwe3AIAAEC+AgAANYQA= Date: Wed, 5 Feb 2014 23:31:11 +0000 Message-ID: References: <88259CEC-4D10-48EC-8A21-0D2F348EEE3F@cisco.com> <574468F8-9203-451C-A145-C9E1DD51D781@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.15] x-forefront-prvs: 01136D2D90 Content-Type: text/plain; charset="utf-8" Content-ID: <58066E643191E14EB629A9F7D9D086CB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: " WG" Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:31:41 -0000 SGkgRnJlZCwNCg0KSSBzZWUgZHJhZnQtZGV0aWVubmXCuXMgdmlldyBvZiBkaXNjb3Zlcnkgb2Yg dHVubmVsLXBlZXIgaXMgYSByb3V0aW5nDQppc3N1ZS4gU28gRE1WUE4gc29sdXRpb24gcHJlZG9t aW5hbnRseSBhIHJvdXRpbmcgc29sdXRpb24uIFNvLA0KZHJhZnQtZGV0aWVubmUgbWF5IHdvcmsg Z29vZCBmb3Igcm91dGluZyB2ZW5kb3JzLg0KDQpCdXQgaXQgaXMgbm90IGEgc29sdXRpb24gZm9y IG5vbi1yb3V0aW5nIHZlbmRvcnMuIEFzIGFuIGV4YW1wbGUsIG1vYmlsZQ0KZGV2aWNlcyBpbmNy ZWFzaW5nbHkgY2FuIGRvIG1vcmUgZmVhdHVyZXMgbGlrZSBGYWNlVGltZS9Ta3lwZS9IYW5nb3V0 LA0KQWlyZHJvcC4gVG8gZG8gdGhlc2UsIGV4cGVjdGluZyBtb2JpbGUgZGV2aWNlcyB0byBydW4g QkdQIHByb3RvY29sLCB0bw0KZGlzY292ZXIgYSBkaXJlY3QgdHVubmVsIGlzIG5vdCBhIHJlYXNv bmFibGUgZXhwZWN0YXRpb24uIE9yIGZvciB0aGF0DQptYXR0ZXIgZXhwZWN0aW5nIGEgZmlyZXdh bGwgZGV2aWNlIHRvIHJ1biByb3V0aW5nIHByb3RvY29sLCBpcyBub3QgYQ0KcmVhc29uYWJsZSBl eHBlY3RhdGlvbiBlaXRoZXIuDQoNCk1vcmUgY29tbWVudHMgaW5saW5lLg0KDQoNClRoYW5rcywN ClByYXZlZW4NCg0KDQoNCk9uIDIvNS8xNCwgNTo0NSBBTSwgIkZyZWRlcmljIERldGllbm5lIChm ZGV0aWVubikiIDxmZGV0aWVubkBjaXNjby5jb20+DQp3cm90ZToNCg0KPiBXZSBjYW4gbm8gbG9u Z2VyIGNhbGwgdGhhdCBhIHNpbXBsZSBzb2x1dGlvbi4gVGhlcmUgYXJlIHBpZWNlcyB0aGF0IG1l ZXQNCj5zb21lIG9mIHRoZSByZXF1aXJlbWVudHMgYnV0IGFyZSBpbiBjb250cmFkaWN0aW9uIHdp dGggb3RoZXJzLg0KDQo+IFNpbWlsYXJseSwgZHJhZnQtc2F0aHlhbmFyYXlhbiBvZmZlcnMgbXVs dGlwbGUgaW1wbGVtZW50YXRpb24gb3INCj5kZXBsb3ltZW50IHN5c3RlbXMgKHBvbGljeSBiYXNl ZCBvciB0dW5uZWwgYmFzZWQpIHdoaWNoIGFyZSBub3QNCj5jb21wYXRpYmxlIGF0IHByb3RvY29s IGxldmVsLiBJdCBtZWFucyBpbXBsZW1lbnRhdGlvbnMgaGF2ZSB0byBjb3ZlciBCT1RIDQo+bWV0 aG9kcyB0byBndWFyYW50ZWUgaW50ZXJvcGVyYWJpbGl0eS4NCg0KW1BSQVZFRU5dIEkgZGlzYWdy ZWUuIEhvdyB3aWxsIGEgc3Bva2UgcnVubmluZyBPU1BGIGFuZCBvdGhlciBzcG9rZQ0KcnVubmlu ZyBCR1AgaW50ZXJvcCBpbiBkcmFmdC1kZXRpZW5uZT8gIFlvdXIgYW5zd2VyIHdhcywgKHByZXZp b3VzbHkgaW4NCnZpcnR1YWwgY29uZmVyZW5jZSkgd2FzIHRoYXQgaXQgZG9lcyBub3QgbWF0dGVy LiBCZWNhdXNlLCBhcyBsb25nIGFzIEh1Yg0Kc3VwcG9ydHMgYm90aCByb3V0aW5nIHByb3RvY29s cywgdGhlcmUgaXMgbm8gaXNzdWUuIFRoZSBzYW1lIHRoaW5nIGFwcGxpZXMNCmhlcmUuIElmIHlv dSBoYXZlIHJvdXRlIGJhc2VkIGltcGxlbWVudGF0aW9uIG9uIGEgU3Bva2VBIGFuZCBQb2xpY3kg YmFzZWQNCmltcGxlbWVudGF0aW9uIFNwb2tlQiwgaXQgY2FuIHN0aWxsIG9wZW4gYSBkaXJlY3Qg SVBTZWMgdHVubmVsIHdpdGhvdXQNCmNhdXNpbmcgYW55IGludGVyb3BlcmFiaWxpdHkuIEFuZCBv ZiBjb3Vyc2UsIHRoZXJlIGlzIG5vIG5lZWQgb2YgcnVubmluZw0Kcm91dGluZyBwcm90b2NvbCBi ZXR3ZWVuIHRoZSBzcG9rZXMsIGV2ZW4gaW4gb3VyIHNvbHV0aW9uLg0KDQpUbyB0YWtlIGEgcHJh Y3RpY2FsIGV4YW1wbGU6IG9uZSBkb21haW4gbWF5IGluaXRpYWxseSBiZSBydWxlIGJhc2VkLCB0 aGUNCm90aGVyIHR1bm5lbCBiYXNlZC4gV2hhdCBoYXBwZW5zIHdoZW4gdGhvc2UgZG9tYWlucyBt dXN0IG5vdyBjb29wZXJhdGUgPw0KDQoNCkJvdGggaXNzdWVzIGFib3ZlIHdpbGwgcHJldmVudCBw cm9wZXIgY3Jvc3MtZG9tYWluIGludGVyb3BlcmFiaWxpdHkuIEluDQpwYXJ0aWN1bGFyLCBhICJw b2xpY3ktYmFzZWQiIHNwb2tlIHdpbGwgbm90IGJlIGFibGUgdG8gdGFsayB0byBhICJ0dW5uZWwN CmJhc2VkIiBodWIgYXMgcGVyIHRoaXMgZHJhZnTFoCBpdCB3b3VsZCB0YWtlIGEgZGVjaXNpb24g YXMgdG8gd2hpY2ggaXMgdGhlDQpmYWxsYmFjayBtb2RlIGFuZCBhIGR1YWwgaW1wbGVtZW50YXRp b24gb24gYXQgbGVhc3Qgb25lIG9mIHRoZSBkZXZpY2VzLg0KDQoNCltQUkFWRUVOXSBObyBpc3N1 ZXMgaGVyZS4gQXMgbG9uZyBhcyB5b3Ugc3VwcG9ydCByZmM1OTk2LCBhbmQgeW91IGV4Y2hhbmdl DQpUU2kgYW5kIFRzciBwYXlsb2FkcywgeW91IGFyZSByZWFkeSB0byBzZXR1cCBhIHR1bm5lbCBh bmQgZm9yd2FyZCB0aGUNCnRyYWZmaWMuIE9uIHJvdXRlIGJhc2VkIFZQTiBzaWRlLCB5b3UgZ2V0 IFRTaSBhbmQgVFNyIHBheWxvYWQgdGhhdCBkZWZpbmVzDQp0aGUgU1BEIGVudHJpZXMuIFRoZXNl IFNQRCBlbnRyaWVzIGFyZSBib3VuZCB0byB5b3VyIHR1bm5lbCBpbnRlcmZhY2UuDQpSb3V0ZSB0 aGF0IGV4aXN0IGJlZm9yZSB0aGUgc2hvcnRjdXQgdHVubmVsLCBzdGlsbCBwb2ludHMgdG8gdHVu bmVsDQppbnRlcmZhY2UuIEFzIHRoaXMgdHVubmVsLWludGVyZmFjZSBpcyBub3cgaGFzIGR5bmFt aWMgU1BEIGVudHJpZXMsIGl0IG5vdw0Ka25vd3MgaG93IHRvIGZvcndhcmQgYWxsL3NlbGVjdGl2 ZSB0cmFmZmljIHRvIHRoZSBzaG9ydGN1dCB0dW5uZWwuIEFuZCBvZg0KY291cnNlIHRoZSBQb2xp Y3kgYmFzZWQgZG9tYWluIHNpZGUgaXQgaXMgc3RyYWlnaHQgZm9yd2FyZC4gV2hlcmUgZG8geW91 DQpzZWUgdGhlIGlzc3VlPyANCg0KDQpUaGFua3MsDQpQcmF2ZWVuDQoNCg0K From yaronf.ietf@gmail.com Wed Feb 5 18:42:00 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8BB1A0214 for ; Wed, 5 Feb 2014 18:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFAPSqFcC319 for ; Wed, 5 Feb 2014 18:41:59 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E51671A0207 for ; Wed, 5 Feb 2014 18:41:58 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so1114236pab.18 for ; Wed, 05 Feb 2014 18:41:58 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=4sGcpMVnQKuX8tlhOtH8sEdQ9FO6aL+k/0cEL4vmpgI=; b=KHjYZ+xH3HrqyKt3idm5RW9yt5Wfj56e//BPogOgqvanHihPe2uABGcRAAzjdzuuQh +EGj53zIAV1o9eFVfg72nc6QxlRhuunePawgGh7IrgDrvH8rdXpLUTaDI9Y59Wj7o03h F5VYc2UR65kgQgtdSr/54b2iZimp6Ivg4CqTEIANCKaFnhDDuimxFW3Hf2o1fNCOHTsU rS2hGnQl7oc6de9HFy6jJgjIChbu5kESnutTU7SOtnWSMRfmfCzJemIRmQO9ylxBrbG5 2GRlxOc9iDJZtVo5db00AHSrxV8zziW3vUvzru1ifFmwtjdqiZXhp6TG9aLo0kL3ps9I DWeA== X-Received: by 10.68.197.40 with SMTP id ir8mr7974772pbc.138.1391654516974; Wed, 05 Feb 2014 18:41:56 -0800 (PST) Received: from [192.168.1.230] (c-67-169-181-102.hsd1.ca.comcast.net. [67.169.181.102]) by mx.google.com with ESMTPSA id vg1sm81402179pbc.44.2014.02.05.18.41.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 18:41:55 -0800 (PST) Message-ID: <52F2F672.5010009@gmail.com> Date: Wed, 05 Feb 2014 18:41:54 -0800 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: IPsecME WG References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: Re: AD VPN next steps - pls review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 02:42:00 -0000 Dear IPsec folks, Two months ago we requested input from the list to determine the group's consensus on a protocol candidate for auto-discovery VPN. Sadly, we received too few responses from non-authors (exactly 9), which we deem insufficient to determine consensus on such a major work item. Paul and I have decided to call this activity off. Although there is certainly industry interest in AD VPN, we seem to lack WG energy to move forward. We request and encourage the authors of both leading proposals (draft-sathyanarayan-ipsecme-advpn and draft-detienne-dmvpn) to publish them as individually submitted RFCs. Note however that we do not know how the Security ADs or the IETF community will want to handle two competing proposals. Thanks, Yaron From yaronf.ietf@gmail.com Wed Feb 5 19:01:59 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C54B1A0005 for ; Wed, 5 Feb 2014 19:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL47YhAy5_mS for ; Wed, 5 Feb 2014 19:01:58 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 669521A0004 for ; Wed, 5 Feb 2014 19:01:58 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id jt11so1191597pbb.11 for ; Wed, 05 Feb 2014 19:01:57 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=yctzAg9v/y2tZMOZ4Zg6sEaBQ36J9i7Kw2KyJnoa7tw=; b=Y+qel9Mk3BLiTJDKlK1i3IbxJBFHWYeXw1i7zofTM2Ymkgoa4C2o2Nz0tFkv8n6PjU dt2qoUVeebqZApAPTYZorns44BGsLFmaK3UxyVh2LYcEQQ+Qxwdq1N7w3s4nkyIzFiaP mYaXvBf0QK8I0af5GXMCi7HlHaDIik8fZTn3VwXmuMEXLA2v1EoF64Gz1Clp1URpiVPO Z1vz7rSanpaOSxZjDc1rYtqQhF1qZn+VmXTqQso33DIIRktqflCxwdOprUgLXMeDbD3t GltrZZ8CPWnEkjkBa5tPpWJpMljH3LHeJcZSEHFGKM1awyGYQVTRuH3Yv2J+QiB/OqgQ b5zg== X-Received: by 10.68.189.198 with SMTP id gk6mr8116492pbc.146.1391655717475; Wed, 05 Feb 2014 19:01:57 -0800 (PST) Received: from [192.168.1.230] (c-67-169-181-102.hsd1.ca.comcast.net. [67.169.181.102]) by mx.google.com with ESMTPSA id qq5sm81530282pbb.24.2014.02.05.19.01.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 19:01:56 -0800 (PST) Message-ID: <52F2FB21.6060907@gmail.com> Date: Wed, 05 Feb 2014 19:01:53 -0800 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: IPsecME WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] AD VPN next steps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 03:01:59 -0000 [Resending with a correct subject line, sorry.] Dear IPsec folks, Two months ago we requested input from the list to determine the group's consensus on a protocol candidate for auto-discovery VPN. Sadly, we received too few responses from non-authors (exactly 9), which we deem insufficient to determine consensus on such a major work item. Paul and I have decided to call this activity off. Although there is certainly industry interest in AD VPN, we seem to lack WG energy to move forward. We request and encourage the authors of both leading proposals (draft-sathyanarayan-ipsecme-advpn and draft-detienne-dmvpn) to publish them as individually submitted RFCs. Note however that we do not know how the Security ADs or the IETF community will want to handle two competing proposals. Thanks, Yaron From fdetienn@cisco.com Wed Feb 5 20:45:06 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7811A0374 for ; Wed, 5 Feb 2014 20:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmI6N_PlJUyh for ; Wed, 5 Feb 2014 20:45:01 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7D96A1A0277 for ; Wed, 5 Feb 2014 20:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5728; q=dns/txt; s=iport; t=1391661900; x=1392871500; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EG9rqswaU3awGZScyKssY8lwr/0mPG8C+e5ayGi880k=; b=RPeeqHMrTpyEnEU4LGJC1TYfALW+L2OLpkUbRr7m8pWJsm91Suu0ruzc k0F9wrpBFKv5kqSF1P9gFEosDBmGGQyiGo+p5G5yCaHJ1+s9ghjWhu/nm okmURktNl5IIBjOrRgU5ew0kNiZLc2dWKhVgTmGuzvh8/UspGiYQHH8U+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAM0S81KtJXG9/2dsb2JhbABZgwy/doEHFnSCJQEBAQMBaBEFCwIBCBgdETIlAgQOBRuHYgjOYxeOExEBHTMHgySBFASYK5IhgW+BPoFx X-IronPort-AV: E=Sophos;i="4.95,791,1384300800"; d="scan'208";a="18360566" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 06 Feb 2014 04:44:59 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s164ixxJ014207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 04:44:59 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.227]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 22:44:58 -0600 From: "Frederic Detienne (fdetienn)" To: Praveen Sathyanarayan Thread-Topic: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 Thread-Index: AQHPG4MvdTmd1tpwSEqyl/V9y2lTr5qYT5OAgAtpFQCAAwe3AIAAEC+AgAANYQCAANdrZw== Date: Thu, 6 Feb 2014 04:44:58 +0000 Message-ID: <5C13728B-72D0-42A3-996C-858430C334BD@cisco.com> References: <88259CEC-4D10-48EC-8A21-0D2F348EEE3F@cisco.com> <574468F8-9203-451C-A145-C9E1DD51D781@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " WG" , Yoav Nir Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 04:45:06 -0000 Hi Praveen, I suppose it would be convenient for you to minimize DMVPN to a "routing so= lution" however draft-detienne covers more than that. The remote access client case is fully covered. Without routing protocol. T= his point was clarified sometime in November (I believe) and draft-detienne= was updated accordingly. Now back to the discussion, I think I now do understand precisely how you s= ee the negotiation going. It turns out we support all these methods already= and we know the complexity of it. I would like to verify a few more points because it is not trivial at all. What I am exposing here is that draft-sathyanarayan will quickly grow out o= f control as it tries to encompass all possible negotiation methods. In practice, it means only a couple vendors will be able to implement it de= cently and will likely clash quite hard. All this at the expense of users w= ho are lured by failed promises. More inline on this topic then I will slowly move on to the next points. Thanks, Fred (sent from mobile) > On 06 Feb 2014, at 00:31, "Praveen Sathyanarayan" = wrote: >=20 > Hi Fred, >=20 > I see draft-detienne=B9s view of discovery of tunnel-peer is a routing > issue. So DMVPN solution predominantly a routing solution. So, > draft-detienne may work good for routing vendors. > But it is not a solution for non-routing vendors. As an example, mobile > devices increasingly can do more features like FaceTime/Skype/Hangout, > Airdrop. To do these, expecting mobile devices to run BGP protocol, to > discover a direct tunnel is not a reasonable expectation. Or for that > matter expecting a firewall device to run routing protocol, is not a > reasonable expectation either. >=20 > More comments inline. >=20 >=20 > Thanks, > Praveen >=20 >=20 >=20 > On 2/5/14, 5:45 AM, "Frederic Detienne (fdetienn)" > wrote: >=20 >> We can no longer call that a simple solution. There are pieces that meet >> some of the requirements but are in contradiction with others. >=20 >> Similarly, draft-sathyanarayan offers multiple implementation or >> deployment systems (policy based or tunnel based) which are not >> compatible at protocol level. It means implementations have to cover BOT= H >> methods to guarantee interoperability. >=20 > [PRAVEEN] I disagree. How will a spoke running OSPF and other spoke > running BGP interop in draft-detienne? Your answer was, (previously in > virtual conference) was that it does not matter. Because, as long as Hub > supports both routing protocols, there is no issue. The same thing applie= s > here. If you have route based implementation on a SpokeA and Policy based > implementation SpokeB, it can still open a direct IPSec tunnel without > causing any interoperability. And of course, there is no need of running > routing protocol between the spokes, even in our solution. The big difference is here: domain1 can deploy a routed based network only by picking a vendor focusing= on that method only. In this case, the TSi TSr may be 0.0.0.0/0 0.0.0.0/0 Domain2 may deploy a pure policy based implementation. Now how does domain 2 accept domain1's proposals ? And vice versa ? As you explain below, the route based method probably has to fall back to a= policy type negotiation. If domain1 admin made that choice, one can assume there is a reason. Now we= end up with a double negotiation method. Also how does spoke domain 1 initiate to hub domain 2 ? How does that hub k= now how to narrow down the TSi to ? It does not know that spoke yet... What now if domain 3 wants GRE/IPsec ? I remember an early email saying it = can be negotiated too. Draft-sathyanarayan possibly allows any protocol to be negotiated but it fo= cuses on the policy based method and does not mention at all how interop is= achieved. > To take a practical example: one domain may initially be rule based, the > other tunnel based. What happens when those domains must now cooperate ? >=20 >=20 > Both issues above will prevent proper cross-domain interoperability. In > particular, a "policy-based" spoke will not be able to talk to a "tunnel > based" hub as per this draft=8A it would take a decision as to which is t= he > fallback mode and a dual implementation on at least one of the devices. >=20 >=20 > [PRAVEEN] No issues here. As long as you support rfc5996, and you exchang= e > TSi and Tsr payloads, you are ready to setup a tunnel and forward the > traffic. On route based VPN side, you get TSi and TSr payload that define= s > the SPD entries. These SPD entries are bound to your tunnel interface. > Route that exist before the shortcut tunnel, still points to tunnel > interface. As this tunnel-interface is now has dynamic SPD entries, it no= w > knows how to forward all/selective traffic to the shortcut tunnel. And of > course the Policy based domain side it is straight forward. Where do you > see the issue?=20 So I presume TSi TSr of the routed spoke will be 0.0.0.0/0 0.0.0.0/0 ? This then gets narrowed down by the policy spoke ? We would create a tunnel per peer to achieve that. Your comment is interest= ing however as it raises a complexity. On a policy spoke1, the initial policy is 10.0.0.0/24 10.0.0.0/8 to hub Then spoke2 is discovered hosting 10.0.1.0/24 Now the SPD says 10.0.0.0/24 10.0.0.0/8 to hub 10.0.0.0/24 10.0.1.0/24 to spoke2 I know implementations that will not behave well in this case. The SPDB doe= s not guarantee a best match or sorted search. What should they do ? Thanks, Fred > Thanks, > Praveen >=20 >=20 From mglt.ietf@gmail.com Thu Feb 6 00:20:18 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794191A0092 for ; Thu, 6 Feb 2014 00:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX1vH35vySQ3 for ; Thu, 6 Feb 2014 00:20:10 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 471731A018E for ; Thu, 6 Feb 2014 00:20:10 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id e4so1286696wiv.0 for ; Thu, 06 Feb 2014 00:20:08 -0800 (PST) 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=nhhXBpiW4B9r55tSx8aVpRDWhoovWlN6EojvkEizqvA=; b=DqwyHGbuPU3hQM8eeMH/Ut61hQegi1YdoSXAUchs1zjFFsyaDf9f5uMhOxe9GrCKKV lpDwBCOHMe5Htvh+9OYZJ3ECc7rk/haDYvuF31x3/9BVT2m94+2Hq3YpY+qiYnuOEuG+ VKveOmdjbPXmV6MSghm7wf3bj2E3hGhx/7h2tk6cAEpDh8J3z5CdWAG8eQgLCy8oNlrm PHOwbcUSHcI7QPfEs1EhbmMcoFS8J/xW4YWpqfcCHlNky0P3z3SdnneiG7oE8ztQGuOH w5kDL9Q+LsV6cjqeDOJ517oH1M56e7NCXvgOSTqjJGPXNj5MpX3AhnyFJKy4j4kS2SXv g90g== MIME-Version: 1.0 X-Received: by 10.180.13.33 with SMTP id e1mr20515652wic.38.1391674808697; Thu, 06 Feb 2014 00:20:08 -0800 (PST) Received: by 10.194.171.129 with HTTP; Thu, 6 Feb 2014 00:20:08 -0800 (PST) In-Reply-To: <20140205135046.61c4f7a5@vostro> References: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com> <20140205135046.61c4f7a5@vostro> Date: Thu, 6 Feb 2014 09:20:08 +0100 Message-ID: From: Daniel Migault To: Timo Teras Content-Type: text/plain; charset=ISO-8859-1 Cc: " WG" , "Frederic Detienne \(fdetienn\)" , Praveen Sathyanarayan Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 08:20:18 -0000 Hi Timo, Thanks for the feed back. We are happy you provide requirements over "dynamically routing subnets" as a MUST. ADVPN responds to the requirements listed in RFC7018. If there is a requirement that does not match you opinion, can you please point it out? Just to make it clear this 1 day time has never been mentioned in the draft and is your assumption. The use of TTL does not impose a 1 day and ADVPN can take advantage of the Redirect Mechanism or MOBIKE for multihoming. As you can see the ADVPN solution can take advantage of all previous and future featured designed for IKEv2. As you point out the key characteristic of our design is its flexibility. RFC5685 is not limited to client-gateway, the second line of the section 10 you pointed out says: [...] the mechanism can also be used between any two IKEv2 peers. " So no additional specification are required. You mention load balancing may be an issue. Can you please specify the issue you see? One last point to clarify. it seems that you are trying to say ADVPN misses some features provided by routing protocols. In fact ADVPN can take advanatge of ALL of these features as ANY routing protocol can run on the top of ADVPN. This was a MUST requirement of RFC5685. If you see a scenrio that you think does not fit ADVPN, please document it so we can address your specific issue. Best Regards Daniel On Wed, Feb 5, 2014 at 12:50 PM, Timo Teras wrote: > On Mon, 20 Jan 2014 18:14:58 +0000 > Praveen Sathyanarayan wrote: > >> 1.2 What happens when a prefix administratively changes from behind >> one branch to another ? How do servers get notified about that ? >> >> [PRAVEEN] That's an interesting point Fred, and thanks for bringing >> it up. First, please refer the ADVPN_INFO Payload and >> PROTECTED_DOMAIN sections (3.6 and 3.9, respectively) of >> http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03. As a >> general rule, each spoke can download updated PROTECTED_DOMAIN >> information periodically, which advertises everything behind the hub >> and all other spokes combined. Of course, this does not change if >> some subnet has moved from behind spoke A to behind another spoke, B. >> However, the Lifetime attribute of the ADVPN_INFO payload is key >> here. We could see this being employed in a straightforward manner to >> allow for this transition: a) the subnet can "disappear" and be >> unreachable for one Lifetime, or b) the original spoke can redirect >> to the new spoke. >> >> We don't think this matters much in the real world, because people >> don't just move entire subnets instantaneously. Typically, folks stop >> using a subnet in one place, then begin using it in another. This >> makes a lot of sense for several operational reasons, as you would >> imagine. In fact, experience shows that since routing doesn't update >> across the world immediately, best practice would, for instance, >> indicate that it's best to wait a day between stopping using the >> subnet in one place and starting to use it in another place. In this >> case, a Lifetime of one day or less should be just fine (and we're >> thinking that, in fact, an hour would be a reasonable Lifetime value >> in practice). >> >> We would indeed argue that using Lifetime allows us to make the basic >> implementation of ADVPN handle a transition from one administrative >> domain to another in a straightforward manner. A redirection based on >> RFC5685 re-uses an already defined mechanism and makes the transition >> immediate, if/when necessary. This is one more argument for >> draft-sathyanarayan-ipsecme-advpn as it illustrates the modularity of >> our ADVPN proposal _and_ keeps the implementation simple. > > I disagree. IMGO, dynamically routing subnets is a MUST. > > Multiple scenarios exist. But to name one: > > I have complex site with multiple internal links and dynamic internal > routing connected to ADVPN via two or more spokes (connected via > different ISP lines). > > All the spokes can route to all subnets inside that site to provide > redundancy, and in some cases load balancing. > > If one spoke's ISP line dies, or if the internal routing protocol > decides other wise (e.g. intra-site link fails), the spokes should > dynamically move the subnet from one to another. > > Having a failover time of _a day_ is unacceptable. > > The redirect mechanism seems to be limited to client-gateway > connections, and only the gateway can send it (rfc5685 point 10). This > is not true in advpn context as any spoke may want to later on redirect > the SA of subnet it originally initiated. Using redirect would need > additional specifications to be usable. > > Then there is also the case of load balancing... etc. > > I do agree that subnets should be authorized to be routed. I do that in > existing dmvpn install, by means of automatically filtering the > announced routes based on the presented certificate. That is, the > certificate tells which subnets it can announce. > > - Timo > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From timo.teras@gmail.com Thu Feb 6 02:07:09 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8141A035D for ; Thu, 6 Feb 2014 02:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od75yO0FHJ65 for ; Thu, 6 Feb 2014 02:07:07 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 983601A00B4 for ; Thu, 6 Feb 2014 02:07:06 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id y1so1250786lam.8 for ; Thu, 06 Feb 2014 02:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=nYIce11pdAYv5KdLyuPixnXt3jLS527UknzrvP3G6bU=; b=FIgd/ZtQMya0ZzvUlMUSP83HCxGgff1kU5tL1M8+tVBw2zDSDRwnnCrzM80dq+7B3N Tt+1aC9xGI4emfsLl7diqLhdb96H+9ud75A/S3dIoa/6xy/2LwbOrYyUapTUCLTEaSfU ByWWz0IbmKchAUrMxlr9DkEFXrzML2p2T2eTAdjC1w5qhfJoXbSSiRTZWQCpXkMs0jfJ lCQcRbV0P7xs+FKTWH60izbEHCyg4AE4eF4fxa7Z7zTDmlk1ptmb5mEcgvrw5rSzSFLw hxQRu5UoM3jy0jPrn518tvLQghZvb5nfUNa9cgO2EE6Sc1nbpfgfcmJ35Xz92Gz5uhcU kElg== X-Received: by 10.112.138.233 with SMTP id qt9mr1350737lbb.34.1391681224929; Thu, 06 Feb 2014 02:07:04 -0800 (PST) Received: from vostro ([2001:1bc8:101:f402:21c:23ff:fefc:bf0b]) by mx.google.com with ESMTPSA id ri4sm488537lbb.6.2014.02.06.02.07.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2014 02:07:04 -0800 (PST) Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= Date: Thu, 6 Feb 2014 12:07:38 +0200 From: Timo Teras To: Daniel Migault Message-ID: <20140206120738.06195c09@vostro> In-Reply-To: References: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com> <20140205135046.61c4f7a5@vostro> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.20; i486-alpine-linux-uclibc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: " WG" , "Frederic Detienne \(fdetienn\)" , Praveen Sathyanarayan Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 10:07:09 -0000 On Thu, 6 Feb 2014 09:20:08 +0100 Daniel Migault wrote: > Thanks for the feed back. > > We are happy you provide requirements over "dynamically routing > subnets" as a MUST. ADVPN responds to the requirements listed in > RFC7018. If there is a requirement that does not match you opinion, > can you please point it out? > > Just to make it clear this 1 day time has never been mentioned in the > draft and is your assumption. The use of TTL does not impose a 1 day > and ADVPN can take advantage of the Redirect Mechanism or MOBIKE for > multihoming. As you can see the ADVPN solution can take advantage of > all previous and future featured designed for IKEv2. As you point out > the key characteristic of our design is its flexibility. It was Praveen's suggestion in the email I replied. My point was that having that sort of default TTL does not sound good. And to me it sounds like having very low TTL (in level of seconds or minutes) is too heavy to be used in practice. So the TTL mechanism does not really sound feasible to me. > RFC5685 is not limited to client-gateway, the second line of the > section 10 you pointed out says: [...] the mechanism can also be used > between any two IKEv2 peers. " So no additional specification are > required. You missed the next sentance: "However, the mechanism can also be used between any two IKEv2 peers. But this protocol is asymmetric, meaning that only the original responder can redirect the original initiator to another server." Spoke A established tunnel to spoke B. A is thus original initiator. But the routing change is on spoke B subnet. B cannot send Redirect according to the above. You'd need to specify additional mechanism for that, or re-specify the original one. I believe this restriction is due to security considerations for client-gateway type connectivity. > You mention load balancing may be an issue. Can you please specify the > issue you see? Could you specify how in practice I could implement one subnet to be load-balanced to spoke nodes? > One last point to clarify. it seems that you are trying to say ADVPN > misses some features provided by routing protocols. In fact ADVPN can > take advanatge of ALL of these features as ANY routing protocol can > run on the top of ADVPN. This was a MUST requirement of RFC5685. If > you see a scenrio that you think does not fit ADVPN, please document > it so we can address your specific issue. I thought the advantage was to _not_ run routing protocol. If running routing protocol is supported, can you please specify how a routing protocol is to be integrated with the IKE traffic exchange? Yes, it is possible, but non-trivial, thus I would like to see some specification mapping how to do that mapping. And like someone else asked, how is MPLS routed? Thanks, Timo From praveenys@juniper.net Thu Feb 6 17:24:06 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7137B1A0477 for ; Thu, 6 Feb 2014 17:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jNFAVXCWqf8 for ; Thu, 6 Feb 2014 17:24:03 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 83AE41A03FD for ; Thu, 6 Feb 2014 17:24:03 -0800 (PST) Received: from mail84-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE033.bigfish.com (10.236.130.96) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Feb 2014 01:24:02 +0000 Received: from mail84-co9 (localhost [127.0.0.1]) by mail84-co9-R.bigfish.com (Postfix) with ESMTP id 24BAA2C04BB; Fri, 7 Feb 2014 01:24:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(z579ehzbb2dI98dI9371Ic89bh1432I4015Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h8275bh1de097hz2fh109h2a8h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h1155h) Received-SPF: pass (mail84-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(479174003)(164054003)(24454002)(377454003)(51704005)(76786001)(92726001)(2656002)(94316002)(74876001)(76796001)(59766001)(85306002)(90146001)(56816005)(76482001)(93136001)(50986001)(83322001)(47976001)(95416001)(19580405001)(74366001)(19580395003)(63696002)(93516002)(87936001)(81342001)(46102001)(54316002)(81542001)(65816001)(80022001)(561944002)(85852003)(49866001)(69226001)(47736001)(83072002)(83506001)(80976001)(74662001)(56776001)(94946001)(76176001)(51856001)(31966008)(4396001)(77982001)(54356001)(92566001)(81686001)(53806001)(81816001)(36756003)(74706001)(87266001)(86362001)(74502001)(47446002)(79102001)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB666; H:CO2PR05MB665.namprd05.prod.outlook.com; CLIP:66.129.239.11; FPR:EED4F295.A7EA9194.B1F3F577.8AF9E841.20650; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail84-co9 (localhost.localdomain [127.0.0.1]) by mail84-co9 (MessageSwitch) id 139173623997529_19282; Fri, 7 Feb 2014 01:23:59 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.238]) by mail84-co9.bigfish.com (Postfix) with ESMTP id 131E22007F; Fri, 7 Feb 2014 01:23:59 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Feb 2014 01:23:58 +0000 Received: from CO2PR05MB666.namprd05.prod.outlook.com (10.141.230.19) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 7 Feb 2014 01:23:47 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB666.namprd05.prod.outlook.com (10.141.230.19) with Microsoft SMTP Server (TLS) id 15.0.868.8; Fri, 7 Feb 2014 01:23:45 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0868.013; Fri, 7 Feb 2014 01:23:45 +0000 From: Praveen Sathyanarayan To: "Frederic Detienne (fdetienn)" Thread-Topic: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 Thread-Index: AQHPGFBmIvsjxkaNukGJzmUJkO7gl5qYT5OAgAtpFQCAAwe3AIAAEC+AgAANYQCAAN3QAIAA0/KA Date: Fri, 7 Feb 2014 01:23:43 +0000 Message-ID: In-Reply-To: <5C13728B-72D0-42A3-996C-858430C334BD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [66.129.239.11] x-forefront-prvs: 011579F31F Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: " WG" , Yoav Nir Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 01:24:06 -0000 SGkgRnJlZCwNCg0KQ29tbWVudHMgaW5saW5lLg0KDQpUaGFua3MsDQpQcmF2ZWVuDQoNCk9uIDIv NS8xNCA4OjQ0IFBNLCAiRnJlZGVyaWMgRGV0aWVubmUgKGZkZXRpZW5uKSIgPGZkZXRpZW5uQGNp c2NvLmNvbT4NCndyb3RlOg0KDQo+SGkgUHJhdmVlbiwNCj4NCj5JIHN1cHBvc2UgaXQgd291bGQg YmUgY29udmVuaWVudCBmb3IgeW91IHRvIG1pbmltaXplIERNVlBOIHRvIGEgInJvdXRpbmcNCj5z b2x1dGlvbiIgaG93ZXZlciBkcmFmdC1kZXRpZW5uZSBjb3ZlcnMgbW9yZSB0aGFuIHRoYXQuDQo+ DQo+VGhlIHJlbW90ZSBhY2Nlc3MgY2xpZW50IGNhc2UgaXMgZnVsbHkgY292ZXJlZC4gV2l0aG91 dCByb3V0aW5nIHByb3RvY29sLg0KPlRoaXMgcG9pbnQgd2FzIGNsYXJpZmllZCBzb21ldGltZSBp biBOb3ZlbWJlciAoSSBiZWxpZXZlKSBhbmQNCj5kcmFmdC1kZXRpZW5uZSB3YXMgdXBkYXRlZCBh Y2NvcmRpbmdseS4NCj4NCj5Ob3cgYmFjayB0byB0aGUgZGlzY3Vzc2lvbiwgSSB0aGluayBJIG5v dyBkbyB1bmRlcnN0YW5kIHByZWNpc2VseSBob3cgeW91DQo+c2VlIHRoZSBuZWdvdGlhdGlvbiBn b2luZy4gSXQgdHVybnMgb3V0IHdlIHN1cHBvcnQgYWxsIHRoZXNlIG1ldGhvZHMNCj5hbHJlYWR5 IGFuZCB3ZSBrbm93IHRoZSBjb21wbGV4aXR5IG9mIGl0Lg0KPg0KPkkgd291bGQgbGlrZSB0byB2 ZXJpZnkgYSBmZXcgbW9yZSBwb2ludHMgYmVjYXVzZSBpdCBpcyBub3QgdHJpdmlhbCBhdCBhbGwu DQo+DQo+V2hhdCBJIGFtIGV4cG9zaW5nIGhlcmUgaXMgdGhhdCBkcmFmdC1zYXRoeWFuYXJheWFu IHdpbGwgcXVpY2tseSBncm93IG91dA0KPm9mIGNvbnRyb2wgYXMgaXQgdHJpZXMgdG8gZW5jb21w YXNzIGFsbCBwb3NzaWJsZSBuZWdvdGlhdGlvbiBtZXRob2RzLg0KPg0KPkluIHByYWN0aWNlLCBp dCBtZWFucyBvbmx5IGEgY291cGxlIHZlbmRvcnMgd2lsbCBiZSBhYmxlIHRvIGltcGxlbWVudCBp dA0KPmRlY2VudGx5IGFuZCB3aWxsIGxpa2VseSBjbGFzaCBxdWl0ZSBoYXJkLiBBbGwgdGhpcyBh dCB0aGUgZXhwZW5zZSBvZg0KPnVzZXJzIHdobyBhcmUgbHVyZWQgYnkgZmFpbGVkIHByb21pc2Vz Lg0KPg0KPk1vcmUgaW5saW5lIG9uIHRoaXMgdG9waWMgdGhlbiBJIHdpbGwgc2xvd2x5IG1vdmUg b24gdG8gdGhlIG5leHQgcG9pbnRzLg0KPg0KPlRoYW5rcywNCj4NCj4gICBGcmVkDQo+DQo+KHNl bnQgZnJvbSBtb2JpbGUpDQo+DQo+PiBPbiAwNiBGZWIgMjAxNCwgYXQgMDA6MzEsICJQcmF2ZWVu IFNhdGh5YW5hcmF5YW4iDQo+PjxwcmF2ZWVueXNAanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4gDQo+ PiBIaSBGcmVkLA0KPj4gDQo+PiBJIHNlZSBkcmFmdC1kZXRpZW5uZcK5cyB2aWV3IG9mIGRpc2Nv dmVyeSBvZiB0dW5uZWwtcGVlciBpcyBhIHJvdXRpbmcNCj4+IGlzc3VlLiBTbyBETVZQTiBzb2x1 dGlvbiBwcmVkb21pbmFudGx5IGEgcm91dGluZyBzb2x1dGlvbi4gU28sDQo+PiBkcmFmdC1kZXRp ZW5uZSBtYXkgd29yayBnb29kIGZvciByb3V0aW5nIHZlbmRvcnMuDQo+DQo+PiBCdXQgaXQgaXMg bm90IGEgc29sdXRpb24gZm9yIG5vbi1yb3V0aW5nIHZlbmRvcnMuIEFzIGFuIGV4YW1wbGUsIG1v YmlsZQ0KPj4gZGV2aWNlcyBpbmNyZWFzaW5nbHkgY2FuIGRvIG1vcmUgZmVhdHVyZXMgbGlrZSBG YWNlVGltZS9Ta3lwZS9IYW5nb3V0LA0KPj4gQWlyZHJvcC4gVG8gZG8gdGhlc2UsIGV4cGVjdGlu ZyBtb2JpbGUgZGV2aWNlcyB0byBydW4gQkdQIHByb3RvY29sLCB0bw0KPj4gZGlzY292ZXIgYSBk aXJlY3QgdHVubmVsIGlzIG5vdCBhIHJlYXNvbmFibGUgZXhwZWN0YXRpb24uIE9yIGZvciB0aGF0 DQo+PiBtYXR0ZXIgZXhwZWN0aW5nIGEgZmlyZXdhbGwgZGV2aWNlIHRvIHJ1biByb3V0aW5nIHBy b3RvY29sLCBpcyBub3QgYQ0KPj4gcmVhc29uYWJsZSBleHBlY3RhdGlvbiBlaXRoZXIuDQo+PiAN Cj4+IE1vcmUgY29tbWVudHMgaW5saW5lLg0KPj4gDQo+PiANCj4+IFRoYW5rcywNCj4+IFByYXZl ZW4NCj4+IA0KPj4gDQo+PiANCj4+IE9uIDIvNS8xNCwgNTo0NSBBTSwgIkZyZWRlcmljIERldGll bm5lIChmZGV0aWVubikiIDxmZGV0aWVubkBjaXNjby5jb20+DQo+PiB3cm90ZToNCj4+IA0KPj4+ IFdlIGNhbiBubyBsb25nZXIgY2FsbCB0aGF0IGEgc2ltcGxlIHNvbHV0aW9uLiBUaGVyZSBhcmUg cGllY2VzIHRoYXQNCj4+Pm1lZXQNCj4+PiBzb21lIG9mIHRoZSByZXF1aXJlbWVudHMgYnV0IGFy ZSBpbiBjb250cmFkaWN0aW9uIHdpdGggb3RoZXJzLg0KPj4gDQo+Pj4gU2ltaWxhcmx5LCBkcmFm dC1zYXRoeWFuYXJheWFuIG9mZmVycyBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbiBvcg0KPj4+IGRl cGxveW1lbnQgc3lzdGVtcyAocG9saWN5IGJhc2VkIG9yIHR1bm5lbCBiYXNlZCkgd2hpY2ggYXJl IG5vdA0KPj4+IGNvbXBhdGlibGUgYXQgcHJvdG9jb2wgbGV2ZWwuIEl0IG1lYW5zIGltcGxlbWVu dGF0aW9ucyBoYXZlIHRvIGNvdmVyDQo+Pj5CT1RIDQo+Pj4gbWV0aG9kcyB0byBndWFyYW50ZWUg aW50ZXJvcGVyYWJpbGl0eS4NCj4+IA0KPj4gW1BSQVZFRU5dIEkgZGlzYWdyZWUuIEhvdyB3aWxs IGEgc3Bva2UgcnVubmluZyBPU1BGIGFuZCBvdGhlciBzcG9rZQ0KPj4gcnVubmluZyBCR1AgaW50 ZXJvcCBpbiBkcmFmdC1kZXRpZW5uZT8gIFlvdXIgYW5zd2VyIHdhcywgKHByZXZpb3VzbHkgaW4N Cj4+IHZpcnR1YWwgY29uZmVyZW5jZSkgd2FzIHRoYXQgaXQgZG9lcyBub3QgbWF0dGVyLiBCZWNh dXNlLCBhcyBsb25nIGFzIEh1Yg0KPj4gc3VwcG9ydHMgYm90aCByb3V0aW5nIHByb3RvY29scywg dGhlcmUgaXMgbm8gaXNzdWUuIFRoZSBzYW1lIHRoaW5nDQo+PmFwcGxpZXMNCj4+IGhlcmUuIElm IHlvdSBoYXZlIHJvdXRlIGJhc2VkIGltcGxlbWVudGF0aW9uIG9uIGEgU3Bva2VBIGFuZCBQb2xp Y3kNCj4+YmFzZWQNCj4+IGltcGxlbWVudGF0aW9uIFNwb2tlQiwgaXQgY2FuIHN0aWxsIG9wZW4g YSBkaXJlY3QgSVBTZWMgdHVubmVsIHdpdGhvdXQNCj4+IGNhdXNpbmcgYW55IGludGVyb3BlcmFi aWxpdHkuIEFuZCBvZiBjb3Vyc2UsIHRoZXJlIGlzIG5vIG5lZWQgb2YgcnVubmluZw0KPj4gcm91 dGluZyBwcm90b2NvbCBiZXR3ZWVuIHRoZSBzcG9rZXMsIGV2ZW4gaW4gb3VyIHNvbHV0aW9uLg0K Pg0KPlRoZSBiaWcgZGlmZmVyZW5jZSBpcyBoZXJlOg0KPg0KPmRvbWFpbjEgY2FuIGRlcGxveSBh IHJvdXRlZCBiYXNlZCBuZXR3b3JrIG9ubHkgYnkgcGlja2luZyBhIHZlbmRvcg0KPmZvY3VzaW5n IG9uIHRoYXQgbWV0aG9kIG9ubHkuIEluIHRoaXMgY2FzZSwgdGhlIFRTaSBUU3IgbWF5IGJlIDAu MC4wLjAvMA0KPjAuMC4wLjAvMA0KPg0KPkRvbWFpbjIgbWF5IGRlcGxveSBhIHB1cmUgcG9saWN5 IGJhc2VkIGltcGxlbWVudGF0aW9uLg0KPg0KPk5vdyBob3cgZG9lcyBkb21haW4gMiBhY2NlcHQg ZG9tYWluMSdzIHByb3Bvc2FscyA/IEFuZCB2aWNlIHZlcnNhID8NCg0KDQpbUFJBVkVFTl0gSG1t 4oCmIE1heSBiZSB5b3Ugc2hvdWxkIHJlLXJlYWQgb3VyIGRyYWZ0LiBXaGF0IG91ciBkcmFmdCBz YXlzDQp0aGF0IHRoZSBzdWdnZXN0ZXIvaHViIHdpbGwgc3VnZ2VzdCB3aGF0IHRyYWZmaWMtc2Vs Y3RvciBzaG91bGQgYmUgdXNlZA0KZm9yIGVzdGFibGlzaCB0aGUgdHVubmVsLiBTbyBlYWNoIHNw b2tlcyBrbm93cyBleGFjdGx5IHdoYXQgVHNpIGFuZCBUc3INCmJlaW5nIG5lZ290aWF0ZWQuIA0K DQoNCj4NCj5BcyB5b3UgZXhwbGFpbiBiZWxvdywgdGhlIHJvdXRlIGJhc2VkIG1ldGhvZCBwcm9i YWJseSBoYXMgdG8gZmFsbCBiYWNrIHRvDQo+YSBwb2xpY3kgdHlwZSBuZWdvdGlhdGlvbi4NCj4N Cj5JZiBkb21haW4xIGFkbWluIG1hZGUgdGhhdCBjaG9pY2UsIG9uZSBjYW4gYXNzdW1lIHRoZXJl IGlzIGEgcmVhc29uLiBOb3cNCj53ZSBlbmQgdXAgd2l0aCBhIGRvdWJsZSBuZWdvdGlhdGlvbiBt ZXRob2QuDQo+DQo+QWxzbyBob3cgZG9lcyBzcG9rZSBkb21haW4gMSBpbml0aWF0ZSB0byBodWIg ZG9tYWluIDIgPyBIb3cgZG9lcyB0aGF0IGh1Yg0KPmtub3cgaG93IHRvIG5hcnJvdyBkb3duIHRo ZSBUU2kgdG8gPyBJdCBkb2VzIG5vdCBrbm93IHRoYXQgc3Bva2UgeWV0Li4uDQo+DQo+V2hhdCBu b3cgaWYgZG9tYWluIDMgd2FudHMgR1JFL0lQc2VjID8gSSByZW1lbWJlciBhbiBlYXJseSBlbWFp bCBzYXlpbmcNCj5pdCBjYW4gYmUgbmVnb3RpYXRlZCB0b28uDQoNCltQUkFWRUVOXSBBZ2FpbiBp biBUc2kgYW5kIFRzciBwYXlsb2FkIGNhcnJ5IHRoYXQgaW5mb3JtYXRpb24gc2hvcnRjdXQNCnN1 Z2dlc3Rpb24gZnJvbSBIdWIuIElmIEdSRSBpcyBzdXBwb3J0ZWQgaW4gYSBwYXJ0aWN1bGFyIGRv bWFpbiwgaXQgc2hvdWxkDQpiZSBhYmxlIHRvIHN3aXRjaCB0byBHUkUvSVBTZWMuDQoNCj4NCj5E cmFmdC1zYXRoeWFuYXJheWFuIHBvc3NpYmx5IGFsbG93cyBhbnkgcHJvdG9jb2wgdG8gYmUgbmVn b3RpYXRlZCBidXQgaXQNCj5mb2N1c2VzIG9uIHRoZSBwb2xpY3kgYmFzZWQgbWV0aG9kIGFuZCBk b2VzIG5vdCBtZW50aW9uIGF0IGFsbCBob3cNCj5pbnRlcm9wIGlzIGFjaGlldmVkLg0KDQpbUFJB VkVFTl0gU3VyZSBpZiBuZWVkZWQgd2Ugd2lsbCB1cGRhdGUgd2l0aCB0aGUgaW5mb3JtYXRpb24g dGhhdCBpcw0KcmVxdWlyZWQuIFRoaXMgaXMgd2h5IHdlIGFyZSBoYXZpbmcgZGlzY3Vzc2lvbiBp c27igJl0IGl0PyA7LSkNCg0KPg0KPg0KPj4gVG8gdGFrZSBhIHByYWN0aWNhbCBleGFtcGxlOiBv bmUgZG9tYWluIG1heSBpbml0aWFsbHkgYmUgcnVsZSBiYXNlZCwgdGhlDQo+PiBvdGhlciB0dW5u ZWwgYmFzZWQuIFdoYXQgaGFwcGVucyB3aGVuIHRob3NlIGRvbWFpbnMgbXVzdCBub3cgY29vcGVy YXRlID8NCj4+IA0KPj4gDQo+PiBCb3RoIGlzc3VlcyBhYm92ZSB3aWxsIHByZXZlbnQgcHJvcGVy IGNyb3NzLWRvbWFpbiBpbnRlcm9wZXJhYmlsaXR5LiBJbg0KPj4gcGFydGljdWxhciwgYSAicG9s aWN5LWJhc2VkIiBzcG9rZSB3aWxsIG5vdCBiZSBhYmxlIHRvIHRhbGsgdG8gYSAidHVubmVsDQo+ PiBiYXNlZCIgaHViIGFzIHBlciB0aGlzIGRyYWZ0xaAgaXQgd291bGQgdGFrZSBhIGRlY2lzaW9u IGFzIHRvIHdoaWNoIGlzDQo+PnRoZQ0KPj4gZmFsbGJhY2sgbW9kZSBhbmQgYSBkdWFsIGltcGxl bWVudGF0aW9uIG9uIGF0IGxlYXN0IG9uZSBvZiB0aGUgZGV2aWNlcy4NCj4+IA0KPj4gDQo+PiBb UFJBVkVFTl0gTm8gaXNzdWVzIGhlcmUuIEFzIGxvbmcgYXMgeW91IHN1cHBvcnQgcmZjNTk5Niwg YW5kIHlvdQ0KPj5leGNoYW5nZQ0KPj4gVFNpIGFuZCBUc3IgcGF5bG9hZHMsIHlvdSBhcmUgcmVh ZHkgdG8gc2V0dXAgYSB0dW5uZWwgYW5kIGZvcndhcmQgdGhlDQo+PiB0cmFmZmljLiBPbiByb3V0 ZSBiYXNlZCBWUE4gc2lkZSwgeW91IGdldCBUU2kgYW5kIFRTciBwYXlsb2FkIHRoYXQNCj4+ZGVm aW5lcw0KPj4gdGhlIFNQRCBlbnRyaWVzLiBUaGVzZSBTUEQgZW50cmllcyBhcmUgYm91bmQgdG8g eW91ciB0dW5uZWwgaW50ZXJmYWNlLg0KPj4gUm91dGUgdGhhdCBleGlzdCBiZWZvcmUgdGhlIHNo b3J0Y3V0IHR1bm5lbCwgc3RpbGwgcG9pbnRzIHRvIHR1bm5lbA0KPj4gaW50ZXJmYWNlLiBBcyB0 aGlzIHR1bm5lbC1pbnRlcmZhY2UgaXMgbm93IGhhcyBkeW5hbWljIFNQRCBlbnRyaWVzLCBpdA0K Pj5ub3cNCj4+IGtub3dzIGhvdyB0byBmb3J3YXJkIGFsbC9zZWxlY3RpdmUgdHJhZmZpYyB0byB0 aGUgc2hvcnRjdXQgdHVubmVsLiBBbmQNCj4+b2YNCj4+IGNvdXJzZSB0aGUgUG9saWN5IGJhc2Vk IGRvbWFpbiBzaWRlIGl0IGlzIHN0cmFpZ2h0IGZvcndhcmQuIFdoZXJlIGRvIHlvdQ0KPj4gc2Vl IHRoZSBpc3N1ZT8gDQo+DQo+U28gSSBwcmVzdW1lIFRTaSBUU3Igb2YgdGhlIHJvdXRlZCBzcG9r ZSB3aWxsIGJlIDAuMC4wLjAvMCAwLjAuMC4wLzAgPw0KPg0KPlRoaXMgdGhlbiBnZXRzIG5hcnJv d2VkIGRvd24gYnkgdGhlIHBvbGljeSBzcG9rZSA/DQo+DQo+V2Ugd291bGQgY3JlYXRlIGEgdHVu bmVsIHBlciBwZWVyIHRvIGFjaGlldmUgdGhhdC4gWW91ciBjb21tZW50IGlzDQo+aW50ZXJlc3Rp bmcgaG93ZXZlciBhcyBpdCByYWlzZXMgYSBjb21wbGV4aXR5Lg0KPg0KPk9uIGEgcG9saWN5IHNw b2tlMSwgdGhlIGluaXRpYWwgcG9saWN5IGlzDQo+DQo+MTAuMC4wLjAvMjQgMTAuMC4wLjAvOCB0 byBodWINCj4NCj5UaGVuIHNwb2tlMiBpcyBkaXNjb3ZlcmVkIGhvc3RpbmcgMTAuMC4xLjAvMjQN Cj4NCj5Ob3cgdGhlIFNQRCBzYXlzDQo+DQo+MTAuMC4wLjAvMjQgMTAuMC4wLjAvOCB0byBodWIN Cj4xMC4wLjAuMC8yNCAxMC4wLjEuMC8yNCB0byBzcG9rZTINCj4NCj5JIGtub3cgaW1wbGVtZW50 YXRpb25zIHRoYXQgd2lsbCBub3QgYmVoYXZlIHdlbGwgaW4gdGhpcyBjYXNlLiBUaGUgU1BEQg0K PmRvZXMgbm90IGd1YXJhbnRlZSBhIGJlc3QgbWF0Y2ggb3Igc29ydGVkIHNlYXJjaC4NCg0KDQpb UFJBVkVFTl0gVGhpcyBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LiBJdCBleHBsYWlucyB3aXRo IGV4YW1wbGUuIFBsZWFzZQ0KdGFrZSBhIGxvb2suDQoNCj4NCj5XaGF0IHNob3VsZCB0aGV5IGRv ID8NCj4NCj5UaGFua3MsDQo+DQo+ICBGcmVkDQo+DQo+PiBUaGFua3MsDQo+PiBQcmF2ZWVuDQo+ PiANCj4+IA0KPg0KPg0KDQo= From timo.teras@gmail.com Thu Feb 6 23:29:21 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550D61A05B7 for ; Thu, 6 Feb 2014 23:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivB0k31f8W4t for ; Thu, 6 Feb 2014 23:29:19 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1E44F1A05AC for ; Thu, 6 Feb 2014 23:29:18 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id c6so2280363lan.25 for ; Thu, 06 Feb 2014 23:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=7wdWElZB2iNNzdKLSoOPok3wmrP7cSzGxCbXl+0O2PA=; b=U75iFeONhnBN/jENArTVbOMr4k/PGWBHHQpBc4aR/nGF9bK30kz2o184mrMq3As/6d gOnyILsN+wJi/WAEowk0WuiRncICEEyx5Vfn+e70HKKmQeKz5U+4vQfUGzdJW81jE0PQ rDbtu2WCTIb0aiLyyV9NwNFpQMBNwRU/h08Fil9UfgydTCy0JVaTx61AaRCQanIr3wGC WsmQDxiXLK+rpHvq+rlGcOoJCgxY6gNiE5bKc5BcJxc+cduxtP6ln7KO0D74CMFThzCt WwGWEqOut40RD9EwdsykCywwbIQvaCylZAR7fugQu79llX5zgPVfNL1CXY3mHGSRaQpq cG6g== X-Received: by 10.153.3.2 with SMTP id bs2mr8760354lad.5.1391758157131; Thu, 06 Feb 2014 23:29:17 -0800 (PST) Received: from vostro ([2001:1bc8:101:f402:21c:23ff:fefc:bf0b]) by mx.google.com with ESMTPSA id jf8sm3874109lbc.8.2014.02.06.23.29.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2014 23:29:17 -0800 (PST) Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= Date: Fri, 7 Feb 2014 09:29:52 +0200 From: Timo Teras To: " WG" Message-ID: <20140207092952.01039e7f@vostro> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.20; i486-alpine-linux-uclibc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [IPsec] scalability questions for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 07:29:21 -0000 Hi, In addition to previous questions, I have few additional scalability concerns regarding draft-sathyanarayan-ipsecme-advpn-03. 1. Scaling hubs, and shortcut creation times If I have so many spokes (>1000) that single gateway node cannot handle feasibly simultaneous connectivity all of them. Appendix A.2. describes shows that in advpn shortcut establishment requires spoke to first connect to the next nearer 'shortcut suggester' with the specific SA, at least temporarily, before final shortcut. This implies that in worst case all short suggester gateways should be able to handle simultaneous connection to all non-suggester nodes to handle shortcut formation. So instead of suggesters requiring SA only for it's static set of clients, it must be scaled to handle SAs for *all* clients in the same domain. (As comparison, dmvpn forms shortcuts directly spoke-spoke even if there multiple hubs involved in between.) It does not sound feasible that to grow network, say every additional 500-1000 spokes, I would need to replace all the *core* locations to be faster so that they can handle the larger number of connections. Of course things work if it's assumed that it's not full mesh, but I'm not happy building architectures around assumptions that cannot be guaranteed. Or did I somehow misunderstand these implications? Any comments? This also means that I might need multiple SA negotiations for one shortcut which can be very CPU intensive. Additionally it limits the number of intermediate shortcut suggesters or the shortcut creation can take long amount of time (both wall and CPU). Do you have recommendations on how a complicated topology should be configured? What is the normal / recommended maximum amount of shortcut suggester nodes 'in a path from A to B' envisioned in this setup? 2. Scaling number of prefixes Suppose I have medium sized spokes A and B with 10 prefixes. This means they would need 10*10 SAs in the policy based approach. Additionally, if these cannot be "supernetted" as less prefixes on hub, each spoke would need another additional 10*10 SAs with the all of the hubs in path. To me this sounds like the CPU power need in spokes is not proportional to the number of _connected_ devices (as in dmvpn), but instead it is exponentially proportional to number of prefixes it communicates with (because of previous point, it needs these prefixes negotiated with all shortcut suggestors involved and the final spoke). Or did I misunderstand something? If the solution is to use routed mode: - do you have recommendations to when use which mode? - does it make sense to complicate things by specifying policy based mode at all if it does not scale? Thanks, Timo From paul.hoffman@vpnc.org Mon Feb 10 14:08:28 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0E21A05F2 for ; Mon, 10 Feb 2014 14:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ5qRUxNxg40 for ; Mon, 10 Feb 2014 14:08:27 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E29291A050E for ; Mon, 10 Feb 2014 14:08:26 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1AM8O7r081205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 Feb 2014 15:08:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <19DA3007-4A4F-4226-96E0-E885010FE253@vpnc.org> Date: Mon, 10 Feb 2014 14:08:24 -0800 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [IPsec] Proposed agenda for London X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:08:28 -0000 http://www.ietf.org/proceedings/89/agenda/agenda-89-ipsecme Proposals for changes are welcome. Note that some of the people listed = as speaking have not yet been asked, but we hope they agree. :-) --Paul Hoffman= From daniel.palomares.ietf@gmail.com Thu Feb 13 06:09:52 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F85B1A0286 for ; Thu, 13 Feb 2014 06:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYCsmHJT2eI3 for ; Thu, 13 Feb 2014 06:09:50 -0800 (PST) Received: from mail-ie0-x242.google.com (mail-ie0-x242.google.com [IPv6:2607:f8b0:4001:c03::242]) by ietfa.amsl.com (Postfix) with ESMTP id D45551A026C for ; Thu, 13 Feb 2014 06:09:49 -0800 (PST) Received: by mail-ie0-f194.google.com with SMTP id at1so327136iec.1 for ; Thu, 13 Feb 2014 06:09:48 -0800 (PST) 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=zB+Dc+/wd9w7cgfS6Femfh1NKR1AlKDsiW7jqVkh0No=; b=iNcyP8SEdW7Pn8efv8EXLhCVlKZSIkeL3H+WJqkefrQqaA2Uq4TjVm32Y2aNaN5brv Qf69gtyiK2Yk+42MOHzQ9SAYEKDvYs9E2vFs/bp4zldj/eeWl19hLvpxHYdHcdpo2UOO I6cY8Rx/hxYvqSNcEZ806SIB4TMAsThOMvryiI0wHHB6NRZuixjK7RHKSJK4eoOXYEm9 ZyyMnOmG//41mISscS/qZ1kgg8K2kPZwJ/cDHH0A266uNCPJa4d8W9vXGI+6KtjUKs7h dl4VhXbb3rsJxZahvpUqiFwuZzC4S1obVODxHhErRbk2f1Xe1W9Pgo4jzzfqtZyP9jwi /A6w== MIME-Version: 1.0 X-Received: by 10.42.104.74 with SMTP id q10mr638352ico.75.1392300588695; Thu, 13 Feb 2014 06:09:48 -0800 (PST) Received: by 10.50.40.131 with HTTP; Thu, 13 Feb 2014 06:09:48 -0800 (PST) Date: Thu, 13 Feb 2014 15:09:48 +0100 Message-ID: From: Daniel Palomares To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=20cf303dd43802834104f24a3e72 Subject: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:09:52 -0000 --20cf303dd43802834104f24a3e72 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please find a draft we have Posted. They concern the definition of IKEv2 and IPsec contexts. Comments are welcome, BR, Daniel Palomares Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. Revision: 00 Title: IKEv2/IPsec Context Definition Document date: 2014-02-12 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt Status: https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ Htmlized: http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 Abstract IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a single address by the end user. The traffic is then split between the nodes via specific IP load balancing policies. Once a session is assigned to a given node, IPsec makes it difficult to assign the session to another node. This makes management operations and transparent high availability for end users difficult to perform within the cluster. This document describes the contexts for IKEv2 and IPsec that MUST be transferred between two nodes so a session can be restored. This makes possible to transfer an IPsec session transparently to the end user. *Daniel* *PALOMARES* *Orange Labs, Issy-les-Moulineaux* +33 6 34 23 07 88 --20cf303dd43802834104f24a3e72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Please find a draft we have Posted. They concern the definition of IKEv2 and IPsec contexts.
Comments are welcome,

BR,

Daniel Palomares

=A0

=A0

Name: =A0 =A0 =A0=A0 draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

Revision: 00
Title: =A0 =A0 =A0 IKEv2/IPsec Context Definition
Document date: =A0 =A02014-02-12
Group: =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0=A0 8
URL:http://www.iet= f.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
Status:https://data= tracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/
Htmlized: http://tools.= ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00<= /a>


Abstract

=A0 =A0IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a
=A0 =A0single address by the end user. =A0The traffic is then split between
=A0 =A0the nodes via specific IP load balancing policies. =A0Once a session is
=A0 =A0assigned to a given node, IPsec makes it difficult to assign the
=A0 =A0session to another node. =A0This makes management operations and
=A0 =A0transparent high availability for end users difficult to perform
=A0 =A0within the cluster.

=A0 =A0This document describes the contexts for IKEv2 and IPsec that MUST be
=A0 =A0transferred between two nodes so a session can be restored. =A0This
=A0 =A0makes possible to transfer an IPsec session transparently to the end
=A0 =A0user.

=A0

Daniel PALOMARES

Orange Labs, Issy-les-Moulineaux

+33 6 34 23 07 = 88

--20cf303dd43802834104f24a3e72-- From mglt.ietf@gmail.com Thu Feb 13 06:24:57 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9B91A0240 for ; Thu, 13 Feb 2014 06:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqtW7IUYtrcL for ; Thu, 13 Feb 2014 06:24:56 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id B748B1A0237 for ; Thu, 13 Feb 2014 06:24:55 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hi5so8632596wib.8 for ; Thu, 13 Feb 2014 06:24:54 -0800 (PST) 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=J7CMIxdSp68efdjPCcPgnQytWaFGhG1rYOrL/C231nc=; b=Suy+TFGWo2rvNvWmFrOfEeDo11hgPhWp36sQrv01SJgy6blTnDcw1QWvMCIBv8e60a AXIqlRKNVgTSrgm0DNsQOnATqB1kjXJKelXG1aRpAYq69NBWefPVl7fx1t0SykXf9zZV 5BezM5Zu1eLyUCqzIgCaiJfL9ZRz63mbPNBEveS036eIQndbKDQkHdGfjgO/peng/iEc j2zXS4JhIYsocjbFyJIpLvhbVdX6N+Ov16zUFvNOMm+Tf42R7gNn0p1zjwW263XzKNIv Smc+VuC/BhYS3QIEC4p679gzde1/osOr6cQPUu6ZREMeJGhL/dikRarXBlhOmbAKR70q XQ7g== MIME-Version: 1.0 X-Received: by 10.180.13.33 with SMTP id e1mr6774149wic.38.1392301494105; Thu, 13 Feb 2014 06:24:54 -0800 (PST) Received: by 10.194.171.129 with HTTP; Thu, 13 Feb 2014 06:24:53 -0800 (PST) Date: Thu, 13 Feb 2014 15:24:53 +0100 Message-ID: From: Daniel Migault To: "ipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [IPsec] draft-mglt-ipsecme-clone-ike-sa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:24:58 -0000 Hi, Please find our draft "Clone IKE SA Extension" http://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/ This extension indicate that during a rekey of a IKE_SA, the current IKE_SA MUST NOT be deleted, thus leaving two parallel IKE_SA. This draft has been presented as draft-mglt-ipsecme-keep-old-ike-sa-00 in Berlin. This version added the comments received from Valery, Yaron and Tero both on th emailing list and during the meeting. Any comment is welcome! I have two questions regarding this draft: 1) I specified in which exchange type the different payloads are expected to be found. CLONE_IKE_SA is sent in a CREATE_CHILD_SA exchange only. CLONE_IKE_SA_SUPPORTED is expected to be found in message of type IKE_AUTH and INFORMATIONAL. Should we restrict it to IKE_AUTH ? 2) The CLONE_IKE_SA Notify Payload in a CREATE_CHILD_SA exchange is included both by the initiator and by the responder. By doing so, the responder confirm everything is fine. On the other hand we can assume sending no error - once peers have agreed they support the extension - indicates it is fine. I would like your feed back whether the responder should have this CLONE_IKE_SA Notify payload in the response or not. -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From paul.hoffman@vpnc.org Thu Feb 13 07:36:07 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DED31A02C6 for ; Thu, 13 Feb 2014 07:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiErHtSdf-4V for ; Thu, 13 Feb 2014 07:36:05 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 917C91A02E8 for ; Thu, 13 Feb 2014 07:36:04 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1DFa1bM000166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 13 Feb 2014 08:36:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 13 Feb 2014 07:36:02 -0800 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [IPsec] Our London agenda is filling up X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:36:07 -0000 Greetings again. I have updated the agenda at = to reflect = recent requests. Yaron and I would like to see active discussion on the mailing list of = any of the drafts that are listed in the agenda. The face-to-face time = in London should be focused on dealing with issues, not making = introductory presentations. --Paul Hoffman= From nobody Sun Feb 16 14:04:33 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDCD1A040D; Sun, 16 Feb 2014 14:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjelmYchAwUz; Sun, 16 Feb 2014 14:04:25 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id A08551A02C4; Sun, 16 Feb 2014 14:04:25 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 53AA5800AA; Sun, 16 Feb 2014 17:04:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1392588262; bh=umdGRtuVVd5oFrKBYABzCe/xWOaRyfy0NnPAy7iKX5Y=; h=Date:From:To:Subject; b=WI3mI65kPpCs1LVG9zgK+kTGvf3AtJdYWgCDRtYen1boE0EUfXiq/qgP4jCrlUYYh QBUBxWmDImBnfnHgWKKkcr6+hlcTmVbz6G1F3q9wcBzKjHUP8lNPuWPlL+xdd/4nDh ruK7h91lPoFZllukwjFnnDmXZgGEG+lDkiGJ58I0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1GM4LLb014255; Sun, 16 Feb 2014 17:04:22 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 16 Feb 2014 17:04:21 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" , dane WG list Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/GWjmSQGMsQcDbzaHuXAsNgJKy1o Subject: [IPsec] Review of draft-osterweil-dane-ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 22:04:29 -0000 Review of draft-osterweil-dane-ipsec I'm heavilly involved with Oportunistic Encryption using IPsec with The Libreswan Project. We opted to first gain more experience with running code before attempting to write a draft. As such, we have found many corner cases that need to be handled that are completely left out of this document. I think it's a good idea if the authors of this document talk to people in the IPsec and DANE working groups. This draft introduces an overly complex and bad coupling of DNS, PKIX and IPsec with the very limited goal of encrypting _some_ DNS traffic. It seems to make a lot more sense to use (D)TLS to encrypt DNS traffic using the existing TLSA records at the _53.{tcp|udp} prefix. Further comments below, Paul Abstract It is not clear from the document what is being attempted. Is it encrypting all DNS traffic? The stub to the local resolver? Stub to a remote resolver? What's special about DNS compared to using IPsec to encrypt everything? Introduction Don't use the word meta-data. It's just data. We don't need to give TLA's more justification for the redefinition of the term meta-data. The introduction makes clear only (some?) DNS data is being targeted for encryption. Why would protecting DNS using OE-IPsec be treated differently from protecting ALL traffic using OE-IPsec? For example, the information leakage exposed by observing DNSSEC transactions, could enable an adversary to not only learn what Second Level Domains (SLDs) a user is querying (such as their bank, a funding agency, a security contractor, etc.), How does encrypting the DNS help? So now you don't see I was going to "nohats.ca", but you see port 443 packets to 193.110.157.102. DNS information that is encrypted yet acted upon, leaks per definition. This is like encrypting visits to Google Maps while broadcasting your GPS coordinates. The last-mile protection argument is very weak. DNSSEC validators are moving to what used to be stub resolvers only. There is no need for new technology for last-mile protection. The bootstreap is unclear. DANE uses DNS yet you plan to encrypt DNS? Section 1.1 This section introduces using PKIX certificates for binding DNS to IPsec. IPsec does not require X.509 and has support for bare public keys. Why drag in the whole TLS style Certificate, Usage and Selectors? Unlike TLS, there is no legacy base that needs to be accomodated. It makes no sense to deviate from bare public keys. It adds all the complexity without much, if any, benefit over the traditional IPSECKEY record. In fact, even the authors themselves see that: The advantages of using DANE for IPsec OE also include other simplifications that the DANE protocol inherently offers all of its protocols. Such as, the automatic deauthorization of certificates that happens when they are removed from a DNS zone , which may (under many circumstances) obviate the need for extensive use of revocation mechanisms (OCSP [RFC6960] or CRL [RFC5280]) Storing public keys in DNS removes the need for things like PKIX expiry times, CRL, OCSP... So why introduce PKIX at all??? Section 1.2 This section talks about IPSECKEY and dismisses its use because it is limited to IP-centric networks. This is not the case when one places IPSECKEYs in the forward DNS (as the current Libreswan IPsec Opportunistic Encryption uses). For example, one can build a OE-IPsec tunnel to the host bofh.nohats.ca using the IPSECKEY published for bofh.nohats.ca. No new IPSECA record is needed for that. Section 1.3 When an IPSECA record is discovered by a resolver, that resolver SHOULD follow its configurations and setup an SPD entry. If your approach uses a local resolver to setup IPsec security, then your approach could be much simplified using the same method we are curently experimenting with, which is IPSECKEY records in the forward DNS zone. If you are using a modified validating resolver on the host, it also undermines your statement in the Introduction about this solution being needed for last-mile authenticity of DNS - you already run a validating resolver on teh stub. When using IPSECA resource records to verify OE tunnels, clients MUST perform full DNSSEC validation of the DNSSEC chain of trust that leads to IPSECA RRs This looks like a big bootstrap issue. The old FreeS/WAN IPsec OE also had isues with bootstrapping and DNS. It was so bad that when starting freeswan, you would be dead in the water for about a minute while DNS lookups for OE hit the OE machinery causing more OE lookups and it took time to deal with all the failures before lines to DNS servers were either encrypted or marked as cleartext (as opposed to block until we know if we need to do crypto to it ) Trust anchors (which may be distributed during dynamic host configuration) may be useful for bootstrapping. Securing DHCP is a really hard problem. accepting trust anchors from DHCP seems a security nightmare. It goes on to note that it is okay when using RFC1918 space, but that is also dangerous. I might have VPN connections that use RFC1918 that I don't wish to yield to a wifi-based trust anchor. Section 2 This section specifies the IPSECA record. As I already said, I see no good reasons for introducing PKIX into this mix. Additionally, the use of a GATEWAY option means that these record MUST NOT be used in any forward DNS, but only in the reverse, otherwise I can put malicious entries into my forward DNS to steal other people's IP address ranges. It is not very clear IPSECA is meant only to appear in the reverse. Our experience with FreeS/WAN is that the reverse is just not good enough apart for a few big players in data centers. And with IPv6, it becomes even harder for people to put records in (resulting in amusing situations like that I cannot email Paul Vixie). Depending on the reverse tree means this will only be deployable by enterprises, and not by home users. IPsec is an IP to IP protocol. It can be used to hide port numbers. Deploying IPsec using _prefix constructions that expose port numbers defeats part of the security that IPsec offers over inline encryption such as TLS or STARTTLS. Section 3 The operational considerations are really weird. They basically state "there is no operational impact as long as our protocol is not deployed widely". It does not mention anything about additional latency for the end user. It does not talk about the IPsec NAT-T and clashing/overlapping internal IP addresses. It does not mention anycast issues, load balancers, crypto offloaders, etc. Section 5 I'm not sure what the "cooperative benefits with TLS" are? What advantage does this solution provide over using DNS (D)TLS with TLSA? Any combination of these types of protections offer both defense-in-depth (securing transactions at multiple levels) and offer security practitioners a larger mosaic of security tools from which to construct and maintain their security postures. This is a rather weak argument for adoption. From nobody Sun Feb 16 21:50:59 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4151A02DD for ; Sun, 16 Feb 2014 21:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6suTiDFxJt7 for ; Sun, 16 Feb 2014 21:50:56 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 334521A030A for ; Sun, 16 Feb 2014 21:50:55 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id j5so4379220qga.4 for ; Sun, 16 Feb 2014 21:50:53 -0800 (PST) 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=LS3BSs5bXa5l9vVdlHkloEsmO2Ku7wAZl2VWor4sAUI=; b=lTuelPSXmOfglK+7wZJ1GOdfROUJyZhEZRqZOWuMCNpz7vWrUIfP0aKfGjY2qyiTHv 1NiGVY9IrWSh0vnfzPIbq09HuoqA8P7TvY5mjgeewsyIN3CAmKqDNqC1uw+aysBgTemv Gn4gGfg2CyOBQWo/AmWAKrsb8s2hlRAGPgP316qc6NPkbMWAviVRQjtplgockiEtMv6M 7eTH3PMCXjAOZJ8wLCXeK+dDlwdBFvbKPInIVemE3Er9c7OvzG+ueK5VDDvojRt1wXJI vnwW2sGcPfbCbelkII7AfwKxBQj+nD7i1mU1fPlmqJVtAJEGbe8XR+hzlxg7+GtCi6zt gWqQ== MIME-Version: 1.0 X-Received: by 10.224.121.137 with SMTP id h9mr32480396qar.55.1392616253561; Sun, 16 Feb 2014 21:50:53 -0800 (PST) Received: by 10.229.232.202 with HTTP; Sun, 16 Feb 2014 21:50:53 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Feb 2014 11:20:53 +0530 Message-ID: From: yogendra pal To: Daniel Palomares Content-Type: multipart/alternative; boundary=089e0160c2421a204d04f293bdab Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/hp55FmW8PZIw783VNFYb8dkN1hw Cc: IPsecme WG Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 05:50:58 -0000 --089e0160c2421a204d04f293bdab Content-Type: text/plain; charset=ISO-8859-1 Hi Daniel, Quickly went through your draft, have one input for you, [In section "*5. IPsec Session parameters*"] - Consider to have case of IPCOMP also for ipsec session parameters. BR, Yogendra Pal (Ericsson) On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares < daniel.palomares.ietf@gmail.com> wrote: > Hi, > > Please find a draft we have Posted. They concern the definition of IKEv2 > and IPsec contexts. > Comments are welcome, > > BR, > > Daniel Palomares > > > > > > Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. > > Revision: 00 > Title: IKEv2/IPsec Context Definition > Document date: 2014-02-12 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt > Status: > https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ > Htmlized: > http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 > > > Abstract > > IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a > single address by the end user. The traffic is then split between > the nodes via specific IP load balancing policies. Once a session is > assigned to a given node, IPsec makes it difficult to assign the > session to another node. This makes management operations and > transparent high availability for end users difficult to perform > within the cluster. > > This document describes the contexts for IKEv2 and IPsec that MUST be > transferred between two nodes so a session can be restored. This > makes possible to transfer an IPsec session transparently to the end > user. > > > > *Daniel* *PALOMARES* > > *Orange Labs, Issy-les-Moulineaux* > > +33 6 34 23 07 88 > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --089e0160c2421a204d04f293bdab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

Quickly went through you= r draft, have one input for you,
[In section "5. IPsec Session = parameters"]
=A0- Consider to have case of IPCOMP also fo= r ipsec session parameters.


BR,
Yogendra Pal
(Ericsson)


On Thu, Fe= b 13, 2014 at 7:39 PM, Daniel Palomares <daniel.palomares.ie= tf@gmail.com> wrote:

Hi= ,

Please find a draft we have Posted. They concern the definition of IKEv2 and IPsec contexts.
Comments are welcome,

BR,

Daniel Palomares

=A0

=A0

Name: =A0 =A0 =A0=A0 draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

Re= vision: 00
Title: =A0 =A0 =A0 IKEv2/IPsec Context Definition
Document date: =A0 =A02014-02-12
Group: =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0=A0 8
URL:http://www.ietf.org/= id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
Status:= https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-de= finition/
Htmlized: h= ttp://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definitio= n-00

Abstract

=A0 =A0IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a
=A0 =A0single address by the end user. =A0The traffic is then split between
=A0 =A0the nodes via specific IP load balancing policies. =A0Once a session is
=A0 =A0assigned to a given node, IPsec makes it difficult to assign the
=A0 =A0session to another node. =A0This makes management operations and
=A0 =A0transparent high availability for end users difficult to perform
=A0 =A0within the cluster.

=A0 =A0This document describes the contexts for IKEv2 and IPsec that MUST be
=A0 =A0transferred between two nodes so a session can be restored. =A0This
=A0 =A0makes possible to transfer an IPsec session transparently to the end
=A0 =A0user.

=A0

Daniel PALOMARES

Orange Labs, Issy-les-Moulineaux

+33 6 34 23 07 = 88


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





--089e0160c2421a204d04f293bdab-- From nobody Tue Feb 18 05:06:31 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9006B1A04BE; Tue, 18 Feb 2014 05:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxcqeIkjg2oJ; Tue, 18 Feb 2014 05:06:18 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6459C1A03E4; Tue, 18 Feb 2014 05:06:17 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id x48so5906333wes.18 for ; Tue, 18 Feb 2014 05:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ytU74mhsAvmOXMMSOl6vQfnoNAP65lbwxhL77WmICm8=; b=KGujQ7OL1nOKvx7BXVNwtnH8rn7UHnP2ItjZoCu8nU6dmJ3EiUCkC0sIxpNDEOPvvQ 0rE40h3gVOg9LNWmSy1ol+J3Uqq/oQEb4XF+SBwb9ypy7X8GBAaUdAed8rrsbbq0A3GB ydLD7s3b5ECg0HOAwK6UyJ9Nytn3+tHzxI03OpqnXcGHKCEPmwpy+khPXIvoHREge6xf LL4gcooyLplTxWZMUExOogDh4zhb5n2Ebo1cDRxzfNVvWCYEX0OS0Wtd5pir6dRCEhew EoaUNW2i95vbNbOSCKCzUOqUEd79bTUApccTcPfi8UvuWyRzbXD7P8goEMLsnEutS2Y5 kRfA== MIME-Version: 1.0 X-Received: by 10.180.24.227 with SMTP id x3mr18078312wif.41.1392728773999; Tue, 18 Feb 2014 05:06:13 -0800 (PST) Received: by 10.194.171.129 with HTTP; Tue, 18 Feb 2014 05:06:13 -0800 (PST) Date: Tue, 18 Feb 2014 14:06:13 +0100 Message-ID: From: Daniel Migault To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/bV-ENwbAIEmMfW4llnuYX6JWkwY Cc: "ipsec@ietf.org" , lwip@ietf.org, "dtls-iot@ietf.org" , Sye Loong Keoh Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 13:06:21 -0000 Hi Hannes, Thank you for pointing out the issue. Actually we wanted to have feed back from both communities. - lwig for IoT to make sure we address all or relevant scenarios of IoT, and understand those we do not address. - ipsecme for the design of diet-esp. My understanding is that diet-esp should then be more an ipsecme draft and minimal esp should be in lwig. We will make this change in the next version of the draft diet-esp this week! Now comes also another question: Is diet-ESP a new protocol, a new extension, a ESP compression algorithm.... I would be happy to get opinion on that. 1) Diet-ESP: Extension vs Protocol - a) Diet-ESP is an IPsec extension The way we considered to peers agreeing on the diet-esp context is using minimal IKE sending an DIET-ESP_SUPPORTED Notify Payloads with proposition of DIET-ESP Context. The responder just ignores the propositions or chose one. All remaining stuff would be negotiated via the traditional CREATE_CHILD_SA were peers would agree on ESP, keys, algos.... >From that point of view it looks the diet-ESP is more a wire-compression algorithm. If not supported by one of the peer we fall back with standard ESP. -b) Diet-ESP is a new Protocol Another way would be to consider that all parameters of the Diet-ESP Context would be negotiated in the CREATE_CHILD_SA exchange with new Transform structures. >From that point of view diet-esp would look more like a new protocol and the possible choice may be IKE/ESP/AH/DIET-ESP.... There might be other alternatives I would be happy to hear about. For now I like better the extension way. 2) What Diet-ESP changes from regular ESP Diet-ESP changes IPsec and ESP headers, trailers with smaller fields. Diet-ESP changes the way the packet is compressed and encrypted. On the other hand, for a sensor with a single diet-ESP configuration, most of the IPsec stack remains unchanged. This is not so true for peers that are able to handle all Diet-ESP configuraions. In that case the standard way of looking up in the SAD may be changed. We will provide a better description of this in the next version of the draft. BR, Daniel On Sun, Feb 16, 2014 at 8:23 PM, Hannes Tschofenig wrote: > Hi Daniel, > > thanks for the pointer to the ipsecme agenda. > > I agree with you that ipsecme would be the right place to get this work > done since the proposal makes changes to IPsec ESP and they have the > needed experience. > > LWIG, as part of the charter, is not allowed to make changes to existing > protocols, as this snippet from the charter illustrates: > " > The group shall also not develop any new protocols or protocol behavior > modifications beyond what is already allowed by existing RFCs, because > it is important to ensure that different types of devices can work together. > " > > > Ciao > Hannes > > On 02/13/2014 02:45 PM, Daniel Migault wrote: >> Hi, >> >> We have not updated the draft to change their names, but I agree they >> definitely better fit in the LWIG. We would like to present them both >> in LWIG in London. >> >> Note Tero has been provided a 20 minute slot for an overview on "IPsec >> in constrained environments". So people interested in IoT and security >> should check the agenda at ipsecme too. >> >> [1] http://www.ietf.org/proceedings/89/agenda/agenda-89-ipsecme >> >> On Tue, Feb 4, 2014 at 2:53 AM, Sye Loong Keoh >> wrote: >>> Hi Daniel, >>> >>> As pointed out by Hannes, DICE WG is not chartered to look at IPSec for IoT. >>> However, I think your draft might be useful for LWIG WG though. >>> >>> Cheers >>> Sye Loong >>> >>> -----Original Message----- >>> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Daniel Migault >>> Sent: Friday, 31 January, 2014 10:48 PM >>> To: ipsec@ietf.org; dtls-iot@ietf.org >>> Subject: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP >>> >>> Hi, >>> >>> Please find the two drafts we have just posted. They are about IPsec/ESP minimal implementation and Diet-ESP designed for IoT. >>> >>> Comment are welcome! >>> >>> Best Regards, >>> Daniel >>> >>> >>> Name: draft-mglt-dice-diet-esp >>> Revision: 00 >>> Title: Diet-ESP: a flexible and compressed format for IPsec/ESP >>> Document date: 2014-01-31 >>> Group: Individual Submission >>> Pages: 21 >>> URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt >>> Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/ >>> Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00 >>> >>> >>> Abstract: >>> IPsec/ESP has been designed to secure IP packets exchanged between >>> two nodes. IPsec implements security at the IP layer which makes >>> security transparent to the applications, as opposed to TLS or DTLS >>> that requires application to implement TLS/DTLS. As a result, IPsec >>> enable to define the security rules in a similar way one establishes >>> firewall rules. >>> >>> One of the IPsec's drawbacks is that implementing security on a per >>> packet basis adds overhead to each IP packet. Considering IoT >>> devices, the data transmitted over an IP packet is expected to be >>> rather small, and the cost of sending extra bytes is so high that >>> IPsec/ESP can hardly be used for IoT as it is currently defined in >>> RFC 4303. >>> >>> This document defines Diet-ESP, a protocol that compress and reduce >>> the ESP overhead of IPsec/ESP so that it can fit security and energy >>> efficient IoT requirements. Diet-ESP use already existing mechanism >>> like IKEv2 to negotiate the compression format. Furthermore a lot of >>> information, already existing for an IPsec Security Association, are >>> reused to offer light negotiation in addition to maximum compression. >>> >>> >>> Name: draft-mglt-lwig-minimal-esp >>> Revision: 00 >>> Title: Minimal ESP >>> Document date: 2014-01-31 >>> Group: Individual Submission >>> Pages: 6 >>> URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt >>> Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/ >>> Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00 >>> >>> >>> Abstract: >>> This document describes a minimal version of the IP Encapsulation >>> Security Payload (ESP) described in RFC 4303 which is part of the >>> IPsec suite. >>> >>> ESP is used to provide confidentiality, data origin authentication, >>> connectionless integrity, an anti-replay service (a form of partial >>> sequence integrity), and limited traffic flow confidentiality. >>> >>> This document does not update or modify RFC 4303, but provides a >>> compact description of the minimal version of the protocol. If this >>> document and RFC 4303 conflicts then RFC 4303 is the authoritative >>> description. >>> >>> >>> -- >>> Daniel Migault >>> Orange Labs -- Security >>> +33 6 70 72 69 58 >>> _______________________________________________ >>> dtls-iot mailing list >>> dtls-iot@ietf.org >>> https://www.ietf.org/mailman/listinfo/dtls-iot >> >> >> > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Tue Feb 18 05:22:33 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B721A04BF; Tue, 18 Feb 2014 05:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExKevo7n0Lvx; Tue, 18 Feb 2014 05:22:28 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9023A1A04B1; Tue, 18 Feb 2014 05:22:27 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w62so11752888wes.29 for ; Tue, 18 Feb 2014 05:22:24 -0800 (PST) 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=hYFllRPDFL37bUQZgtAXIxSTM0SS/gO+4uiG5Kfcf4Y=; b=QByA7slGg8LbsG4RiiV8OH95pVzPgOVvvv0FjL3gnCrQdJ3uGAXqgBRJ+QwsI1w76w Oo0QtXMfTotrdx9BmBuFJMoH/Q2hQvbLm/xcHwZuh7D6aahuO/qlsNW/wQ8ObLnhgQRU jjvPsHIs618LG6GMyjXZTiaeR3ZndTIfCexuWoN5YMammlc9yXN69CwcBhKZ9NNI+b+J 7UZ7lfRyv9ChJxov83ltOo3+Ib9MVqoqDWwuGCv4YZ8GswpQCfIwVeAQfZolFqL4gs2w GYPPnYsjFasn1YkyK+4QN485iUTnEvPzm44mleEX0e33M9uISGGMQ1CTPjqsz0FmAjKa 2OYQ== MIME-Version: 1.0 X-Received: by 10.194.87.5 with SMTP id t5mr1912317wjz.68.1392729744184; Tue, 18 Feb 2014 05:22:24 -0800 (PST) Received: by 10.194.171.129 with HTTP; Tue, 18 Feb 2014 05:22:24 -0800 (PST) In-Reply-To: <52EC03BC.60609@gmx.net> References: <52EC03BC.60609@gmx.net> Date: Tue, 18 Feb 2014 14:22:24 +0100 Message-ID: From: Daniel Migault To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Z-Iiqy0T68P8ZLvMfE6WJPmmi6k Cc: "ipsec@ietf.org" , tobias.guggemos@stud.ifi.lmu.de, "dtls-iot@ietf.org" , dominique.barthel@orange.com Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 13:22:30 -0000 Hi Hannes, So yes I agree, minimal ESP better fits lwig whereas diet-esp better fits ipsecme. Orange already operates networks of smart communicating objects, either directly or through its joint-venture m2o City. Orange is committed to contributing to the advent of the Internet of Things. Dominique is maybe the best entry point to know more on our activities with IoT. We are currently looking at using IPsec and compare it with TLS as a research topic. Currently Tobi implemented Diet-ESP on Python and for contiki. As soon as we have published tests we will provide the code as opensource. BR, Daniel On Fri, Jan 31, 2014 at 9:12 PM, Hannes Tschofenig wrote: > Hi Daniel, > > the charter of the DICE working group considers IPsec/IKEv2 outside the > scope. The charter also requires the work to be a profile rather than a > new design. A profile is just a subset of the functionality of the > existing protocol that would still interoperate with the full version. > > On the content: Do you plan to use the work within your company / in > products? I have not ran into someone who was planning to use IPsec in > the IoT context but I am happy to learn about new deployments. > > Ciao > Hannes > > > On 01/31/2014 02:48 PM, Daniel Migault wrote: >> Hi, >> >> Please find the two drafts we have just posted. They are about >> IPsec/ESP minimal implementation and Diet-ESP designed for IoT. >> >> Comment are welcome! >> >> Best Regards, >> Daniel >> >> >> Name: draft-mglt-dice-diet-esp >> Revision: 00 >> Title: Diet-ESP: a flexible and compressed format for IPsec/ESP >> Document date: 2014-01-31 >> Group: Individual Submission >> Pages: 21 >> URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt >> Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/ >> Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00 >> >> >> Abstract: >> IPsec/ESP has been designed to secure IP packets exchanged between >> two nodes. IPsec implements security at the IP layer which makes >> security transparent to the applications, as opposed to TLS or DTLS >> that requires application to implement TLS/DTLS. As a result, IPsec >> enable to define the security rules in a similar way one establishes >> firewall rules. >> >> One of the IPsec's drawbacks is that implementing security on a per >> packet basis adds overhead to each IP packet. Considering IoT >> devices, the data transmitted over an IP packet is expected to be >> rather small, and the cost of sending extra bytes is so high that >> IPsec/ESP can hardly be used for IoT as it is currently defined in >> RFC 4303. >> >> This document defines Diet-ESP, a protocol that compress and reduce >> the ESP overhead of IPsec/ESP so that it can fit security and energy >> efficient IoT requirements. Diet-ESP use already existing mechanism >> like IKEv2 to negotiate the compression format. Furthermore a lot of >> information, already existing for an IPsec Security Association, are >> reused to offer light negotiation in addition to maximum compression. >> >> >> Name: draft-mglt-lwig-minimal-esp >> Revision: 00 >> Title: Minimal ESP >> Document date: 2014-01-31 >> Group: Individual Submission >> Pages: 6 >> URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt >> Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/ >> Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00 >> >> >> Abstract: >> This document describes a minimal version of the IP Encapsulation >> Security Payload (ESP) described in RFC 4303 which is part of the >> IPsec suite. >> >> ESP is used to provide confidentiality, data origin authentication, >> connectionless integrity, an anti-replay service (a form of partial >> sequence integrity), and limited traffic flow confidentiality. >> >> This document does not update or modify RFC 4303, but provides a >> compact description of the minimal version of the protocol. If this >> document and RFC 4303 conflicts then RFC 4303 is the authoritative >> description. >> >> > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Tue Feb 18 08:25:24 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31D81A04DC for ; Tue, 18 Feb 2014 08:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3YhXY00OBBK for ; Tue, 18 Feb 2014 08:25:21 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 36F5E1A04F1 for ; Tue, 18 Feb 2014 08:25:21 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id f10so15701882yha.35 for ; Tue, 18 Feb 2014 08:25:18 -0800 (PST) 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=ghQNUTWxD2tJRGiS4L+92+tQlRggI2Ct/Hpa36fuoxQ=; b=b0ehktsj3qS2NuLOovJPvUTdXhgu161gfchTbJlXfmjmQvkSBkPN7AtXCA3zrH+ha3 uyF76N8/ztiTvwya8Fv3gVtSOwFq+hhB9JLA06y1l2q0h/3ChD8T8QzjvbGz8ll1/mOR WT7enCQ+UZQl3Os7RLyJp9OFBJHIFFniuoTyr3KVbXL8Nld95NAsTQRACGVwXo3VJtAU dpGZOiEsX9UB/PxziLqkiN9UujAyG03fKdxEGAmOYhVS1nXmN3Qog/DrcWqlk9c4o+U/ DqbeYKAnGpEyJlr2VY+TLvK3cJDlVoB9xqEBENntAL5Rgux8Ks5PkYapBvFCF8HMfY9+ 5juQ== MIME-Version: 1.0 X-Received: by 10.236.100.235 with SMTP id z71mr30933288yhf.43.1392740718135; Tue, 18 Feb 2014 08:25:18 -0800 (PST) Received: by 10.170.189.70 with HTTP; Tue, 18 Feb 2014 08:25:18 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Feb 2014 21:55:18 +0530 Message-ID: From: yogendra pal To: Daniel Palomares Content-Type: multipart/alternative; boundary=20cf301b65fbc4cdfe04f2b0b744 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/60M6odGlcprHk2gLFxUCUuvu2WA Cc: IPsecme WG Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:25:23 -0000 --20cf301b65fbc4cdfe04f2b0b744 Content-Type: text/plain; charset=ISO-8859-1 Hi Daniel, Given that ike and ipsec can runs on different context and nodes, context SHOULD capture at least *instance-id* or *flow-id*. This *instance-id* can help the node to identify which packet processing unit will process this ipsec traffic or which ipsec instance out of multiple ipsec processing unit will process this ipsec traffic. Let me take a simple example case to explain: On a node A, which has 10 processing unit (pu) = {1,2,3,4,5,6,7,8,9,10} and out of which ike is using single unit = {1} and ipsec is using 7 processing unit(s) = {2,3,4,5,6,7,8} and other processing units = {9,10} for general purpose. Each IPsec SA processing can be tied with specific processing unit and can be called as *instance-id *or *flow-id*. This SA can hold *instance-id *or *flow-id *information. Upon sync up of context for each IPsec SA to other node B upon failure, it can process the same SA on specific *instance-id* or *flow-id.* P.S: If your need some text around this, I can provide you a example and usage of it. BR, Yogendra Pal (Ericsson, India) On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal wrote: > Hi Daniel, > > Quickly went through your draft, have one input for you, > [In section "*5. IPsec Session parameters*"] > - Consider to have case of IPCOMP also for ipsec session parameters. > > > BR, > Yogendra Pal > (Ericsson) > > > On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares < > daniel.palomares.ietf@gmail.com> wrote: > >> Hi, >> >> Please find a draft we have Posted. They concern the definition of IKEv2 >> and IPsec contexts. >> Comments are welcome, >> >> BR, >> >> Daniel Palomares >> >> >> >> >> >> Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. >> >> Revision: 00 >> Title: IKEv2/IPsec Context Definition >> Document date: 2014-02-12 >> Group: Individual Submission >> Pages: 8 >> URL: >> http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ >> Htmlized: >> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 >> >> >> Abstract >> >> IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a >> single address by the end user. The traffic is then split between >> the nodes via specific IP load balancing policies. Once a session is >> assigned to a given node, IPsec makes it difficult to assign the >> session to another node. This makes management operations and >> transparent high availability for end users difficult to perform >> within the cluster. >> >> This document describes the contexts for IKEv2 and IPsec that MUST be >> transferred between two nodes so a session can be restored. This >> makes possible to transfer an IPsec session transparently to the end >> user. >> >> >> >> *Daniel* *PALOMARES* >> >> *Orange Labs, Issy-les-Moulineaux* >> >> +33 6 34 23 07 88 >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > > > > --20cf301b65fbc4cdfe04f2b0b744 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

Given that ike and ipsec= can runs on different context and nodes, context SHOULD capture at least <= i>instance-id or flow-id. This instance-id can help the n= ode to identify which packet processing unit will process this ipsec traffi= c or which ipsec instance out of multiple ipsec processing unit will proces= s this ipsec traffic.

Let me take a simple example case to explain:

<= div>On a node A, which has 10 processing unit (pu) =3D {1,2,3,4,5,6,7,8,9,1= 0} and out of which ike is using single unit =3D {1} and ipsec is using 7 p= rocessing unit(s) =3D {2,3,4,5,6,7,8} and other processing units =3D {9,10}= for general purpose.

Each IPsec SA processing can be tied with specific processin= g unit and can be called as instance-id or flow-id. This SA c= an hold instance-id or flow-id information. Upon sync up of c= ontext for each IPsec SA to other node B upon failure, it can process the s= ame SA on specific instance-id or flow-id.

P.S: If your need some text around this, I can pr= ovide you a example and usage of it.

BR,
Yogendra Pal
(Ericsson, India)

On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal <= span dir=3D"ltr"><jntupal@gmail.com> wrote:
Hi Daniel,

Quickly went through you= r draft, have one input for you,
[In section "5. IPsec Session = parameters"]
=A0- Consider to have case of IPCOMP also fo= r ipsec session parameters.


BR,
Yogendra Pal
(Ericsson)


On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares <daniel.palomares.ietf@gmail.com> wrote:

Hi= ,

Please find a draft we have Posted. They concern the definition of IKEv2 and IPsec contexts.
Comments are welcome,

BR,

Daniel Palomares

=A0

=A0

Name: =A0 =A0 =A0=A0 draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

Re= vision: 00
Title: =A0 =A0 =A0 IKEv2/IPsec Context Definition
Document date: =A0 =A02014-02-12
Group: =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0=A0 8
URL:http://www.ietf.org/= id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
Status:= https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-de= finition/
Htmlized: h= ttp://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definitio= n-00

Abstract

=A0 =A0IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a
=A0 =A0single address by the end user. =A0The traffic is then split between
=A0 =A0the nodes via specific IP load balancing policies. =A0Once a session is
=A0 =A0assigned to a given node, IPsec makes it difficult to assign the
=A0 =A0session to another node. =A0This makes management operations and
=A0 =A0transparent high availability for end users difficult to perform
=A0 =A0within the cluster.

=A0 =A0This document describes the contexts for IKEv2 and IPsec that MUST be
=A0 =A0transferred between two nodes so a session can be restored. =A0This
=A0 =A0makes possible to transfer an IPsec session transparently to the end
=A0 =A0user.

=A0

Daniel PALOMARES

Orange Labs, Issy-les-Moulineaux

+33 6 34 23 07 = 88


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








--20cf301b65fbc4cdfe04f2b0b744-- From nobody Tue Feb 18 09:10:15 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C3E1A0213; Tue, 18 Feb 2014 09:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQhvvu6Xmc8D; Tue, 18 Feb 2014 09:10:09 -0800 (PST) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DACEA1A020A; Tue, 18 Feb 2014 09:10:08 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id c13so7905041eek.17 for ; Tue, 18 Feb 2014 09:10:05 -0800 (PST) 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=wsNzuN3JKdWrBCm7n/nY0NZHN4jUe0ZSlj04+FIFFx4=; b=dq7TIXyR4e7kGEjpZkak9ZYorucQMCu2sof5uY/0D3G39DEsot87EieYoPSothQaD7 9nssPxX+tKX4b/NBm4Dq7GNPevKS1v/kCG2u+OKFbhJrnqliOtAF+EnYwaIQYiqJiXNm xGe4QkZZ6s++iDiK+kRRRvZFAHLmvrloCBwD2XuK2wZP9EXQ24Jnr74w2GhcHEpj2uRM zELTEVbjUoMwn/LaDQAbWy/s4zER5ZpKIPacnqR6y9kPOJrgOHN4kcR98QEf2irULp59 VTOzBE28vdme9P31BFTQw3gTUiGFd3KU4jkxt+TN1aboz3kJ/9JigAZSKAbVt4rzyxG0 UnYg== X-Received: by 10.14.194.193 with SMTP id m41mr9482728een.76.1392743405416; Tue, 18 Feb 2014 09:10:05 -0800 (PST) Received: from [10.0.0.6] (bzq-79-177-25-225.red.bezeqint.net. [79.177.25.225]) by mx.google.com with ESMTPSA id 46sm72183092ees.4.2014.02.18.09.10.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 09:10:04 -0800 (PST) Message-ID: <530393EA.5020008@gmail.com> Date: Tue, 18 Feb 2014 19:10:02 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Daniel Migault , Hannes Tschofenig References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/aLxmS7MeKytqu7wtOk0p6jD3jD0 Cc: "ipsec@ietf.org" , lwip@ietf.org, Sye Loong Keoh Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:10:11 -0000 Hi Daniel, This might be a naive answer - I have not read the draft in detail. But on the "is this a duck or not" question, it seems to me the answer is simple: if the protocol can work stand-alone (two endpoints talking to each other, with manual keying and no IKE), then it's a protocol. Otherwise it's a protocol extension. And if it's a protocol, it needs an IP protocol number, which is a seriously expensive resource. We allocated one for WESP (http://tools.ietf.org/html/rfc5840#section-4), is there any chance we could reuse it somehow? Thanks, Yaron On 02/18/2014 03:06 PM, Daniel Migault wrote: > Hi Hannes, > [...] > > Now comes also another question: Is diet-ESP a new protocol, a new > extension, a ESP compression algorithm.... I would be happy to get > opinion on that. > > 1) Diet-ESP: Extension vs Protocol > > - a) Diet-ESP is an IPsec extension > The way we considered to peers agreeing on the diet-esp context is > using minimal IKE sending an DIET-ESP_SUPPORTED Notify Payloads with > proposition of DIET-ESP Context. The responder just ignores the > propositions or chose one. All remaining stuff would be negotiated via > the traditional CREATE_CHILD_SA were peers would agree on ESP, keys, > algos.... >>From that point of view it looks the diet-ESP is more a > wire-compression algorithm. If not supported by one of the peer we > fall back with standard ESP. > > -b) Diet-ESP is a new Protocol > Another way would be to consider that all parameters of the Diet-ESP > Context would be negotiated in the CREATE_CHILD_SA exchange with new > Transform structures. >>From that point of view diet-esp would look more like a new protocol > and the possible choice may be IKE/ESP/AH/DIET-ESP.... > > There might be other alternatives I would be happy to hear about. For > now I like better the extension way. > > 2) What Diet-ESP changes from regular ESP > > Diet-ESP changes IPsec and ESP headers, trailers with smaller fields. > > Diet-ESP changes the way the packet is compressed and encrypted. > > On the other hand, for a sensor with a single diet-ESP configuration, > most of the IPsec stack remains unchanged. This is not so true for > peers that are able to handle all Diet-ESP configuraions. In that case > the standard way of looking up in the SAD may be changed. We will > provide a better description of this in the next version of the draft. > > BR, > Daniel > From nobody Tue Feb 18 10:17:19 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C429D1A00F2 for ; Tue, 18 Feb 2014 10:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsguE81TGWSv for ; Tue, 18 Feb 2014 10:17:14 -0800 (PST) Received: from mail-ie0-x243.google.com (mail-ie0-x243.google.com [IPv6:2607:f8b0:4001:c03::243]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCF71A002C for ; Tue, 18 Feb 2014 10:17:14 -0800 (PST) Received: by mail-ie0-f195.google.com with SMTP id to1so1284689ieb.6 for ; Tue, 18 Feb 2014 10:17:11 -0800 (PST) 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=JzXunWNHj6ZgZOhPt7JtMwDcCAXXHvg7oF4cCis9QD4=; b=x5YayK8DoIQMOlzLfIeH9cebgJnj4JvaJClNXQYS6oYfT09VbPWQzg3JLjIuAZo4nd M4ceNeAcUu8WLXwhjOAbpSCfzWGnqNKSronaqSB0ZBd99tOXK7Tg/q0Sp6JXPFgFpICo VOpvXX6rpvHOnf8q5MfKUAnN/YxJnosMhrkRA30h/QbP7nUrCC2MdbuzigSHlO8k19VN 3dIEBuO2bAnyWSRJBWw0zZ3C04Vd6GvuXOVhpHndbH/N6T7GjXFdz1zQuFPqYUyC5gqg dSldpU6vZDVxOoB4cCSffZxmyeYQ4dhrN7RG9VxqS6ObgU1hq0AkC9sRI+gt6PFZADuA x7mg== MIME-Version: 1.0 X-Received: by 10.43.58.19 with SMTP id wi19mr2861920icb.53.1392747431522; Tue, 18 Feb 2014 10:17:11 -0800 (PST) Received: by 10.50.40.131 with HTTP; Tue, 18 Feb 2014 10:17:11 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Feb 2014 19:17:11 +0100 Message-ID: From: Daniel Palomares To: yogendra pal Content-Type: multipart/alternative; boundary=bcaec51f9663eaf75b04f2b247eb Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/aMlyflfzSXSRYs3SY79Y03ykDmk Cc: IPsecme WG Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:17:18 -0000 --bcaec51f9663eaf75b04f2b247eb Content-Type: text/plain; charset=ISO-8859-1 Hi Yogendra, Thank you for your comments and pointing out the lack of the IPComp parameter. I will update the draft including the IPComp flag , as well as the IPcomp algo and the cpi-in/out values. I understand when you say the draft "SHOULD capture at least *instance-id*or *flow-id". *However, I'm not familiar with this definitions as IKEv2 or IPsec standards. Please don't hesitate to address me to those documents if they are actually standardized. On the other hand, I could understand that those parameters you just mention (*instance-id* and *flow-id*), might be proprietary solutions to improve IPsec treatment among several processing units. If it is the case, I believe that our document may introduce supplementary information in the context prior some negotiation, but I believe we should let the whole mailing-list discuss about this. By now, our wish is to isolate the IKEv2 and IPsec mandatory parameters in order to keep an IKEv2/IPsec session alive. KR, Daniel Palomares 2014-02-18 17:25 GMT+01:00 yogendra pal : > Hi Daniel, > > Given that ike and ipsec can runs on different context and nodes, context > SHOULD capture at least *instance-id* or *flow-id*. This *instance-id*can help the node to identify which packet processing unit will process > this ipsec traffic or which ipsec instance out of multiple ipsec processing > unit will process this ipsec traffic. > > Let me take a simple example case to explain: > > On a node A, which has 10 processing unit (pu) = {1,2,3,4,5,6,7,8,9,10} > and out of which ike is using single unit = {1} and ipsec is using 7 > processing unit(s) = {2,3,4,5,6,7,8} and other processing units = {9,10} > for general purpose. > > Each IPsec SA processing can be tied with specific processing unit and can > be called as *instance-id *or *flow-id*. This SA can hold *instance-id *or > *flow-id *information. Upon sync up of context for each IPsec SA to other > node B upon failure, it can process the same SA on specific *instance-id*or > *flow-id.* > > P.S: If your need some text around this, I can provide you a example and > usage of it. > > BR, > Yogendra Pal > (Ericsson, India) > > > On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal wrote: > >> Hi Daniel, >> >> Quickly went through your draft, have one input for you, >> [In section "*5. IPsec Session parameters*"] >> - Consider to have case of IPCOMP also for ipsec session parameters. >> >> >> BR, >> Yogendra Pal >> (Ericsson) >> >> >> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares < >> daniel.palomares.ietf@gmail.com> wrote: >> >>> Hi, >>> >>> Please find a draft we have Posted. They concern the definition of IKEv2 >>> and IPsec contexts. >>> Comments are welcome, >>> >>> BR, >>> >>> Daniel Palomares >>> >>> >>> >>> >>> >>> Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. >>> >>> Revision: 00 >>> Title: IKEv2/IPsec Context Definition >>> Document date: 2014-02-12 >>> Group: Individual Submission >>> Pages: 8 >>> URL: >>> http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 >>> >>> >>> Abstract >>> >>> IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a >>> single address by the end user. The traffic is then split between >>> the nodes via specific IP load balancing policies. Once a session is >>> assigned to a given node, IPsec makes it difficult to assign the >>> session to another node. This makes management operations and >>> transparent high availability for end users difficult to perform >>> within the cluster. >>> >>> This document describes the contexts for IKEv2 and IPsec that MUST be >>> transferred between two nodes so a session can be restored. This >>> makes possible to transfer an IPsec session transparently to the end >>> user. >>> >>> >>> >>> *Daniel* *PALOMARES* >>> >>> *Orange Labs, Issy-les-Moulineaux* >>> >>> +33 6 34 23 07 88 >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >> >> >> >> > > > --bcaec51f9663eaf75b04f2b247eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Yogendra,

Thank you for your comment= s and pointing out the lack of the IPComp parameter.
I will u= pdate the draft including the IPComp flag , as well as the IPcomp algo and = the cpi-in/out values.

I understand when you say=A0 the draft "SHOULD capture = at least instance-id or flow-id". However, I'm not f= amiliar with this definitions as IKEv2 or IPsec standards. Please don't= hesitate to address me to those documents if they are actually standardize= d.

On the other hand, I could understand that those parameters you just me= ntion (instance-id and flow-id), might be proprietary solutio= ns to improve IPsec treatment among several processing units. If it is the = case, I believe that our document may introduce supplementary information i= n the context prior some negotiation, but I believe we should let the whole= mailing-list discuss about this.

By now, our wish is to isolate the IKEv2 and IPsec mandatory parameters= in order to keep an IKEv2/IPsec session alive.

KR,
Daniel Palomares




2014-02-18 17:25 GMT+01:00 yogendra pal = <jntupal@gmail.com>:
Hi Daniel,

Given that ike and ipsec= can runs on different context and nodes, context SHOULD capture at least <= i>instance-id or flow-id. This instance-id can help the n= ode to identify which packet processing unit will process this ipsec traffi= c or which ipsec instance out of multiple ipsec processing unit will proces= s this ipsec traffic.

Let me take a simple example case to explain:

<= div>On a node A, which has 10 processing unit (pu) =3D {1,2,3,4,5,6,7,8,9,1= 0} and out of which ike is using single unit =3D {1} and ipsec is using 7 p= rocessing unit(s) =3D {2,3,4,5,6,7,8} and other processing units =3D {9,10}= for general purpose.

Each IPsec SA processing can be tied with specific processin= g unit and can be called as instance-id or flow-id. This SA c= an hold instance-id or flow-id information. Upon sync up of c= ontext for each IPsec SA to other node B upon failure, it can process the s= ame SA on specific instance-id or flow-id.

P.S: If your need some text around this, I can pr= ovide you a example and usage of it.

BR,
Yogendra Pal
(Ericsson, India)


On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal <= span dir=3D"ltr"><jntupal@gmail.com> wrote:
Hi Daniel,

Quickly went through you= r draft, have one input for you,
[In section "5. IPsec Session = parameters"]
=A0- Consider to have case of IPCOMP also fo= r ipsec session parameters.


BR,
Yogendra Pal
(Ericsson)


= On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares <daniel.pa= lomares.ietf@gmail.com> wrote:

Hi= ,

Please find a draft we have Posted. They concern the definition of IKEv2 and IPsec contexts.
Comments are welcome,

BR,

Daniel Palomares

=A0

=A0

Name: =A0 =A0 =A0=A0 draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

Re= vision: 00
Title: =A0 =A0 =A0 IKEv2/IPsec Context Definition
Document date: =A0 =A02014-02-12
Group: =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0=A0 8
URL:http://www.ietf.org/= id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
Status:= https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-de= finition/
Htmlized: h= ttp://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definitio= n-00

Abstract

=A0 =A0IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a
=A0 =A0single address by the end user. =A0The traffic is then split between
=A0 =A0the nodes via specific IP load balancing policies. =A0Once a session is
=A0 =A0assigned to a given node, IPsec makes it difficult to assign the
=A0 =A0session to another node. =A0This makes management operations and
=A0 =A0transparent high availability for end users difficult to perform
=A0 =A0within the cluster.

=A0 =A0This document describes the contexts for IKEv2 and IPsec that MUST be
=A0 =A0transferred between two nodes so a session can be restored. =A0This
=A0 =A0makes possible to transfer an IPsec session transparently to the end
=A0 =A0user.

=A0

Daniel PALOMARES

Orange Labs, Issy-les-Moulineaux

+33 6 34 23 07 = 88


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









--bcaec51f9663eaf75b04f2b247eb-- From nobody Tue Feb 18 21:27:51 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610091A0443 for ; Tue, 18 Feb 2014 21:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ3x9DqLUhDJ for ; Tue, 18 Feb 2014 21:27:44 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1115D1A043E for ; Tue, 18 Feb 2014 21:27:43 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 200so36089064ykr.3 for ; Tue, 18 Feb 2014 21:27:40 -0800 (PST) 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=a0S+oa5LrIEKELfO7mkY4u6w38/dacdZ093A0mNrQ3Q=; b=UncX91wtuw5SlHNEbyWoNHvZXCp+PNtHg3dytsc7CoVr7zJEa4JLxihvsAmgW0xTjw SI6Z0LwzV2Xlj9PSAnCDt4ArumSOG6BaTNRlfqo/c1sZfHCSixmc4HP3hjF+GHCbzJWy DIz7KKQuSYwadSmJNRRgBLEjABaGnKE7AtE972SKoVHcIMCxphMu8sk6aaQeUKq+pfxN a3oLX/j7w7ZmIn8c3hbS3d56Jv3rB9fEB3RtK4s6j85mc94pf0nTOPj5gmx69LYsC4En jkWLxADvbDdDlTPj+k14F98CY32N2NhPJ5+9LMsOhscDn4CP6SrqJon7lvz6CXSRQMZ/ RRew== MIME-Version: 1.0 X-Received: by 10.236.100.235 with SMTP id z71mr35106333yhf.43.1392787660682; Tue, 18 Feb 2014 21:27:40 -0800 (PST) Received: by 10.170.189.70 with HTTP; Tue, 18 Feb 2014 21:27:40 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 10:57:40 +0530 Message-ID: From: yogendra pal To: Daniel Palomares Content-Type: multipart/alternative; boundary=20cf301b65fbc33c7d04f2bba54c Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/but58SNIMTbusQdHRkT-P8MHD4I Cc: IPsecme WG Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 05:27:47 -0000 --20cf301b65fbc33c7d04f2bba54c Content-Type: text/plain; charset=ISO-8859-1 Hi Daniel, I agree w/ what you said, let the ipsec mailing list discussion this out, I just opened the forum w/ my inputs "*instance-id". *Since this draft is towards keeping IKEv2/IPsec session alive when any fault is detected on current node. Thanks, Yogendra Pal (Ericssson, India) On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares < daniel.palomares.ietf@gmail.com> wrote: > Hi Yogendra, > > Thank you for your comments and pointing out the lack of the IPComp > parameter. > I will update the draft including the IPComp flag , as well as the IPcomp > algo and the cpi-in/out values. > > I understand when you say the draft "SHOULD capture at least > *instance-id* or *flow-id". *However, I'm not familiar with this > definitions as IKEv2 or IPsec standards. Please don't hesitate to address > me to those documents if they are actually standardized. > > On the other hand, I could understand that those parameters you just > mention (*instance-id* and *flow-id*), might be proprietary solutions to > improve IPsec treatment among several processing units. If it is the case, > I believe that our document may introduce supplementary information in the > context prior some negotiation, but I believe we should let the whole > mailing-list discuss about this. > > By now, our wish is to isolate the IKEv2 and IPsec mandatory parameters in > order to keep an IKEv2/IPsec session alive. > > KR, > Daniel Palomares > > > > > 2014-02-18 17:25 GMT+01:00 yogendra pal : > > Hi Daniel, >> >> Given that ike and ipsec can runs on different context and nodes, context >> SHOULD capture at least *instance-id* or *flow-id*. This *instance-id*can help the node to identify which packet processing unit will process >> this ipsec traffic or which ipsec instance out of multiple ipsec processing >> unit will process this ipsec traffic. >> >> Let me take a simple example case to explain: >> >> On a node A, which has 10 processing unit (pu) = {1,2,3,4,5,6,7,8,9,10} >> and out of which ike is using single unit = {1} and ipsec is using 7 >> processing unit(s) = {2,3,4,5,6,7,8} and other processing units = {9,10} >> for general purpose. >> >> Each IPsec SA processing can be tied with specific processing unit and >> can be called as *instance-id *or *flow-id*. This SA can hold *instance-id >> *or *flow-id *information. Upon sync up of context for each IPsec SA to >> other node B upon failure, it can process the same SA on specific >> *instance-id* or *flow-id.* >> >> P.S: If your need some text around this, I can provide you a example and >> usage of it. >> >> BR, >> Yogendra Pal >> (Ericsson, India) >> >> >> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal wrote: >> >>> Hi Daniel, >>> >>> Quickly went through your draft, have one input for you, >>> [In section "*5. IPsec Session parameters*"] >>> - Consider to have case of IPCOMP also for ipsec session parameters. >>> >>> >>> BR, >>> Yogendra Pal >>> (Ericsson) >>> >>> >>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares < >>> daniel.palomares.ietf@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> Please find a draft we have Posted. They concern the definition of >>>> IKEv2 and IPsec contexts. >>>> Comments are welcome, >>>> >>>> BR, >>>> >>>> Daniel Palomares >>>> >>>> >>>> >>>> >>>> >>>> Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. >>>> >>>> Revision: 00 >>>> Title: IKEv2/IPsec Context Definition >>>> Document date: 2014-02-12 >>>> Group: Individual Submission >>>> Pages: 8 >>>> URL: >>>> http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 >>>> >>>> >>>> Abstract >>>> >>>> IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a >>>> single address by the end user. The traffic is then split between >>>> the nodes via specific IP load balancing policies. Once a session is >>>> assigned to a given node, IPsec makes it difficult to assign the >>>> session to another node. This makes management operations and >>>> transparent high availability for end users difficult to perform >>>> within the cluster. >>>> >>>> This document describes the contexts for IKEv2 and IPsec that MUST be >>>> transferred between two nodes so a session can be restored. This >>>> makes possible to transfer an IPsec session transparently to the end >>>> user. >>>> >>>> >>>> >>>> *Daniel* *PALOMARES* >>>> >>>> *Orange Labs, Issy-les-Moulineaux* >>>> >>>> +33 6 34 23 07 88 >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> >>> >>> >>> >>> >> >> >> > -- Thanks and Regards, Yogendra Pal +919686202644 --20cf301b65fbc33c7d04f2bba54c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

I agree w/ what you said= , let the ipsec mailing list discussion this out, I just opened the forum w= / my inputs "instance-id".=A0 Since this draft is towards = keeping IKEv2/IPsec session alive when any fault is detected on current nod= e.

Thanks,
Yogendra Pal
(Ericssson,= India)



On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares <daniel.palomares.ietf@gmail.com> wrote:
Hi Yogendra,
Thank you for your comments and pointing out the lack of the IPComp pa= rameter.
I will update the draft including the IPComp flag , as well as t= he IPcomp algo and the cpi-in/out values.

I understand when you say=A0 the draft "SHOULD capture = at least instance-id or flow-id". However, I'm not f= amiliar with this definitions as IKEv2 or IPsec standards. Please don't= hesitate to address me to those documents if they are actually standardize= d.

On the other hand, I could understand that those parameters you just me= ntion (instance-id and flow-id), might be proprietary solutio= ns to improve IPsec treatment among several processing units. If it is the = case, I believe that our document may introduce supplementary information i= n the context prior some negotiation, but I believe we should let the whole= mailing-list discuss about this.

By now, our wish is to isolate the IKEv2 and IPsec mandatory parameters= in order to keep an IKEv2/IPsec session alive.

KR,
Daniel Palomares




2014-02-18 17:25 GMT+01:00 yogendra pal = <jntupal@gmail.com>:

Hi Daniel,

Given that ike and ipsec= can runs on different context and nodes, context SHOULD capture at least <= i>instance-id or flow-id. This instance-id can help the n= ode to identify which packet processing unit will process this ipsec traffi= c or which ipsec instance out of multiple ipsec processing unit will proces= s this ipsec traffic.

Let me take a simple example case to explain:

<= div>On a node A, which has 10 processing unit (pu) =3D {1,2,3,4,5,6,7,8,9,1= 0} and out of which ike is using single unit =3D {1} and ipsec is using 7 p= rocessing unit(s) =3D {2,3,4,5,6,7,8} and other processing units =3D {9,10}= for general purpose.

Each IPsec SA processing can be tied with specific processin= g unit and can be called as instance-id or flow-id. This SA c= an hold instance-id or flow-id information. Upon sync up of c= ontext for each IPsec SA to other node B upon failure, it can process the s= ame SA on specific instance-id or flow-id.

P.S: If your need some text around this, I can pr= ovide you a example and usage of it.

BR,
Yogendra Pal
(Ericsson, India)


On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal <= span dir=3D"ltr"><jntupal@gmail.com> wrote:
Hi Daniel,

Quickly went through you= r draft, have one input for you,
[In section "5. IPsec Session = parameters"]
=A0- Consider to have case of IPCOMP also fo= r ipsec session parameters.


BR,
Yogendra Pal
(Ericsson)


= On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares <daniel.pa= lomares.ietf@gmail.com> wrote:

Hi= ,

Please find a draft we have Posted. They concern the definition of IKEv2 and IPsec contexts.
Comments are welcome,

BR,

Daniel Palomares

=A0

=A0

Name: =A0 =A0 =A0=A0 draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

Re= vision: 00
Title: =A0 =A0 =A0 IKEv2/IPsec Context Definition
Document date: =A0 =A02014-02-12
Group: =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0=A0 8
URL:http://www.ietf.org/= id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
Status:= https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-de= finition/
Htmlized: h= ttp://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definitio= n-00

Abstract

=A0 =A0IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a
=A0 =A0single address by the end user. =A0The traffic is then split between
=A0 =A0the nodes via specific IP load balancing policies. =A0Once a session is
=A0 =A0assigned to a given node, IPsec makes it difficult to assign the
=A0 =A0session to another node. =A0This makes management operations and
=A0 =A0transparent high availability for end users difficult to perform
=A0 =A0within the cluster.

=A0 =A0This document describes the contexts for IKEv2 and IPsec that MUST be
=A0 =A0transferred between two nodes so a session can be restored. =A0This
=A0 =A0makes possible to transfer an IPsec session transparently to the end
=A0 =A0user.

=A0

Daniel PALOMARES

Orange Labs, Issy-les-Moulineaux

+33 6 34 23 07 = 88


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












--
Thanks and Regards,
= Yogendra Pal
+919686202644 --20cf301b65fbc33c7d04f2bba54c-- From nobody Wed Feb 19 01:03:39 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7E51A0582 for ; Wed, 19 Feb 2014 01:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACW8hGWYPiVc for ; Wed, 19 Feb 2014 01:03:34 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id EDC4D1A0581 for ; Wed, 19 Feb 2014 01:03:33 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hi5so4409768wib.3 for ; Wed, 19 Feb 2014 01:03:30 -0800 (PST) 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=M+q1X+EQN5p/xcNRD8UoL4FHCuZ62W3VicxLvucSbEk=; b=dt+NslEab0XrantvawtwttgJYqGuCcE0x33/hVK3Qki7TZwUDlyCWdLRGlQucggeVu z7+WR7TnKJg6k4BKtF/rtRaM0/XTgLShM0yptK0jJHKPRC5XrNrowe8iHar2v/CBN7ZQ rirsdl0l6G9Rvz9AKkVAZ4k6/lWN3M/dXtvSvb8kpB3ekmoQ9wmZL1JZWEs9zTbVDqi0 RU8yRKzfThI2JVhe/iDl39y/jVm/D71EK1rtO5/g4tTPGE2ZECFW/3M42x2S1OWfNvxj 5xUq4tnj9BmI+6iBaN4AY+uHgsfWU5xHQe1UR873b2pbEiRMOlTfYHZC2b/Vl9IZ2eOZ llBg== MIME-Version: 1.0 X-Received: by 10.194.60.37 with SMTP id e5mr26392466wjr.32.1392800609950; Wed, 19 Feb 2014 01:03:29 -0800 (PST) Received: by 10.194.171.129 with HTTP; Wed, 19 Feb 2014 01:03:29 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 10:03:29 +0100 Message-ID: From: Daniel Migault To: yogendra pal Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/lf7Y22JbsczydTLYALvCmPD5roo Cc: IPsecme WG , Daniel Palomares Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 09:03:38 -0000 Hi, My understanding is that at the time a format will be defined for embedding IKEv2 and IPsec context, we should be able to embed also proprietary parameters similar to vendor-ID with IKEv2. Of course these parameters will be most probably ignored by other implementations. Is there any format you like to see xml, jason, bytes format... ? What is not clear to me is why a SA on a processing unit X of node A MUST necessarily be also on processing unit X of node B. I understand processing unit as a CPU or a specific core. Am I right? BR, Daniel On Wed, Feb 19, 2014 at 6:27 AM, yogendra pal wrote: > Hi Daniel, > > I agree w/ what you said, let the ipsec mailing list discussion this out, I > just opened the forum w/ my inputs "instance-id". Since this draft is > towards keeping IKEv2/IPsec session alive when any fault is detected on > current node. > > Thanks, > Yogendra Pal > (Ericssson, India) > > > > On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares > wrote: >> >> Hi Yogendra, >> >> Thank you for your comments and pointing out the lack of the IPComp >> parameter. >> I will update the draft including the IPComp flag , as well as the IPcomp >> algo and the cpi-in/out values. >> >> I understand when you say the draft "SHOULD capture at least instance-id >> or flow-id". However, I'm not familiar with this definitions as IKEv2 or >> IPsec standards. Please don't hesitate to address me to those documents if >> they are actually standardized. >> >> On the other hand, I could understand that those parameters you just >> mention (instance-id and flow-id), might be proprietary solutions to improve >> IPsec treatment among several processing units. If it is the case, I believe >> that our document may introduce supplementary information in the context >> prior some negotiation, but I believe we should let the whole mailing-list >> discuss about this. >> >> By now, our wish is to isolate the IKEv2 and IPsec mandatory parameters in >> order to keep an IKEv2/IPsec session alive. >> >> KR, >> Daniel Palomares >> >> >> >> >> 2014-02-18 17:25 GMT+01:00 yogendra pal : >> >>> Hi Daniel, >>> >>> Given that ike and ipsec can runs on different context and nodes, context >>> SHOULD capture at least instance-id or flow-id. This instance-id can help >>> the node to identify which packet processing unit will process this ipsec >>> traffic or which ipsec instance out of multiple ipsec processing unit will >>> process this ipsec traffic. >>> >>> Let me take a simple example case to explain: >>> >>> On a node A, which has 10 processing unit (pu) = {1,2,3,4,5,6,7,8,9,10} >>> and out of which ike is using single unit = {1} and ipsec is using 7 >>> processing unit(s) = {2,3,4,5,6,7,8} and other processing units = {9,10} for >>> general purpose. >>> >>> Each IPsec SA processing can be tied with specific processing unit and >>> can be called as instance-id or flow-id. This SA can hold instance-id or >>> flow-id information. Upon sync up of context for each IPsec SA to other node >>> B upon failure, it can process the same SA on specific instance-id or >>> flow-id. >>> >>> P.S: If your need some text around this, I can provide you a example and >>> usage of it. >>> >>> BR, >>> Yogendra Pal >>> (Ericsson, India) >>> >>> >>> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal wrote: >>>> >>>> Hi Daniel, >>>> >>>> Quickly went through your draft, have one input for you, >>>> [In section "5. IPsec Session parameters"] >>>> - Consider to have case of IPCOMP also for ipsec session parameters. >>>> >>>> >>>> BR, >>>> Yogendra Pal >>>> (Ericsson) >>>> >>>> >>>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please find a draft we have Posted. They concern the definition of >>>>> IKEv2 and IPsec contexts. >>>>> Comments are welcome, >>>>> >>>>> BR, >>>>> >>>>> Daniel Palomares >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. >>>>> >>>>> Revision: 00 >>>>> Title: IKEv2/IPsec Context Definition >>>>> Document date: 2014-02-12 >>>>> Group: Individual Submission >>>>> Pages: 8 >>>>> >>>>> URL:http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt >>>>> >>>>> Status:https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 >>>>> >>>>> >>>>> Abstract >>>>> >>>>> IPsec/IKEv2 clusters are constituted of multiple nodes accessed via >>>>> a >>>>> single address by the end user. The traffic is then split between >>>>> the nodes via specific IP load balancing policies. Once a session >>>>> is >>>>> assigned to a given node, IPsec makes it difficult to assign the >>>>> session to another node. This makes management operations and >>>>> transparent high availability for end users difficult to perform >>>>> within the cluster. >>>>> >>>>> This document describes the contexts for IKEv2 and IPsec that MUST >>>>> be >>>>> transferred between two nodes so a session can be restored. This >>>>> makes possible to transfer an IPsec session transparently to the end >>>>> user. >>>>> >>>>> >>>>> >>>>> Daniel PALOMARES >>>>> >>>>> Orange Labs, Issy-les-Moulineaux >>>>> >>>>> +33 6 34 23 07 88 >>>>> >>>>> >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> > > > > -- > Thanks and Regards, > Yogendra Pal > +919686202644 > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Wed Feb 19 02:22:56 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6E91A0457 for ; Wed, 19 Feb 2014 02:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62mPV0hhcioC for ; Wed, 19 Feb 2014 02:22:49 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CD2081A03EE for ; Wed, 19 Feb 2014 02:22:48 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 20so456704yks.5 for ; Wed, 19 Feb 2014 02:22:45 -0800 (PST) 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=AkQyVPtAKaEMXwq5nHFMAiIQQClQnMJ0FUuxkUjQgl8=; b=YHxBsZhBmHReimTibulbbZtkh4gYutXO8nzd17YixsXaWGVJ7PqhOdf0w1/7a6yHyL QO7M4IaeZQgIFKCpi7M1q4S8i8F1icUouPtFHdzBXYIn5vSUFOeUDoXzVlWIl0pv6rzN b/5w0S8a/58QroE8YJh5Pa3o/f6a3UWdGbwP8ZaDT/Udsks2qAjl+3ucB05nvETRcWZ2 MXEpl5YRcU7TCyZvr/pQyxVBUdDqhjlNwYK2/2HiVs/9yoWG4LcL9pHjU4YGyRMZFAQY 126WBaKOdzOUtFFVFyA2n+9B6lXJPUiXwthSskSEX90HcAiDdjmfxcyoQ2QSJxTFESc+ bOEA== MIME-Version: 1.0 X-Received: by 10.236.100.235 with SMTP id z71mr37050824yhf.43.1392805365419; Wed, 19 Feb 2014 02:22:45 -0800 (PST) Received: by 10.170.189.70 with HTTP; Wed, 19 Feb 2014 02:22:45 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 15:52:45 +0530 Message-ID: From: yogendra pal To: Daniel Migault Content-Type: multipart/alternative; boundary=20cf301b65fb0c133904f2bfc588 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Tipc_DxNrTtRG5PyTi4uhmV0ZIs Cc: IPsecme WG , Daniel Palomares Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 10:22:53 -0000 --20cf301b65fb0c133904f2bfc588 Content-Type: text/plain; charset=ISO-8859-1 See inline comments >>Is there any format you like to see xml, jason, bytes format... ? [Yogendra Pal] instance-id or flow-id will be in bytes, atmost 4 bytes. >>What is not clear to me is why a SA on a processing unit X of node A >>MUST necessarily be also on processing unit X of node B. I understand >>processing unit as a CPU or a specific core. Am I right? [Yogendra Pal] 1. From end-user perspective, initiator may NOT know his tunnel is with A or B (since, operator would have configured A and B with same tunnel endpoint for redundancy). 2. Given that A and B are supporting redundancy for tunnel. Operator configure(s) node A and B as same h/w, however, B can be a low hanging node (asymmetric h/w). 3. Node A can be a device (e.g router) with multiple blades or linecard and each linecard doing ipsec processing. Similarly B also. In general, operator have load balancing/sharing which will dictates different tunnels hosted on different linecards and hence the steering logic/load balancing algorithm. This steering logic resulting into *flow-id or instance-id. * I hope I have answered your query Thanks, Yogendra Pal (Ericsson, India) On Wed, Feb 19, 2014 at 2:33 PM, Daniel Migault wrote: > Hi, > > My understanding is that at the time a format will be defined for > embedding IKEv2 and IPsec context, we should be able to embed also > proprietary parameters similar to vendor-ID with IKEv2. Of course > these parameters will be most probably ignored by other > implementations. > > Is there any format you like to see xml, jason, bytes format... ? > > What is not clear to me is why a SA on a processing unit X of node A > MUST necessarily be also on processing unit X of node B. I understand > processing unit as a CPU or a specific core. Am I right? > > > BR, > Daniel > > On Wed, Feb 19, 2014 at 6:27 AM, yogendra pal wrote: > > Hi Daniel, > > > > I agree w/ what you said, let the ipsec mailing list discussion this > out, I > > just opened the forum w/ my inputs "instance-id". Since this draft is > > towards keeping IKEv2/IPsec session alive when any fault is detected on > > current node. > > > > Thanks, > > Yogendra Pal > > (Ericssson, India) > > > > > > > > On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares > > wrote: > >> > >> Hi Yogendra, > >> > >> Thank you for your comments and pointing out the lack of the IPComp > >> parameter. > >> I will update the draft including the IPComp flag , as well as the > IPcomp > >> algo and the cpi-in/out values. > >> > >> I understand when you say the draft "SHOULD capture at least > instance-id > >> or flow-id". However, I'm not familiar with this definitions as IKEv2 or > >> IPsec standards. Please don't hesitate to address me to those documents > if > >> they are actually standardized. > >> > >> On the other hand, I could understand that those parameters you just > >> mention (instance-id and flow-id), might be proprietary solutions to > improve > >> IPsec treatment among several processing units. If it is the case, I > believe > >> that our document may introduce supplementary information in the context > >> prior some negotiation, but I believe we should let the whole > mailing-list > >> discuss about this. > >> > >> By now, our wish is to isolate the IKEv2 and IPsec mandatory parameters > in > >> order to keep an IKEv2/IPsec session alive. > >> > >> KR, > >> Daniel Palomares > >> > >> > >> > >> > >> 2014-02-18 17:25 GMT+01:00 yogendra pal : > >> > >>> Hi Daniel, > >>> > >>> Given that ike and ipsec can runs on different context and nodes, > context > >>> SHOULD capture at least instance-id or flow-id. This instance-id can > help > >>> the node to identify which packet processing unit will process this > ipsec > >>> traffic or which ipsec instance out of multiple ipsec processing unit > will > >>> process this ipsec traffic. > >>> > >>> Let me take a simple example case to explain: > >>> > >>> On a node A, which has 10 processing unit (pu) = {1,2,3,4,5,6,7,8,9,10} > >>> and out of which ike is using single unit = {1} and ipsec is using 7 > >>> processing unit(s) = {2,3,4,5,6,7,8} and other processing units = > {9,10} for > >>> general purpose. > >>> > >>> Each IPsec SA processing can be tied with specific processing unit and > >>> can be called as instance-id or flow-id. This SA can hold instance-id > or > >>> flow-id information. Upon sync up of context for each IPsec SA to > other node > >>> B upon failure, it can process the same SA on specific instance-id or > >>> flow-id. > >>> > >>> P.S: If your need some text around this, I can provide you a example > and > >>> usage of it. > >>> > >>> BR, > >>> Yogendra Pal > >>> (Ericsson, India) > >>> > >>> > >>> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal > wrote: > >>>> > >>>> Hi Daniel, > >>>> > >>>> Quickly went through your draft, have one input for you, > >>>> [In section "5. IPsec Session parameters"] > >>>> - Consider to have case of IPCOMP also for ipsec session parameters. > >>>> > >>>> > >>>> BR, > >>>> Yogendra Pal > >>>> (Ericsson) > >>>> > >>>> > >>>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> Please find a draft we have Posted. They concern the definition of > >>>>> IKEv2 and IPsec contexts. > >>>>> Comments are welcome, > >>>>> > >>>>> BR, > >>>>> > >>>>> Daniel Palomares > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. > >>>>> > >>>>> Revision: 00 > >>>>> Title: IKEv2/IPsec Context Definition > >>>>> Document date: 2014-02-12 > >>>>> Group: Individual Submission > >>>>> Pages: 8 > >>>>> > >>>>> URL: > http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt > >>>>> > >>>>> Status: > https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ > >>>>> Htmlized: > >>>>> > http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 > >>>>> > >>>>> > >>>>> Abstract > >>>>> > >>>>> IPsec/IKEv2 clusters are constituted of multiple nodes accessed > via > >>>>> a > >>>>> single address by the end user. The traffic is then split between > >>>>> the nodes via specific IP load balancing policies. Once a session > >>>>> is > >>>>> assigned to a given node, IPsec makes it difficult to assign the > >>>>> session to another node. This makes management operations and > >>>>> transparent high availability for end users difficult to perform > >>>>> within the cluster. > >>>>> > >>>>> This document describes the contexts for IKEv2 and IPsec that MUST > >>>>> be > >>>>> transferred between two nodes so a session can be restored. This > >>>>> makes possible to transfer an IPsec session transparently to the > end > >>>>> user. > >>>>> > >>>>> > >>>>> > >>>>> Daniel PALOMARES > >>>>> > >>>>> Orange Labs, Issy-les-Moulineaux > >>>>> > >>>>> +33 6 34 23 07 88 > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> IPsec mailing list > >>>>> IPsec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ipsec > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > > > > > > > > -- > > Thanks and Regards, > > Yogendra Pal > > +919686202644 > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > --20cf301b65fb0c133904f2bfc588 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
See= inline comments

>>Is there any format you like to see xml, ja= son, bytes format... ?
[Yogendra Pal] instance-id or flow-id will = be in bytes, atmost 4 bytes.

>>What is not clear to me is why a SA on a processing unit X of n= ode A
>>MUST necessarily be also on processing unit X of node B. I= understand
>>processing unit as a CPU or a specific core. Am I ri= ght?
[Yogendra Pal]
1. From end-user perspective, initiator may NOT kn= ow his tunnel
is with A or B (since, operator would have configure= d A and B with
same tunnel endpoint for redundancy).

2. Given that A and B are supporting redundancy for tunnel. Operator config= ure(s)
node A and B as same h/w, however, B can be a low hanging n= ode (asymmetric h/w).

3. Node A can be a device (e.g router) w= ith multiple blades or linecard and each linecard doing ipsec processing.
Similarly B also. In general, operator have load balancing/sharing wh= ich will dictates different tunnels
hosted on different linecards = and hence the steering logic/load balancing algorithm. This steering logic = resulting
into flow-id or instance-id.

I hope I have answered your query

Thanks,
Yogendra Pal
(Erics= son, India)

On Wed, Feb 19, 2014 at 2:33 PM, Daniel Migault <<= a href=3D"mailto:mglt.ietf@gmail.com" target=3D"_blank">mglt.ietf@gmail.com= > wrote:
Hi,

My understanding is that at the time a format will be defined for
embedding IKEv2 and IPsec context, we should be able to embed also
proprietary parameters similar to vendor-ID with IKEv2. Of course
these parameters will be most probably ignored by other
implementations.

Is there any format you like to see xml, jason, bytes format... ?

What is not clear to me is why a SA on a processing unit X of node A
MUST necessarily be also on processing unit X of node B. I understand
processing unit as a CPU or a specific core. Am I right?


BR,
Daniel

On Wed, Feb 19, 2014 at 6:27 AM, yogendra pal <jntupal@gmail.com> wrote:
> Hi Daniel,
>
> I agree w/ what you said, let the ipsec mailing list discussion this o= ut, I
> just opened the forum w/ my inputs "instance-id". =A0Since t= his draft is
> towards keeping IKEv2/IPsec session alive when any fault is detected o= n
> current node.
>
> Thanks,
> Yogendra Pal
> (Ericssson, India)
>
>
>
> On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares
> <daniel.palomare= s.ietf@gmail.com> wrote:
>>
>> Hi Yogendra,
>>
>> Thank you for your comments and pointing out the lack of the IPCom= p
>> parameter.
>> I will update the draft including the IPComp flag , as well as the= IPcomp
>> algo and the cpi-in/out values.
>>
>> I understand when you say =A0the draft "SHOULD capture at lea= st instance-id
>> or flow-id". However, I'm not familiar with this definiti= ons as IKEv2 or
>> IPsec standards. Please don't hesitate to address me to those = documents if
>> they are actually standardized.
>>
>> On the other hand, I could understand that those parameters you ju= st
>> mention (instance-id and flow-id), might be proprietary solutions = to improve
>> IPsec treatment among several processing units. If it is the case,= I believe
>> that our document may introduce supplementary information in the c= ontext
>> prior some negotiation, but I believe we should let the whole mail= ing-list
>> discuss about this.
>>
>> By now, our wish is to isolate the IKEv2 and IPsec mandatory param= eters in
>> order to keep an IKEv2/IPsec session alive.
>>
>> KR,
>> Daniel Palomares
>>
>>
>>
>>
>> 2014-02-18 17:25 GMT+01:00 yogendra pal <jntupal@gmail.com>:
>>
>>> Hi Daniel,
>>>
>>> Given that ike and ipsec can runs on different context and nod= es, context
>>> SHOULD capture at least instance-id or flow-id. This instance-= id can help
>>> the node to identify which packet processing unit will process= this ipsec
>>> traffic or which ipsec instance out of multiple ipsec processi= ng unit will
>>> process this ipsec traffic.
>>>
>>> Let me take a simple example case to explain:
>>>
>>> On a node A, which has 10 processing unit (pu) =3D {1,2,3,4,5,= 6,7,8,9,10}
>>> and out of which ike is using single unit =3D {1} and ipsec is= using 7
>>> processing unit(s) =3D {2,3,4,5,6,7,8} and other processing un= its =3D {9,10} for
>>> general purpose.
>>>
>>> Each IPsec SA processing can be tied with specific processing = unit and
>>> can be called as instance-id or flow-id. This SA can hold inst= ance-id or
>>> flow-id information. Upon sync up of context for each IPsec SA= to other node
>>> B upon failure, it can process the same SA on specific instanc= e-id or
>>> flow-id.
>>>
>>> P.S: If your need some text around this, I can provide you a e= xample and
>>> usage of it.
>>>
>>> BR,
>>> Yogendra Pal
>>> (Ericsson, India)
>>>
>>>
>>> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal <jntupal@gmail.com> wrote:
>>>>
>>>> Hi Daniel,
>>>>
>>>> Quickly went through your draft, have one input for you, >>>> [In section "5. IPsec Session parameters"]
>>>> =A0- Consider to have case of IPCOMP also for ipsec sessio= n parameters.
>>>>
>>>>
>>>> BR,
>>>> Yogendra Pal
>>>> (Ericsson)
>>>>
>>>>
>>>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares
>>>> <dan= iel.palomares.ietf@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please find a draft we have Posted. They concern the d= efinition of
>>>>> IKEv2 and IPsec contexts.
>>>>> Comments are welcome,
>>>>>
>>>>> BR,
>>>>>
>>>>> Daniel Palomares
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Name: =A0 =A0 =A0 =A0draft-plmrs-ipsecme-ipsec-ikev2-c= ontext-definition.
>>>>>
>>>>> Revision: 00
>>>>> Title: =A0 =A0 =A0 IKEv2/IPsec Context Definition
>>>>> Document date: =A0 =A02014-02-12
>>>>> Group: =A0 =A0 =A0 =A0Individual Submission
>>>>> Pages: =A0 =A0 =A0 =A08
>>>>>
>>>>> URL:http://www.iet= f.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
>>>>>
>>>>> Status:https:/= /datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definitio= n/
>>>>> Htmlized:
>>>>> http://tools.ietf.= org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00
>>>>>
>>>>>
>>>>> Abstract
>>>>>
>>>>> =A0 =A0IPsec/IKEv2 clusters are constituted of multipl= e nodes accessed via
>>>>> a
>>>>> =A0 =A0single address by the end user. =A0The traffic = is then split between
>>>>> =A0 =A0the nodes via specific IP load balancing polici= es. =A0Once a session
>>>>> is
>>>>> =A0 =A0assigned to a given node, IPsec makes it diffic= ult to assign the
>>>>> =A0 =A0session to another node. =A0This makes manageme= nt operations and
>>>>> =A0 =A0transparent high availability for end users dif= ficult to perform
>>>>> =A0 =A0within the cluster.
>>>>>
>>>>> =A0 =A0This document describes the contexts for IKEv2 = and IPsec that MUST
>>>>> be
>>>>> =A0 =A0transferred between two nodes so a session can = be restored. =A0This
>>>>> =A0 =A0makes possible to transfer an IPsec session tra= nsparently to the end
>>>>> =A0 =A0user.
>>>>>
>>>>>
>>>>>
>>>>> Daniel PALOMARES
>>>>>
>>>>> Orange Labs, Issy-les-Moulineaux
>>>>>
>>>>> +33 6 34 23 07 88
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> IPsec mailing list
>>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Thanks and Regards,
> Yogendra Pal
> +919686202644
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



--
Daniel Migault Orange Labs -- Security
+33 6 70 72 69 58

--20cf301b65fb0c133904f2bfc588-- From nobody Wed Feb 19 12:57:35 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D501A0150 for ; Wed, 19 Feb 2014 12:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFu9lh5s6OVh for ; Wed, 19 Feb 2014 12:57:31 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3B41A0152 for ; Wed, 19 Feb 2014 12:57:30 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id t61so780672wes.22 for ; Wed, 19 Feb 2014 12:57:27 -0800 (PST) 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=jRvnWAPqp06NCueAd/v6a4Ukh52vSogyv/XtW2n7lGI=; b=BK6z+hMgDDOkJgCW5KnbcyGQi/MJWsASZSACLyJlJeGygNDI+/8DYPK63RWou9VD3Q atR0674Ktya/9NwnolZs8PwzH0zadCk6Y9Ux00ncoawq2it0CPJ5RT8uFZCSTQkAcHyK +x0dD1++oaIZ3T39ZJCo9IhlF2o8HrtM9zSULuNcyt20cecl+wohTdsHDFWSxUCtSxR5 amQU8ChkLX7zwm+asUtwazef1XdRnQuTxA+Q/GFmlu1Jr6p6zTotQaPmJTmaleK3qGZO 3GNKsLYvjBXCmkOS2w2GXsREH/8HrESDZZdSXCpkBi5fgGamRZhz4F05xjjSiyn+6UPt znmA== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr3535277wiw.56.1392843446854; Wed, 19 Feb 2014 12:57:26 -0800 (PST) Received: by 10.194.171.129 with HTTP; Wed, 19 Feb 2014 12:57:26 -0800 (PST) In-Reply-To: <20140206120738.06195c09@vostro> References: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com> <20140205135046.61c4f7a5@vostro> <20140206120738.06195c09@vostro> Date: Wed, 19 Feb 2014 21:57:26 +0100 Message-ID: From: Daniel Migault To: Timo Teras Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IbK3YIrNEmjnJdio-blk8A8LlCU Cc: " WG" , "Frederic Detienne \(fdetienn\)" , Praveen Sathyanarayan Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:57:34 -0000 Hi, Thanks for the feed back, please see inline my response. BR, Daniel On Thu, Feb 6, 2014 at 11:07 AM, Timo Teras wrote: > On Thu, 6 Feb 2014 09:20:08 +0100 > Daniel Migault wrote: > >> Thanks for the feed back. >> >> We are happy you provide requirements over "dynamically routing >> subnets" as a MUST. ADVPN responds to the requirements listed in >> RFC7018. If there is a requirement that does not match you opinion, >> can you please point it out? >> >> Just to make it clear this 1 day time has never been mentioned in the >> draft and is your assumption. The use of TTL does not impose a 1 day >> and ADVPN can take advantage of the Redirect Mechanism or MOBIKE for >> multihoming. As you can see the ADVPN solution can take advantage of >> all previous and future featured designed for IKEv2. As you point out >> the key characteristic of our design is its flexibility. > > It was Praveen's suggestion in the email I replied. My point was that > having that sort of default TTL does not sound good. And to me it > sounds like having very low TTL (in level of seconds or minutes) is too > heavy to be used in practice. So the TTL mechanism does not really > sound feasible to me. Fine so TTL is a simple way to provide resilience, but not an optimized one. MOBIKE address this issue for IPsec. > >> RFC5685 is not limited to client-gateway, the second line of the >> section 10 you pointed out says: [...] the mechanism can also be used >> between any two IKEv2 peers. " So no additional specification are >> required. > > You missed the next sentance: > "However, the mechanism can also be used between any two IKEv2 peers. > But this protocol is asymmetric, meaning that only the original > responder can redirect the original initiator to another server." > Suppose A establish an IPsec session with node B. B can use a Redirect not A. If A has not the capacity to handle the communication it should not initiate it, and let C initiate the communication. This may be a disadvantage is A and B are "equal", but in that case A and B should be organized as clusters and redirect may not be the best way. > Spoke A established tunnel to spoke B. A is thus original initiator. > But the routing change is on spoke B subnet. B cannot send Redirect > according to the above. You'd need to specify additional mechanism for > that, or re-specify the original one. I believe this restriction is due > to security considerations for client-gateway type connectivity. > >> You mention load balancing may be an issue. Can you please specify the >> issue you see? > > Could you specify how in practice I could implement one subnet to be > load-balanced to spoke nodes? > If I correctly understand your scenario, you are looking at load balancing the traffic of your private network between two spokes. Any IP-load balancer could split and load balance the traffic between the two spokes. On the other hand you might also want to have multiple spokes under a given IP address. In that case, load balancing is performed according to the hash of the IP addresses or according to values of the SPI. Solution like cluster IP load balance the traffic between the two spokes [1]. [1] http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability >> One last point to clarify. it seems that you are trying to say ADVPN >> misses some features provided by routing protocols. In fact ADVPN can >> take advanatge of ALL of these features as ANY routing protocol can >> run on the top of ADVPN. This was a MUST requirement of RFC5685. If >> you see a scenrio that you think does not fit ADVPN, please document >> it so we can address your specific issue. > > I thought the advantage was to _not_ run routing protocol. You are right ADVPN does not necessarily need routing protocol. It can have one or not, it is up to the scenarios you want to address. > If running routing protocol is supported, can you please specify how a routing > protocol is to be integrated with the IKE traffic exchange? Yes, it is > possible, but non-trivial, thus I would like to see some specification > mapping how to do that mapping. I do not see the issue. Can you point out the issue more specifically. > > And like someone else asked, how is MPLS routed? Maybe you could encapsulates MPLS traffic in GRE/IP. Everything possible with DMVPN is possible with ADVPN. > > Thanks, > Timo -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Wed Feb 19 21:53:00 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B1E1A054A for ; Wed, 19 Feb 2014 21:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjdeMYErexlI for ; Wed, 19 Feb 2014 21:52:52 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6E1A0263 for ; Wed, 19 Feb 2014 21:52:51 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id e16so2557113qcx.35 for ; Wed, 19 Feb 2014 21:52:48 -0800 (PST) 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=3PTYBE04T3wglShwOThdVtGER51/uVILwMBa+Z7iNjY=; b=oD5QVJFBYzqUeSnCEJUkJOH5V1eWTIJ5PqObr3f28y35m3159zMj+0EGbs1gowuS2m l225PQlT37z3rpdQC4s8nwprJca7zf9zH/cU5kGV249KpHNv1cI2BpPjjfRndBhPHq9k 0RwcgRbBViO1x9vGMHYXiSolCOMRU1chUmBflAvMCx8EIYC8XoWzE95ZycAHsCMaA2qh n52o2z/S6b8UUPbQi4YyIxRqOymTlt+o2Bi+nxnOnNkVcFQ4J7bJr/eDBpGFnN5Pa1pM QLwVhNnGaU8ScB6N6ZrJ0RoKWFG23Dv1SRqUnPdr8LtqmUgjJIwEJ+PNcRlPY7HcmZyL csFQ== MIME-Version: 1.0 X-Received: by 10.236.91.201 with SMTP id h49mr36801009yhf.96.1392875568231; Wed, 19 Feb 2014 21:52:48 -0800 (PST) Received: by 10.170.189.70 with HTTP; Wed, 19 Feb 2014 21:52:48 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 11:22:48 +0530 Message-ID: From: yogendra pal To: Daniel Migault Content-Type: multipart/alternative; boundary=20cf3011ddfd75fa9204f2d01dbf Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ZoZY4S-KCGq_ROt1Kh4AgLv7qA4 Cc: IPsecme WG , Daniel Palomares Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 05:52:56 -0000 --20cf3011ddfd75fa9204f2d01dbf Content-Type: text/plain; charset=ISO-8859-1 Hi Daniel, Few more queries/input I have. 1. When you say "IKEv2 Session parameters" and "IPsec Session parameters" , is it implicit that respective IKEv2 policy and IPsec policy governing these sessions are also part of these session parameters or they get explicitly synced between nodes ? 2. I have NOT seen IKEv2 SA lifetime present in the "IKEv2 Session parameters" similar to, IPsec SA lifetime present in "IPsec Session parameters". Is this got missed or will be coming as part of explicit sync of policy b/w nodes ? If it's implicit then we SHOULD add this into "IKEv2 Session parameters" to support IKEv2 SA rekey. 3. Similar to (2), Is ESN (extended sequence number) support will come in into "IPsec Session parameters" ? 4. For IPsec SA, if PFS is enabled, does it need to reflect in "IPsec Session parameters" ? 5. In IKEv2, there is option to support ike-window-size, will this also be part of "IKEv2 Session parameters" ? 6. Message-ID for IKEv2 SA would be required to sync b/w nodes, will this be synced as part of IKEv2 Session parameters" ? 6. For IRAS usecase, ip address assignment from tunnel address pool will be synced separately and will NOT be covered as part of this document or will it be part of "IKEv2 Sesssion parameters" ? Thanks, Yogendra Pal (Ericsson, India) On Wed, Feb 19, 2014 at 3:52 PM, yogendra pal wrote: > See inline comments > > > >>Is there any format you like to see xml, jason, bytes format... ? > [Yogendra Pal] instance-id or flow-id will be in bytes, atmost 4 bytes. > > > >>What is not clear to me is why a SA on a processing unit X of node A > >>MUST necessarily be also on processing unit X of node B. I understand > >>processing unit as a CPU or a specific core. Am I right? > [Yogendra Pal] > 1. From end-user perspective, initiator may NOT know his tunnel > is with A or B (since, operator would have configured A and B with > same tunnel endpoint for redundancy). > > 2. Given that A and B are supporting redundancy for tunnel. Operator > configure(s) > node A and B as same h/w, however, B can be a low hanging node (asymmetric > h/w). > > 3. Node A can be a device (e.g router) with multiple blades or linecard > and each linecard doing ipsec processing. > Similarly B also. In general, operator have load balancing/sharing which > will dictates different tunnels > hosted on different linecards and hence the steering logic/load balancing > algorithm. This steering logic resulting > into > > *flow-id or instance-id. * > I hope I have answered your query > > Thanks, > Yogendra Pal > (Ericsson, India) > > On Wed, Feb 19, 2014 at 2:33 PM, Daniel Migault wrote: > >> Hi, >> >> My understanding is that at the time a format will be defined for >> embedding IKEv2 and IPsec context, we should be able to embed also >> proprietary parameters similar to vendor-ID with IKEv2. Of course >> these parameters will be most probably ignored by other >> implementations. >> >> Is there any format you like to see xml, jason, bytes format... ? >> >> What is not clear to me is why a SA on a processing unit X of node A >> MUST necessarily be also on processing unit X of node B. I understand >> processing unit as a CPU or a specific core. Am I right? >> >> >> BR, >> Daniel >> >> On Wed, Feb 19, 2014 at 6:27 AM, yogendra pal wrote: >> > Hi Daniel, >> > >> > I agree w/ what you said, let the ipsec mailing list discussion this >> out, I >> > just opened the forum w/ my inputs "instance-id". Since this draft is >> > towards keeping IKEv2/IPsec session alive when any fault is detected on >> > current node. >> > >> > Thanks, >> > Yogendra Pal >> > (Ericssson, India) >> > >> > >> > >> > On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares >> > wrote: >> >> >> >> Hi Yogendra, >> >> >> >> Thank you for your comments and pointing out the lack of the IPComp >> >> parameter. >> >> I will update the draft including the IPComp flag , as well as the >> IPcomp >> >> algo and the cpi-in/out values. >> >> >> >> I understand when you say the draft "SHOULD capture at least >> instance-id >> >> or flow-id". However, I'm not familiar with this definitions as IKEv2 >> or >> >> IPsec standards. Please don't hesitate to address me to those >> documents if >> >> they are actually standardized. >> >> >> >> On the other hand, I could understand that those parameters you just >> >> mention (instance-id and flow-id), might be proprietary solutions to >> improve >> >> IPsec treatment among several processing units. If it is the case, I >> believe >> >> that our document may introduce supplementary information in the >> context >> >> prior some negotiation, but I believe we should let the whole >> mailing-list >> >> discuss about this. >> >> >> >> By now, our wish is to isolate the IKEv2 and IPsec mandatory >> parameters in >> >> order to keep an IKEv2/IPsec session alive. >> >> >> >> KR, >> >> Daniel Palomares >> >> >> >> >> >> >> >> >> >> 2014-02-18 17:25 GMT+01:00 yogendra pal : >> >> >> >>> Hi Daniel, >> >>> >> >>> Given that ike and ipsec can runs on different context and nodes, >> context >> >>> SHOULD capture at least instance-id or flow-id. This instance-id can >> help >> >>> the node to identify which packet processing unit will process this >> ipsec >> >>> traffic or which ipsec instance out of multiple ipsec processing unit >> will >> >>> process this ipsec traffic. >> >>> >> >>> Let me take a simple example case to explain: >> >>> >> >>> On a node A, which has 10 processing unit (pu) = >> {1,2,3,4,5,6,7,8,9,10} >> >>> and out of which ike is using single unit = {1} and ipsec is using 7 >> >>> processing unit(s) = {2,3,4,5,6,7,8} and other processing units = >> {9,10} for >> >>> general purpose. >> >>> >> >>> Each IPsec SA processing can be tied with specific processing unit and >> >>> can be called as instance-id or flow-id. This SA can hold instance-id >> or >> >>> flow-id information. Upon sync up of context for each IPsec SA to >> other node >> >>> B upon failure, it can process the same SA on specific instance-id or >> >>> flow-id. >> >>> >> >>> P.S: If your need some text around this, I can provide you a example >> and >> >>> usage of it. >> >>> >> >>> BR, >> >>> Yogendra Pal >> >>> (Ericsson, India) >> >>> >> >>> >> >>> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal >> wrote: >> >>>> >> >>>> Hi Daniel, >> >>>> >> >>>> Quickly went through your draft, have one input for you, >> >>>> [In section "5. IPsec Session parameters"] >> >>>> - Consider to have case of IPCOMP also for ipsec session parameters. >> >>>> >> >>>> >> >>>> BR, >> >>>> Yogendra Pal >> >>>> (Ericsson) >> >>>> >> >>>> >> >>>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares >> >>>> wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> Please find a draft we have Posted. They concern the definition of >> >>>>> IKEv2 and IPsec contexts. >> >>>>> Comments are welcome, >> >>>>> >> >>>>> BR, >> >>>>> >> >>>>> Daniel Palomares >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. >> >>>>> >> >>>>> Revision: 00 >> >>>>> Title: IKEv2/IPsec Context Definition >> >>>>> Document date: 2014-02-12 >> >>>>> Group: Individual Submission >> >>>>> Pages: 8 >> >>>>> >> >>>>> URL: >> http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt >> >>>>> >> >>>>> Status: >> https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ >> >>>>> Htmlized: >> >>>>> >> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 >> >>>>> >> >>>>> >> >>>>> Abstract >> >>>>> >> >>>>> IPsec/IKEv2 clusters are constituted of multiple nodes accessed >> via >> >>>>> a >> >>>>> single address by the end user. The traffic is then split >> between >> >>>>> the nodes via specific IP load balancing policies. Once a >> session >> >>>>> is >> >>>>> assigned to a given node, IPsec makes it difficult to assign the >> >>>>> session to another node. This makes management operations and >> >>>>> transparent high availability for end users difficult to perform >> >>>>> within the cluster. >> >>>>> >> >>>>> This document describes the contexts for IKEv2 and IPsec that >> MUST >> >>>>> be >> >>>>> transferred between two nodes so a session can be restored. This >> >>>>> makes possible to transfer an IPsec session transparently to the >> end >> >>>>> user. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Daniel PALOMARES >> >>>>> >> >>>>> Orange Labs, Issy-les-Moulineaux >> >>>>> >> >>>>> +33 6 34 23 07 88 >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> IPsec mailing list >> >>>>> IPsec@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/ipsec >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >> >> > >> > >> > >> > -- >> > Thanks and Regards, >> > Yogendra Pal >> > +919686202644 >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> >> >> >> -- >> Daniel Migault >> Orange Labs -- Security >> +33 6 70 72 69 58 >> > > -- Thanks and Regards, Yogendra Pal +919686202644 --20cf3011ddfd75fa9204f2d01dbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

Few = more queries/input I have.

1. When you say "IKEv2 Se= ssion parameters" and "IPsec Session parameters" , is it imp= licit that respective IKEv2 policy and IPsec policy governing these session= s are also part of these session parameters or they get explicitly synced b= etween
nodes ?

2. I have NOT seen IKEv2 SA= lifetime present in the "IKEv2 Session parameters" similar to, I= Psec SA lifetime present in "IPsec Session parameters". Is this g= ot missed or will be coming as part of explicit sync of policy b/w nodes ? = If it's implicit then we SHOULD add this into "IKEv2 Session param= eters" to support IKEv2 SA rekey.

3. Similar to (2), Is ESN (extended sequence number) support= will come in into "IPsec Session parameters" ?

4. For IPsec SA, if PFS is enabled, does it need to reflect in "IPsec= Session parameters" ?

5. In IKEv2, there is option to support ike-window-size, wil= l this also be part of "IKEv2 Session parameters" ?

=
6. Message-ID for IKEv2 SA would be required to sync b/w nodes, will t= his be synced as part of IKEv2 Session parameters" ?

6. For IRAS usecase, ip address assignment from tunnel= address pool will be synced separately and will NOT be covered as part of = this document or will it be part of "IKEv2 Sesssion parameters" ?=


Thanks,
Yogendra Pal
(= Ericsson, India)



On Wed, Feb 19, 2014 at 3:52 PM, yogendra = pal <jntupal@gmail.com> wrote:
See inline comments


>= >Is there any format you like to see xml, jason, bytes format... ?
[Yogendra Pal] instance-id or flow-id will be in bytes, atmost = 4 bytes.


>>What is not clear to me is why a SA on a processing unit X of n= ode A
>>MUST necessarily be also on processing unit X of node B. I= understand
>>processing unit as a CPU or a specific core. Am I ri= ght?
[Yogendra Pal]
1. From end-user perspective, initiator may = NOT know his tunnel
is with A or B (since, operator would have con= figured A and B with
same tunnel endpoint for redundancy).

2. Given that A and B are supporting redundancy for tunnel. Operator config= ure(s)
node A and B as same h/w, however, B can be a low hanging n= ode (asymmetric h/w).

3. Node A can be a device (e.g router) w= ith multiple blades or linecard and each linecard doing ipsec processing.
Similarly B also. In general, operator have load balancing/sharing wh= ich will dictates different tunnels
hosted on different linecards = and hence the steering logic/load balancing algorithm. This steering logic = resulting
into flow-id or instance-id.

I hope I have answered your query

Thanks,
Yogendra Pal
(Erics= son, India)

=
On Wed, Feb 19, 2014 at 2:33 PM, Daniel Migault = <mglt.ietf@gmail.com> wrote:
Hi,

My understanding is that at the time a format will be defined for
embedding IKEv2 and IPsec context, we should be able to embed also
proprietary parameters similar to vendor-ID with IKEv2. Of course
these parameters will be most probably ignored by other
implementations.

Is there any format you like to see xml, jason, bytes format... ?

What is not clear to me is why a SA on a processing unit X of node A
MUST necessarily be also on processing unit X of node B. I understand
processing unit as a CPU or a specific core. Am I right?


BR,
Daniel

On Wed, Feb 19, 2014 at 6:27 AM, yogendra pal <jntupal@gmail.com> wrote:
> Hi Daniel,
>
> I agree w/ what you said, let the ipsec mailing list discussion this o= ut, I
> just opened the forum w/ my inputs "instance-id". =A0Since t= his draft is
> towards keeping IKEv2/IPsec session alive when any fault is detected o= n
> current node.
>
> Thanks,
> Yogendra Pal
> (Ericssson, India)
>
>
>
> On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares
> <daniel.palomares.ietf@gmail.com> wrote:
>>
>> Hi Yogendra,
>>
>> Thank you for your comments and pointing out the lack of the IPCom= p
>> parameter.
>> I will update the draft including the IPComp flag , as well as the= IPcomp
>> algo and the cpi-in/out values.
>>
>> I understand when you say =A0the draft "SHOULD capture at lea= st instance-id
>> or flow-id". However, I'm not familiar with this definiti= ons as IKEv2 or
>> IPsec standards. Please don't hesitate to address me to those = documents if
>> they are actually standardized.
>>
>> On the other hand, I could understand that those parameters you ju= st
>> mention (instance-id and flow-id), might be proprietary solutions = to improve
>> IPsec treatment among several processing units. If it is the case,= I believe
>> that our document may introduce supplementary information in the c= ontext
>> prior some negotiation, but I believe we should let the whole mail= ing-list
>> discuss about this.
>>
>> By now, our wish is to isolate the IKEv2 and IPsec mandatory param= eters in
>> order to keep an IKEv2/IPsec session alive.
>>
>> KR,
>> Daniel Palomares
>>
>>
>>
>>
>> 2014-02-18 17:25 GMT+01:00 yogendra pal <jntupal@gmail.com>:
>>
>>> Hi Daniel,
>>>
>>> Given that ike and ipsec can runs on different context and nod= es, context
>>> SHOULD capture at least instance-id or flow-id. This instance-= id can help
>>> the node to identify which packet processing unit will process= this ipsec
>>> traffic or which ipsec instance out of multiple ipsec processi= ng unit will
>>> process this ipsec traffic.
>>>
>>> Let me take a simple example case to explain:
>>>
>>> On a node A, which has 10 processing unit (pu) =3D {1,2,3,4,5,= 6,7,8,9,10}
>>> and out of which ike is using single unit =3D {1} and ipsec is= using 7
>>> processing unit(s) =3D {2,3,4,5,6,7,8} and other processing un= its =3D {9,10} for
>>> general purpose.
>>>
>>> Each IPsec SA processing can be tied with specific processing = unit and
>>> can be called as instance-id or flow-id. This SA can hold inst= ance-id or
>>> flow-id information. Upon sync up of context for each IPsec SA= to other node
>>> B upon failure, it can process the same SA on specific instanc= e-id or
>>> flow-id.
>>>
>>> P.S: If your need some text around this, I can provide you a e= xample and
>>> usage of it.
>>>
>>> BR,
>>> Yogendra Pal
>>> (Ericsson, India)
>>>
>>>
>>> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal <jntupal@gmail.com> wrote= :
>>>>
>>>> Hi Daniel,
>>>>
>>>> Quickly went through your draft, have one input for you, >>>> [In section "5. IPsec Session parameters"]
>>>> =A0- Consider to have case of IPCOMP also for ipsec sessio= n parameters.
>>>>
>>>>
>>>> BR,
>>>> Yogendra Pal
>>>> (Ericsson)
>>>>
>>>>
>>>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares
>>>> <daniel.palomares.ietf@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please find a draft we have Posted. They concern the d= efinition of
>>>>> IKEv2 and IPsec contexts.
>>>>> Comments are welcome,
>>>>>
>>>>> BR,
>>>>>
>>>>> Daniel Palomares
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Name: =A0 =A0 =A0 =A0draft-plmrs-ipsecme-ipsec-ikev2-c= ontext-definition.
>>>>>
>>>>> Revision: 00
>>>>> Title: =A0 =A0 =A0 IKEv2/IPsec Context Definition
>>>>> Document date: =A0 =A02014-02-12
>>>>> Group: =A0 =A0 =A0 =A0Individual Submission
>>>>> Pages: =A0 =A0 =A0 =A08
>>>>>
>>>>> URL:http://www.iet= f.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
>>>>>
>>>>> Status:https:/= /datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definitio= n/
>>>>> Htmlized:
>>>>> http://tools.ietf.= org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00
>>>>>
>>>>>
>>>>> Abstract
>>>>>
>>>>> =A0 =A0IPsec/IKEv2 clusters are constituted of multipl= e nodes accessed via
>>>>> a
>>>>> =A0 =A0single address by the end user. =A0The traffic = is then split between
>>>>> =A0 =A0the nodes via specific IP load balancing polici= es. =A0Once a session
>>>>> is
>>>>> =A0 =A0assigned to a given node, IPsec makes it diffic= ult to assign the
>>>>> =A0 =A0session to another node. =A0This makes manageme= nt operations and
>>>>> =A0 =A0transparent high availability for end users dif= ficult to perform
>>>>> =A0 =A0within the cluster.
>>>>>
>>>>> =A0 =A0This document describes the contexts for IKEv2 = and IPsec that MUST
>>>>> be
>>>>> =A0 =A0transferred between two nodes so a session can = be restored. =A0This
>>>>> =A0 =A0makes possible to transfer an IPsec session tra= nsparently to the end
>>>>> =A0 =A0user.
>>>>>
>>>>>
>>>>>
>>>>> Daniel PALOMARES
>>>>>
>>>>> Orange Labs, Issy-les-Moulineaux
>>>>>
>>>>> +33 6 34 23 07 88
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> IPsec mailing list
>>>>> IP= sec@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Thanks and Regards,
> Yogendra Pal
> +919686202644
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/ipsec
>



--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58




--
Thanks and Regards,
= Yogendra Pal
+919686202644 --20cf3011ddfd75fa9204f2d01dbf-- From nobody Wed Feb 19 23:12:19 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACE81A0443 for ; Wed, 19 Feb 2014 23:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 649Gt-I7K7df for ; Wed, 19 Feb 2014 23:12:15 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 066471A0646 for ; Wed, 19 Feb 2014 23:12:14 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id s7so1047676lbd.32 for ; Wed, 19 Feb 2014 23:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=lzHZMNY1eYqTQTGNvbOXV+Pwwx21rT63gOsv8QbIg+w=; b=KH6E5iHjQ/58aQ7gf/H5f00K7TSlQj3EefT4YkpdPWTvYfloN/iznooKisNp8GNILX +npo6usT2mLXmi+XbpotSMo7b4DrqEFxl1Mm2fVDnxQCZ0bfSMYOKEqPs3aQPjN9+FQs cPQi+Swx+fCUhkGX7uRMPqXI9iemJlFQpTrvdZINq31XstSz0XWEpqVt/9VDqLMkLUTz rg1/twsN7pARsAl34Jr2ZffpQLQzeSdSiLyvg4fOOlnYxKD76Rf/XK7UYlR7/8SAvCTy b1XETA/pAymI7p+NcClGEz1mvo70hsp/KIXQ+799tPyzegMfrguIp8md7lRCg+rb2dUP a1rw== X-Received: by 10.152.1.3 with SMTP id 3mr177173lai.58.1392880330641; Wed, 19 Feb 2014 23:12:10 -0800 (PST) Received: from vostro ([2001:1bc8:101:f402:21c:23ff:fefc:bf0b]) by mx.google.com with ESMTPSA id ya9sm2959119lbb.2.2014.02.19.23.12.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2014 23:12:10 -0800 (PST) Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= Date: Thu, 20 Feb 2014 09:12:57 +0200 From: Timo Teras To: Daniel Migault Message-ID: <20140220091257.1ed2f498@vostro> In-Reply-To: References: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com> <20140205135046.61c4f7a5@vostro> <20140206120738.06195c09@vostro> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.20; i486-alpine-linux-uclibc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/LJ1HftsJE2UOfucqzqdAayCP310 Cc: " WG" , "Frederic Detienne \(fdetienn\)" , Praveen Sathyanarayan Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 07:12:18 -0000 Hi, On Wed, 19 Feb 2014 21:57:26 +0100 Daniel Migault wrote: > On Thu, Feb 6, 2014 at 11:07 AM, Timo Teras wrote: > > On Thu, 6 Feb 2014 09:20:08 +0100 > > Daniel Migault wrote: > > > >> RFC5685 is not limited to client-gateway, the second line of the > >> section 10 you pointed out says: [...] the mechanism can also be > >> used between any two IKEv2 peers. " So no additional specification > >> are required. > > > > You missed the next sentance: > > "However, the mechanism can also be used between any two IKEv2 > > peers. But this protocol is asymmetric, meaning that only the > > original responder can redirect the original initiator to another > > server." > > > > Suppose A establish an IPsec session with node B. B can use a Redirect > not A. If A has not the capacity to handle the communication it should > not initiate it, and let C initiate the communication. This may be a > disadvantage is A and B are "equal", but in that case A and B should > be organized as clusters and redirect may not be the best way. But if A original had the capacity and was intended to establish it, but then later on routing protocol or administrative action made the prefix to be removed from A. A would then need to inform of this somehow. > >> You mention load balancing may be an issue. Can you please specify > >> the issue you see? > > > > Could you specify how in practice I could implement one subnet to be > > load-balanced to spoke nodes? > > > If I correctly understand your scenario, you are looking at load > balancing the traffic of your private network between two spokes. Any > IP-load balancer could split and load balance the traffic between the > two spokes. > On the other hand you might also want to have multiple spokes under a > given IP address. In that case, load balancing is performed according > to the hash of the IP addresses or according to values of the SPI. > Solution like cluster IP load balance the traffic between the two > spokes [1]. > > [1] > http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability This generally works by requiring single virtual IP that is then later on load-blanced. How about I have two ISP connection with separate public IPs. Haw can I loadbalance over them? This is relatively simple to achieve in DMVPN. > >> One last point to clarify. it seems that you are trying to say > >> ADVPN misses some features provided by routing protocols. In fact > >> ADVPN can take advanatge of ALL of these features as ANY routing > >> protocol can run on the top of ADVPN. This was a MUST requirement > >> of RFC5685. If you see a scenrio that you think does not fit > >> ADVPN, please document it so we can address your specific issue. > > > > I thought the advantage was to _not_ run routing protocol. > > You are right ADVPN does not necessarily need routing protocol. It can > have one or not, it is up to the scenarios you want to address. > > > If running routing protocol is supported, can you please specify > > how a routing protocol is to be integrated with the IKE traffic > > exchange? Yes, it is possible, but non-trivial, thus I would like > > to see some specification mapping how to do that mapping. > > I do not see the issue. Can you point out the issue more specifically. There is a lot of things involved. First question is already explained in this (see above) and the previous mails. What happens when routing protocol withdraws a subnet from one gateway, and it needs to tell everyone that it's no longer available from it, but may be available through other nodes. > > And like someone else asked, how is MPLS routed? > > Maybe you could encapsulates MPLS traffic in GRE/IP. Everything > possible with DMVPN is possible with ADVPN. This is one step closer to dmvpn. But how would the SHORTCUT mechanism work then? 4.1. says protected domain can contain only INTERNAL_IP4_SUBNET (13) and INTERNAL_IP6_SUBNET (15). You'd need to specify additional record types to all possible protocols ever needed to run over GRE. From nobody Fri Feb 21 03:03:02 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26731A00A2 for ; Fri, 21 Feb 2014 03:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9w58onH9pZH for ; Fri, 21 Feb 2014 03:02:58 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 073D81A0089 for ; Fri, 21 Feb 2014 03:02:57 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id p9so366192lbv.8 for ; Fri, 21 Feb 2014 03:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type; bh=OdBGyHWwpZBLyqQlIxxIkUlfhCXQpZNrAKD/42mjS0s=; b=m3iKV+DbUFBVc65vnxJYYM6pWSJhjQ+adHkRSeiWm5zVvIIXw2ViLSr0PMvgQDfSeA k7f2eCphmPlMEYdHs0Zilz7/wTSRT+SLs72lW1z13kbiUZPFNAU5kB3fSo9D4fzcWIyq mSO2Ymckp6RQcDSUXklJLR90ozItF+DTeLRbm2ewuSndSVed7I0bWRWrkRZB0VktgUTo FI2yi0vFNDGuLbTCowY4552MgPIaTlC3qrdlFOsgN+IxLJcdVy0hM9yMD8DuZ/DIGulF E8jdj31X0TzPtpxHgwZ2b/MYJ/TWgEvJw9ZDsf5Yud9fcvCr+7O8OCwyO3jPseBX8E9U irvw== X-Received: by 10.152.115.132 with SMTP id jo4mr3900375lab.69.1392980573346; Fri, 21 Feb 2014 03:02:53 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id rt7sm7330327lbb.0.2014.02.21.03.02.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 21 Feb 2014 03:02:48 -0800 (PST) Message-ID: <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> From: "Valery Smyslov" To: "Daniel Palomares" , References: Date: Fri, 21 Feb 2014 15:02:31 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_040F_01CF2F15.F1A75DD0" 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.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/RupHoeVNkZzDIHOuTqCjrRGRj9k Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 11:03:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_040F_01CF2F15.F1A75DD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have some comments regarding the draft. First, I'm a bit puzzled by intended status of the draft: Standards = Track. >From my understanding this means, that the document defines some = protocol, that needs to be standardized to get interoperability. But the draft = defines no protocol, it just speculates on what contents of IKE/IPsec SA must = contain. While no doubt it is helpful, I think that the proper intended status = for the draft is Informational. Then, I've been always thinking that the content of the IKE/IPsec SA is=20 an implementation issue. The draft tries to mandate this content, but it lacks plenty of absolutely needed information (this is especially = true for IKE SA), like MID counters, window bitmaps, lifetimes, credential = information, VIDs, features, statistics and so on.=20 On the other hand, the draft tries to mandate one way of presenting some = data,=20 ignoring the fact that it is not the only (and probably not the best) = way. For example, instead of transferring nonces and DH secret to the other node one may=20 transfer computed SK_* keys. This approach may have some advantages both = from security and performance perspectives.=20 Regards, Valery Smyslov. ----- Original Message -----=20 From: Daniel Palomares=20 To: ipsec@ietf.org=20 Sent: Thursday, February 13, 2014 6:09 PM Subject: [IPsec] Draft: IKEv2/IPsec Context Definition Hi, Please find a draft we have Posted. They concern the definition of = IKEv2 and IPsec contexts.=20 Comments are welcome, BR, Daniel Palomares Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. Revision: 00 Title: IKEv2/IPsec Context Definition Document date: 2014-02-12 Group: Individual Submission Pages: 8 = URL:http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-defini= tion-00.txt = Status:https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-c= ontext-definition/ Htmlized: = http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-defini= tion-00 Abstract IPsec/IKEv2 clusters are constituted of multiple nodes accessed via = a single address by the end user. The traffic is then split between the nodes via specific IP load balancing policies. Once a session = is assigned to a given node, IPsec makes it difficult to assign the session to another node. This makes management operations and transparent high availability for end users difficult to perform within the cluster. This document describes the contexts for IKEv2 and IPsec that MUST = be transferred between two nodes so a session can be restored. This makes possible to transfer an IPsec session transparently to the = end user. Daniel PALOMARES Orange Labs, Issy-les-Moulineaux +33 6 34 23 07 88 -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_040F_01CF2F15.F1A75DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have some comments regarding the = draft.
 
First, I'm a bit puzzled by intended status of the = draft:=20 Standards Track.
From my understanding this means, that the document = defines=20 some protocol,
that needs to be standardized to get = interoperability. But the=20 draft defines
no protocol, it just speculates on what = contents of=20 IKE/IPsec SA must contain.
While no doubt it is helpful, I think that the = proper intended=20 status for the draft
is Informational.
 
Then, I've been always thinking that the content of = the=20 IKE/IPsec SA is
an implementation issue. The draft tries to mandate = this=20 content,
but it lacks plenty of absolutely needed information = (this is=20 especially true
for IKE SA), like MID counters, window bitmaps, = lifetimes,=20 credential information,
VIDs, features, statistics and = so on.=20
 
On the other hand, the draft tries to=20 mandate one way of presenting some data,
ignoring the fact that it is = not the only=20 (and probably not the best) way. For example,
instead of transferring nonces and DH secret to = the other=20 node one may
transfer computed SK_* keys. This=20 approach may have some advantages both
from security and performance = perspectives.
 
Regards,
Valery Smyslov.
 
----- Original Message -----
From:=20 Daniel Palomares =
Sent: Thursday, February 13, = 2014 6:09=20 PM
Subject: [IPsec] Draft: = IKEv2/IPsec=20 Context Definition

Hi,

Please find a draft we have Posted. They = concern the=20 definition of IKEv2 and IPsec contexts.
Comments are = welcome,

BR,

Daniel Palomares

 

 

Name:     =   =20 draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

Revision:=20 00
Title:       IKEv2/IPsec Context = Definition
Document=20 date:    2014-02-12
Group:       =  Individual=20 Submission
Pages:        8
URL:http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-conte= xt-definition-00.txt
Status:https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-i= kev2-context-definition/
Htmlized: http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-c= ontext-definition-00


Abstract

   IPsec/IKEv2 clusters are = constituted of multiple nodes accessed via a
   single = address by=20 the end user.  The traffic is then split between
  =  the=20 nodes via specific IP load balancing policies.  Once a session=20 is
   assigned to a given node, IPsec makes it difficult = to=20 assign the
   session to another node.  This makes=20 management operations and
   transparent high = availability for=20 end users difficult to perform
   within the=20 cluster.

   This document describes the contexts for = IKEv2=20 and IPsec that MUST be
   transferred between two nodes = so a=20 session can be restored.  This
   makes possible to = transfer=20 an IPsec session transparently to the end
  =  user.

 

Daniel PALOMARES

Orange = Labs,=20 Issy-les-Moulineaux

+33 6 34 23 = 07=20 88

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_040F_01CF2F15.F1A75DD0-- From nobody Fri Feb 21 03:28:42 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C871A0518 for ; Fri, 21 Feb 2014 03:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9obBO2b0ujC for ; Fri, 21 Feb 2014 03:28:39 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C0BCE1A050D for ; Fri, 21 Feb 2014 03:28:38 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hr17so2232642lab.34 for ; Fri, 21 Feb 2014 03:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=6wVVul7cdqYT3aJ9GMgm0INE5Hfca4V4dtX9PpSoNVI=; b=xgyDri7qIdCf+KyZlqmR+vDWw2GgXhityBkJchMGgE14HGo8TJJyE3/Uc7qtRojnhE pNwJ0Qjdk+y5zNPHnLRRvBNeZ10RJr8V1qvVePeWRp014cdU+IGvWZb617Hq86sBgt0j CZvC7qUzquHvago6Kh1TJBrWKvpvSadp6qSgvzlpaLwrJ3Vnn4I5U5aqIV97xJQL5sfC BCkIuyRIFUO09qdrc34CahqISVBjzbwHvvCETBGX/N6NEtlipOokJuX6yOZEi/glKVy3 LUvoGLlIxVuwu0jISjqAp7nKSfHmH1UvxTy1P1DYu4UPwy87/9b1EydXB1bvuPlRMZsp Hcrg== X-Received: by 10.152.5.229 with SMTP id v5mr243170lav.11.1392982114104; Fri, 21 Feb 2014 03:28:34 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id dm8sm10262779lad.7.2014.02.21.03.28.32 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 21 Feb 2014 03:28:33 -0800 (PST) Message-ID: <65EBC43335D34F00B46DB1750578F35C@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "ipsec" References: <20140204033045.18512.74632.idtracker@ietfa.amsl.com> <52F0605C.5020507@gmail.com> Date: Fri, 21 Feb 2014 15:28:16 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/lbUn4qcqpzr6Q71YHdmsSJvusUs Subject: Re: [IPsec] Fwd: New Version Notification fordraft-sheffer-autovpn-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 11:28:41 -0000 Hi Yaron, Yoav, very interesting approach. Just a pair of quick comments. 1. You suppose to allocate 16-bytes long SPI for probe response from "reserved" SPI space. The packet looks like UDP-encapsulated IPsec packet, so it must start from ESP SPI, for which the values below 256 are reserved. So, why do you make your "SPI" 16 bytes long, while 4 bytes is enough to distinguish it from both IKE and IPsec? 2. What's the reason to allocate new payloads for AutoVPN Nonce and (especially) for Contact Details? Why Notify Payload cannot be used? It is more cheap resource and, I think, well suited for these purposes. Regards, Valery Smyslov. ----- Original Message ----- From: "Yaron Sheffer" To: "ipsec" Sent: Tuesday, February 04, 2014 7:37 AM Subject: [IPsec] Fwd: New Version Notification fordraft-sheffer-autovpn-00.txt > Hi, > > Yoav and I just published this draft. The two main points are: > > - IPsec opportunistic encryption is also interesting between security > gateways, not only between hosts. > - With a bit of extra plumbing, opportunistic encryption can be "upgraded" > post facto into full authentication. > > Comments are welcome on this list, but note that this is not proposed as a > working group document. > > Thanks, > Yaron > > -------- Original Message -------- > Subject: New Version Notification for draft-sheffer-autovpn-00.txt > Date: Mon, 03 Feb 2014 19:30:45 -0800 > From: internet-drafts@ietf.org > To: Yoav Nir , Yaron Sheffer , > "Yaron Sheffer" , "Yoav Nir" > > > A new version of I-D, draft-sheffer-autovpn-00.txt > has been successfully submitted by Yaron Sheffer and posted to the > IETF repository. > > Name: draft-sheffer-autovpn > Revision: 00 > Title: The AutoVPN Architecture > Document date: 2014-02-04 > Group: Individual Submission > Pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-sheffer-autovpn-00.txt > Status: https://datatracker.ietf.org/doc/draft-sheffer-autovpn/ > Htmlized: http://tools.ietf.org/html/draft-sheffer-autovpn-00 > > > Abstract: > This document describes the AutoVPN architecture. AutoVPN allows > IPsec security associations to be set up with no prior configuration, > using the "leap of faith" paradigm. The document defines a > lightweight protocol for negotiating such opportunistic encryption > either directly between hosts or between two security gateways on the > path. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Feb 21 08:39:12 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296B61A03CF for ; Fri, 21 Feb 2014 08:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7XhfNmP2yZ5 for ; Fri, 21 Feb 2014 08:39:07 -0800 (PST) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 43FC01A01F4 for ; Fri, 21 Feb 2014 08:39:07 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id n15so563149ead.32 for ; Fri, 21 Feb 2014 08:39:02 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=JeLc/G8Cu7DcSb6xzzWrSV31zZJM+RZZwem80w+PFXk=; b=sEPh040TwN/l15SLblXger3kSG0IXBStRPJanY0VuIdG0e21fq8nBhDuW3M/9EqMDs jP3qRupaGaNnBXDAEZIGlqIA27mG9q1EirR8fHKhT6BA/HXubmeIeI3qckqPYb7eDLd+ 5jCZsJGJVHKmR4aJ1L9eLAIj/Cgt+TaPq6W36a5qSQRgMU4Z2sAZkV8hL/BCsCvuGyHZ c5XYFBhXe349+WrnCsIU+C0wOxThm2od78TNMJw8N1EeLuEvWkfRbaJI4F7N0fU7IPuR qQU1goa4QLTuKPdioRPNe7iPp8n3FCHgNk9qIRk+eObJh32aubTNUPl4lYi9CN55+ao9 rLDg== X-Received: by 10.14.180.71 with SMTP id i47mr9540129eem.50.1393000742856; Fri, 21 Feb 2014 08:39:02 -0800 (PST) Received: from [10.0.0.6] (bzq-79-182-122-235.red.bezeqint.net. [79.182.122.235]) by mx.google.com with ESMTPSA id m8sm18306627eef.14.2014.02.21.08.38.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 08:39:01 -0800 (PST) Message-ID: <53078122.4010504@gmail.com> Date: Fri, 21 Feb 2014 18:38:58 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Valery Smyslov , ipsec References: <20140204033045.18512.74632.idtracker@ietfa.amsl.com> <52F0605C.5020507@gmail.com> <65EBC43335D34F00B46DB1750578F35C@buildpc> In-Reply-To: <65EBC43335D34F00B46DB1750578F35C@buildpc> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/WMHBtPadpgl2yV9t5RF8NL1A-Sg Subject: Re: [IPsec] Fwd: New Version Notification fordraft-sheffer-autovpn-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 16:39:10 -0000 Hi Valery, Thanks for your comments. I accept both, and we will use them for the next revision of the draft. Best, Yaron On 02/21/2014 01:28 PM, Valery Smyslov wrote: > Hi Yaron, Yoav, > > very interesting approach. Just a pair of quick comments. > > 1. You suppose to allocate 16-bytes long SPI for probe response > from "reserved" SPI space. The packet looks like UDP-encapsulated > IPsec packet, so it must start from ESP SPI, for which the values > below 256 are reserved. So, why do you make your "SPI" > 16 bytes long, while 4 bytes is enough to distinguish it from > both IKE and IPsec? > > 2. What's the reason to allocate new payloads for AutoVPN Nonce > and (especially) for Contact Details? Why Notify Payload cannot be > used? > It is more cheap resource and, I think, well suited for these > purposes. > > Regards, > Valery Smyslov. > > > > ----- Original Message ----- From: "Yaron Sheffer" > To: "ipsec" > Sent: Tuesday, February 04, 2014 7:37 AM > Subject: [IPsec] Fwd: New Version Notification > fordraft-sheffer-autovpn-00.txt > > >> Hi, >> >> Yoav and I just published this draft. The two main points are: >> >> - IPsec opportunistic encryption is also interesting between security >> gateways, not only between hosts. >> - With a bit of extra plumbing, opportunistic encryption can be >> "upgraded" post facto into full authentication. >> >> Comments are welcome on this list, but note that this is not proposed >> as a working group document. >> >> Thanks, >> Yaron >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-sheffer-autovpn-00.txt >> Date: Mon, 03 Feb 2014 19:30:45 -0800 >> From: internet-drafts@ietf.org >> To: Yoav Nir , Yaron Sheffer >> , "Yaron Sheffer" , >> "Yoav Nir" >> >> >> A new version of I-D, draft-sheffer-autovpn-00.txt >> has been successfully submitted by Yaron Sheffer and posted to the >> IETF repository. >> >> Name: draft-sheffer-autovpn >> Revision: 00 >> Title: The AutoVPN Architecture >> Document date: 2014-02-04 >> Group: Individual Submission >> Pages: 17 >> URL: http://www.ietf.org/internet-drafts/draft-sheffer-autovpn-00.txt >> Status: https://datatracker.ietf.org/doc/draft-sheffer-autovpn/ >> Htmlized: http://tools.ietf.org/html/draft-sheffer-autovpn-00 >> >> >> Abstract: >> This document describes the AutoVPN architecture. AutoVPN allows >> IPsec security associations to be set up with no prior configuration, >> using the "leap of faith" paradigm. The document defines a >> lightweight protocol for negotiating such opportunistic encryption >> either directly between hosts or between two security gateways on the >> path. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon Feb 24 02:05:31 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4151E1A0871 for ; Mon, 24 Feb 2014 02:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6J8h9ps3f7k for ; Mon, 24 Feb 2014 02:05:17 -0800 (PST) Received: from mail-ie0-x243.google.com (mail-ie0-x243.google.com [IPv6:2607:f8b0:4001:c03::243]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEAC1A086A for ; Mon, 24 Feb 2014 02:05:14 -0800 (PST) Received: by mail-ie0-f195.google.com with SMTP id to1so1850474ieb.10 for ; Mon, 24 Feb 2014 02:05:13 -0800 (PST) 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=DZ0ctJHaael4KUSFI4y/yxqKbhL6kb7hcKZzGM7qXIA=; b=E6UxAMhiGUKc5px3p8qQnzFmfcBLZdhxZc/2AbjMC/Nid7JN+444Gb50zWXf6Ywm9T 6uAY/rXYvyprVzvX0j0OJwx1aNQ3XnumtnO4K0UKFYtu2FM5Oz1Pt490kh52+8E/rTeA wqbdKVSVuIL5RSSMxgsH/sew8ktxW7y4FLWVa9lf3nZomigdVFcvDoVEHxge4zDCFJFR R7yx/SPXAirYzTGCyUH4+AMBUHjGZsO2K7ZsMa8/n0WAxkIedRKxMvVuMtg0XiahzcvZ nSJ9nmZle8eLyMxIZoUg9A5lQB7DFGRvd8rIIumAst8WcC0J0BrwgstB26VOKJUeU3dU XRXQ== MIME-Version: 1.0 X-Received: by 10.50.55.6 with SMTP id n6mr12979310igp.45.1393236313659; Mon, 24 Feb 2014 02:05:13 -0800 (PST) Received: by 10.50.40.131 with HTTP; Mon, 24 Feb 2014 02:05:13 -0800 (PST) In-Reply-To: References: Date: Mon, 24 Feb 2014 11:05:13 +0100 Message-ID: From: Daniel Palomares To: yogendra pal Content-Type: multipart/alternative; boundary=047d7b10c9b79061b104f3241ba5 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/2FpjN5NfzkOnCfqAG6LxpUhDffY Cc: IPsecme WG , Daniel Migault Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 10:05:26 -0000 --047d7b10c9b79061b104f3241ba5 Content-Type: text/plain; charset=ISO-8859-1 Hello Yogendra, 2014-02-20 6:52 GMT+01:00 yogendra pal : > Hi Daniel, > > Few more queries/input I have. > > 1. When you say "IKEv2 Session parameters" and "IPsec Session parameters" > , is it implicit that respective IKEv2 policy and IPsec policy governing > these sessions are also part of these session parameters or they get > explicitly synced between > nodes ? > Yes, these parameters are the IKEv2 and IPsec policies governing the sessions. > > 2. I have NOT seen IKEv2 SA lifetime present in the "IKEv2 Session > parameters" similar to, IPsec SA lifetime present in "IPsec Session > parameters". Is this got missed or will be coming as part of explicit sync > of policy b/w nodes ? If it's implicit then we SHOULD add this into "IKEv2 > Session parameters" to support IKEv2 SA rekey. > > 3. Similar to (2), Is ESN (extended sequence number) support will come in > into "IPsec Session parameters" ? > > 4. For IPsec SA, if PFS is enabled, does it need to reflect in "IPsec > Session parameters" ? > > 5. In IKEv2, there is option to support ike-window-size, will this also be > part of "IKEv2 Session parameters" ? > > 6. Message-ID for IKEv2 SA would be required to sync b/w nodes, will this > be synced as part of IKEv2 Session parameters" ? > > 6. For IRAS usecase, ip address assignment from tunnel address pool will > be synced separately and will NOT be covered as part of this document or > will it be part of "IKEv2 Sesssion parameters" ? > > We have included all these parameters explicitly in the following version 01. The IETF Internet-Draft Submission is disabled until 3 march 2014, so we haven't been able to upload a newer version. The IKEv2 lifetime, Message IDs, the ike-window-size are part of the IKEv2 session parameters, and the extended sequence numbers support will also be part of the IPsec session parameters. > > Thanks, > Yogendra Pal > (Ericsson, India) > > > > > On Wed, Feb 19, 2014 at 3:52 PM, yogendra pal wrote: > >> See inline comments >> >> >> >>Is there any format you like to see xml, jason, bytes format... ? >> [Yogendra Pal] instance-id or flow-id will be in bytes, atmost 4 bytes. >> >> >> >>What is not clear to me is why a SA on a processing unit X of node A >> >>MUST necessarily be also on processing unit X of node B. I understand >> >>processing unit as a CPU or a specific core. Am I right? >> [Yogendra Pal] >> 1. From end-user perspective, initiator may NOT know his tunnel >> is with A or B (since, operator would have configured A and B with >> same tunnel endpoint for redundancy). >> >> 2. Given that A and B are supporting redundancy for tunnel. Operator >> configure(s) >> node A and B as same h/w, however, B can be a low hanging node >> (asymmetric h/w). >> >> 3. Node A can be a device (e.g router) with multiple blades or linecard >> and each linecard doing ipsec processing. >> Similarly B also. In general, operator have load balancing/sharing which >> will dictates different tunnels >> hosted on different linecards and hence the steering logic/load balancing >> algorithm. This steering logic resulting >> into >> >> *flow-id or instance-id. * >> I hope I have answered your query >> >> Thanks, >> Yogendra Pal >> (Ericsson, India) >> >> On Wed, Feb 19, 2014 at 2:33 PM, Daniel Migault wrote: >> >>> Hi, >>> >>> My understanding is that at the time a format will be defined for >>> embedding IKEv2 and IPsec context, we should be able to embed also >>> proprietary parameters similar to vendor-ID with IKEv2. Of course >>> these parameters will be most probably ignored by other >>> implementations. >>> >>> Is there any format you like to see xml, jason, bytes format... ? >>> >>> What is not clear to me is why a SA on a processing unit X of node A >>> MUST necessarily be also on processing unit X of node B. I understand >>> processing unit as a CPU or a specific core. Am I right? >>> >>> >>> BR, >>> Daniel >>> >>> On Wed, Feb 19, 2014 at 6:27 AM, yogendra pal wrote: >>> > Hi Daniel, >>> > >>> > I agree w/ what you said, let the ipsec mailing list discussion this >>> out, I >>> > just opened the forum w/ my inputs "instance-id". Since this draft is >>> > towards keeping IKEv2/IPsec session alive when any fault is detected on >>> > current node. >>> > >>> > Thanks, >>> > Yogendra Pal >>> > (Ericssson, India) >>> > >>> > >>> > >>> > On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares >>> > wrote: >>> >> >>> >> Hi Yogendra, >>> >> >>> >> Thank you for your comments and pointing out the lack of the IPComp >>> >> parameter. >>> >> I will update the draft including the IPComp flag , as well as the >>> IPcomp >>> >> algo and the cpi-in/out values. >>> >> >>> >> I understand when you say the draft "SHOULD capture at least >>> instance-id >>> >> or flow-id". However, I'm not familiar with this definitions as IKEv2 >>> or >>> >> IPsec standards. Please don't hesitate to address me to those >>> documents if >>> >> they are actually standardized. >>> >> >>> >> On the other hand, I could understand that those parameters you just >>> >> mention (instance-id and flow-id), might be proprietary solutions to >>> improve >>> >> IPsec treatment among several processing units. If it is the case, I >>> believe >>> >> that our document may introduce supplementary information in the >>> context >>> >> prior some negotiation, but I believe we should let the whole >>> mailing-list >>> >> discuss about this. >>> >> >>> >> By now, our wish is to isolate the IKEv2 and IPsec mandatory >>> parameters in >>> >> order to keep an IKEv2/IPsec session alive. >>> >> >>> >> KR, >>> >> Daniel Palomares >>> >> >>> >> >>> >> >>> >> >>> >> 2014-02-18 17:25 GMT+01:00 yogendra pal : >>> >> >>> >>> Hi Daniel, >>> >>> >>> >>> Given that ike and ipsec can runs on different context and nodes, >>> context >>> >>> SHOULD capture at least instance-id or flow-id. This instance-id can >>> help >>> >>> the node to identify which packet processing unit will process this >>> ipsec >>> >>> traffic or which ipsec instance out of multiple ipsec processing >>> unit will >>> >>> process this ipsec traffic. >>> >>> >>> >>> Let me take a simple example case to explain: >>> >>> >>> >>> On a node A, which has 10 processing unit (pu) = >>> {1,2,3,4,5,6,7,8,9,10} >>> >>> and out of which ike is using single unit = {1} and ipsec is using 7 >>> >>> processing unit(s) = {2,3,4,5,6,7,8} and other processing units = >>> {9,10} for >>> >>> general purpose. >>> >>> >>> >>> Each IPsec SA processing can be tied with specific processing unit >>> and >>> >>> can be called as instance-id or flow-id. This SA can hold >>> instance-id or >>> >>> flow-id information. Upon sync up of context for each IPsec SA to >>> other node >>> >>> B upon failure, it can process the same SA on specific instance-id or >>> >>> flow-id. >>> >>> >>> >>> P.S: If your need some text around this, I can provide you a example >>> and >>> >>> usage of it. >>> >>> >>> >>> BR, >>> >>> Yogendra Pal >>> >>> (Ericsson, India) >>> >>> >>> >>> >>> >>> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal >>> wrote: >>> >>>> >>> >>>> Hi Daniel, >>> >>>> >>> >>>> Quickly went through your draft, have one input for you, >>> >>>> [In section "5. IPsec Session parameters"] >>> >>>> - Consider to have case of IPCOMP also for ipsec session >>> parameters. >>> >>>> >>> >>>> >>> >>>> BR, >>> >>>> Yogendra Pal >>> >>>> (Ericsson) >>> >>>> >>> >>>> >>> >>>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi, >>> >>>>> >>> >>>>> Please find a draft we have Posted. They concern the definition of >>> >>>>> IKEv2 and IPsec contexts. >>> >>>>> Comments are welcome, >>> >>>>> >>> >>>>> BR, >>> >>>>> >>> >>>>> Daniel Palomares >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. >>> >>>>> >>> >>>>> Revision: 00 >>> >>>>> Title: IKEv2/IPsec Context Definition >>> >>>>> Document date: 2014-02-12 >>> >>>>> Group: Individual Submission >>> >>>>> Pages: 8 >>> >>>>> >>> >>>>> URL: >>> http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt >>> >>>>> >>> >>>>> Status: >>> https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ >>> >>>>> Htmlized: >>> >>>>> >>> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 >>> >>>>> >>> >>>>> >>> >>>>> Abstract >>> >>>>> >>> >>>>> IPsec/IKEv2 clusters are constituted of multiple nodes accessed >>> via >>> >>>>> a >>> >>>>> single address by the end user. The traffic is then split >>> between >>> >>>>> the nodes via specific IP load balancing policies. Once a >>> session >>> >>>>> is >>> >>>>> assigned to a given node, IPsec makes it difficult to assign the >>> >>>>> session to another node. This makes management operations and >>> >>>>> transparent high availability for end users difficult to perform >>> >>>>> within the cluster. >>> >>>>> >>> >>>>> This document describes the contexts for IKEv2 and IPsec that >>> MUST >>> >>>>> be >>> >>>>> transferred between two nodes so a session can be restored. >>> This >>> >>>>> makes possible to transfer an IPsec session transparently to >>> the end >>> >>>>> user. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Daniel PALOMARES >>> >>>>> >>> >>>>> Orange Labs, Issy-les-Moulineaux >>> >>>>> >>> >>>>> +33 6 34 23 07 88 >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> IPsec mailing list >>> >>>>> IPsec@ietf.org >>> >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >> >>> > >>> > >>> > >>> > -- >>> > Thanks and Regards, >>> > Yogendra Pal >>> > +919686202644 >>> > >>> > _______________________________________________ >>> > IPsec mailing list >>> > IPsec@ietf.org >>> > https://www.ietf.org/mailman/listinfo/ipsec >>> > >>> >>> >>> >>> -- >>> Daniel Migault >>> Orange Labs -- Security >>> +33 6 70 72 69 58 >>> >> >> > > > -- > Thanks and Regards, > Yogendra Pal > +919686202644 > Thanks for the comments, Regards Daniel Palomares --047d7b10c9b79061b104f3241ba5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Yogendra,

2014-02-20 6:52 GMT+01:= 00 yogendra pal <jntupal@gmail.com>:
Hi Daniel,

Few more queries/input I have= .

1. When you say "IKEv2 Session parameters" and &qu= ot;IPsec Session parameters" , is it implicit that respective IKEv2 po= licy and IPsec policy governing these sessions are also part of these sessi= on parameters or they get explicitly synced between
nodes ?

Yes, these parameters are the IKEv2 and IPsec policies gove= rning the sessions.
=A0

2. I ha= ve NOT seen IKEv2 SA lifetime present in the "IKEv2 Session parameters= " similar to, IPsec SA lifetime present in "IPsec Session paramet= ers". Is this got missed or will be coming as part of explicit sync of= policy b/w nodes ? If it's implicit then we SHOULD add this into "= ;IKEv2 Session parameters" to support IKEv2 SA rekey.
=A0
=
3. Similar to (2), Is ESN (extended sequence number) support will come in i= nto "IPsec Session parameters" ?

4. For IPsec S= A, if PFS is enabled, does it need to reflect in "IPsec Session parame= ters" ?

5. In IKEv2, there is option to support ike-window-size, wil= l this also be part of "IKEv2 Session parameters" ?

=
6. Message-ID for IKEv2 SA would be required to sync b/w nodes, will t= his be synced as part of IKEv2 Session parameters" ?

6. For IRAS usecase, ip address assignment from tunnel= address pool will be synced separately and will NOT be covered as part of = this document or will it be part of "IKEv2 Sesssion parameters" ?=


We = have included all these parameters explicitly in the following version 01. = The IETF Internet-Draft Submission is disabled until 3 march 2014, so we haven'= t been=20 able to upload a newer version.
The IKEv2 lifetime, Message IDs, the ik= e-window-size are part of the IKEv2 session parameters, and the extended s= equence numbers support will also be part of the IPsec session parameters.<= br>
=A0

Thanks,
Yogendra Pal
(Ericsson, India)

=



On Wed, Feb 19, 2014 at 3:52 PM, yogendra pal <= jntupal@gmail.com> wrote:
See inline comments

=
>>Is there any format you like to see xml, jason, bytes format... ?
[Yogendra Pal] instance-id or flow-id will be in bytes, atmost = 4 bytes.


>>What is not clear to me is why a SA on a processing unit X of n= ode A
>>MUST necessarily be also on processing unit X of node B. I= understand
>>processing unit as a CPU or a specific core. Am I ri= ght?
[Yogendra Pal]
1. From end-user perspective, initiator may = NOT know his tunnel
is with A or B (since, operator would have con= figured A and B with
same tunnel endpoint for redundancy).

2. Given that A and B are supporting redundancy for tunnel. Operator config= ure(s)
node A and B as same h/w, however, B can be a low hanging n= ode (asymmetric h/w).

3. Node A can be a device (e.g router) w= ith multiple blades or linecard and each linecard doing ipsec processing.
Similarly B also. In general, operator have load balancing/sharing wh= ich will dictates different tunnels
hosted on different linecards = and hence the steering logic/load balancing algorithm. This steering logic = resulting
into flow-id or instance-id.

I hope I have answered your query

Thanks,
Yogendra Pal
(Erics= son, India)

On Wed, Feb 19, 2014 at 2:33 PM, Daniel Migault <mglt.ietf= @gmail.com> wrote:
Hi,

My understanding is that at the time a format will be defined for
embedding IKEv2 and IPsec context, we should be able to embed also
proprietary parameters similar to vendor-ID with IKEv2. Of course
these parameters will be most probably ignored by other
implementations.

Is there any format you like to see xml, jason, bytes format... ?

What is not clear to me is why a SA on a processing unit X of node A
MUST necessarily be also on processing unit X of node B. I understand
processing unit as a CPU or a specific core. Am I right?


BR,
Daniel

On Wed, Feb 19, 2014 at 6:27 AM, yogendra pal <jntupal@gmail.com> wrote:
> Hi Daniel,
>
> I agree w/ what you said, let the ipsec mailing list discussion this o= ut, I
> just opened the forum w/ my inputs "instance-id". =A0Since t= his draft is
> towards keeping IKEv2/IPsec session alive when any fault is detected o= n
> current node.
>
> Thanks,
> Yogendra Pal
> (Ericssson, India)
>
>
>
> On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares
> <daniel.palomares.ietf@gmail.com> wrote:
>>
>> Hi Yogendra,
>>
>> Thank you for your comments and pointing out the lack of the IPCom= p
>> parameter.
>> I will update the draft including the IPComp flag , as well as the= IPcomp
>> algo and the cpi-in/out values.
>>
>> I understand when you say =A0the draft "SHOULD capture at lea= st instance-id
>> or flow-id". However, I'm not familiar with this definiti= ons as IKEv2 or
>> IPsec standards. Please don't hesitate to address me to those = documents if
>> they are actually standardized.
>>
>> On the other hand, I could understand that those parameters you ju= st
>> mention (instance-id and flow-id), might be proprietary solutions = to improve
>> IPsec treatment among several processing units. If it is the case,= I believe
>> that our document may introduce supplementary information in the c= ontext
>> prior some negotiation, but I believe we should let the whole mail= ing-list
>> discuss about this.
>>
>> By now, our wish is to isolate the IKEv2 and IPsec mandatory param= eters in
>> order to keep an IKEv2/IPsec session alive.
>>
>> KR,
>> Daniel Palomares
>>
>>
>>
>>
>> 2014-02-18 17:25 GMT+01:00 yogendra pal <jntupal@gmail.com>:
>>
>>> Hi Daniel,
>>>
>>> Given that ike and ipsec can runs on different context and nod= es, context
>>> SHOULD capture at least instance-id or flow-id. This instance-= id can help
>>> the node to identify which packet processing unit will process= this ipsec
>>> traffic or which ipsec instance out of multiple ipsec processi= ng unit will
>>> process this ipsec traffic.
>>>
>>> Let me take a simple example case to explain:
>>>
>>> On a node A, which has 10 processing unit (pu) =3D {1,2,3,4,5,= 6,7,8,9,10}
>>> and out of which ike is using single unit =3D {1} and ipsec is= using 7
>>> processing unit(s) =3D {2,3,4,5,6,7,8} and other processing un= its =3D {9,10} for
>>> general purpose.
>>>
>>> Each IPsec SA processing can be tied with specific processing = unit and
>>> can be called as instance-id or flow-id. This SA can hold inst= ance-id or
>>> flow-id information. Upon sync up of context for each IPsec SA= to other node
>>> B upon failure, it can process the same SA on specific instanc= e-id or
>>> flow-id.
>>>
>>> P.S: If your need some text around this, I can provide you a e= xample and
>>> usage of it.
>>>
>>> BR,
>>> Yogendra Pal
>>> (Ericsson, India)
>>>
>>>
>>> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal <jntupal@gmail.com> wrote= :
>>>>
>>>> Hi Daniel,
>>>>
>>>> Quickly went through your draft, have one input for you, >>>> [In section "5. IPsec Session parameters"]
>>>> =A0- Consider to have case of IPCOMP also for ipsec sessio= n parameters.
>>>>
>>>>
>>>> BR,
>>>> Yogendra Pal
>>>> (Ericsson)
>>>>
>>>>
>>>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares
>>>> <daniel.palomares.ietf@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please find a draft we have Posted. They concern the d= efinition of
>>>>> IKEv2 and IPsec contexts.
>>>>> Comments are welcome,
>>>>>
>>>>> BR,
>>>>>
>>>>> Daniel Palomares
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Name: =A0 =A0 =A0 =A0draft-plmrs-ipsecme-ipsec-ikev2-c= ontext-definition.
>>>>>
>>>>> Revision: 00
>>>>> Title: =A0 =A0 =A0 IKEv2/IPsec Context Definition
>>>>> Document date: =A0 =A02014-02-12
>>>>> Group: =A0 =A0 =A0 =A0Individual Submission
>>>>> Pages: =A0 =A0 =A0 =A08
>>>>>
>>>>> URL:http://www.iet= f.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
>>>>>
>>>>> Status:https:/= /datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definitio= n/
>>>>> Htmlized:
>>>>> http://tools.ietf.= org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00
>>>>>
>>>>>
>>>>> Abstract
>>>>>
>>>>> =A0 =A0IPsec/IKEv2 clusters are constituted of multipl= e nodes accessed via
>>>>> a
>>>>> =A0 =A0single address by the end user. =A0The traffic = is then split between
>>>>> =A0 =A0the nodes via specific IP load balancing polici= es. =A0Once a session
>>>>> is
>>>>> =A0 =A0assigned to a given node, IPsec makes it diffic= ult to assign the
>>>>> =A0 =A0session to another node. =A0This makes manageme= nt operations and
>>>>> =A0 =A0transparent high availability for end users dif= ficult to perform
>>>>> =A0 =A0within the cluster.
>>>>>
>>>>> =A0 =A0This document describes the contexts for IKEv2 = and IPsec that MUST
>>>>> be
>>>>> =A0 =A0transferred between two nodes so a session can = be restored. =A0This
>>>>> =A0 =A0makes possible to transfer an IPsec session tra= nsparently to the end
>>>>> =A0 =A0user.
>>>>>
>>>>>
>>>>>
>>>>> Daniel PALOMARES
>>>>>
>>>>> Orange Labs, Issy-les-Moulineaux
>>>>>
>>>>> +33 6 34 23 07 88
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> IPsec mailing list
>>>>> IP= sec@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Thanks and Regards,
> Yogendra Pal
> +919686202644
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/ipsec
>



--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58




--
Thanks and Regards,
= Yogendra Pal
+919686202644
<= br>
Thanks for the comments,

Regard= s
Daniel Palomares

--047d7b10c9b79061b104f3241ba5-- From nobody Tue Feb 25 10:48:47 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9E01A0735 for ; Tue, 25 Feb 2014 10:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DYDHwNd1PXD for ; Tue, 25 Feb 2014 10:48:39 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F079B1A072E for ; Tue, 25 Feb 2014 10:48:37 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hi5so4734398wib.3 for ; Tue, 25 Feb 2014 10:48:36 -0800 (PST) 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=zO+T6+ghhTYIPkxEhQ1nzP6kNTfAmEvMuMhRdjrsA5k=; b=MrsIDHD/qOHbkDZGIMgXX0hZUGuAeVPCeLFiOb2e6zGdg4IQy5Blcfa7Il9Ip4VMrE j88cLh5UubWsTE1nwDagqFKoV2SLsCxokwbIWBp9CLFL27U2wC572M6tFE9JQFvyMe1D 6y5T2wnnbnIgrJ5WoZo7v9iF7B66NLCrTjtdIkak37UiSzWua1msfhJuun/9sdzCGXfF dKciGlme2V3o76oKyut1KLXkQreTk4Pn6R02fvG2a8POPhgekAfJ3l2iRvxmt0hP+yrj 9TyfHoQPYvQ+t9jTt4d31CKDI0Ary1oJpkEd/SzJ/RhRG9jDUZQaiiiImalgLECQE81H 3unQ== X-Received: by 10.194.250.34 with SMTP id yz2mr25955395wjc.18.1393354116664; Tue, 25 Feb 2014 10:48:36 -0800 (PST) Received: from [10.0.0.6] (bzq-79-177-80-210.red.bezeqint.net. [79.177.80.210]) by mx.google.com with ESMTPSA id u6sm2621713wif.6.2014.02.25.10.48.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 10:48:36 -0800 (PST) Message-ID: <530CE583.6030801@gmail.com> Date: Tue, 25 Feb 2014 20:48:35 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/i9xUH9OFp16CfKWSzpz67P3R14k Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 18:48:41 -0000 Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. The changes from the existing requirements are listed in Sec. 2.5 of the draft, but most of this (rather short) document is new and describes the rationale for the choice of algorithms and requirement levels. Please read this draft and send any comments to the WG mailing list, even if the comments are "I see no problems". Comments such as "I do not understand this part" or "this part could be explained better in this way" are particularly useful at this point. Thanks, Yaron From ynir.ietf@gmail.com Tue Feb 25 12:27:18 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02BE1A07A9 for ; Tue, 25 Feb 2014 12:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX6972h8p_Ow for ; Tue, 25 Feb 2014 12:27:12 -0800 (PST) Received: from mail-we0-x243.google.com (mail-we0-x243.google.com [IPv6:2a00:1450:400c:c03::243]) by ietfa.amsl.com (Postfix) with ESMTP id 398E21A0789 for ; Tue, 25 Feb 2014 12:27:12 -0800 (PST) Received: by mail-we0-f195.google.com with SMTP id q58so244358wes.6 for ; Tue, 25 Feb 2014 12:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=34ZPo/wUjpLfNXhgy95ZsWacLPpZB+Y9sp3OLuMhHZc=; b=j1xM2PIQ+xTB6pqfydalGMFWuZQ2xwKeOlOGWqSStHg1+2CMaenME13glNgzSgd4SQ wn3H28jeAMtDD2ouCKl41fYwMfZJ0JzgtJnfIXV5cyMo3m9BKoamcWRXFXiz+cLuJGC9 apwm4vT1R60eh+vWcUny9dOfZ0nHGYO+WIN6XqUZD1k+b/TZ+2SkjkskUlYHDhf8i4qf t5xe2Smr8S/bXwRD2diem1w8R6K6ctOeG35pztdCYuGI6VFq/XbX1y+KMpsg/q0cw3bh y7XJIXGvwNrT+AA21ua3+zhYYtNkx01PcOU+a1IChzjQQqqywFyZIxUIo+CCzYqMUQCo HEbA== X-Received: by 10.181.12.16 with SMTP id em16mr1736390wid.3.1393360030844; Tue, 25 Feb 2014 12:27:10 -0800 (PST) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id jd2sm3337609wic.9.2014.02.25.12.27.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 12:27:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_184D298D-AEE5-4545-85FC-CD9FEA5E372B" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Yoav Nir In-Reply-To: <530CE583.6030801@gmail.com> Date: Tue, 25 Feb 2014 22:27:07 +0200 Message-Id: References: <530CE583.6030801@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/p_WvqfvTHYZcEQ3dbs8-q2-y_cA Cc: ipsec Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 20:28:45 -0000 --Apple-Mail=_184D298D-AEE5-4545-85FC-CD9FEA5E372B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi I think this document is ready.=20 A quick glance at the tables in section two lead me to ask some = questions: Why is DES singled out, while things like HMAC-MD5 are not discouraged? Why is there no algorithm diversity? Why is HMAC-SHA-256 not there? However, reading section 4 answered all of those questions, so I think = it=92s clear. The only nit I can find is that =93+=94 means =93in the = future this will be more encouraged=94, and =93-=93 means =93in the = future this will be less encouraged, except for =93SHOULD NOT+=94. It = might be more consistent if that was called =93SHOULD NOT-=93. But that = is nit-picking, as the text does explain what that means.=20 Yoav On Feb 25, 2014, at 8:48 PM, Yaron Sheffer = wrote: > Hi, this is to start a 2-week working group last call on the revised = Algorithm Implementation Requirements document, ending March 11. The = draft is at: = http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should = have last called the draft a while ago, and I apologize for the delay. >=20 > The changes from the existing requirements are listed in Sec. 2.5 of = the draft, but most of this (rather short) document is new and describes = the rationale for the choice of algorithms and requirement levels. >=20 > Please read this draft and send any comments to the WG mailing list, = even if the comments are "I see no problems". Comments such as "I do not = understand this part" or "this part could be explained better in this = way" are particularly useful at this point. >=20 > Thanks, > Yaron >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_184D298D-AEE5-4545-85FC-CD9FEA5E372B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi

I think this document is = ready. 

A quick glance at the tables in = section two lead me to ask some questions:
  • Why is DES singled out, while things like = HMAC-MD5 are not discouraged?
  • Why = is there no algorithm diversity?
  • Why is HMAC-SHA-256 not = there?

However, reading section 4 answered = all of those questions, so I think it=92s clear. The only nit I can find = is that =93+=94 means =93in the future this will be more encouraged=94, = and =93-=93 means =93in the future this will be less encouraged, except = for =93SHOULD NOT+=94. It might be more consistent if that was called = =93SHOULD NOT-=93. But that is nit-picking, as the text does explain = what that = means. 

Yoav

O= n Feb 25, 2014, at 8:48 PM, Yaron Sheffer <yaronf.ietf@gmail.com> = wrote:

Hi, this is to start a 2-week working group last call on = the revised Algorithm Implementation Requirements document, ending March = 11. The draft is at: htt= p://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We = should have last called the draft a while ago, and I apologize for the = delay.

The changes from the existing requirements are listed in = Sec. 2.5 of the draft, but most of this (rather short) document is new = and describes the rationale for the choice of algorithms and requirement = levels.

Please read this draft and send any comments to the WG = mailing list, even if the comments are "I see no problems". Comments = such as "I do not understand this part" or "this part could be explained = better in this way" are particularly useful at this = point.

Thanks,
=    Yaron

___________________________________________= ____
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/= mailman/listinfo/ipsec

= --Apple-Mail=_184D298D-AEE5-4545-85FC-CD9FEA5E372B-- From nobody Tue Feb 25 15:10:01 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336241A02F3 for ; Tue, 25 Feb 2014 15:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzBUIB-Pk6Pr for ; Tue, 25 Feb 2014 15:09:51 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1689D1A00C2 for ; Tue, 25 Feb 2014 15:09:51 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0C56680D6D; Tue, 25 Feb 2014 18:09:49 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1PN9mEK028543; Tue, 25 Feb 2014 18:09:48 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 25 Feb 2014 18:09:48 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yaron Sheffer In-Reply-To: Message-ID: References: <530CE583.6030801@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/eKItQry1RdNNzcgHeLG67-1JeW8 Cc: ipsec Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 23:09:54 -0000 > On Feb 25, 2014, at 8:48 PM, Yaron Sheffer wrote: > > Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements > document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We > should have last called the draft a while ago, and I apologize for the delay. Section 2.2: It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old crypto export restrictions? While I think NULL ESP is a good debugging tool, and a good replacement for AH in general, I don't think this is really a MUST item (unless you would actually advise people to migrate from AH to ESP NULL, in which case I'll cheer on this MUST) Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane modern IKE daemon that allows 1DES (or modp768) Section 2.3: This does not list anything with md5. Is there another RFC that already discourages this use for IPsec? If so, can it be references in this document. If not, shouldn't we talk about an HMAC-MD5 downgrade to SHOULD NOT+ ? [ Turns out that document is RFC 4835, but only mentioned at the end. Should this document not Obsolete: 4835? ] Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can think of for this is when we use a combined mode algorithm like AES-GCM. But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be SHOULD+ as well? Section 2.5: I would put 2.5 as the introduction paragraph to 2.1. I'm also confused why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. Should they be added with "-" in the Old Requirement, and their listing in the New Requirement? Section 3 states: If authentication on the IP header is needed in conjunction with confidentiality of higher-layer data, then AH SHOULD be used in addition to the transforms recommended above. How does AH protect the confidentiality of "higher-layer data" ? Seciont 4: The text about "The Triple Data Encryption Standard (TDES) is obsolete" appears twice and could be consolidated? Section 4.3: This section is the only section that mentions MD5 and SHA1. Perhaps it should summarize or refer to RFC 4835? Paul From nobody Tue Feb 25 16:17:57 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4D11A0311 for ; Tue, 25 Feb 2014 16:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kjp4wMCqJH3 for ; Tue, 25 Feb 2014 16:17:52 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C106D1A030E for ; Tue, 25 Feb 2014 16:17:52 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1Q0HgTI024482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 17:17:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Tue, 25 Feb 2014 16:17:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> References: <530CE583.6030801@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/1CRi0XOYwZ8fXL6EUhF5RLiVJLs Cc: ipsec Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 00:17:54 -0000 On Feb 25, 2014, at 3:09 PM, Paul Wouters wrote: >> On Feb 25, 2014, at 8:48 PM, Yaron Sheffer = wrote: >>=20 >> Hi, this is to start a 2-week working group last call on the = revised Algorithm Implementation Requirements >> document, ending March 11. The draft is at: = http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We >> should have last called the draft a while ago, and I apologize = for the delay. >=20 > Section 2.2: >=20 > It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the = old > crypto export restrictions? While I think NULL ESP is a good debugging > tool, and a good replacement for AH in general, I don't think this is > really a MUST item (unless you would actually advise people to migrate > from AH to ESP NULL, in which case I'll cheer on this MUST) It is for systems that don't implement AH. We should probably say this = explicitly in section 3. > Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane > modern IKE daemon that allows 1DES (or modp768) The WG has never voiced a MUST NOT for this before. I'm fine with making = that change if no one objects. > Section 2.3: >=20 > This does not list anything with md5. Is there another RFC that = already > discourages this use for IPsec? If so, can it be references in this > document. If not, shouldn't we talk about an HMAC-MD5 downgrade to > SHOULD NOT+ ? HMAC-MD5 still gives 128 bits of strength, which in fact is more than = the MUST-level HMAC-SHA1-96. It was a MAY in 4835; by not listing it = here, it is still "MAY". > [ Turns out that document is RFC 4835, but only mentioned at the > end. Should this document not Obsolete: 4835? ] This document should indeed obsolete 4835. Good catch. > Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I = can > think of for this is when we use a combined mode algorithm like = AES-GCM. > But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be > SHOULD+ as well? That's covered in Section 3. The tables are the raw list of = requirements; their use is covered in Section 3. > Section 2.5: >=20 > I would put 2.5 as the introduction paragraph to 2.1. Bike shed. > I'm also confused > why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. I just checked, and I think the table of changes is correct. Which do = you think is missing? > Should > they be added with "-" in the Old Requirement, and their listing in = the > New Requirement? No, this is a table of differences. > Section 3 states: >=20 > If authentication on the IP header is needed in conjunction with > confidentiality of higher-layer data, then AH SHOULD be used in > addition to the transforms recommended above. >=20 > How does AH protect the confidentiality of "higher-layer data" ? It does not, of course. I think this sentence was trying to be about "if = the higher-layer data already has its own confidentiality, then you can = add AH". I think the sentence should be removed because it assumes that = the device adding authentication knows whether or not the higher-layer = service is using confidentiality correctly, and it can't know this. > Seciont 4: >=20 > The text about "The Triple Data Encryption Standard (TDES) is = obsolete" > appears twice and could be consolidated? The second one is about DES. :-) > Section 4.3: >=20 > This section is the only section that mentions MD5 and SHA1. Perhaps = it > should summarize or refer to RFC 4835? I think it is better to make this document obsolete 4835 and keep the = negative text. --Paul Hoffman= From nobody Tue Feb 25 16:50:58 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFBC1A01D5 for ; Tue, 25 Feb 2014 16:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IC4OpY9_ONL for ; Tue, 25 Feb 2014 16:50:51 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB2B1A0347 for ; Tue, 25 Feb 2014 16:50:51 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8D0D980D6D; Tue, 25 Feb 2014 19:50:49 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1Q0ocZe011720; Tue, 25 Feb 2014 19:50:49 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 25 Feb 2014 19:50:38 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> Message-ID: References: <530CE583.6030801@gmail.com> <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/cnrmL01FTeI6HYIQlzSrBJD3CVo Cc: ipsec Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 00:50:55 -0000 On Tue, 25 Feb 2014, Paul Hoffman wrote: >> It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old >> crypto export restrictions? While I think NULL ESP is a good debugging >> tool, and a good replacement for AH in general, I don't think this is >> really a MUST item (unless you would actually advise people to migrate >> from AH to ESP NULL, in which case I'll cheer on this MUST) > > It is for systems that don't implement AH. We should probably say this explicitly in section 3. Ahh, I'm okay with that if we can make that clarification. >> Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane >> modern IKE daemon that allows 1DES (or modp768) > > The WG has never voiced a MUST NOT for this before. I'm fine with making that change if no one objects. Good. >> Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can >> think of for this is when we use a combined mode algorithm like AES-GCM. >> But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be >> SHOULD+ as well? > > That's covered in Section 3. The tables are the raw list of requirements; their use is covered in Section 3. That still does not address my point. If AES-GCM is rated FOO, then per definition since it uses ESP auth NULL, that ESP auth NULL should also be rated FOO. Right now AES-GCM is SHOULD+ and ESP auth NULL is MAY. >> Section 2.5: >> >> I would put 2.5 as the introduction paragraph to 2.1. > > Bike shed. Sure :) It just seems that the 2.5 listing is the essential core of the document. I'm fine if you prefer green. >> I'm also confused >> why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. > > I just checked, and I think the table of changes is correct. Which do you think is missing? AES-CCM, AES-128-CBC, DES-CBC, HMAC-SHA1-96, NULL ? >> Section 3 states: >> >> If authentication on the IP header is needed in conjunction with >> confidentiality of higher-layer data, then AH SHOULD be used in >> addition to the transforms recommended above. >> >> How does AH protect the confidentiality of "higher-layer data" ? > > It does not, of course. I think this sentence was trying to be about "if the higher-layer data already has its own confidentiality, then you can add AH". I think the sentence should be removed because it assumes that the device adding authentication knows whether or not the higher-layer service is using confidentiality correctly, and it can't know this. To me it seemed that "AH" needed to be "ESP"? >> Seciont 4: >> >> The text about "The Triple Data Encryption Standard (TDES) is obsolete" >> appears twice and could be consolidated? > > The second one is about DES. :-) No higher up :) Section 3: Triple-DES SHOULD NOT be used in any scenario in which multiple gigabytes of data will be encrypted with a single key. As a 64-bit block cipher, it leaks information about plaintexts above that "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement for the sake of backwards compatibility, but its use is discouraged. Seciont 4.2: The Triple Data Encryption Standard (TDES) is obsolete because of its small block size; as with all 64-bit block ciphers, it SHOULD NOT be used to encrypt more than one gigabyte of data with a single key [M13]. Its key size is smaller than that of the Advanced Encryption Standard (AES), while at the same time its performance and efficiency is worse. Thus, its use in new implementations is discouraged. >> Section 4.3: >> >> This section is the only section that mentions MD5 and SHA1. Perhaps it >> should summarize or refer to RFC 4835? > > I think it is better to make this document obsolete 4835 and keep the negative text. Fine with me, Paul From nobody Tue Feb 25 17:17:44 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21DC1A0827 for ; Tue, 25 Feb 2014 17:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCpswiTsgxQ0 for ; Tue, 25 Feb 2014 17:17:39 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 162B41A0825 for ; Tue, 25 Feb 2014 17:17:39 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1Q1HRIC027405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 18:17:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Tue, 25 Feb 2014 17:17:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <530CE583.6030801@gmail.com> <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/7ZrDm5rT2TlWoPJXsalumk7v7hk Cc: ipsec Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 01:17:41 -0000 On Feb 25, 2014, at 4:50 PM, Paul Wouters wrote: >>> Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I = can >>> think of for this is when we use a combined mode algorithm like = AES-GCM. >>> But in that case if AES-GCM is SHOULD+ it requires ESP auth null to = be >>> SHOULD+ as well? >>=20 >> That's covered in Section 3. The tables are the raw list of = requirements; their use is covered in Section 3. >=20 > That still does not address my point. If AES-GCM is rated FOO, then = per > definition since it uses ESP auth NULL, that ESP auth NULL should also > be rated FOO. Right now AES-GCM is SHOULD+ and ESP auth NULL is MAY. This seems to be calling for a relational table that I think is beyond = where we want to go. If someone implements AES-GCM and doesn't implement = ESP-NULL, Section 3 covers that. >>> I'm also confused >>> why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. >>=20 >> I just checked, and I think the table of changes is correct. Which do = you think is missing? >=20 > AES-CCM, AES-128-CBC, DES-CBC, HMAC-SHA1-96, NULL ? AES-CCM is MAY in both documents AES-128-CBC is MUST in both documents DES-CBC is now under discussion HMAC-SHA1-96 is MUST in both documents NULL is MAY in both documents So, I'm still confused. >>> Section 3 states: >>>=20 >>> If authentication on the IP header is needed in conjunction with >>> confidentiality of higher-layer data, then AH SHOULD be used in >>> addition to the transforms recommended above. >>>=20 >>> How does AH protect the confidentiality of "higher-layer data" ? >>=20 >> It does not, of course. I think this sentence was trying to be about = "if the higher-layer data already has its own confidentiality, then you = can add AH". I think the sentence should be removed because it assumes = that the device adding authentication knows whether or not the = higher-layer service is using confidentiality correctly, and it can't = know this. >=20 > To me it seemed that "AH" needed to be "ESP"? Even then, the sentence is about "the higher-layer data already has its = own confidentiality", which I think is unknowable by an ESP or AH = implementation. I think the sentence can safely be removed. >=20 >>> Seciont 4: >>>=20 >>> The text about "The Triple Data Encryption Standard (TDES) is = obsolete" >>> appears twice and could be consolidated? >>=20 >> The second one is about DES. :-) >=20 > No higher up :) >=20 > Section 3: >=20 > Triple-DES SHOULD NOT be used in any scenario in which multiple > gigabytes of data will be encrypted with a single key. As a 64-bit > block cipher, it leaks information about plaintexts above that > "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement > for the sake of backwards compatibility, but its use is discouraged. >=20 > Seciont 4.2: >=20 > The Triple Data Encryption Standard (TDES) is obsolete because of = its > small block size; as with all 64-bit block ciphers, it SHOULD NOT be > used to encrypt more than one gigabyte of data with a single key > [M13]. Its key size is smaller than that of the Advanced Encryption > Standard (AES), while at the same time its performance and = efficiency > is worse. Thus, its use in new implementations is discouraged. I admit that "usage guidance" and "rationale" overlap, but I think = having the "please rethink 3DES" discussion twice is a positive. --Paul Hoffman= From nobody Tue Feb 25 22:47:10 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FCA1A047C; Tue, 25 Feb 2014 22:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUyTIJPK04QC; Tue, 25 Feb 2014 22:47:01 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AB1D31A046F; Tue, 25 Feb 2014 22:47:00 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id hr13so311264lab.17 for ; Tue, 25 Feb 2014 22:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=TDze3BTU83oMmZI7m8bPw2RE3+Glu2iYNO8ChS6ZiX4=; b=Q0XyADY5zKz1OckVgnsmufLaLgRsJz1TkqVPaXB73OdVbdarxoRGI43j44acewczUB P4h5ps1wFE/A/LhNtlK6tHCVUIClskJUgeJ8ILfD2HXbpZoaIYUwq/yitZ1qZIHLgKrQ 51A5c4ePAf2TXzcJrDkToQocYL+wt77yQksFobUuQCcbzZDeoT64HCK8KM4HXgLxA5rG UPICybsr3cF5s/8VSbOJt4/pJUqlWF761l7YrB1K5k/rKl1D0VwMp/6L8ajPBjo26XnE kkAhoJpjkvbD8jiE1UavZ58Zo13Cvioj7CaAxKh5Z8rHE/ywpFl4tGWvmjgZV7ksH+e2 Q6qQ== X-Received: by 10.152.23.132 with SMTP id m4mr1162125laf.34.1393397218753; Tue, 25 Feb 2014 22:46:58 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id mo3sm24849628lbb.17.2014.02.25.22.46.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Feb 2014 22:46:58 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Yaron Sheffer" , "Daniel Migault" , "Hannes Tschofenig" References: <530393EA.5020008@gmail.com> Date: Wed, 26 Feb 2014 10:47:09 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/AEXgkMSJT66ADwjPOtnc-sX0KgA Cc: ipsec@ietf.org, lwip@ietf.org, Sye Loong Keoh Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 06:47:03 -0000 Hi, First, I agree with Yaron that Diet-ESP looks more like a new protocol, than like ESP extension. And in this case it must have its own protocol number. Then, I have some concerns how Diet-ESP will live with NATs. The draft is silent about it. If we consider Diet-ESP as ESP extension, then standard UDP-encapsulation must apply. But here is the problem - with UDP encapsulation the first 4 bytes of packet data are used to distinguish between IKE and UDP-encapsulated ESP, as in ESP these bytes are SPI wich is never zero. In Diet-ESP this is not true - SPI may be shorter than 4 bytes or even be absent and there is a chance that those bytes will be zero (e.g. an IV may appear to be zero, and SPI and SN are absent). So, with Diet-ESP we cannot reliably distinguish IKE from UDP-encapsulated ESP and therefore some other mechanism must be (re)invented. And last, the draft declares that its main goal is to minimize power consumption caused by transferring extra bytes. But in this case it's probably more fruitful to define some new crypto transform for IoT, than redesigning ESP. In this case you may use implicit IV (or explicit, but small), small ICV, use stream cipher etc. I think that in this case you may gain even more economy in power consumption than with current approach. Regards, Valery Smyslov. ----- Original Message ----- From: "Yaron Sheffer" To: "Daniel Migault" ; "Hannes Tschofenig" Cc: ; ; "Sye Loong Keoh" Sent: Tuesday, February 18, 2014 9:10 PM Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP > Hi Daniel, > > This might be a naive answer - I have not read the draft in detail. > > But on the "is this a duck or not" question, it seems to me the answer is > simple: if the protocol can work stand-alone (two endpoints talking to > each other, with manual keying and no IKE), then it's a protocol. > Otherwise it's a protocol extension. > > And if it's a protocol, it needs an IP protocol number, which is a > seriously expensive resource. We allocated one for WESP > (http://tools.ietf.org/html/rfc5840#section-4), is there any chance we > could reuse it somehow? > > Thanks, > Yaron > > On 02/18/2014 03:06 PM, Daniel Migault wrote: >> Hi Hannes, >> > [...] > >> >> Now comes also another question: Is diet-ESP a new protocol, a new >> extension, a ESP compression algorithm.... I would be happy to get >> opinion on that. >> >> 1) Diet-ESP: Extension vs Protocol >> >> - a) Diet-ESP is an IPsec extension >> The way we considered to peers agreeing on the diet-esp context is >> using minimal IKE sending an DIET-ESP_SUPPORTED Notify Payloads with >> proposition of DIET-ESP Context. The responder just ignores the >> propositions or chose one. All remaining stuff would be negotiated via >> the traditional CREATE_CHILD_SA were peers would agree on ESP, keys, >> algos.... >>>From that point of view it looks the diet-ESP is more a >> wire-compression algorithm. If not supported by one of the peer we >> fall back with standard ESP. >> >> -b) Diet-ESP is a new Protocol >> Another way would be to consider that all parameters of the Diet-ESP >> Context would be negotiated in the CREATE_CHILD_SA exchange with new >> Transform structures. >>>From that point of view diet-esp would look more like a new protocol >> and the possible choice may be IKE/ESP/AH/DIET-ESP.... >> >> There might be other alternatives I would be happy to hear about. For >> now I like better the extension way. >> >> 2) What Diet-ESP changes from regular ESP >> >> Diet-ESP changes IPsec and ESP headers, trailers with smaller fields. >> >> Diet-ESP changes the way the packet is compressed and encrypted. >> >> On the other hand, for a sensor with a single diet-ESP configuration, >> most of the IPsec stack remains unchanged. This is not so true for >> peers that are able to handle all Diet-ESP configuraions. In that case >> the standard way of looking up in the SAD may be changed. We will >> provide a better description of this in the next version of the draft. >> >> BR, >> Daniel >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Feb 25 23:07:07 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1BD1A0864 for ; Tue, 25 Feb 2014 23:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.139 X-Spam-Level: * X-Spam-Status: No, score=1.139 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ambCvTtZ4Od6 for ; Tue, 25 Feb 2014 23:07:03 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2E01A0860 for ; Tue, 25 Feb 2014 23:07:03 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id hr13so323841lab.17 for ; Tue, 25 Feb 2014 23:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=kk0yO0e//URML6UuCZocFPSc9AFDimPaMuQZNWibDd8=; b=QRwxhHU6ENMoJ7mKeDD1VVlrsQ4+KZw1kcs8p8bK9wr4yVfvEAbwTAVkKMNwr1Kf0g quWBnm+c7TTiDN2CxuMQrO+5gjq2gpB3fX4GtrrchXMgpOpg1GNXa6dQdjd0x8drkLiK sqolWamD+pZa9UtfqaG9wSvXL/dZZ6VmMVADXtQSpI+FgNU3b5kp3EUvt0W32jWZsq+l ePW7h7JK4Jooesq2WGdIChRCG5I5a5RxeuFHSSD2rCkvGgtOeDKHcV3BIn0VOwddU3kQ mcPw7vENqviTZiQpDlm7qVehR9op3I8AN5o7E13MLJKlkYaPif1V1UX1oraHjWITaGIF rUcA== X-Received: by 10.152.205.197 with SMTP id li5mr311599lac.50.1393398421291; Tue, 25 Feb 2014 23:07:01 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id 10sm3728688lan.5.2014.02.25.23.06.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Feb 2014 23:07:00 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Hoffman" , "Paul Wouters" References: <530CE583.6030801@gmail.com> <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> Date: Wed, 26 Feb 2014 11:07:11 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/7XfL9k01l7Lhr5x7SykuKKz16HQ Cc: ipsec Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 07:07:05 -0000 Hi Paul, >> It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old >> crypto export restrictions? While I think NULL ESP is a good debugging >> tool, and a good replacement for AH in general, I don't think this is >> really a MUST item (unless you would actually advise people to migrate >> from AH to ESP NULL, in which case I'll cheer on this MUST) > > It is for systems that don't implement AH. We should probably say this > explicitly in section 3. I don't think it is limited for those systems only. You may implement AH, but yon cannot use it everywhere, as it is not compatible with NATs. And ESP-NULL with Auth is the only substitute there. So, it must be MUST for any system. Regards, Valery Smyslov. From nobody Wed Feb 26 00:15:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664731A0047 for ; Wed, 26 Feb 2014 00:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48Qg8wTqbq-L for ; Wed, 26 Feb 2014 00:15:03 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F26541A0078 for ; Wed, 26 Feb 2014 00:15:02 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id z12so1377955wgg.5 for ; Wed, 26 Feb 2014 00:15:01 -0800 (PST) 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=Q4tNVjdKMlKSCmXj9jAPt+NVRSwieApaF7wqzpKF+Nw=; b=d5RjiSUY8ySspiU2th1BCHXhyWy0gb272rNcuXWAFyRhlt0FLEKSwDFwlaVjKuDwnr 7w3iRcLYodK5iNUHWK0Qb4Kjm/x9n/57BieXIubLPvwk7ACayjWVs7Sd06yH11TkpCb3 i8/jSUA88zP9kDVE8GT1jG1q7BNwTL65TmvbLBgcl6fgybuUJwq2P6CzXSQyYw5rS7xO gih0Ny/LIVSZ/t6ClNKOHmCcL4/3QwnXUMMvAOv9tORwNSjdv6UHhq9UmNu+a3Z/lIej qJZKtoxyn1k/n3YeXAZnLgsM2VzYXkMF0ClsiM3hpqw8U14Bbxfgubvt3ZGaFMOSalHX YBtA== X-Received: by 10.194.219.132 with SMTP id po4mr1190540wjc.7.1393402501375; Wed, 26 Feb 2014 00:15:01 -0800 (PST) Received: from [10.2.0.25] (93-173-72-197.bb.netvision.net.il. [93.173.72.197]) by mx.google.com with ESMTPSA id di9sm3073669wid.6.2014.02.26.00.15.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Feb 2014 00:15:01 -0800 (PST) Message-ID: <530DA283.3080606@gmail.com> Date: Wed, 26 Feb 2014 10:14:59 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Hoffman , Paul Wouters References: <530CE583.6030801@gmail.com> <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> In-Reply-To: <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/MiNZkS0TqSx6p2mcHahTVtodxxQ Cc: ipsec Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 08:15:11 -0000 (Hats off) +1 on making single-DES CBC a MUST NOT. Yaron > >> Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane >> modern IKE daemon that allows 1DES (or modp768) > > The WG has never voiced a MUST NOT for this before. I'm fine with making that change if no one objects. > From nobody Wed Feb 26 03:42:45 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484D21A029F; Wed, 26 Feb 2014 03:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcnpcAMD0HZ7; Wed, 26 Feb 2014 03:42:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 916E61A0241; Wed, 26 Feb 2014 03:42:36 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140226114236.6159.95981.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 03:42:36 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/nOEJxyFgZyvgukPioXqRxD5151U Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (IKEv2 Fragmentation) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 11:42:39 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IKEv2 Fragmentation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-03-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 26 05:20:48 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADBE1A030B for ; Wed, 26 Feb 2014 05:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PabcroPaxrML for ; Wed, 26 Feb 2014 05:20:40 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1C11A007F for ; Wed, 26 Feb 2014 05:20:40 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C66F580D6D; Wed, 26 Feb 2014 08:20:37 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1QDKbeZ008503; Wed, 26 Feb 2014 08:20:37 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 26 Feb 2014 08:20:37 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Valery Smyslov In-Reply-To: Message-ID: References: <530CE583.6030801@gmail.com> <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QHskMef5IPUYEMHkytR3dF9-hIM Cc: ipsec , Paul Hoffman Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 13:20:43 -0000 On Wed, 26 Feb 2014, Valery Smyslov wrote: >> It is for systems that don't implement AH. We should probably say this >> explicitly in section 3. > > I don't think it is limited for those systems only. > You may implement AH, but yon cannot use it > everywhere, as it is not compatible with NATs. > And ESP-NULL with Auth is the only substitute there. > So, it must be MUST for any system. Why did we not kill AH all together when Schneier and Ferguson told us so? :P But you are right. Perhaps some text along the line of: ESP-NULL offers the same protection as AH, but is more widely accepted and functional compared to AH. AH does not work through NATs and is not implemented in every IPsec stack. AH requires firewall rules different from ESP causing it to get accidentally filtered. ESP-NULL is also used in performance testing as a benchmark against ESP encryption algorithms. ESP-NULL should never be automatically selected as part of IKE unless explicitely configured as the only ESP encryption algorithm. Paul From nobody Wed Feb 26 07:10:02 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF911A0670 for ; Wed, 26 Feb 2014 07:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC0CH7L01PMN for ; Wed, 26 Feb 2014 07:09:55 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E909B1A01F2 for ; Wed, 26 Feb 2014 07:09:53 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1QF9oWp064070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 26 Feb 2014 08:09:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140226114236.6159.95981.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 07:09:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <46B75C7A-B5CC-4A19-AA5D-2631DFCD5C49@vpnc.org> References: <20140226114236.6159.95981.idtracker@ietfa.amsl.com> To: ipsec X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QeBJ3mFFECI60ygeTNy0Q-ZW1Bw Subject: Re: [IPsec] Last Call: (IKEv2 Fragmentation) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 15:09:57 -0000 A process note: even though this is IETF Last Call, WG members are still = encouraged to comment on the draft. That is, just because we already = finished WG LC, that doesn't mean you should not read the draft again = and make any helpful comments on ietf@ietf.org or to the IESG. --Paul Hoffman On Feb 26, 2014, at 3:42 AM, The IESG wrote: >=20 > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > - 'IKEv2 Fragmentation' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-03-12. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. >=20 >=20 >=20 >=20 > The file can be obtained via > = http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ >=20 > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/bal= lot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Wed Feb 26 07:22:31 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04A21A065A for ; Wed, 26 Feb 2014 07:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXLrr7HcQh7n for ; Wed, 26 Feb 2014 07:22:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 119A11A01EF for ; Wed, 26 Feb 2014 07:22:25 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53870) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WIgJS-000M6N-Ol for ipsec@ietf.org; Wed, 26 Feb 2014 10:22:22 -0500 Message-ID: <530E06AE.9040800@bbn.com> Date: Wed, 26 Feb 2014 10:22:22 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <530CE583.6030801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/RlsNx5Jwdqxeq2Y1Y2dgqHR6nAw Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 15:22:27 -0000 Paul, >> On Feb 25, 2014, at 8:48 PM, Yaron Sheffer >> wrote: >> >> Hi, this is to start a 2-week working group last call on the revised >> Algorithm Implementation Requirements >> document, ending March 11. The draft is at: >> http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We >> should have last called the draft a while ago, and I apologize for >> the delay. > > Section 2.2: > > It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old > crypto export restrictions? While I think NULL ESP is a good debugging > tool, and a good replacement for AH in general, I don't think this is > really a MUST item (unless you would actually advise people to migrate > from AH to ESP NULL, in which case I'll cheer on this MUST) I think we do want folks to migrate from AH to ESP/NULL. That's why we made support for AH a MAY a while ago. Steve From nobody Wed Feb 26 07:25:03 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9E21A028A for ; Wed, 26 Feb 2014 07:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYazMNIKPZHt for ; Wed, 26 Feb 2014 07:24:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id F3C731A0645 for ; Wed, 26 Feb 2014 07:24:50 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53871) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WIgLp-000MCq-9n; Wed, 26 Feb 2014 10:24:49 -0500 Message-ID: <530E0741.4040800@bbn.com> Date: Wed, 26 Feb 2014 10:24:49 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Wouters , ipsec References: <530CE583.6030801@gmail.com> <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/dmET_S4X56gktAju-LUY0kzsirw Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 15:24:57 -0000 Paul, > On Wed, 26 Feb 2014, Valery Smyslov wrote: > >>> It is for systems that don't implement AH. We should probably say >>> this explicitly in section 3. >> >> I don't think it is limited for those systems only. >> You may implement AH, but yon cannot use it >> everywhere, as it is not compatible with NATs. >> And ESP-NULL with Auth is the only substitute there. >> So, it must be MUST for any system. > > Why did we not kill AH all together when Schneier and Ferguson told us > so? :P > But you are right. Perhaps some text along the line of: perhaps because they were wrong. ESP-NULL offers better performance than AH and so it is desirable in most cases. But, AH has been specified by some protocols and we don't want to undermine their choice by killing it. Steve From nobody Wed Feb 26 08:42:21 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85531A069A for ; Wed, 26 Feb 2014 08:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6gurE-QXLjP for ; Wed, 26 Feb 2014 08:42:17 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 89F861A0139 for ; Wed, 26 Feb 2014 08:42:10 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1QGg7M7068624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 26 Feb 2014 09:42:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <119B957E-8E00-40C4-ABC5-6D1C3AB8B963@vpnc.org> Date: Wed, 26 Feb 2014 08:42:06 -0800 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/CTDGAOTcCxZKgGyuGbmAK6AY0Qk Subject: [IPsec] Getting slides for the upcoming meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 16:42:18 -0000 Greetings. We are having our face-to-face meeting in a week; = https://datatracker.ietf.org/meeting/89/agenda/ipsecme/ So far, I have received no slides. I would like to. --Paul Hoffman= From nobody Thu Feb 27 05:55:32 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BF01A028D; Thu, 27 Feb 2014 05:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV-5ujilyHA9; Thu, 27 Feb 2014 05:55:26 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 972051A01E8; Thu, 27 Feb 2014 05:55:25 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id p61so2885604wes.38 for ; Thu, 27 Feb 2014 05:55:23 -0800 (PST) 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=Hfdekl5Xl+iXHn6Tumv3jrc0SLADvxDmv/aDweLjtW8=; b=pwo0DmZiNycHhVrHo/rH6fVtuyJPIfr++NI98vUzcW5JWg5IPzS157de6vo3AegtyX ik1hkqae2A2Vid6wu2Lygy8s1hSZsl1Uq++j6th3gckZDRHlRUqa6PIRwXOwwiVAe1BB CkKbKmash01Ad70xWhUHgbkkhnkqveMDOwRQJMeF6O5b3+8u7P6VhFQHXx3AwzJtAa5I EoUCFbkH6MPh/iBkDwhV8/gpI/X5u2cxeQeRFoQ0wb/jB485xkSCaH1lZvwMgChzDbaL duX3Ul7RCfNj2CrM8zoLavKw+q3AfLmvjVnV1Zsx95zf1KkxXkdj3jLffsS1ipnOubEX Usgg== MIME-Version: 1.0 X-Received: by 10.180.13.33 with SMTP id e1mr10013586wic.38.1393509323617; Thu, 27 Feb 2014 05:55:23 -0800 (PST) Received: by 10.194.171.129 with HTTP; Thu, 27 Feb 2014 05:55:23 -0800 (PST) In-Reply-To: References: <530393EA.5020008@gmail.com> Date: Thu, 27 Feb 2014 14:55:23 +0100 Message-ID: From: Daniel Migault To: Valery Smyslov Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/PV1aBwCMRBgN9_LZcZt9F_tggTk Cc: "ipsec@ietf.org" , Hannes Tschofenig , Sye Loong Keoh , lwip@ietf.org Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 13:55:28 -0000 Hi Valery, On Wed, Feb 26, 2014 at 7:47 AM, Valery Smyslov wrote: > Hi, > > First, I agree with Yaron that Diet-ESP looks more like a new protocol, > than like ESP extension. And in this case it must have its own > protocol number. > I agree, for me the best way would have had and ESP extension and eventually define a new algorithm DIET-AES-CTR for example. However, because we are also making possible to remove Padding and Pad Len and Next Header this looks comprised and we change the header it looks that Diet-ESP is a new protocol. > Then, I have some concerns how Diet-ESP will live with NATs. > The draft is silent about it. If we consider Diet-ESP as ESP > extension, then standard UDP-encapsulation must apply. > But here is the problem - with UDP encapsulation the first > 4 bytes of packet data are used to distinguish between > IKE and UDP-encapsulated ESP, as in ESP these bytes > are SPI wich is never zero. In Diet-ESP this is not true - > SPI may be shorter than 4 bytes or even be absent and > there is a chance that those bytes will be zero (e.g. an IV > may appear to be zero, and SPI and SN are absent). > So, with Diet-ESP we cannot reliably distinguish IKE > from UDP-encapsulated ESP and therefore some other > mechanism must be (re)invented. > True, we did not think of of NAT in IoT context. We have added a section on that point. Actually, if UPD encapsulation is required, then using a SPI (even one byte) solves this issue. We will publish the draft as soon as possible wit the update. Thanks for the feed back. > And last, the draft declares that its main goal is to minimize > power consumption caused by transferring extra bytes. > But in this case it's probably more fruitful to define some > new crypto transform for IoT, than redesigning ESP. In this > case you may use implicit IV (or explicit, but small), > small ICV, use stream cipher etc. I think > that in this case you may gain even more economy > in power consumption than with current approach. > Completely agree. We are currently working on ESP format, but we are also considering AES-CTR without explicit IV. However, the ratio computing vs communication in IoT is quite impressive and there is a high interest in compressing frames before transmitting them. - Computing ranges from 0.5nJ per instruction for extremely energy-efficient microcontrollers (such as CoolRisc or MSP430) to 200 nJ per instruction for high-performance microprocessors (such as ARM9). - Communication: from 100nJ to 1uJ per bit transmitted or received, depending on modulation complexity and transmission power (we only consider "low-power" radios, with transmit powers lower than about 10mW). Roughly speaking, this means that, for the energy cost of exchanging 1 bit, our system can alternatively compute 10-100 instructions. > Regards, > Valery Smyslov. > > Best Regards, Daniel > > > ----- Original Message ----- From: "Yaron Sheffer" > To: "Daniel Migault" ; "Hannes Tschofenig" > > Cc: ; ; "Sye Loong Keoh" > > Sent: Tuesday, February 18, 2014 9:10 PM > Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP > > >> Hi Daniel, >> >> This might be a naive answer - I have not read the draft in detail. >> >> But on the "is this a duck or not" question, it seems to me the answer is >> simple: if the protocol can work stand-alone (two endpoints talking to each >> other, with manual keying and no IKE), then it's a protocol. Otherwise it's >> a protocol extension. >> >> And if it's a protocol, it needs an IP protocol number, which is a >> seriously expensive resource. We allocated one for WESP >> (http://tools.ietf.org/html/rfc5840#section-4), is there any chance we could >> reuse it somehow? >> >> Thanks, >> Yaron >> >> On 02/18/2014 03:06 PM, Daniel Migault wrote: >>> >>> Hi Hannes, >>> >> [...] >> >>> >>> Now comes also another question: Is diet-ESP a new protocol, a new >>> extension, a ESP compression algorithm.... I would be happy to get >>> opinion on that. >>> >>> 1) Diet-ESP: Extension vs Protocol >>> >>> - a) Diet-ESP is an IPsec extension >>> The way we considered to peers agreeing on the diet-esp context is >>> using minimal IKE sending an DIET-ESP_SUPPORTED Notify Payloads with >>> proposition of DIET-ESP Context. The responder just ignores the >>> propositions or chose one. All remaining stuff would be negotiated via >>> the traditional CREATE_CHILD_SA were peers would agree on ESP, keys, >>> algos.... >>>> >>>> From that point of view it looks the diet-ESP is more a >>> >>> wire-compression algorithm. If not supported by one of the peer we >>> fall back with standard ESP. >>> >>> -b) Diet-ESP is a new Protocol >>> Another way would be to consider that all parameters of the Diet-ESP >>> Context would be negotiated in the CREATE_CHILD_SA exchange with new >>> Transform structures. >>>> >>>> From that point of view diet-esp would look more like a new protocol >>> >>> and the possible choice may be IKE/ESP/AH/DIET-ESP.... >>> >>> There might be other alternatives I would be happy to hear about. For >>> now I like better the extension way. >>> >>> 2) What Diet-ESP changes from regular ESP >>> >>> Diet-ESP changes IPsec and ESP headers, trailers with smaller fields. >>> >>> Diet-ESP changes the way the packet is compressed and encrypted. >>> >>> On the other hand, for a sensor with a single diet-ESP configuration, >>> most of the IPsec stack remains unchanged. This is not so true for >>> peers that are able to handle all Diet-ESP configuraions. In that case >>> the standard way of looking up in the SAD may be changed. We will >>> provide a better description of this in the next version of the draft. >>> >>> BR, >>> Daniel >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Thu Feb 27 10:16:58 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9A71A015A for ; Thu, 27 Feb 2014 10:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6R9Kuvdw44A for ; Thu, 27 Feb 2014 10:16:52 -0800 (PST) Received: from mail-ie0-x244.google.com (mail-ie0-x244.google.com [IPv6:2607:f8b0:4001:c03::244]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1351A036E for ; Thu, 27 Feb 2014 10:16:52 -0800 (PST) Received: by mail-ie0-f196.google.com with SMTP id rd18so236055iec.11 for ; Thu, 27 Feb 2014 10:16:51 -0800 (PST) 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=1nMO/WzOyEbk3mmEESE5XtzOQd5NgTHZdwGwI6oboHI=; b=mIjNMRdik8Dtmc+DTblA6arQ4/RquxKfajl4gxgA0pirf4tvPOoKH2xqz5y168abN3 t+uWhmUVzWTW2sG8aDfxbMLxIpyo+89fKsTGV6NpvojPP7m+IM+CWef1rzIIKeYgQN6n 5W4Yz5IPzuhggoXJEg4QxlDTcSx65sAkTtsHuqSVw8hcEen9U8WjdrmD7QA68R/l+HsN S9RmBlcBIr0rg5EBM5Lv1l1VxeSkIBQ7LI3EUISr9J5HJsG99ykmdp6p486w5Gi5FiO2 Sqk+td30hlIOjIZBIDylgY3VPsITjxTtEhdIlWt/Ch9bX30S9gNCjmk0H1h9JUcbJGE9 ZvVw== MIME-Version: 1.0 X-Received: by 10.43.58.19 with SMTP id wi19mr7020865icb.53.1393525010847; Thu, 27 Feb 2014 10:16:50 -0800 (PST) Received: by 10.50.40.131 with HTTP; Thu, 27 Feb 2014 10:16:50 -0800 (PST) In-Reply-To: <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> References: <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> Date: Thu, 27 Feb 2014 19:16:50 +0100 Message-ID: From: Daniel Palomares To: Valery Smyslov Content-Type: multipart/alternative; boundary=bcaec51f966341ddc204f367539b Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/9cONqs7u1ZQj71e-YwCUmz2iHBA Cc: IPsecme WG Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:16:57 -0000 --bcaec51f966341ddc204f367539b Content-Type: text/plain; charset=ISO-8859-1 Hello Valery, Thanks for commenting on the draft . 2014-02-21 12:02 GMT+01:00 Valery Smyslov : > Hi, > > I have some comments regarding the draft. > > First, I'm a bit puzzled by intended status of the draft: Standards Track. > From my understanding this means, that the document defines some protocol, > that needs to be standardized to get interoperability. But the draft > defines > no protocol, it just speculates on what contents of IKE/IPsec SA must > contain. > While no doubt it is helpful, I think that the proper intended status for > the draft > is Informational. > You are right, the draft is intended to be INFORMATIONAL. This is already changed in version -01, but will be uploaded later as this draft tool is disable until 3th march. > > Then, I've been always thinking that the content of the IKE/IPsec SA is > an implementation issue. The draft tries to mandate this content, > but it lacks plenty of absolutely needed information (this is especially > true > for IKE SA), like MID counters, window bitmaps, lifetimes, credential > information, > VIDs, features, statistics and so on. > Yeah, in the lists of the IKE_SA/IPsec_SA parameters, some information was missing, but they actually appear in the structure example on the Appendix. These parameters, together with those pointed out by Yogendra in previous comments, are explicitly added in their corresponding sections. > > On the other hand, the draft tries to mandate one way of presenting some > data, > ignoring the fact that it is not the only (and probably not the best) > way. For example, > instead of transferring nonces and DH secret to the other node one may > transfer computed SK_* keys. This approach may have some advantages both > from security and performance perspectives. > We actually think sending keys is one quick way to build an IKE_SA/IPsec_SA. As I said before, all the keys SK_* were included in the Appendix but are missing within the lists in sections 4 and 5. They are added in the following version of the draft -01. We also included three different level of parameters in order to classify their relevance: *Mandatory, Optional or Vendor Specific*. Note that the draft does not intend to define the format for transferring the parameters/contexts. The draft actually identifies each parameter that MUST be included to maintain the IKE_SA/IPsec_SA alive. To classify the relevance of the parameter, it can be defined as Mandatory (M), Optional (O) or Vendor Specific (V). I have one question concerning about comment concerning the keys (SK_*), : A node can send all the keys (SK_*) to avoid their recalculation in the other node, ignoring the Nonces and DH secret. However, ignoring Nonces might lead to the impossibility of REKYING crypto material. Please correct me if I'm wrong. So my question is: Are you proposing to add all SK_* together with the Nonce and DH information? Or, do you think that sending all keys might be enough (ignoring Ni, Nr and DH-related information)? Kind Regards, Daniel Palomares > Regards, > Valery Smyslov. > > > ----- Original Message ----- > *From:* Daniel Palomares > *To:* ipsec@ietf.org > *Sent:* Thursday, February 13, 2014 6:09 PM > *Subject:* [IPsec] Draft: IKEv2/IPsec Context Definition > > Hi, > > Please find a draft we have Posted. They concern the definition of IKEv2 > and IPsec contexts. > Comments are welcome, > > BR, > > Daniel Palomares > > > > > > Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. > > Revision: 00 > Title: IKEv2/IPsec Context Definition > Document date: 2014-02-12 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt > Status: > https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ > Htmlized: > http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 > > > Abstract > > IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a > single address by the end user. The traffic is then split between > the nodes via specific IP load balancing policies. Once a session is > assigned to a given node, IPsec makes it difficult to assign the > session to another node. This makes management operations and > transparent high availability for end users difficult to perform > within the cluster. > > This document describes the contexts for IKEv2 and IPsec that MUST be > transferred between two nodes so a session can be restored. This > makes possible to transfer an IPsec session transparently to the end > user. > > > > *Daniel* *PALOMARES* > > *Orange Labs, Issy-les-Moulineaux* > > +33 6 34 23 07 88 > > ------------------------------ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --bcaec51f966341ddc204f367539b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Valery,

Thanks for commenting on the draft .=


2014-02-2= 1 12:02 GMT+01:00 Valery Smyslov <svanru@gmail.com>:
Hi,
=A0
I have some comments regarding the draft.
=A0
First, I'm a bit puzzled by intended status of the draft:=20 Standards Track.
From my understanding this means, that the document defines=20 some protocol,
that needs to be standardized to get interoperability. But the= =20 draft defines
no protocol, it just speculates=A0on what contents of=20 IKE/IPsec SA must contain.
While no doubt it is helpful, I think that the proper intended= =20 status for the draft
is Informational.

You are right, the draf= t is intended to be INFORMATIONAL. This is already changed in version -01, = but will be uploaded later as this draft tool is disable until 3th march. =A0
=A0
Then, I've been always thinking that the content of the=20 IKE/IPsec SA is
an implementation issue. The draft tries to mandate this=20 content,
but it lacks plenty of absolutely needed information (this is=20 especially true
for IKE SA), like MID counters, window bitmaps, lifetimes,=20 credential information,
VIDs, features, statistics and so on.=20

Yeah, in the lists of t= he IKE_SA/IPsec_SA parameters, some information was missing, but they actua= lly appear in the structure example on the Appendix. These parameters, toge= ther with those pointed out by Yogendra in previous comments, are explicitl= y added in their corresponding sections.
=A0
=A0
On the other hand, the draft tries to=20 mandate one way of presenting some data,
ignoring the fact that it is not the only=20 (and probably not the best) way. For example,
instead of=A0transferring nonces and DH secret to the other=20 node one may
transfer computed SK_* keys. This=20 approach=A0may have=A0some advantages both
from security and performance perspect= ives.

We actually think = sending keys is one quick way to build an IKE_SA/IPsec_SA.=A0 As I said bef= ore, all the keys SK_* were included in the Appendix but are missing within= the lists in sections 4 and 5. They are added in the following version of = the draft -01.

We also included three different level of parameters in order to classi= fy their relevance: Mandatory, Optional or Vendor Specific.
Note that the draft does not intend to define the format for transfe= rring the parameters/contexts. The draft actually identifies each parameter= that MUST be included to maintain the IKE_SA/IPsec_SA alive. To classify t= he relevance of the parameter, it can be defined as Mandatory (M), Optional= (O) or Vendor Specific (V).

I have one question concerning about comment concerning the = keys (SK_*), :
A node can send all the keys (SK_*) to avoid = their recalculation in the other node, ignoring the Nonces and DH secret. H= owever,=A0 ignoring Nonces might lead to the impossibility of REKYING crypt= o material. Please correct me if I'm wrong. So my question is:
Are you proposing to add all SK_* together with the Nonce and DH informatio= n? Or, do you think that sending all keys might be enough (ignoring Ni, Nr = and DH-related information)?
=A0

Kind Regar= ds,
Daniel Palomares


=A0
Regards,
Valery Smyslov.
=A0
----- Original Message -----
Sent: Thursday, February 13, 2014 6= :09=20 PM
Subject: [IPsec] Draft: IKEv2/IPsec= =20 Context Definition

= Hi,

Please find a draft we have Posted. They concern the=20 definition of IKEv2 and IPsec contexts.
Comments are welcome,<= /p>

BR,

Daniel Palomares

=A0

=A0

Name: =A0 =A0 =A0=A0=20 draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

= Revision:=20 00
Title: =A0 =A0 =A0 IKEv2/IPsec Context Definition
Document=20 date: =A0 =A02014-02-12
Group: =A0 =A0 =A0 =A0Individual=20 Submission
Pages: =A0 =A0 =A0=A0 8
URL:http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ike= v2-context-definition-00.txt
Status:= https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-de= finition/
Htmlized: h= ttp://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definitio= n-00

=
Abstract

=A0 =A0IPsec/IKEv2 clusters are=20 constituted of multiple nodes accessed via a
=A0 =A0single address by= =20 the end user. =A0The traffic is then split between
=A0 =A0the=20 nodes via specific IP load balancing policies. =A0Once a session=20 is
=A0 =A0assigned to a given node, IPsec makes it difficult to=20 assign the
=A0 =A0session to another node. =A0This makes=20 management operations and
=A0 =A0transparent high availability for=20 end users difficult to perform
=A0 =A0within the=20 cluster.

=A0 =A0This document describes the contexts for IKEv2=20 and IPsec that MUST be
=A0 =A0transferred between two nodes so a=20 session can be restored. =A0This
=A0 =A0makes possible to transfer=20 an IPsec session transparently to the end
=A0 =A0user.

=A0

Daniel PALOMARES

Orange Lab= s,=20 Issy-les-Moulineaux

+33 6 34 23 0= 7=20 88

_______________________________________________
IPsec mailing= =20 list
IPsec@ietf.or= g
https://www.ietf.org/mailman/listinfo/ipsec


--bcaec51f966341ddc204f367539b-- From nobody Thu Feb 27 22:30:47 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB601A03FF for ; Thu, 27 Feb 2014 22:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fstKXSOmzMbb for ; Thu, 27 Feb 2014 22:30:41 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 674A91A02D3 for ; Thu, 27 Feb 2014 22:30:40 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id z11so2349203lbi.8 for ; Thu, 27 Feb 2014 22:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=mJUMdH3Oz5XIIDrVFUzuTfFklqQcWOJQYj0y5WZbw7Q=; b=yali2XXSxjF5sb2cajLUdDVDKwIVMh4Wz5pi+UR0EfatsdXNSPM385lOszuDLS6l9M GFhDpSXtPXgInL7fMBuSE4eZEPOp0CHa2C8mQg7D9pmxz/5WiFPYPjno8SD/KlIdo16U Z3GnDFiYgfnXuwQuH3Q9Y4pibIuohAQqWDBdCd/lsPK/a9pKC/e0Dsbsh8/PCCgc5TrW J4gbea2Xq01+RCDFZyeh34ZPzE45bYCyPe5cv/H8k/AEnqtwEgwATs/3cJPL2TrYqXpD bWa2+3r13wZ7D+t5ty+GnvJEZ36+rFSvNsm/gjmb43M/a211f2735m84G1LFs9t1xX2C VQzQ== X-Received: by 10.152.88.82 with SMTP id be18mr9862492lab.3.1393569037833; Thu, 27 Feb 2014 22:30:37 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id gb8sm2538734lbc.13.2014.02.27.22.30.36 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Feb 2014 22:30:36 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Daniel Palomares" References: <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> Date: Fri, 28 Feb 2014 10:30:34 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0993_01CF3470.1D4CFD00" 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.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/lF5ZVZnS84_VD4qW1wwUeLfgWug Cc: IPsecme WG Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 06:30:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0993_01CF3470.1D4CFD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniel, ----- Original Message -----=20 From: Daniel Palomares=20 To: Valery Smyslov=20 Cc: IPsecme WG=20 Sent: Thursday, February 27, 2014 10:16 PM Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition Hello Valery,=20 Thanks for commenting on the draft . =20 Then, I've been always thinking that the content of the IKE/IPsec SA = is=20 an implementation issue. The draft tries to mandate this content, but it lacks plenty of absolutely needed information (this is = especially true for IKE SA), like MID counters, window bitmaps, lifetimes, = credential information, VIDs, features, statistics and so on.=20 Yeah, in the lists of the IKE_SA/IPsec_SA parameters, some information = was missing, but they actually appear in the structure example on the = Appendix. These parameters, together with those pointed out by Yogendra = in previous comments, are explicitly added in their corresponding = sections.=20 Sorry, I still couldn't find in IKEV2CONTEXT structure neither next_mid, = nor next_expected_mid, nor window_bitmap etc. All this parameters are mandatory for IKEv2 to work properly. On the other hand, the draft tries to mandate one way of presenting = some data,=20 ignoring the fact that it is not the only (and probably not the = best) way. For example, instead of transferring nonces and DH secret to the other node one = may=20 transfer computed SK_* keys. This approach may have some advantages = both=20 from security and performance perspectives. We actually think sending keys is one quick way to build an = IKE_SA/IPsec_SA. As I said before, all the keys SK_* were included in = the Appendix but are missing within the lists in sections 4 and 5. They = are added in the following version of the draft -01. We also included three different level of parameters in order to = classify their relevance: Mandatory, Optional or Vendor Specific.=20 Note that the draft does not intend to define the format for = transferring the parameters/contexts. The draft actually identifies each = parameter that MUST be included to maintain the IKE_SA/IPsec_SA alive. = To classify the relevance of the parameter, it can be defined as = Mandatory (M), Optional (O) or Vendor Specific (V). I have one question concerning about comment concerning the keys = (SK_*), :=20 A node can send all the keys (SK_*) to avoid their recalculation in = the other node, ignoring the Nonces and DH secret. However, ignoring = Nonces might lead to the impossibility of REKYING crypto material. = Please correct me if I'm wrong. So my question is:=20 Are you proposing to add all SK_* together with the Nonce and DH = information? Or, do you think that sending all keys might be enough = (ignoring Ni, Nr and DH-related information)? Sending SK_* is enough. Nonces are used only in calculations of = SKEYSEED, SK_*, keymat for Child SA and AUTH payload content.Anyway, once the = exchange is complete, the nonces, appeared in this exchange, may be discarded. Actually, you have 3 choices to exchange IKEv2 keying information = between nodes in cluster: 1. Send your private DH key, peer's KE content and nonces. In this case other nodes will recalculate all keys from the very beginning. 2. Send SKEYSEED and nonces. 3. Send computed SK_* keys. Note. that you even may omit sending SK_p*, = as these keys are used only during authentication (unless you implement = Session Resumption, but it also depends on how you store the tickets - by value or by = reference). All approaches are equally possible. There seems to be some security and performance benefists for approach 3, but somebody may argue. Implementation may use any of this approaches and I don't think it's good to mandate the only approach, Regards, Valery. Kind Regards, Daniel Palomares Regards, Valery Smyslov. ----- Original Message -----=20 From: Daniel Palomares=20 To: ipsec@ietf.org=20 Sent: Thursday, February 13, 2014 6:09 PM Subject: [IPsec] Draft: IKEv2/IPsec Context Definition Hi, Please find a draft we have Posted. They concern the definition of = IKEv2 and IPsec contexts.=20 Comments are welcome, BR, Daniel Palomares Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. Revision: 00 Title: IKEv2/IPsec Context Definition Document date: 2014-02-12 Group: Individual Submission Pages: 8 = URL:http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-defini= tion-00.txt = Status:https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-c= ontext-definition/ Htmlized: = http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-defini= tion-00 Abstract IPsec/IKEv2 clusters are constituted of multiple nodes accessed = via a single address by the end user. The traffic is then split = between the nodes via specific IP load balancing policies. Once a = session is assigned to a given node, IPsec makes it difficult to assign = the session to another node. This makes management operations and transparent high availability for end users difficult to = perform within the cluster. This document describes the contexts for IKEv2 and IPsec that = MUST be transferred between two nodes so a session can be restored. = This makes possible to transfer an IPsec session transparently to = the end user. Daniel PALOMARES Orange Labs, Issy-les-Moulineaux +33 6 34 23 07 88 -------------------------------------------------------------------------= - _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0993_01CF3470.1D4CFD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Daniel,
----- Original Message -----
From:=20 Daniel Palomares =
Sent: Thursday, February 27, = 2014 10:16=20 PM
Subject: Re: [IPsec] Draft: = IKEv2/IPsec=20 Context Definition

Hello Valery,

Thanks for commenting on the = draft=20 .
 
Then, I've been always thinking that the = content of the=20 IKE/IPsec SA is
an implementation issue. The draft tries to = mandate this=20 content,
but it lacks plenty of absolutely needed = information=20 (this is especially true
for IKE SA), like MID counters, window bitmaps, = lifetimes, credential information,
VIDs, features, statistics and so=20 on.

Yeah, in the lists of the IKE_SA/IPsec_SA parameters, some = information=20 was missing, but they actually appear in the structure example on the=20 Appendix. These parameters, together with those pointed out by = Yogendra in=20 previous comments, are explicitly added in their corresponding = sections.=20
Sorry, I still = couldn't find in=20 IKEV2CONTEXT structure neither next_mid, =
nor next_expected_mid, = nor=20 window_bitmap etc. All this parameters
are mandatory for = IKEv2 to work=20 properly.
 
On the other hand, the draft tries to=20 mandate one way of presenting some data,
ignoring the fact that = it is not the=20 only (and probably not the best) way. For example,
instead of transferring nonces and DH = secret to the=20 other node one may
transfer computed SK_* keys. This=20 approach may have some advantages both
from security and = performance=20 perspectives.

We actually think sending keys is one quick way to build an=20 IKE_SA/IPsec_SA.  As I said before, all the keys SK_* were = included in=20 the Appendix but are missing within the lists in sections 4 and 5. = They are=20 added in the following version of the draft -01.

We also = included three=20 different level of parameters in order to classify their relevance:=20 Mandatory, Optional or Vendor Specific.
Note that the draft does not intend to define the format for = transferring=20 the parameters/contexts. The draft actually identifies each parameter = that=20 MUST be included to maintain the IKE_SA/IPsec_SA alive. To classify = the=20 relevance of the parameter, it can be defined as Mandatory (M), = Optional (O)=20 or Vendor Specific (V).

I have one question concerning about comment concerning the keys = (SK_*),=20 :
A node can send all the keys (SK_*) to avoid their recalculation = in the=20 other node, ignoring the Nonces and DH secret. However,  ignoring = Nonces=20 might lead to the impossibility of REKYING crypto material. Please = correct me=20 if I'm wrong. So my question is:
Are you proposing to add all SK_* = together with the Nonce and DH information? Or, do you think that = sending all=20 keys might be enough (ignoring Ni, Nr and DH-related=20 information)?
Sending SK_* is enough. Nonces are used = only in=20 calculations of SKEYSEED,
SK_*, keymat for Child SA and AUTH payload = content.Anyway, once the exchange
is complete, the nonces, appeared in this = exchange,=20 may be discarded.
 
Actually, you have 3 choices to exchange = IKEv2 keying=20 information between nodes in cluster:
1. Send your private DH key, peer's KE = content and=20 nonces. In this case
    other nodes will = recalculate all=20 keys from the very beginning.
2. Send SKEYSEED and nonces.
3. Send computed SK_* keys. Note. that you = even may=20 omit sending SK_p*, as these
    keys are used only = during=20 authentication (unless you implement Session=20 Resumption,
    but it also depends on = how you=20 store the tickets - by value or by reference).
 
All approaches are equally possible. There = seems to be=20 some
security and performance benefists for = approach 3, but=20 somebody
may argue. Implementation may use any of = this=20 approaches
and I don't think it's good to mandate the = only=20 approach,
 
Regards,
Valery.



 
Kind Regards,
Daniel = Palomares


 
Regards,
Valery Smyslov.
 
----- Original Message ----- =
Sent: Thursday, February = 13, 2014=20 6:09 PM
Subject: [IPsec] Draft: = IKEv2/IPsec=20 Context Definition

Hi,

Please find a draft we have Posted. They = concern the=20 definition of IKEv2 and IPsec contexts.
Comments are=20 welcome,

BR,

Daniel = Palomares

 

 

Name:     =   =20 draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

Revision:=20 00
Title:       IKEv2/IPsec Context=20 Definition
Document date:    2014-02-12
Group: =  =20      Individual Submission
Pages:    =20    8
URL:http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-conte= xt-definition-00.txt
Status:https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-i= kev2-context-definition/
Htmlized: http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-c= ontext-definition-00


Abstract

   IPsec/IKEv2 clusters = are=20 constituted of multiple nodes accessed via a
  =  single=20 address by the end user.  The traffic is then split = between
 =20  the nodes via specific IP load balancing policies. =  Once a=20 session is
   assigned to a given node, IPsec makes = it=20 difficult to assign the
   session to another node.=20  This makes management operations and
  =  transparent=20 high availability for end users difficult to perform
 =20  within the cluster.

   This document = describes the=20 contexts for IKEv2 and IPsec that MUST be
  =  transferred=20 between two nodes so a session can be restored. =  This
 =20  makes possible to transfer an IPsec session transparently to = the=20 end
   user.

 

Daniel PALOMARES

Orange Labs,=20 Issy-les-Moulineaux

+33 6 = 34 23 07=20 88

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


------=_NextPart_000_0993_01CF3470.1D4CFD00-- From nobody Thu Feb 27 22:34:40 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3441A0411; Thu, 27 Feb 2014 22:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gONPLLNXFnNV; Thu, 27 Feb 2014 22:34:34 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3F80C1A03FF; Thu, 27 Feb 2014 22:34:34 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id hr17so2414764lab.33 for ; Thu, 27 Feb 2014 22:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=zsfQQTerMM5cbUzpn7XQtyKF//54MRAVFyCJCxx/vq0=; b=hXE2iHAMLJgSnD1VF6/LzSZyTzw4gk6l5SaKs5p7jdmMNcnNdubRE4VKRAGB23kkZY 2l7v8Kp1kKtA6WEvp0UdxJxzEvgKGzn+LzGRY5ewpRErj+JoMIGtn7DG971arouSrxjp mWDaYLNCwsOnv5r8LWcHT07Ek4gH1W8hvIRmoJbKwMZ9AcQmwSsUdrIr1iSZvbcG7rQj w+BS4E8E1Lgn3WnTI1hldaCJdY7li7aN/A8UyMImp2j6IOCXse9Zrwho1wTUeVINa5a6 WrnvwshjWkC8JWp0/Aq3Uc2gKFV4jY5MzuaLf9ya9dO8w6VYIOQqUp1umNKxmNYmzswA PcPw== X-Received: by 10.112.180.72 with SMTP id dm8mr9499562lbc.28.1393569271898; Thu, 27 Feb 2014 22:34:31 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id rt7sm2585078lbb.0.2014.02.27.22.34.30 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Feb 2014 22:34:31 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Daniel Migault" References: <530393EA.5020008@gmail.com> Date: Fri, 28 Feb 2014 10:34:29 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/HDFpO45S4QJDBkIuN3TIHimMsTE Cc: ipsec@ietf.org, Hannes Tschofenig , Sye Loong Keoh , lwip@ietf.org Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 06:34:35 -0000 Hi Daniel, > However, the ratio computing vs communication in IoT is quite > impressive and there is a high interest in compressing frames before > transmitting them. > - Computing ranges from 0.5nJ per instruction for extremely > energy-efficient microcontrollers (such as CoolRisc or MSP430) to 200 > nJ per instruction for high-performance microprocessors (such as > ARM9). > - Communication: from 100nJ to 1uJ per bit transmitted or > received, depending on modulation complexity and transmission power > (we only consider "low-power" radios, with transmit powers lower than > about 10mW). > > Roughly speaking, this means that, for the energy cost of exchanging 1 > bit, our system can alternatively compute 10-100 instructions. Yes, it's impressive. Did you consider using ROHC (RObust Header Compression)? It will allow you to significantly decrease size of TCP/UDP/IP headers. Regards, Valery Smyslov. From nobody Fri Feb 28 03:43:46 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E472C1A045D for ; Fri, 28 Feb 2014 03:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8hl6oDkAJlQ for ; Fri, 28 Feb 2014 03:43:40 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A41FD1A004C for ; Fri, 28 Feb 2014 03:43:39 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s1SBhUDU029892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Feb 2014 13:43:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s1SBhSYh009612; Fri, 28 Feb 2014 13:43:28 +0200 (EET) 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: <21264.30304.786430.344200@fireball.kivinen.iki.fi> Date: Fri, 28 Feb 2014 13:43:28 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <530DA283.3080606@gmail.com> References: <530CE583.6030801@gmail.com> <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org> <530DA283.3080606@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/mUetXqzjtaBkd3bOqXhm1drgJlI Cc: ipsec , Paul Wouters , Paul Hoffman Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 11:43:43 -0000 Yaron Sheffer writes: > +1 on making single-DES CBC a MUST NOT. Agree on that. (And I still need to read the whole document, I am way too much behind with my IPsecME WG draft reading). -- kivinen@iki.fi From nobody Fri Feb 28 07:00:32 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8A01A01E8; Fri, 28 Feb 2014 07:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH-gUPE1iVqD; Fri, 28 Feb 2014 07:00:27 -0800 (PST) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) by ietfa.amsl.com (Postfix) with ESMTP id 09BFF1A07C0; Fri, 28 Feb 2014 07:00:27 -0800 (PST) Received: from webmail2.cip.ifi.lmu.de (mailserv1.ifi.lmu.de [IPv6:2001:4ca0:4000:0:141:84:220:222]) by acheron.ifi.lmu.de (Postfix) with ESMTP id 9E9F094A142; Fri, 28 Feb 2014 16:00:24 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 28 Feb 2014 16:00:24 +0100 From: Tobias Guggemos To: Valery Smyslov In-Reply-To: References: <530393EA.5020008@gmail.com> Message-ID: <4e008ff196be9869dd80785909687adf@imap.cip.ifi.lmu.de> X-Sender: tobias.guggemos@stud.ifi.lmu.de User-Agent: Roundcube Webmail/1.0-beta Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/foDM8YrxZ2uYijXavluyasgVj-0 Cc: ipsec@ietf.org, lwip@ietf.org, Hannes Tschofenig , Sye Loong Keoh , Daniel Migault Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 15:00:30 -0000 Hello Valery Yes we considered ROHC and also 6LoWPAN, because both include possibilities for compression ESP. First, it's definitely an option and remains an option even if Diet-ESP is going to be used. We are thinking about Diet-ESP because: - If I'm right ROHC needs at least one uncompressed packet to be send, which may be expensive. - As we want to use IPsec/ESP we have all necessary information in the SAD/SPD to restore the information of IP/UDP/(partly TCP). The idea is to use them instead of adding ROHC compressors between the different layers which 1) adds ROM space (which may be limited) and 2) storage for an information which is already there. - In case of Diet-ESP it is really simple to restore the payload headers and it costs only two bits to send once in the session. This is why we decided to add this as an option. BR Tobias Am 28.02.2014 07:34, schrieb Valery Smyslov: > Hi Daniel, > >> However, the ratio computing vs communication in IoT is quite >> impressive and there is a high interest in compressing frames before >> transmitting them. >> - Computing ranges from 0.5nJ per instruction for extremely >> energy-efficient microcontrollers (such as CoolRisc or MSP430) to 200 >> nJ per instruction for high-performance microprocessors (such as >> ARM9). >> - Communication: from 100nJ to 1uJ per bit transmitted or >> received, depending on modulation complexity and transmission power >> (we only consider "low-power" radios, with transmit powers lower than >> about 10mW). >> >> Roughly speaking, this means that, for the energy cost of exchanging 1 >> bit, our system can alternatively compute 10-100 instructions. > > Yes, it's impressive. Did you consider using ROHC (RObust Header > Compression)? > It will allow you to significantly decrease size of TCP/UDP/IP headers. > > Regards, > Valery Smyslov. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec