From emma.zhanglijia@huawei.com Fri Nov 1 00:10:01 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF4F11E8215; Fri, 1 Nov 2013 00:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.992 X-Spam-Level: X-Spam-Status: No, score=-3.992 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq16HqeTIvJw; Fri, 1 Nov 2013 00:09:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2DF11E80ED; Fri, 1 Nov 2013 00:09:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZT14321; Fri, 01 Nov 2013 07:09:54 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 07:09:26 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 07:09:53 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.121]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 1 Nov 2013 15:09:51 +0800 From: "Zhanglijia (A)" To: John Mattsson Thread-Topic: draft-ietf-ippm-ipsec-01 review Thread-Index: Ac7WzwppfxHy7g5dSjWMtSxLJHcnNgAAhkkA Date: Fri, 1 Nov 2013 07:09:49 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.64] Content-Type: multipart/alternative; boundary="_000_CE92CE3FCF47934CBAE2CCECE119606C6338C67Bnkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" , "ippm@ietf.org" Subject: [IPsec] =?utf-8?b?562U5aSNOiBkcmFmdC1pZXRmLWlwcG0taXBzZWMtMDEg?= =?utf-8?q?review?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 07:23:48 -0000 --_000_CE92CE3FCF47934CBAE2CCECE119606C6338C67Bnkgeml507mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwgYWxsDQoNCg0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldyEgUGxlYXNlIHNl ZSB0aGUgcmVwbHkgYXMgYmVsbG93Lg0KDQoNCg0KQmVzdCBSZWdhcmRzDQoNCkVtbWENCg0KDQoN Ci0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaXBwbS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYu b3JnXSDku6PooaggSm9obiBNYXR0c3Nvbg0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTDmnIgyM+aX pSA1OjM3DQrmlLbku7bkuro6IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQrk uLvpopg6IFtpcHBtXSBkcmFmdC1pZXRmLWlwcG0taXBzZWMtMDEgcmV2aWV3DQoNCg0KDQpIaSwN Cg0KDQoNCkkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLTAxLCBJIHRoaW5rIHRoZSBp c3N1ZSBpcyBpbXBvcnRhbnQsIGFuZCBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBhIGdvb2Qgc3Rh cnQuIEkgZG8gaG93ZXZlciBoYXZlIHNvbWUgdGhlIGRvdWJ0cyByZWdhcmRpbmcgdGhlIHN1Z2dl c3RlZCBzb2x1dGlvbiB0byBleHRyYWN0IGtleWluZyBtYXRlcmlhbCBmcm9tIElQc2VjLg0KDQoN Cg0KSGVyZSBhcmUgbXkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLg0KDQoNCg0KQmVzdCBSZWdh cmRzDQoNCkpvaG4NCg0KDQoNCg0KDQoNCg0KQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1pcHBtLWlw c2VjLTAxDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpJbiBnZW5lcmFsIEkgdGhpbmsgdGhlIGFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24gY291bGQg YmUgY2xlYXJlciBpbiB3aGF0IHRoZSBwcm9ibGVtcyBhbmQgdXNlIGNhc2VzIGFyZSBhbmQgd2hh dCB0aGUgZG9jdW1lbnQgdHJpZXMgdG8gYWNoaWV2ZS4gRS5nLiBkbyB0aGUgZG9jdW1lbnQgd2Fu dCB0byBtZWFzdXJlIHRoZSBwZXJmb3JtYW5jZSBvZiBJUHNlYyBvciB1c2UgSVBzZWMgZm9yIHBy b3RlY3Rpb24sIG9yIGJvdGguIFdoYXQgYXJlIHRoZSBwcm9ibGVtcywgaWYgYW55LCBvZiBqdXN0 IHNlbmRpbmcgTy9UV0FNUCBvdmVyIHRoZSBleGlzdGluZyBJUHNlYyB0dW5uZWw/DQoNCkVtbWE6 IFRoZSBkcmFmdCBjdXJyZW50bHkgYWltcyB0byBjYXBpdGFsaXplIG9uIElQc2VjIGZvciBkZXJp dmluZyBrZXlzIGZvciBPL1RXQU1QLiBXZSB3aWxsIGZ1cnRoZXIgZWRpdCB0aGUgaW50cm9kdWN0 b3J5IHRleHQgdG8gYWRkcmVzcyB0aGlzIHBvaW50Lg0KDQoNCg0KDQoNCi0gW0Fic3RyYWN0XQ0K DQoiaXQgZXh0ZW5kcyB0aGUgYXBwbGljYWJpbGl0eSBvZiBPL1RXQU1QIHRvIG5ldHdvcmtzIHRo YXQgaGF2ZSBhbHJlYWR5IGRlcGxveWVkIElQc2VjIg0KDQoiVW5mb3J0dW5hdGVseSwgaG93ZXZl ciwgc3RhbmRhcmQgSVAgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgc2VjdXJpdHkgbWVjaGFuaXNt cyBjYW5ub3QgYmUgcmVhZGlseSB1c2VkIHdpdGggSVBzZWMuIg0KDQoNCg0KVGhpcyBnaXZlcyB0 aGUgaWRlYSB0aGF0IHlvdSBjYW5ub3QgdXNlIE8vVFdBTVAgd2l0aCBJUHNlYywgYnV0IHRoaXMg aXMgb2YgY291cnNlIG5vdCB0cnVlLiBZb3UgY2FuIGUuZy4gc2VuZCBPL1RXQU1QIG92ZXIgSVBz ZWMsIGFuZCBkZXBlbmRpbmcgb24gdGhlIElQc2VjIHNlY3VyaXR5IHBvbGljeSBkYXRhYmFzZSAo U1BEKSB5b3UgY2FuIHNlbmQgTy9UV0FNUCBvdXRzaWRlIG9mIHRoZSBJUHNlYyB0dW5uZWwuDQoN CkVtbWE6IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuIFRoaXMgd2FzIG5vdCBvdXIgaW50ZW50aW9u LiBJbmRlZWQgTy9UV0FNUCBzZWN1cml0eSBhbmQgSVBzZWMgY2FuIGJlIGRlcGxveWVkIGFuZCBy dW4gc2VwYXJhdGVseS4gQnV0IGdpdmVuIHRoYXQgdGhlIGN1cnJlbnRseSBzdGFuZGFyZGl6ZWQg Ty9UV0FNUCBzZWN1cml0eSBtZWNoYW5pc21zIG9ubHkgc3VwcG9ydCBwcmUtc2hhcmVkIGtleSBt b2RlLCBsYXJnZSBzY2FsZSBkZXBsb3ltZW50IGFuZCB1c2UgaXMgaGluZGVyZWQgc2lnbmlmaWNh bnRseSBhcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LiBEZXBsb3ltZW50IG9mIOKAnHNoYXJlZCBz ZWNyZXRz4oCdIGZvciBtYXNzaXZlIGVxdWlwbWVudCBpbnN0YWxsYXRpb24gaXMgbm90IHRoZSBi ZXN0IGlkZWEgYWZ0ZXIgYWxsLCBJIGhvcGUgeW91IGFncmVlIHdpdGggdGhhdC4gV2Ugd2lsbCBl ZGl0IHRoZSB0ZXh0IHRvIGFkZHJlc3MgdGhpcy4NCg0KDQoNCg0KDQotIFtTZWN0aW9uIDFdDQoN CiJJbiBwYXJ0aWN1bGFyLCB3ZSBub3RlIHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyeSB0byB1c2Ug ZGlzdGluY3Qga2V5cyBpbiBPV0FNUC1Db250cm9sIGFuZCBPV0FNUC1UZXN0IGxheWVycy4gIE9u ZSBrZXkgZm9yIGVuY3J5cHRpb24gYW5kIGFub3RoZXIgZm9yIGF1dGhlbnRpY2F0aW9uIGlzIHN1 ZmZpY2llbnQgZm9yIGJvdGggQ29udHJvbCBhbmQgVGVzdCBsYXllcnMuICBUaGlzIG9idmlhdGVz IHRoZSBuZWVkIHRvIGdlbmVyYXRlIHR3byBrZXlzIGZvciBlYWNoIGxheWVyIGFuZCByZWR1Y2Vz IHRoZSBjb21wbGV4aXR5IG9mIE8vVFdBTVAgcHJvdG9jb2xzIGluIGFuIElQc2VjIGVudmlyb25t ZW50LiAgVGhpcyBvYnNlcnZhdGlvbiBjb21lcyBmcm9tIHRoZSBmYWN0IHRoYXQgc2VwYXJhdGUg c2Vzc2lvbiBrZXlzIGluIHRoZSBPV0FNUC1Db250cm9sIGFuZCBPV0FNUC1UZXN0IGxheWVycyB3 ZXJlIGRlc2lnbmVkIGZvciBwcmV2ZW50aW5nIHJlZmxlY3Rpb24gYXR0YWNrcyB3aGVuIGVtcGxv eWluZyB0aGUgY3VycmVudCBtZWNoYW5pc20uIg0KDQoNCg0KSSBhc3N1bWUgTy9UV0FNUCB1c2Vz IGRpZmZlcmVudCBrZXlzIGFzIGlzIGl0IGJhZCBzZWN1cml0eSBkZXNpZ24gdG8gdXNlIHRoZSBz YW1lIGtleSBmb3IgdHdvIGRpZmZlcmVudCBwdXJwb3Nlcy4gVXNpbmcgdGhlIHNhbWUga2V5IHR3 aWNlIG1heSBsZWFkcyBhIG51bWJlciBvZiBzZWN1cml0eSBwcm9ibGVtcw0KDQotIEl0IGVhc2ls eSBjYXVzZXMgc28gY2FsbGVkICJ0d28tdGltZSBwYWRzIiB3ZXJlIHRoZSBjb25maWRlbnRpYWxp dHkgaXMgdG90YWxseSBjb21wcm9taXNlZC4NCg0KLSBGb3Igc29tZSBhbGdvcml0aG1zIHRoZSBp bnRlZ3JpdHkgbWF5IGJlIGNvbXByb21pc2VkLg0KDQotIElmIG9uZSB1c2Ugb2YgdGhlIGtleXMg aGFzIGEgY3J5cHRvZ3JhcGhpYyB3ZWFrbmVzcyBzbyB0aGFuIGFuIGF0dGFja2VyIGNhbiByZWNv dmVyIHRoZSBrZXksIHRoZSBhdHRhY2tlciBoYXMgdGhlIHVzZSB0aGF0IGtleSB0byBhdHRhY2sg Ym90aCB1c2VzIG9mIHRoZSBrZXkuDQoNCi0gSXQgZ2l2ZXMgYW4gYXR0YWNrZXIgdHdpY2UgYXMg bXVjaCBtYXRlcmlhbCAocHJvdGVjdGVkIHRyYWZmaWMpIHRvIHdvcmsgd2l0aC4NCg0KSSB0aGVy ZWZvcmUgc3Ryb25nbHkgcmVjb21tZW5kcyBhZ2FpbnN0IHVzaW5nIHRoZSBzYW1lIGtleSB0d2lj ZSB1bmxlc3MgeW91IG11c3QsIGFuZCBpbiB0aGlzIGNhc2Ugd2UgZG8gbm90Lg0KDQpFbW1hOiBX ZWxsLCB0aGUgZHJhZnQgZG9lcyBub3QgZXhjbHVkZSB0aGUgdXNlIG9mIGRpc3RpbmN0IGtleXMu IEFjdHVhbGx5IHRoZXJlIGFyZSB0aHJlZSBvcHRpb25zIChiYXNpYyArIDIgYWx0ZXJuYXRpdmVz KSBpbiB0aGUgZHJhZnQgYW5kIHdlIGhhdmUgYWxyZWFkeSBjYWxsZWQgZm9yIGFjdGl2ZSBkaXNj dXNzaW9uIGluIHRoZSBXRyBvbiB3aGljaCBvbmUgaXMgYmV0dGVyLCBhbmQgd2UgYXBwcmVjaWF0 ZSBvcGVuaW5nIHRoZSB0ZWNobmljYWwgZGlzY3Vzc2lvbiBvbiB0aGlzIG1hdHRlci4gVGhlIHRo cmVhdHMgYWJvdmUgY2FuIGJlIGNvbnNpZGVyZWQgd2hlbiBkZXRlcm1pbmluZyB3aGljaCBvcHRp b24gc2hvdWxkIGJlIHN0YW5kYXJkaXplZC4NCg0KDQoNCi0gW1NlY3Rpb24gMy4xXQ0KDQpUaGUg U2VydmVyLVN0YXJ0IG1lc3NhZ2Ugd2l0aCBTZXJ2ZXItSVYgaXMgbWlzc2luZyBmcm9tIHRoZSB0 ZXh0Lg0KDQpTdWdnZXN0aW9uOg0KDQoiSW4gdGhlIGF1dGhlbnRpY2F0ZWQgYW5kIGVuY3J5cHRl ZCBtb2RlcywgYWxsIGZ1cnRoZXIgY29tbXVuaWNhdGlvbiBpcyBlbmNyeXB0ZWQgdXNpbmcgdGhl IEFFUyBTZXNzaW9uLWtleSBhbmQgYXV0aGVudGljYXRlZCB3aXRoIHRoZSBITUFDIFNlc3Npb24t a2V5LiAgQWZ0ZXIgcmVjZWl2aW5nIFNldC1VcC1SZXNwb25zZSB0aGUgc2VydmVyIHJlc3BvbmRz IHdpdGggYSBTZXJ2ZXItU3RhcnQgbWVzc2FnZSBjb250YWluaW5nIFNlcnZlci1JVi4gVGhlIGNs aWVudCBlbmNyeXB0cyBldmVyeXRoaW5nIGl0IHRyYW5zbWl0cyB0aHJvdWdoIHRoZSBqdXN0LWVz dGFibGlzaGVkIE8vVFdBTVAtQ29udHJvbCBjb25uZWN0aW9uIHVzaW5nIHN0cmVhbSBlbmNyeXB0 aW9uIHdpdGggQ2xpZW50LUlWIGFzIHRoZSBJVi4iDQoNCkVtbWE6IE9LIHdpdGggdGhpcyBzdWdn ZXN0aW9uLg0KDQoNCg0KLSBbU2VjdGlvbiA0XQ0KDQpJIHRoaW5rICJJUHNlYyBTQSIgaXMgb2xk IHRlcm1pbm9sb2d5IGZvciBJS0UodjEpLCBhbGwgb2NjdXJyZW5jZXMgc2hvdWxkIGJlIGNoYW5n ZWQgdG8gIkNoaWxkIFNBIi4NCg0KRW1tYTogT0sgd2l0aCB0aGlzIHN1Z2dlc3Rpb24uDQoNCg0K DQoNCg0KLSBbU2VjdGlvbiA0XQ0KDQoiVGhlcmVmb3JlLCBldmVuIGlmIHRoZSBwZWVycyBjaG9v c2UgdG8gb3B0IGZvciB0aGUgdW5hdXRoZW50aWNhdGVkIG1vZGUsIElQc2VjIGludGVncml0eSBw cm90ZWN0aW9uIGlzIGV4dGVuZGVkIHRvIE8vVFdBTVAuDQoNCg0KDQpJIHRoaW5rIHRoZSBkb2N1 bWVudCB3b3VsZCBiZSBpbXByb3ZlZCBieSBkaXNjdXNzaW5nIHRoaXMgYW5kIG90aGVyIG9wdGlv bnM6DQoNCg0KDQpPL1RXQU1QIHVuYXV0aGVudGljYXRlZCBvdmVyIGV4aXN0aW5nIENoaWxkIFNB IHdpdGggaW50ZWdyaXR5Lg0KDQpPL1RXQU1QIHVuYXV0aGVudGljYXRlZCBvdmVyIGV4aXN0aW5n IENoaWxkIFNBIHdpdGggZW5jcnlwdGlvbi4NCg0KTy9UV0FNUCB1bmF1dGhlbnRpY2F0ZWQgb3Zl ciBleGlzdGluZyBDaGlsZCBTQSB3aXRoIGVuY3J5cHRpb24gYW5kIGludGVncml0eS4NCg0KTy9U V0FNUCB1bmF1dGhlbnRpY2F0ZWQgb3ZlciBuZXcgQ2hpbGQgU0Egd2l0aCBlbmNyeXB0aW9uIGFu ZCBvciBpbnRlZ3JpdHkuDQoNCg0KDQppbiBhIHNlcGFyYXRlIHNlY3Rpb24gYmVmb3JlIHRoZSBz ZWN0aW9uIG9uIGV4dHJhY3Rpbmcga2V5aW5nIG1hdGVyaWFsLiBJdCBtYXkgdmVyeSB3ZWxsIGJl IHRoZSBjYXNlIHRoYXQgTy9UV0FNUCB1bmF1dGhlbnRpY2F0ZWQgb3ZlciB0aGUgZXhpc3Rpbmcg Q2hpbGQgU0EgZnVsZmlsbHMgdGhlIHVzZXIncyBzZWN1cml0eSByZXF1aXJlbWVudHMuDQoNCkVt bWE6IFRoZSBvcHRpb25zIGxpc3RlZCBhYm92ZSBleGlzdGVkLiBCdXQgaW4gdGhpcyBjYXNlLCBP L1RXQU1QIGxheWVyIHNob3VsZCBvYnRhaW4gdGhlIGluZm9ybWF0aW9uIGFib3V0IElQc2VjIGxh eWVyIGZpcnN0IChlLmcuIENoaWxkIFNBIHdpdGggaW50ZWdyaXR5IGFuZC9vciBlbmNyeXB0aW9u KS4gVGhlIGludGVyYWN0aW9uIGJldHdlZW4gTy9UV0FNUCBsYXllciBhbmQgSVBzZWMgbGF5ZXIg d2lsbCBpbmNyZWFzZS4NCg0KDQoNCg0KDQotIFtTZWN0aW9uIDMuNF0NCg0KIklmIHRoZSBBSCBw cm90b2NvbCBpcyB1c2VkLCBJUCBwYWNrZXRzIGFyZSB0cmFuc21pdHRlZCBpbiBwbGFpbnRleHQu IFRoZSBhdXRoZW50aWNhdGlvbiBwYXJ0IGNvdmVycyB0aGUgZW50aXJlIHBhY2tldC4gIFNvIGFs bCB0ZXN0IGluZm9ybWF0aW9uLCBzdWNoIGFzIFVEUCBwb3J0IG51bWJlciwgYW5kIHRoZSB0ZXN0 IHJlc3VsdHMgd2lsbCBiZSB2aXNpYmxlIHRvIGFueSBhdHRhY2tlciwgd2hpY2ggY2FuIGludGVy Y2VwdCB0aGVzZSB0ZXN0IHBhY2tldHMsIGFuZCBpbnRyb2R1Y2UgZXJyb3JzIG9yIGZvcmdlIHBh Y2tldHMgdGhhdCBtYXkgYmUgaW5qZWN0ZWQgZHVyaW5nIHRoZSB0cmFuc21pc3Npb24uICBJbiBv cmRlciB0byBhdm9pZCB0aGlzIGF0dGFjaywgdGhlIHJlY2VpdmVyIG11c3QgdmFsaWRhdGUgdGhl IGludGVncml0eSBvZiB0aGVzZSBwYWNrZXRzIHdpdGggdGhlIG5lZ290aWF0ZWQgc2VjcmV0IGtl eS4iDQoNCg0KDQpBcyB0aGUgcGFja2VnZXMgYXJlIGF1dGhlbnRpY2F0ZWQgYW4gYXR0YWNrZXIg Y2Fubm90IGZvcmdlIG9yIGluamVjdCBlcnJvcnMuICBBbmQgYXMgdGhlIHBhY2thZ2VzIGFyZSBu b3QgZW5jcnlwdGVkLCByZWFkaW5nIHRoZSBpbmZvcm1hdGlvbiBjYW5ub3QgYmUgY29uc2lkZXJl ZCBhbiBhdHRhY2suDQoNCg0KDQpJIHN1Z2dlc3QgZGVsZXRpbmcgIiB0byBhbnkgYXR0YWNrZXIs IHdoaWNoIGNhbiBpbnRlcmNlcHQgdGhlc2UgdGVzdCBwYWNrZXRzLCBhbmQgaW50cm9kdWNlIGVy cm9ycyBvciBmb3JnZSBwYWNrZXRzIHRoYXQgbWF5IGJlIGluamVjdGVkIGR1cmluZyB0aGUgdHJh bnNtaXNzaW9uLiAgSW4gb3JkZXIgdG8gYXZvaWQgdGhpcyBhdHRhY2ssIHRoZSByZWNlaXZlciBt dXN0IHZhbGlkYXRlIHRoZSBpbnRlZ3JpdHkgb2YgdGhlc2UgcGFja2V0cyB3aXRoIHRoZSBuZWdv dGlhdGVkIHNlY3JldCBrZXkuDQoNCkVtbWE6IE9LIHdpdGggdGhpcyBzdWdnZXN0aW9uLg0KDQoN Cg0KDQoNCi0gW1NlY3Rpb24gMy40LCBTZWN0aW9uIDRdDQoNCiJJZiBFU1AgaXMgdXNlZCwgSVAg cGFja2V0cyBhcmUgZW5jcnlwdGVkIg0KDQoiV2hlbiB1c2luZyBFU1AsIGFsbCBJUCBwYWNrZXRz IGFyZSBlbmNyeXB0ZWQiDQoNCg0KDQpUaGlzIGlzIG5vdCB0cnVlIGFzIEVTUCBjYW4gYmUgdXNl ZCB3aXRoIG9ubHkgaW50ZWdyaXR5IHByb3RlY3Rpb24gKE5VTEwgY2lwaGVyKS4gSW4gZmFjdCwg SSB0aGluayB0aGlzIGlzIGZhciBtb3JlIGNvbW1vbiB0aGFuIHVzaW5nIEFILiBJbnN0ZWFkIG9m IHN0YXJ0IHRhbGtpbmcgYWJvdXQgQUgsIEkgdGhpbmsgdGhlIGRyYWZ0IGNvdWxkIGxpc3QgdGhl IHRocmVlIGRpZmZlcmVudCBFU1Agb3B0aW9ucyAoaW50ZWdyaXR5IGFuZC9vciBlbmNyeXB0aW9u KSBhbmQgdGhlbiBoYXZlIGEgbm90ZSBzdGF0aW5nIHRoYXQgZm9yIEFIIGhhdmUgc2ltaWxhciBw cm9wZXJ0aWVzIGFzIEVTUCB3aXRoIE5VTEwgY2lwaGVyLg0KDQpFbW1hOiBPSyB3aXRoIHRoaXMg c3VnZ2VzdGlvbi4NCg0KDQoNCg0KDQotIFtTZWN0aW9uIDRdDQoNCkZyb20gYSBzZWN1cml0eSBw ZXJzcGVjdGl2ZSBpdCB3b3VsZCBiZSB2ZXJ5IGJhZCB0byBhbGxvdyBleHRyYWN0aW9uIG9mIFNL RVlTRUVEIG9yIEtFWU1BVC4gVGhleSBjb3VsZCBiZSB1c2VkIHRvIHBhc3NpdmVseSBlYXZlc2Ry b3Agb24gdGhlIElQc2VjIHRyYWZmaWMgb3IgdG8gYWx0ZXIvaW5qZWN0IG1lc3NhZ2VzLiBFdmVu IGlmIHdlIHRydXN0IHRoZSBPL1RXQU1QIGFwcGxpY2F0aW9uIHRvIG5vdCBiZSBtYWxpY2lvdXMs IHVzZSBvZiB0aGUgc2FtZSBrZXkgaW4gYW5vdGhlciBhcHBsaWNhdGlvbiBtYXkgY2F1c2Ugc2Vj dXJpdHkgcHJvYmxlbXMgc3VjaCBhcyB0d28tdGltZSBwYWQsIHdoaWNoIGNvbXBsZXRlbHkgY29t cHJvbWlzZXMgdGhlIGNvbmZpZGVudGlhbGl0eS4NCg0KDQoNCkEgc2VjdXJlIHNvbHV0aW9uIHdv dWxkIGJlIHRoYXQgdGhlIElQc2VjIEFQSSByZXR1cm5zIGEga2V5IHRoYXQgaXMgZGVyaXZlZCBm cm9tIHNvbWUgb2YgSVBzZWMga2V5aW5nIG1hdGVyaWFsLiBFLmcuIGEgbmV3ICJLRVlNQVQiIGRl cml2ZWQgdXNpbmcgc29tZSBuZXcgcmFuZG9tIG1hdGVyaWFsIGluc3RlYWQgb2YgKE5pLE5yKSwg ZS5nLjoNCg0KDQoNClNoYXJlZCBzZWNyZXQgPSBwcmYrKCBTS19kLCBTSUQgKQ0KDQoNCg0KT3Ig YSBrZXkgZGVyaXZlZCBmcm9tIEtFWU1BVDoNCg0KDQoNClNoYXJlZCBzZWNyZXQgPSBQUkYoIEtF WU1BVCwgU0lEICkNCg0KDQoNCkkgc3Ryb25nbHkgc3VnZ2VzdCByZW1vdmluZyB0aGUgb3B0aW9u cyB0aGF0IGV4cG9zZXMgdGhlIElQc2VjIGtleWluZyBtYXRlcmlhbCwgb25seSBrZWVwaW5nIHNl Y3VyZSBvcHRpb25zLCBhbmQgYWRkaW5nIHRleHQgZGVzY3JpYmluZyB0aGF0IGl0IGlzIHRoZSBJ UHNlYyBpbXBsZW1lbnRhdGlvbiB0aGF0IHBlcmZvcm1zIHRoZSBrZXkgZGVyaXZhdGlvbnMuDQoN CkVtbWE6IFdlIGFncmVlIHRoYXQgZnJvbSBhIHNlY3VyaXR5IHBvdiBkZXJpdmluZyBzaGFyZWQg a2V5IGF0IElQc2VjIGlzIGEgYmV0dGVyIGNob2ljZS4gV2UgY2FuIGNvbnNpZGVyIHRoYXQgaW4g bmV4dCB2ZXJzaW9uLg0KDQoNCg0KDQoNCi0gW1NlY3Rpb24gNF0NCg0KV2hpbGUgZXh0cmFjdGlu ZyBrZXlpbmcgbWF0ZXJpYWwgZnJvbSBJUHNlYyB3b3VsZCBiZSBuaWNlLCB0byBteSBrbm93bGVk Z2UgdGhlcmUgaXMgbm8gc3RhbmRhcmRpemVkIChvciBkZSBmYWN0byBzdGFuZGFyZCkgQVBJIHRv IGV4dHJhY3QgU0tFWVNFRUQsIFNLX2QsIEtFWU1BVCBvciBldmVuIFNQSSBmcm9tIGFuIElQc2Vj IGltcGxlbWVudGF0aW9uLiBUaGlzIHdhcyBldmVuIG9uZSBvZiB0aGUgcmVhc29ucyBJUHNlYyB3 YXMgbm90IGNob3NlbiBhcyB0aGUgZGVmYXVsdCBzZWN1cml0eSBwcm90b2NvbCBmb3IgTy9UV0FN UC4gWW91IGNvdWxkIG9mIGNvdXJzZSBkbyBpdCB3aXRoIGEgbmV3IHByb3ByaWV0YXJ5IGltcGxl bWVudGF0aW9uLCBidXQgdGhhdCBraW5kIG9mIGJlYXRzIHNvbWUgb2YgdGhlIHB1cnBvc2UgZnJv bSB0aGUgQWJzdHJhY3QgImdhaW5pbmcgcG9wdWxhcml0eSBpbiBzZXZlcmFsIGRlcGxveW1lbnQg c2NlbmFyaW9zIi4NCg0KDQoNCldvcmsgb24gYW4gSVBzZWMgQVBJIHN0YXJ0ZWQgYSBjb3VwbGUg YSB5ZWFycyBhZ28gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1idG5zLWlw c2VjLWFwaXJlcS0wMA0KDQpidXQgZGllZCwgYW5kIGV2ZW4gdGhhdCB3b3JrIGRpZCBwcm9oaWJp dCBleHRyYWN0aW9uIG9mIGtleWluZyBtYXRlcmlhbCBhbmQgZGlzY291cmFnZWQgdGhlIGV4dHJh Y3Rpb24gb2YgU1BJIGFzIHRoZSBTUEkgbWlnaHQgY2hhbmdlLg0KDQoNCg0KSGFzIHRoZSBBUEkg cHJvcG9zYWxzIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBpcHNlY21lIHdvcmtpbmcgZ3JvdXA/DQoN CkVtbWE6IFdlIHJlY2VpdmVkIHRoaXMgY29tbWVudCBhdCB0aGUgbGFzdCBtZWV0aW5nIChJIHRo aW5rIGl0IHdhcyBZb2F2IHdobyBjb21tZW50ZWQgb24gdGhhdCkuIFdlIGJlbGlldmUgdGhhdCB0 aGlzIGlzIGluIGZhY3QgaW1wbGVtZW50YXRpb24tZGVwZW5kZW50LiBGb3IgZXhhbXBsZSwgZm9y IHRob3NlIHdpdGggZXhpc3RpbmcgSVBzZWMgYW5kIE8vVFdBTVAgaW1wbGVtZW50YXRpb25zIHRo aXMgc2hvdWxkIG5vdCBiZSBhIGJsb2NraW5nIHBvaW50LiBJZiB0aGVyZSB3YXMgYSDigJxzdGFu ZGFyZOKAnSBBUEksIHRoaXMgcHJvdG9jb2wgY291bGQgYmVuZWZpdC4gQnV0IHdoYXQgd2XigJly ZSBpbnRlcmVzdGVkIHByaW1hcmlseSBoZXJlIGlzIE8vVFdBTVAgZGVwbG95bWVudCBhdCBsYXJn ZSBzY2FsZSBhbmQgZm9yIG5ldHdvcmtzIHRoYXQgaGF2ZSBhbHJlYWR5IGRlcGxveWVkIElQc2Vj Lg0KDQoNCg0KDQoNCg0KDQotIFtTZWN0aW9uIDRdDQoNCkkgdGhpbmsgdGhlIGFwcHJvYWNoIGlu IFNlY3Rpb24gNCB3aXRoIGV4dHJhY3Rpbmcga2V5aW5nIG1hdGVyaWFsIHdvdWxkIG9ubHkgd29y ayB3aXRoIGEgcHJvcHJpZXRhcnkgSVBzZWMgaW1wbGVtZW50YXRpb24gYW5kIG1vZGlmaWNhdGlv bnMgKGFkZGluZyBuZXcgZmllbGRzKSB0byBPL1RXQU1QLg0KDQoNCg0KSGF2ZSBhcHByb2FjaGVz IHRoYXQgZG8gbm90IHJlcXVpcmUgZXh0cmFjdGluZyBrZXlpbmcgaW5mb3JtYXRpb24gYmVlbiBj b25zaWRlcmVkPw0KDQpFbW1hOiBJIHRoaW5rIHdlIGNvdWxkIGRpc2N1c3MgdGhpcyBpbiBWYW5j b3V2ZXIuIEluIHRoZSBtZWFudGltZSwgZG8geW91IGhhdmUgdGV4dCB0byBzdWdnZXN0Pw0KDQoN Cg0KDQoNCklmIHRoZSBDaGlsZCBTQSBpcyBlbmNyeXB0ZWQsIGEgc2ltcGxlciBhcHByb2FjaCB3 b3VsZCBiZSB0byB0cmFuc2ZlciB0aGUgTy9UV0FNUCBzaGFyZWQgc2VjcmV0IGluIGEgc2ltaWxh ciBtYW5uZXIgYXMgdGhlIE8vVFdBTVAgc2Vzc2lvbiBrZXksIGUuZy4gaW4gdGhlIEtleUlEIGZp ZWxkLiBUaGlzIHdvdWxkIGp1c3QgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSBmdW5jdGlvbiBpbiB0 aGUgTy9UV0FNUCB0aGF0IHJlY2VpdmVzIHRoZSBzaGFyZWQgc2VjcmV0LCBhbmQgbm8gbW9kaWZp Y2F0aW9ucyB0byBJUHNlYy4NCg0KDQoNCkF0IGxlYXN0IGlmIHRoZSBDaGlsZCBTQSBpcyBpbnRl Z3JpdHkgcHJvdGVjdGVkLCBvbmUgYXBwcm9hY2ggd291bGQgYmUgdG8gdXNlIERpZmZpZS1IZWxs bWFuIGluIE8vVFdBTVAuIFRoaXMgd291bGQgc3RpbGwgcmVxdWlyZSBuZXcgTy9UV0FNUCBmaWVs ZHMgYnV0IHN0aWxsIGJlIGVhc2llciB0aGFuIHRoZSBjdXJyZW50IHN1Z2dlc3Rpb24gYXMgaXQg ZG9lcyBub3QgcmVxdWlyZSBhbnkgY2hhbmdlcyB0byBJUHNlYy4NCg0KDQoNCkEgcHJvYmxlbSBp cyBzdGlsbCB0aGUgbGFjayBvZiBBUEkgdG8gZmluZCBvdXQgd2hldGhlciBlbmNyeXB0aW9uIG9y IGludGVncml0eSBpcyBpbiB1c2UuDQoNCg0KDQoNCg0KTWlub3IgZWRpdG9yaWFsIGNvbW1lbnRz IG9uIGRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wMQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCi0gW3MzLjFd ICJPV0FNUC1Db250cm9sIGNvbW1hbmRzIiAtPiAiTy9UV0FNUC1Db250cm9sIGNvbW1hbmRzIg0K DQoNCg0KLSBbczRdICJtdXN0IGJlIGdlbmVyYXRlZCBmaXJzdGx5IiAtPiAibXVzdCBiZSBnZW5l cmF0ZWQgZmlyc3QiDQoNCg0KDQotIFtzNF0gInNlc3Npb24gSUQgaXMgaXMgdGhlIg0KDQpFbW1h OiBPSyB3aXRoIHRoZXNlIGVkaXRvcmlhbCBjb21tZW50cy4NCg0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpKT0hOIE1BVFRTU09ODQoNCk1TYyBFbmdpbmVlcmluZyBQaHlzaWNz LCBNU2MgQnVzaW5lc3MgQWRtaW5pc3RyYXRpb24gYW5kIEVjb25vbWljcyBTZW5pb3IgUmVzZWFy Y2hlciwgU2VjdXJpdHkNCg0KDQoNCkVyaWNzc29uIEFCDQoNClNlY3VyaXR5IFJlc2VhcmNoDQoN CkbDpHLDtmdhdGFuIDYNCg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuDQoNClBob25lICs0 NiAxMCA3MSA0MyA1MDENCg0KU01TL01NUyArNDYgNzYgMTEgNTMgNTAxDQoNCmpvaG4ubWF0dHNz b24gYXQgZXJpY3Nzb24uY29tDQoNCnd3dy5lcmljc3Nvbi5jb208aHR0cDovL3d3dy5lcmljc3Nv bi5jb20+DQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCmlwcG0gbWFpbGluZyBsaXN0DQoNCmlwcG1AaWV0Zi5vcmc8bWFpbHRv OmlwcG1AaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBwbQ0KDQo= --_000_CE92CE3FCF47934CBAE2CCECE119606C6338C67Bnkgeml507mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5 OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+ac rCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv5paH 5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uQ2hhcjANCgl7bXNvLXN0 eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRleHQtanVzdGlmeS10 cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGkgSm9obiwgYWxsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5NYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldyEgUGxlYXNlIHNlZSB0aGUg cmVwbHkgYXMgYmVsbG93Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXN0IFJlZ2FyZHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+RW1tYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPi0tLS0tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPumCruS7tuWO n+S7tjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS08YnI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij46IDxhIGhyZWY9Im1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmciPg0KaXBwbS1ib3VuY2Vz QGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZyI+bWFp bHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OuWui+S9kyI+5Luj6KGoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gSm9obiBNYXR0 c3Nvbjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7lj5HpgIHm l7bpl7Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjogMjAxMzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk65a6L5L2TIj7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjEwPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPuaciDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+MjM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+5pelPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj4NCiA1OjM3PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTrlrovkvZMiPuaUtuS7tuS6ujwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OiA8YSBo cmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyI+DQppcHBtQGlldGYub3JnPC9hPjxicj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7kuLvpopg8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjogW2lwcG1dIGRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wMSByZXZpZXc8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSByZXZpZXdl ZCBkcmFmdC1pZXRmLWlwcG0taXBzZWMtMDEsIEkgdGhpbmsgdGhlIGlzc3VlIGlzIGltcG9ydGFu dCwgYW5kIEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIGEgZ29vZCBzdGFydC4gSSBkbyBob3dldmVy IGhhdmUgc29tZSB0aGUgZG91YnRzIHJlZ2FyZGluZyB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9uIHRv IGV4dHJhY3Qga2V5aW5nIG1hdGVyaWFsIGZyb20gSVBzZWMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5IZXJlIGFyZSBteSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5CZXN0IFJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Db21tZW50cyBvbiBkcmFmdC1p ZXRmLWlwcG0taXBzZWMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGdlbmVyYWwgSSB0aGluayB0aGUgYWJzdHJhY3Qg YW5kIEludHJvZHVjdGlvbiBjb3VsZCBiZSBjbGVhcmVyIGluIHdoYXQgdGhlIHByb2JsZW1zIGFu ZCB1c2UgY2FzZXMgYXJlIGFuZCB3aGF0IHRoZSBkb2N1bWVudCB0cmllcyB0byBhY2hpZXZlLiBF LmcuIGRvIHRoZSBkb2N1bWVudCB3YW50IHRvIG1lYXN1cmUgdGhlIHBlcmZvcm1hbmNlIG9mIElQ c2VjIG9yIHVzZQ0KIElQc2VjIGZvciBwcm90ZWN0aW9uLCBvciBib3RoLiBXaGF0IGFyZSB0aGUg cHJvYmxlbXMsIGlmIGFueSwgb2YganVzdCBzZW5kaW5nIE8vVFdBTVAgb3ZlciB0aGUgZXhpc3Rp bmcgSVBzZWMgdHVubmVsPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbW1h OiBUaGUgZHJhZnQgY3VycmVudGx5IGFpbXMgdG8gY2FwaXRhbGl6ZSBvbiBJUHNlYyBmb3IgZGVy aXZpbmcga2V5cyBmb3IgTy9UV0FNUC4gV2Ugd2lsbCBmdXJ0aGVyIGVkaXQgdGhlIGludHJvZHVj dG9yeSB0ZXh0IHRvIGFkZHJlc3MgdGhpcyBwb2ludC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIFtBYnN0cmFjdF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7aXQgZXh0 ZW5kcyB0aGUgYXBwbGljYWJpbGl0eSBvZiBPL1RXQU1QIHRvIG5ldHdvcmtzIHRoYXQgaGF2ZSBh bHJlYWR5IGRlcGxveWVkIElQc2VjJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O1VuZm9ydHVuYXRlbHks IGhvd2V2ZXIsIHN0YW5kYXJkIElQIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IHNlY3VyaXR5IG1l Y2hhbmlzbXMgY2Fubm90IGJlIHJlYWRpbHkgdXNlZCB3aXRoIElQc2VjLiZxdW90OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBnaXZlcyB0aGUgaWRlYSB0aGF0IHlvdSBjYW5ub3QgdXNl IE8vVFdBTVAgd2l0aCBJUHNlYywgYnV0IHRoaXMgaXMgb2YgY291cnNlIG5vdCB0cnVlLiBZb3Ug Y2FuIGUuZy4gc2VuZCBPL1RXQU1QIG92ZXIgSVBzZWMsIGFuZCBkZXBlbmRpbmcgb24gdGhlIElQ c2VjIHNlY3VyaXR5IHBvbGljeSBkYXRhYmFzZSAoU1BEKSB5b3UgY2FuIHNlbmQgTy9UV0FNUCBv dXRzaWRlDQogb2YgdGhlIElQc2VjIHR1bm5lbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkVtbWE6IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuIFRoaXMgd2FzIG5vdCBvdXIgaW50 ZW50aW9uLiBJbmRlZWQgTy9UV0FNUCBzZWN1cml0eSBhbmQgSVBzZWMgY2FuIGJlIGRlcGxveWVk IGFuZCBydW4gc2VwYXJhdGVseS4gQnV0IGdpdmVuIHRoYXQgdGhlIGN1cnJlbnRseSBzdGFuZGFy ZGl6ZWQgTy9UV0FNUCBzZWN1cml0eSBtZWNoYW5pc21zDQogb25seSBzdXBwb3J0IHByZS1zaGFy ZWQga2V5IG1vZGUsIGxhcmdlIHNjYWxlIGRlcGxveW1lbnQgYW5kIHVzZSBpcyBoaW5kZXJlZCBz aWduaWZpY2FudGx5IGFzIG1lbnRpb25lZCBpbiB0aGUgZHJhZnQuIERlcGxveW1lbnQgb2Yg4oCc c2hhcmVkIHNlY3JldHPigJ0gZm9yIG1hc3NpdmUgZXF1aXBtZW50IGluc3RhbGxhdGlvbiBpcyBu b3QgdGhlIGJlc3QgaWRlYSBhZnRlciBhbGwsIEkgaG9wZSB5b3UgYWdyZWUgd2l0aCB0aGF0LiBX ZSB3aWxsIGVkaXQNCiB0aGUgdGV4dCB0byBhZGRyZXNzIHRoaXMuPG86cD48L286cD48L3NwYW4+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+LSBbU2VjdGlvbiAxXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtJbiBwYXJ0aWN1bGFy LCB3ZSBub3RlIHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyeSB0byB1c2UgZGlzdGluY3Qga2V5cyBp biBPV0FNUC1Db250cm9sIGFuZCBPV0FNUC1UZXN0IGxheWVycy4mbmJzcDsgT25lIGtleSBmb3Ig ZW5jcnlwdGlvbiBhbmQgYW5vdGhlciBmb3IgYXV0aGVudGljYXRpb24gaXMgc3VmZmljaWVudCBm b3IgYm90aCBDb250cm9sIGFuZCBUZXN0IGxheWVycy4mbmJzcDsNCiBUaGlzIG9idmlhdGVzIHRo ZSBuZWVkIHRvIGdlbmVyYXRlIHR3byBrZXlzIGZvciBlYWNoIGxheWVyIGFuZCByZWR1Y2VzIHRo ZSBjb21wbGV4aXR5IG9mIE8vVFdBTVAgcHJvdG9jb2xzIGluIGFuIElQc2VjIGVudmlyb25tZW50 LiZuYnNwOyBUaGlzIG9ic2VydmF0aW9uIGNvbWVzIGZyb20gdGhlIGZhY3QgdGhhdCBzZXBhcmF0 ZSBzZXNzaW9uIGtleXMgaW4gdGhlIE9XQU1QLUNvbnRyb2wgYW5kIE9XQU1QLVRlc3QgbGF5ZXJz IHdlcmUgZGVzaWduZWQgZm9yDQogcHJldmVudGluZyByZWZsZWN0aW9uIGF0dGFja3Mgd2hlbiBl bXBsb3lpbmcgdGhlIGN1cnJlbnQgbWVjaGFuaXNtLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+SSBhc3N1bWUgTy9UV0FNUCB1c2VzIGRpZmZlcmVudCBrZXlzIGFzIGlzIGl0IGJhZCBz ZWN1cml0eSBkZXNpZ24gdG8gdXNlIHRoZSBzYW1lIGtleSBmb3IgdHdvIGRpZmZlcmVudCBwdXJw b3Nlcy4gVXNpbmcgdGhlIHNhbWUga2V5IHR3aWNlIG1heSBsZWFkcyBhIG51bWJlciBvZiBzZWN1 cml0eSBwcm9ibGVtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIEl0IGVhc2lseSBjYXVzZXMgc28gY2FsbGVkICZxdW90 O3R3by10aW1lIHBhZHMmcXVvdDsgd2VyZSB0aGUgY29uZmlkZW50aWFsaXR5IGlzIHRvdGFsbHkg Y29tcHJvbWlzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gRm9yIHNvbWUgYWxnb3JpdGhtcyB0aGUgaW50ZWdyaXR5 IG1heSBiZSBjb21wcm9taXNlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIElmIG9uZSB1c2Ugb2YgdGhlIGtleXMg aGFzIGEgY3J5cHRvZ3JhcGhpYyB3ZWFrbmVzcyBzbyB0aGFuIGFuIGF0dGFja2VyIGNhbiByZWNv dmVyIHRoZSBrZXksIHRoZSBhdHRhY2tlciBoYXMgdGhlIHVzZSB0aGF0IGtleSB0byBhdHRhY2sg Ym90aCB1c2VzIG9mIHRoZSBrZXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gSXQgZ2l2ZXMgYW4gYXR0YWNrZXIgdHdp Y2UgYXMgbXVjaCBtYXRlcmlhbCAocHJvdGVjdGVkIHRyYWZmaWMpIHRvIHdvcmsgd2l0aC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+SSB0aGVyZWZvcmUgc3Ryb25nbHkgcmVjb21tZW5kcyBhZ2FpbnN0IHVzaW5nIHRoZSBz YW1lIGtleSB0d2ljZSB1bmxlc3MgeW91IG11c3QsIGFuZCBpbiB0aGlzIGNhc2Ugd2UgZG8gbm90 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RW1tYTogV2VsbCwgdGhlIGRyYWZ0 IGRvZXMgbm90IGV4Y2x1ZGUgdGhlIHVzZSBvZiBkaXN0aW5jdCBrZXlzLiBBY3R1YWxseSB0aGVy ZSBhcmUgdGhyZWUgb3B0aW9ucyAoYmFzaWMgJiM0MzsgMiBhbHRlcm5hdGl2ZXMpIGluIHRoZSBk cmFmdCBhbmQgd2UgaGF2ZSBhbHJlYWR5IGNhbGxlZCBmb3IgYWN0aXZlIGRpc2N1c3Npb24gaW4g dGhlDQogV0cgb24gd2hpY2ggb25lIGlzIGJldHRlciwgYW5kIHdlIGFwcHJlY2lhdGUgb3Blbmlu ZyB0aGUgdGVjaG5pY2FsIGRpc2N1c3Npb24gb24gdGhpcyBtYXR0ZXIuIFRoZSB0aHJlYXRzIGFi b3ZlIGNhbiBiZSBjb25zaWRlcmVkIHdoZW4gZGV0ZXJtaW5pbmcgd2hpY2ggb3B0aW9uIHNob3Vs ZCBiZSBzdGFuZGFyZGl6ZWQuPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBbU2VjdGlv biAzLjFdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRoZSBTZXJ2ZXItU3RhcnQgbWVzc2FnZSB3aXRoIFNlcnZlci1JViBp cyBtaXNzaW5nIGZyb20gdGhlIHRleHQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U3VnZ2VzdGlvbjo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ JnF1b3Q7SW4gdGhlIGF1dGhlbnRpY2F0ZWQgYW5kIGVuY3J5cHRlZCBtb2RlcywgYWxsIGZ1cnRo ZXIgY29tbXVuaWNhdGlvbiBpcyBlbmNyeXB0ZWQgdXNpbmcgdGhlIEFFUyBTZXNzaW9uLWtleSBh bmQgYXV0aGVudGljYXRlZCB3aXRoIHRoZSBITUFDIFNlc3Npb24ta2V5LiZuYnNwOyBBZnRlciBy ZWNlaXZpbmcgU2V0LVVwLVJlc3BvbnNlIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCBhIFNlcnZl ci1TdGFydA0KIG1lc3NhZ2UgY29udGFpbmluZyBTZXJ2ZXItSVYuIFRoZSBjbGllbnQgZW5jcnlw dHMgZXZlcnl0aGluZyBpdCB0cmFuc21pdHMgdGhyb3VnaCB0aGUganVzdC1lc3RhYmxpc2hlZCBP L1RXQU1QLUNvbnRyb2wgY29ubmVjdGlvbiB1c2luZyBzdHJlYW0gZW5jcnlwdGlvbiB3aXRoIENs aWVudC1JViBhcyB0aGUgSVYuJnF1b3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkVtbWE6IE9LIHdpdGggdGhpcyBzdWdnZXN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPi0gW1NlY3Rpb24gNF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSB0aGluayAmcXVvdDtJUHNlYyBTQSZxdW90 OyBpcyBvbGQgdGVybWlub2xvZ3kgZm9yIElLRSh2MSksIGFsbCBvY2N1cnJlbmNlcyBzaG91bGQg YmUgY2hhbmdlZCB0byAmcXVvdDtDaGlsZCBTQSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkVtbWE6IE9LIHdpdGggdGhpcyBzdWdnZXN0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIFtTZWN0aW9uIDRdPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZx dW90O1RoZXJlZm9yZSwgZXZlbiBpZiB0aGUgcGVlcnMgY2hvb3NlIHRvIG9wdCBmb3IgdGhlIHVu YXV0aGVudGljYXRlZCBtb2RlLCBJUHNlYyBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBpcyBleHRlbmRl ZCB0byBPL1RXQU1QLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSB0aGluayB0aGUgZG9jdW1l bnQgd291bGQgYmUgaW1wcm92ZWQgYnkgZGlzY3Vzc2luZyB0aGlzIGFuZCBvdGhlciBvcHRpb25z Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5PL1RXQU1QIHVuYXV0aGVudGljYXRlZCBvdmVy IGV4aXN0aW5nIENoaWxkIFNBIHdpdGggaW50ZWdyaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5PL1RXQU1QIHVuYXV0 aGVudGljYXRlZCBvdmVyIGV4aXN0aW5nIENoaWxkIFNBIHdpdGggZW5jcnlwdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Ty9UV0FNUCB1bmF1dGhlbnRpY2F0ZWQgb3ZlciBleGlzdGluZyBDaGlsZCBTQSB3aXRoIGVu Y3J5cHRpb24gYW5kIGludGVncml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Ty9UV0FNUCB1bmF1dGhlbnRpY2F0ZWQg b3ZlciBuZXcgQ2hpbGQgU0Egd2l0aCBlbmNyeXB0aW9uIGFuZCBvciBpbnRlZ3JpdHkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5pbiBhIHNlcGFyYXRlIHNlY3Rpb24gYmVmb3JlIHRoZSBzZWN0 aW9uIG9uIGV4dHJhY3Rpbmcga2V5aW5nIG1hdGVyaWFsLiBJdCBtYXkgdmVyeSB3ZWxsIGJlIHRo ZSBjYXNlIHRoYXQgTy9UV0FNUCB1bmF1dGhlbnRpY2F0ZWQgb3ZlciB0aGUgZXhpc3RpbmcgQ2hp bGQgU0EgZnVsZmlsbHMgdGhlIHVzZXIncyBzZWN1cml0eSByZXF1aXJlbWVudHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbW1hOiBUaGUgb3B0aW9ucyBsaXN0ZWQgYWJvdmUg ZXhpc3RlZC4gQnV0IGluIHRoaXMgY2FzZSwgTy9UV0FNUCBsYXllciBzaG91bGQgb2J0YWluIHRo ZSBpbmZvcm1hdGlvbiBhYm91dCBJUHNlYyBsYXllciBmaXJzdCAoZS5nLiBDaGlsZCBTQSB3aXRo IGludGVncml0eSBhbmQvb3IgZW5jcnlwdGlvbikuIFRoZSBpbnRlcmFjdGlvbg0KIGJldHdlZW4g Ty9UV0FNUCBsYXllciBhbmQgSVBzZWMgbGF5ZXIgd2lsbCBpbmNyZWFzZS48bzpwPjwvbzpwPjwv c3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBbU2VjdGlvbiAzLjRdPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZxdW90O0lmIHRoZSBBSCBwcm90b2NvbCBpcyB1c2VkLCBJUCBwYWNrZXRzIGFyZSB0cmFuc21p dHRlZCBpbiBwbGFpbnRleHQuIFRoZSBhdXRoZW50aWNhdGlvbiBwYXJ0IGNvdmVycyB0aGUgZW50 aXJlIHBhY2tldC4mbmJzcDsgU28gYWxsIHRlc3QgaW5mb3JtYXRpb24sIHN1Y2ggYXMgVURQIHBv cnQgbnVtYmVyLCBhbmQgdGhlIHRlc3QgcmVzdWx0cyB3aWxsIGJlIHZpc2libGUgdG8gYW55DQog YXR0YWNrZXIsIHdoaWNoIGNhbiBpbnRlcmNlcHQgdGhlc2UgdGVzdCBwYWNrZXRzLCBhbmQgaW50 cm9kdWNlIGVycm9ycyBvciBmb3JnZSBwYWNrZXRzIHRoYXQgbWF5IGJlIGluamVjdGVkIGR1cmlu ZyB0aGUgdHJhbnNtaXNzaW9uLiZuYnNwOyBJbiBvcmRlciB0byBhdm9pZCB0aGlzIGF0dGFjaywg dGhlIHJlY2VpdmVyIG11c3QgdmFsaWRhdGUgdGhlIGludGVncml0eSBvZiB0aGVzZSBwYWNrZXRz IHdpdGggdGhlIG5lZ290aWF0ZWQgc2VjcmV0IGtleS4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkFzIHRoZSBwYWNrZWdlcyBhcmUgYXV0aGVudGljYXRlZCBhbiBhdHRhY2tlciBjYW5u b3QgZm9yZ2Ugb3IgaW5qZWN0IGVycm9ycy4mbmJzcDsgQW5kIGFzIHRoZSBwYWNrYWdlcyBhcmUg bm90IGVuY3J5cHRlZCwgcmVhZGluZyB0aGUgaW5mb3JtYXRpb24gY2Fubm90IGJlIGNvbnNpZGVy ZWQgYW4gYXR0YWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSBzdWdnZXN0IGRlbGV0aW5n ICZxdW90OyB0byBhbnkgYXR0YWNrZXIsIHdoaWNoIGNhbiBpbnRlcmNlcHQgdGhlc2UgdGVzdCBw YWNrZXRzLCBhbmQgaW50cm9kdWNlIGVycm9ycyBvciBmb3JnZSBwYWNrZXRzIHRoYXQgbWF5IGJl IGluamVjdGVkIGR1cmluZyB0aGUgdHJhbnNtaXNzaW9uLiZuYnNwOyBJbiBvcmRlciB0byBhdm9p ZCB0aGlzIGF0dGFjaywgdGhlIHJlY2VpdmVyIG11c3QgdmFsaWRhdGUNCiB0aGUgaW50ZWdyaXR5 IG9mIHRoZXNlIHBhY2tldHMgd2l0aCB0aGUgbmVnb3RpYXRlZCBzZWNyZXQga2V5LiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVtbWE6IE9LIHdpdGggdGhpcyBzdWdnZXN0aW9u Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0gW1NlY3Rpb24gMy40LCBTZWN0aW9uIDRdPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90 O0lmIEVTUCBpcyB1c2VkLCBJUCBwYWNrZXRzIGFyZSBlbmNyeXB0ZWQmcXVvdDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ JnF1b3Q7V2hlbiB1c2luZyBFU1AsIGFsbCBJUCBwYWNrZXRzIGFyZSBlbmNyeXB0ZWQmcXVvdDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgaXMgbm90IHRydWUgYXMgRVNQIGNhbiBiZSB1 c2VkIHdpdGggb25seSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiAoTlVMTCBjaXBoZXIpLiBJbiBmYWN0 LCBJIHRoaW5rIHRoaXMgaXMgZmFyIG1vcmUgY29tbW9uIHRoYW4gdXNpbmcgQUguIEluc3RlYWQg b2Ygc3RhcnQgdGFsa2luZyBhYm91dCBBSCwgSSB0aGluayB0aGUgZHJhZnQgY291bGQgbGlzdCB0 aGUgdGhyZWUgZGlmZmVyZW50DQogRVNQIG9wdGlvbnMgKGludGVncml0eSBhbmQvb3IgZW5jcnlw dGlvbikgYW5kIHRoZW4gaGF2ZSBhIG5vdGUgc3RhdGluZyB0aGF0IGZvciBBSCBoYXZlIHNpbWls YXIgcHJvcGVydGllcyBhcyBFU1Agd2l0aCBOVUxMIGNpcGhlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkVtbWE6IE9LIHdpdGggdGhpcyBzdWdnZXN0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIFtTZWN0aW9uIDRdPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PkZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZSBpdCB3b3VsZCBiZSB2ZXJ5IGJhZCB0byBhbGxv dyBleHRyYWN0aW9uIG9mIFNLRVlTRUVEIG9yIEtFWU1BVC4gVGhleSBjb3VsZCBiZSB1c2VkIHRv IHBhc3NpdmVseSBlYXZlc2Ryb3Agb24gdGhlIElQc2VjIHRyYWZmaWMgb3IgdG8gYWx0ZXIvaW5q ZWN0IG1lc3NhZ2VzLiBFdmVuIGlmIHdlIHRydXN0IHRoZSBPL1RXQU1QIGFwcGxpY2F0aW9uDQog dG8gbm90IGJlIG1hbGljaW91cywgdXNlIG9mIHRoZSBzYW1lIGtleSBpbiBhbm90aGVyIGFwcGxp Y2F0aW9uIG1heSBjYXVzZSBzZWN1cml0eSBwcm9ibGVtcyBzdWNoIGFzIHR3by10aW1lIHBhZCwg d2hpY2ggY29tcGxldGVseSBjb21wcm9taXNlcyB0aGUgY29uZmlkZW50aWFsaXR5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+QSBzZWN1cmUgc29sdXRpb24gd291bGQgYmUgdGhhdCB0aGUgSVBz ZWMgQVBJIHJldHVybnMgYSBrZXkgdGhhdCBpcyBkZXJpdmVkIGZyb20gc29tZSBvZiBJUHNlYyBr ZXlpbmcgbWF0ZXJpYWwuIEUuZy4gYSBuZXcgJnF1b3Q7S0VZTUFUJnF1b3Q7IGRlcml2ZWQgdXNp bmcgc29tZSBuZXcgcmFuZG9tIG1hdGVyaWFsIGluc3RlYWQgb2YgKE5pLE5yKSwgZS5nLjo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNoYXJlZCBzZWNyZXQgPSBwcmYmIzQzOyggU0tfZCwgU0lE ICkgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9yIGEga2V5IGRlcml2ZWQgZnJvbSBLRVlN QVQ6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U2hhcmVkIHNlY3JldCA9IFBSRiggS0VZTUFU LCBTSUQgKSA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSBzdHJvbmdseSBzdWdnZXN0IHJl bW92aW5nIHRoZSBvcHRpb25zIHRoYXQgZXhwb3NlcyB0aGUgSVBzZWMga2V5aW5nIG1hdGVyaWFs LCBvbmx5IGtlZXBpbmcgc2VjdXJlIG9wdGlvbnMsIGFuZCBhZGRpbmcgdGV4dCBkZXNjcmliaW5n IHRoYXQgaXQgaXMgdGhlIElQc2VjIGltcGxlbWVudGF0aW9uIHRoYXQgcGVyZm9ybXMgdGhlIGtl eSBkZXJpdmF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVtbWE6IFdl IGFncmVlIHRoYXQgZnJvbSBhIHNlY3VyaXR5IHBvdiBkZXJpdmluZyBzaGFyZWQga2V5IGF0IElQ c2VjIGlzIGEgYmV0dGVyIGNob2ljZS4gV2UgY2FuIGNvbnNpZGVyIHRoYXQgaW4gbmV4dCB2ZXJz aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIFtTZWN0 aW9uIDRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPldoaWxlIGV4dHJhY3Rpbmcga2V5aW5nIG1hdGVyaWFsIGZyb20gSVBz ZWMgd291bGQgYmUgbmljZSwgdG8gbXkga25vd2xlZGdlIHRoZXJlIGlzIG5vIHN0YW5kYXJkaXpl ZCAob3IgZGUgZmFjdG8gc3RhbmRhcmQpIEFQSSB0byBleHRyYWN0IFNLRVlTRUVELCBTS19kLCBL RVlNQVQgb3IgZXZlbiBTUEkgZnJvbSBhbiBJUHNlYyBpbXBsZW1lbnRhdGlvbi4gVGhpcyB3YXMg ZXZlbg0KIG9uZSBvZiB0aGUgcmVhc29ucyBJUHNlYyB3YXMgbm90IGNob3NlbiBhcyB0aGUgZGVm YXVsdCBzZWN1cml0eSBwcm90b2NvbCBmb3IgTy9UV0FNUC4gWW91IGNvdWxkIG9mIGNvdXJzZSBk byBpdCB3aXRoIGEgbmV3IHByb3ByaWV0YXJ5IGltcGxlbWVudGF0aW9uLCBidXQgdGhhdCBraW5k IG9mIGJlYXRzIHNvbWUgb2YgdGhlIHB1cnBvc2UgZnJvbSB0aGUgQWJzdHJhY3QgJnF1b3Q7Z2Fp bmluZyBwb3B1bGFyaXR5IGluIHNldmVyYWwgZGVwbG95bWVudCBzY2VuYXJpb3MmcXVvdDsuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Xb3JrIG9uIGFuIElQc2VjIEFQSSBzdGFydGVkIGEgY291 cGxlIGEgeWVhcnMgYWdvDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWJ0bnMtaXBzZWMtYXBpcmVxLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWJ0bnMtaXBzZWMtYXBpcmVxLTAwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5idXQgZGllZCwgYW5k IGV2ZW4gdGhhdCB3b3JrIGRpZCBwcm9oaWJpdCBleHRyYWN0aW9uIG9mIGtleWluZyBtYXRlcmlh bCBhbmQgZGlzY291cmFnZWQgdGhlIGV4dHJhY3Rpb24gb2YgU1BJIGFzIHRoZSBTUEkgbWlnaHQg Y2hhbmdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGFzIHRoZSBBUEkgcHJvcG9zYWxzIGJl ZW4gZGlzY3Vzc2VkIGluIHRoZSBpcHNlY21lIHdvcmtpbmcgZ3JvdXA/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5FbW1hOiBXZSByZWNlaXZlZCB0aGlzIGNvbW1lbnQgYXQgdGhl IGxhc3QgbWVldGluZyAoSSB0aGluayBpdCB3YXMgWW9hdiB3aG8gY29tbWVudGVkIG9uIHRoYXQp LiBXZSBiZWxpZXZlIHRoYXQgdGhpcyBpcyBpbiBmYWN0IGltcGxlbWVudGF0aW9uLWRlcGVuZGVu dC4gRm9yIGV4YW1wbGUsIGZvciB0aG9zZSB3aXRoIGV4aXN0aW5nDQogSVBzZWMgYW5kIE8vVFdB TVAgaW1wbGVtZW50YXRpb25zIHRoaXMgc2hvdWxkIG5vdCBiZSBhIGJsb2NraW5nIHBvaW50LiBJ ZiB0aGVyZSB3YXMgYSDigJxzdGFuZGFyZOKAnSBBUEksIHRoaXMgcHJvdG9jb2wgY291bGQgYmVu ZWZpdC4gQnV0IHdoYXQgd2XigJlyZSBpbnRlcmVzdGVkIHByaW1hcmlseSBoZXJlIGlzIE8vVFdB TVAgZGVwbG95bWVudCBhdCBsYXJnZSBzY2FsZSBhbmQgZm9yIG5ldHdvcmtzIHRoYXQgaGF2ZSBh bHJlYWR5IGRlcGxveWVkIElQc2VjLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBbU2VjdGlvbiA0XTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5r IHRoZSBhcHByb2FjaCBpbiBTZWN0aW9uIDQgd2l0aCBleHRyYWN0aW5nIGtleWluZyBtYXRlcmlh bCB3b3VsZCBvbmx5IHdvcmsgd2l0aCBhIHByb3ByaWV0YXJ5IElQc2VjIGltcGxlbWVudGF0aW9u IGFuZCBtb2RpZmljYXRpb25zIChhZGRpbmcgbmV3IGZpZWxkcykgdG8gTy9UV0FNUC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkhhdmUgYXBwcm9hY2hlcyB0aGF0IGRvIG5vdCByZXF1aXJlIGV4 dHJhY3Rpbmcga2V5aW5nIGluZm9ybWF0aW9uIGJlZW4gY29uc2lkZXJlZD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVtbWE6IEkgdGhpbmsgd2UgY291bGQgZGlzY3VzcyB0aGlz IGluIFZhbmNvdXZlci4gSW4gdGhlIG1lYW50aW1lLCBkbyB5b3UgaGF2ZSB0ZXh0IHRvIHN1Z2dl c3Q/PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZSBD aGlsZCBTQSBpcyBlbmNyeXB0ZWQsIGEgc2ltcGxlciBhcHByb2FjaCB3b3VsZCBiZSB0byB0cmFu c2ZlciB0aGUgTy9UV0FNUCBzaGFyZWQgc2VjcmV0IGluIGEgc2ltaWxhciBtYW5uZXIgYXMgdGhl IE8vVFdBTVAgc2Vzc2lvbiBrZXksIGUuZy4gaW4gdGhlIEtleUlEIGZpZWxkLiBUaGlzIHdvdWxk IGp1c3QgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSBmdW5jdGlvbg0KIGluIHRoZSBPL1RXQU1QIHRo YXQgcmVjZWl2ZXMgdGhlIHNoYXJlZCBzZWNyZXQsIGFuZCBubyBtb2RpZmljYXRpb25zIHRvIElQ c2VjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QXQgbGVhc3QgaWYgdGhlIENoaWxkIFNBIGlz IGludGVncml0eSBwcm90ZWN0ZWQsIG9uZSBhcHByb2FjaCB3b3VsZCBiZSB0byB1c2UgRGlmZmll LUhlbGxtYW4gaW4gTy9UV0FNUC4gVGhpcyB3b3VsZCBzdGlsbCByZXF1aXJlIG5ldyBPL1RXQU1Q IGZpZWxkcyBidXQgc3RpbGwgYmUgZWFzaWVyIHRoYW4gdGhlIGN1cnJlbnQgc3VnZ2VzdGlvbiBh cyBpdCBkb2VzIG5vdCByZXF1aXJlDQogYW55IGNoYW5nZXMgdG8gSVBzZWMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5BIHByb2JsZW0gaXMgc3RpbGwgdGhlIGxhY2sgb2YgQVBJIHRvIGZpbmQg b3V0IHdoZXRoZXIgZW5jcnlwdGlvbiBvciBpbnRlZ3JpdHkgaXMgaW4gdXNlLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TWlub3IgZWRpdG9yaWFsIGNvbW1lbnRz IG9uIGRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0gW3MzLjFdICZxdW90O09XQU1QLUNvbnRyb2wgY29tbWFuZHMmcXVv dDsgLSZndDsgJnF1b3Q7Ty9UV0FNUC1Db250cm9sIGNvbW1hbmRzJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4tIFtzNF0gJnF1b3Q7bXVzdCBiZSBnZW5lcmF0ZWQgZmlyc3RseSZxdW90 OyAtJmd0OyAmcXVvdDttdXN0IGJlIGdlbmVyYXRlZCBmaXJzdCZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+LSBbczRdICZxdW90O3Nlc3Npb24gSUQgaXMgaXMgdGhlJnF1b3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbW1hOiBPSyB3aXRoIHRoZXNlIGVkaXRvcmlh bCBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Sk9ITiBNQVRUU1NPTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5NU2MgRW5naW5lZXJp bmcgUGh5c2ljcywgTVNjIEJ1c2luZXNzIEFkbWluaXN0cmF0aW9uIGFuZCBFY29ub21pY3MgU2Vu aW9yIFJlc2VhcmNoZXIsIFNlY3VyaXR5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkVyaWNz c29uIEFCPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPlNlY3VyaXR5IFJlc2VhcmNoPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkY8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ w6Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPnI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+w7Y8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPmdhdGFuIDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlBob25lICYjNDM7NDYgMTAgNzEgNDMgNTAxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNNUy9NTVMgJiM0 Mzs0NiA3NiAxMSA1MyA1MDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+am9obi5tYXR0c3NvbiBhdCBlcmljc3Nvbi5jb208 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj53d3cuZXJpY3Nzb24uY29tPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+aXBwbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmlwcG1A aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5pcHBtQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHBtPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE92CE3FCF47934CBAE2CCECE119606C6338C67Bnkgeml507mbschi_-- From emma.zhanglijia@huawei.com Fri Nov 1 00:29:48 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722B621E80A9; Fri, 1 Nov 2013 00:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcXju2d1gFUA; Fri, 1 Nov 2013 00:29:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ACEF421E80AA; Fri, 1 Nov 2013 00:29:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXL17386; Fri, 01 Nov 2013 07:29:36 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 07:29:10 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 07:29:34 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.121]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 1 Nov 2013 15:29:10 +0800 From: "Zhanglijia (A)" To: John Mattsson Thread-Topic: draft-ietf-ippm-ipsec-01 review Thread-Index: Ac7WzwppfxHy7g5dSjWMtSxLJHcnNgAAhkkAAAC1fXA= Date: Fri, 1 Nov 2013 07:29:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.64] Content-Type: multipart/alternative; boundary="_000_CE92CE3FCF47934CBAE2CCECE119606C6338C6B6nkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" , "ippm@ietf.org" Subject: Re: [IPsec] draft-ietf-ippm-ipsec-01 review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 07:29:48 -0000 --_000_CE92CE3FCF47934CBAE2CCECE119606C6338C6B6nkgeml507mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwgYWxsDQoNCg0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldyEgUGxlYXNlIHNl ZSB0aGUgcmVwbHkgYXMgYmVsbG93Lg0KDQoNCg0KQmVzdCBSZWdhcmRzDQoNCkVtbWENCg0KDQoN Ci0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaXBwbS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYu b3JnXSDku6PooaggSm9obiBNYXR0c3Nvbg0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0MTDmnIgyM+aX pSA1OjM3DQrmlLbku7bkuro6IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQrk uLvpopg6IFtpcHBtXSBkcmFmdC1pZXRmLWlwcG0taXBzZWMtMDEgcmV2aWV3DQoNCg0KDQpIaSwN Cg0KDQoNCkkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLTAxLCBJIHRoaW5rIHRoZSBp c3N1ZSBpcyBpbXBvcnRhbnQsIGFuZCBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBhIGdvb2Qgc3Rh cnQuIEkgZG8gaG93ZXZlciBoYXZlIHNvbWUgdGhlIGRvdWJ0cyByZWdhcmRpbmcgdGhlIHN1Z2dl c3RlZCBzb2x1dGlvbiB0byBleHRyYWN0IGtleWluZyBtYXRlcmlhbCBmcm9tIElQc2VjLg0KDQoN Cg0KSGVyZSBhcmUgbXkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLg0KDQoNCg0KQmVzdCBSZWdh cmRzDQoNCkpvaG4NCg0KDQoNCg0KDQoNCg0KQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1pcHBtLWlw c2VjLTAxDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpJbiBnZW5lcmFsIEkgdGhpbmsgdGhlIGFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24gY291bGQg YmUgY2xlYXJlciBpbiB3aGF0IHRoZSBwcm9ibGVtcyBhbmQgdXNlIGNhc2VzIGFyZSBhbmQgd2hh dCB0aGUgZG9jdW1lbnQgdHJpZXMgdG8gYWNoaWV2ZS4gRS5nLiBkbyB0aGUgZG9jdW1lbnQgd2Fu dCB0byBtZWFzdXJlIHRoZSBwZXJmb3JtYW5jZSBvZiBJUHNlYyBvciB1c2UgSVBzZWMgZm9yIHBy b3RlY3Rpb24sIG9yIGJvdGguIFdoYXQgYXJlIHRoZSBwcm9ibGVtcywgaWYgYW55LCBvZiBqdXN0 IHNlbmRpbmcgTy9UV0FNUCBvdmVyIHRoZSBleGlzdGluZyBJUHNlYyB0dW5uZWw/DQoNCkVtbWE6 IFRoZSBkcmFmdCBjdXJyZW50bHkgYWltcyB0byBjYXBpdGFsaXplIG9uIElQc2VjIGZvciBkZXJp dmluZyBrZXlzIGZvciBPL1RXQU1QLiBXZSB3aWxsIGZ1cnRoZXIgZWRpdCB0aGUgaW50cm9kdWN0 b3J5IHRleHQgdG8gYWRkcmVzcyB0aGlzIHBvaW50Lg0KDQoNCg0KDQoNCi0gW0Fic3RyYWN0XQ0K DQoiaXQgZXh0ZW5kcyB0aGUgYXBwbGljYWJpbGl0eSBvZiBPL1RXQU1QIHRvIG5ldHdvcmtzIHRo YXQgaGF2ZSBhbHJlYWR5IGRlcGxveWVkIElQc2VjIg0KDQoiVW5mb3J0dW5hdGVseSwgaG93ZXZl ciwgc3RhbmRhcmQgSVAgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgc2VjdXJpdHkgbWVjaGFuaXNt cyBjYW5ub3QgYmUgcmVhZGlseSB1c2VkIHdpdGggSVBzZWMuIg0KDQoNCg0KVGhpcyBnaXZlcyB0 aGUgaWRlYSB0aGF0IHlvdSBjYW5ub3QgdXNlIE8vVFdBTVAgd2l0aCBJUHNlYywgYnV0IHRoaXMg aXMgb2YgY291cnNlIG5vdCB0cnVlLiBZb3UgY2FuIGUuZy4gc2VuZCBPL1RXQU1QIG92ZXIgSVBz ZWMsIGFuZCBkZXBlbmRpbmcgb24gdGhlIElQc2VjIHNlY3VyaXR5IHBvbGljeSBkYXRhYmFzZSAo U1BEKSB5b3UgY2FuIHNlbmQgTy9UV0FNUCBvdXRzaWRlIG9mIHRoZSBJUHNlYyB0dW5uZWwuDQoN CkVtbWE6IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuIFRoaXMgd2FzIG5vdCBvdXIgaW50ZW50aW9u LiBJbmRlZWQgTy9UV0FNUCBzZWN1cml0eSBhbmQgSVBzZWMgY2FuIGJlIGRlcGxveWVkIGFuZCBy dW4gc2VwYXJhdGVseS4gQnV0IGdpdmVuIHRoYXQgdGhlIGN1cnJlbnRseSBzdGFuZGFyZGl6ZWQg Ty9UV0FNUCBzZWN1cml0eSBtZWNoYW5pc21zIG9ubHkgc3VwcG9ydCBwcmUtc2hhcmVkIGtleSBt b2RlLCBsYXJnZSBzY2FsZSBkZXBsb3ltZW50IGFuZCB1c2UgaXMgaGluZGVyZWQgc2lnbmlmaWNh bnRseSBhcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LiBEZXBsb3ltZW50IG9mIOKAnHNoYXJlZCBz ZWNyZXRz4oCdIGZvciBtYXNzaXZlIGVxdWlwbWVudCBpbnN0YWxsYXRpb24gaXMgbm90IHRoZSBi ZXN0IGlkZWEgYWZ0ZXIgYWxsLCBJIGhvcGUgeW91IGFncmVlIHdpdGggdGhhdC4gV2Ugd2lsbCBl ZGl0IHRoZSB0ZXh0IHRvIGFkZHJlc3MgdGhpcy4NCg0KDQoNCg0KDQotIFtTZWN0aW9uIDFdDQoN CiJJbiBwYXJ0aWN1bGFyLCB3ZSBub3RlIHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyeSB0byB1c2Ug ZGlzdGluY3Qga2V5cyBpbiBPV0FNUC1Db250cm9sIGFuZCBPV0FNUC1UZXN0IGxheWVycy4gIE9u ZSBrZXkgZm9yIGVuY3J5cHRpb24gYW5kIGFub3RoZXIgZm9yIGF1dGhlbnRpY2F0aW9uIGlzIHN1 ZmZpY2llbnQgZm9yIGJvdGggQ29udHJvbCBhbmQgVGVzdCBsYXllcnMuICBUaGlzIG9idmlhdGVz IHRoZSBuZWVkIHRvIGdlbmVyYXRlIHR3byBrZXlzIGZvciBlYWNoIGxheWVyIGFuZCByZWR1Y2Vz IHRoZSBjb21wbGV4aXR5IG9mIE8vVFdBTVAgcHJvdG9jb2xzIGluIGFuIElQc2VjIGVudmlyb25t ZW50LiAgVGhpcyBvYnNlcnZhdGlvbiBjb21lcyBmcm9tIHRoZSBmYWN0IHRoYXQgc2VwYXJhdGUg c2Vzc2lvbiBrZXlzIGluIHRoZSBPV0FNUC1Db250cm9sIGFuZCBPV0FNUC1UZXN0IGxheWVycyB3 ZXJlIGRlc2lnbmVkIGZvciBwcmV2ZW50aW5nIHJlZmxlY3Rpb24gYXR0YWNrcyB3aGVuIGVtcGxv eWluZyB0aGUgY3VycmVudCBtZWNoYW5pc20uIg0KDQoNCg0KSSBhc3N1bWUgTy9UV0FNUCB1c2Vz IGRpZmZlcmVudCBrZXlzIGFzIGlzIGl0IGJhZCBzZWN1cml0eSBkZXNpZ24gdG8gdXNlIHRoZSBz YW1lIGtleSBmb3IgdHdvIGRpZmZlcmVudCBwdXJwb3Nlcy4gVXNpbmcgdGhlIHNhbWUga2V5IHR3 aWNlIG1heSBsZWFkcyBhIG51bWJlciBvZiBzZWN1cml0eSBwcm9ibGVtcw0KDQotIEl0IGVhc2ls eSBjYXVzZXMgc28gY2FsbGVkICJ0d28tdGltZSBwYWRzIiB3ZXJlIHRoZSBjb25maWRlbnRpYWxp dHkgaXMgdG90YWxseSBjb21wcm9taXNlZC4NCg0KLSBGb3Igc29tZSBhbGdvcml0aG1zIHRoZSBp bnRlZ3JpdHkgbWF5IGJlIGNvbXByb21pc2VkLg0KDQotIElmIG9uZSB1c2Ugb2YgdGhlIGtleXMg aGFzIGEgY3J5cHRvZ3JhcGhpYyB3ZWFrbmVzcyBzbyB0aGFuIGFuIGF0dGFja2VyIGNhbiByZWNv dmVyIHRoZSBrZXksIHRoZSBhdHRhY2tlciBoYXMgdGhlIHVzZSB0aGF0IGtleSB0byBhdHRhY2sg Ym90aCB1c2VzIG9mIHRoZSBrZXkuDQoNCi0gSXQgZ2l2ZXMgYW4gYXR0YWNrZXIgdHdpY2UgYXMg bXVjaCBtYXRlcmlhbCAocHJvdGVjdGVkIHRyYWZmaWMpIHRvIHdvcmsgd2l0aC4NCg0KSSB0aGVy ZWZvcmUgc3Ryb25nbHkgcmVjb21tZW5kcyBhZ2FpbnN0IHVzaW5nIHRoZSBzYW1lIGtleSB0d2lj ZSB1bmxlc3MgeW91IG11c3QsIGFuZCBpbiB0aGlzIGNhc2Ugd2UgZG8gbm90Lg0KDQpFbW1hOiBX ZWxsLCB0aGUgZHJhZnQgZG9lcyBub3QgZXhjbHVkZSB0aGUgdXNlIG9mIGRpc3RpbmN0IGtleXMu IEFjdHVhbGx5IHRoZXJlIGFyZSB0aHJlZSBvcHRpb25zIChiYXNpYyArIDIgYWx0ZXJuYXRpdmVz KSBpbiB0aGUgZHJhZnQgYW5kIHdlIGhhdmUgYWxyZWFkeSBjYWxsZWQgZm9yIGFjdGl2ZSBkaXNj dXNzaW9uIGluIHRoZSBXRyBvbiB3aGljaCBvbmUgaXMgYmV0dGVyLCBhbmQgd2UgYXBwcmVjaWF0 ZSBvcGVuaW5nIHRoZSB0ZWNobmljYWwgZGlzY3Vzc2lvbiBvbiB0aGlzIG1hdHRlci4gVGhlIHRo cmVhdHMgYWJvdmUgY2FuIGJlIGNvbnNpZGVyZWQgd2hlbiBkZXRlcm1pbmluZyB3aGljaCBvcHRp b24gc2hvdWxkIGJlIHN0YW5kYXJkaXplZC4NCg0KDQoNCi0gW1NlY3Rpb24gMy4xXQ0KDQpUaGUg U2VydmVyLVN0YXJ0IG1lc3NhZ2Ugd2l0aCBTZXJ2ZXItSVYgaXMgbWlzc2luZyBmcm9tIHRoZSB0 ZXh0Lg0KDQpTdWdnZXN0aW9uOg0KDQoiSW4gdGhlIGF1dGhlbnRpY2F0ZWQgYW5kIGVuY3J5cHRl ZCBtb2RlcywgYWxsIGZ1cnRoZXIgY29tbXVuaWNhdGlvbiBpcyBlbmNyeXB0ZWQgdXNpbmcgdGhl IEFFUyBTZXNzaW9uLWtleSBhbmQgYXV0aGVudGljYXRlZCB3aXRoIHRoZSBITUFDIFNlc3Npb24t a2V5LiAgQWZ0ZXIgcmVjZWl2aW5nIFNldC1VcC1SZXNwb25zZSB0aGUgc2VydmVyIHJlc3BvbmRz IHdpdGggYSBTZXJ2ZXItU3RhcnQgbWVzc2FnZSBjb250YWluaW5nIFNlcnZlci1JVi4gVGhlIGNs aWVudCBlbmNyeXB0cyBldmVyeXRoaW5nIGl0IHRyYW5zbWl0cyB0aHJvdWdoIHRoZSBqdXN0LWVz dGFibGlzaGVkIE8vVFdBTVAtQ29udHJvbCBjb25uZWN0aW9uIHVzaW5nIHN0cmVhbSBlbmNyeXB0 aW9uIHdpdGggQ2xpZW50LUlWIGFzIHRoZSBJVi4iDQoNCkVtbWE6IE9LIHdpdGggdGhpcyBzdWdn ZXN0aW9uLg0KDQoNCg0KLSBbU2VjdGlvbiA0XQ0KDQpJIHRoaW5rICJJUHNlYyBTQSIgaXMgb2xk IHRlcm1pbm9sb2d5IGZvciBJS0UodjEpLCBhbGwgb2NjdXJyZW5jZXMgc2hvdWxkIGJlIGNoYW5n ZWQgdG8gIkNoaWxkIFNBIi4NCg0KRW1tYTogT0sgd2l0aCB0aGlzIHN1Z2dlc3Rpb24uDQoNCg0K DQoNCg0KLSBbU2VjdGlvbiA0XQ0KDQoiVGhlcmVmb3JlLCBldmVuIGlmIHRoZSBwZWVycyBjaG9v c2UgdG8gb3B0IGZvciB0aGUgdW5hdXRoZW50aWNhdGVkIG1vZGUsIElQc2VjIGludGVncml0eSBw cm90ZWN0aW9uIGlzIGV4dGVuZGVkIHRvIE8vVFdBTVAuDQoNCg0KDQpJIHRoaW5rIHRoZSBkb2N1 bWVudCB3b3VsZCBiZSBpbXByb3ZlZCBieSBkaXNjdXNzaW5nIHRoaXMgYW5kIG90aGVyIG9wdGlv bnM6DQoNCg0KDQpPL1RXQU1QIHVuYXV0aGVudGljYXRlZCBvdmVyIGV4aXN0aW5nIENoaWxkIFNB IHdpdGggaW50ZWdyaXR5Lg0KDQpPL1RXQU1QIHVuYXV0aGVudGljYXRlZCBvdmVyIGV4aXN0aW5n IENoaWxkIFNBIHdpdGggZW5jcnlwdGlvbi4NCg0KTy9UV0FNUCB1bmF1dGhlbnRpY2F0ZWQgb3Zl ciBleGlzdGluZyBDaGlsZCBTQSB3aXRoIGVuY3J5cHRpb24gYW5kIGludGVncml0eS4NCg0KTy9U V0FNUCB1bmF1dGhlbnRpY2F0ZWQgb3ZlciBuZXcgQ2hpbGQgU0Egd2l0aCBlbmNyeXB0aW9uIGFu ZCBvciBpbnRlZ3JpdHkuDQoNCg0KDQppbiBhIHNlcGFyYXRlIHNlY3Rpb24gYmVmb3JlIHRoZSBz ZWN0aW9uIG9uIGV4dHJhY3Rpbmcga2V5aW5nIG1hdGVyaWFsLiBJdCBtYXkgdmVyeSB3ZWxsIGJl IHRoZSBjYXNlIHRoYXQgTy9UV0FNUCB1bmF1dGhlbnRpY2F0ZWQgb3ZlciB0aGUgZXhpc3Rpbmcg Q2hpbGQgU0EgZnVsZmlsbHMgdGhlIHVzZXIncyBzZWN1cml0eSByZXF1aXJlbWVudHMuDQoNCkVt bWE6IFRoZSBvcHRpb25zIGxpc3RlZCBhYm92ZSBleGlzdGVkLiBCdXQgaW4gdGhpcyBjYXNlLCBP L1RXQU1QIGxheWVyIHNob3VsZCBvYnRhaW4gdGhlIGluZm9ybWF0aW9uIGFib3V0IElQc2VjIGxh eWVyIGZpcnN0IChlLmcuIENoaWxkIFNBIHdpdGggaW50ZWdyaXR5IGFuZC9vciBlbmNyeXB0aW9u KS4gVGhlIGludGVyYWN0aW9uIGJldHdlZW4gTy9UV0FNUCBsYXllciBhbmQgSVBzZWMgbGF5ZXIg d2lsbCBpbmNyZWFzZS4NCg0KDQoNCg0KDQotIFtTZWN0aW9uIDMuNF0NCg0KIklmIHRoZSBBSCBw cm90b2NvbCBpcyB1c2VkLCBJUCBwYWNrZXRzIGFyZSB0cmFuc21pdHRlZCBpbiBwbGFpbnRleHQu IFRoZSBhdXRoZW50aWNhdGlvbiBwYXJ0IGNvdmVycyB0aGUgZW50aXJlIHBhY2tldC4gIFNvIGFs bCB0ZXN0IGluZm9ybWF0aW9uLCBzdWNoIGFzIFVEUCBwb3J0IG51bWJlciwgYW5kIHRoZSB0ZXN0 IHJlc3VsdHMgd2lsbCBiZSB2aXNpYmxlIHRvIGFueSBhdHRhY2tlciwgd2hpY2ggY2FuIGludGVy Y2VwdCB0aGVzZSB0ZXN0IHBhY2tldHMsIGFuZCBpbnRyb2R1Y2UgZXJyb3JzIG9yIGZvcmdlIHBh Y2tldHMgdGhhdCBtYXkgYmUgaW5qZWN0ZWQgZHVyaW5nIHRoZSB0cmFuc21pc3Npb24uICBJbiBv cmRlciB0byBhdm9pZCB0aGlzIGF0dGFjaywgdGhlIHJlY2VpdmVyIG11c3QgdmFsaWRhdGUgdGhl IGludGVncml0eSBvZiB0aGVzZSBwYWNrZXRzIHdpdGggdGhlIG5lZ290aWF0ZWQgc2VjcmV0IGtl eS4iDQoNCg0KDQpBcyB0aGUgcGFja2VnZXMgYXJlIGF1dGhlbnRpY2F0ZWQgYW4gYXR0YWNrZXIg Y2Fubm90IGZvcmdlIG9yIGluamVjdCBlcnJvcnMuICBBbmQgYXMgdGhlIHBhY2thZ2VzIGFyZSBu b3QgZW5jcnlwdGVkLCByZWFkaW5nIHRoZSBpbmZvcm1hdGlvbiBjYW5ub3QgYmUgY29uc2lkZXJl ZCBhbiBhdHRhY2suDQoNCg0KDQpJIHN1Z2dlc3QgZGVsZXRpbmcgIiB0byBhbnkgYXR0YWNrZXIs IHdoaWNoIGNhbiBpbnRlcmNlcHQgdGhlc2UgdGVzdCBwYWNrZXRzLCBhbmQgaW50cm9kdWNlIGVy cm9ycyBvciBmb3JnZSBwYWNrZXRzIHRoYXQgbWF5IGJlIGluamVjdGVkIGR1cmluZyB0aGUgdHJh bnNtaXNzaW9uLiAgSW4gb3JkZXIgdG8gYXZvaWQgdGhpcyBhdHRhY2ssIHRoZSByZWNlaXZlciBt dXN0IHZhbGlkYXRlIHRoZSBpbnRlZ3JpdHkgb2YgdGhlc2UgcGFja2V0cyB3aXRoIHRoZSBuZWdv dGlhdGVkIHNlY3JldCBrZXkuDQoNCkVtbWE6IE9LIHdpdGggdGhpcyBzdWdnZXN0aW9uLg0KDQoN Cg0KDQoNCi0gW1NlY3Rpb24gMy40LCBTZWN0aW9uIDRdDQoNCiJJZiBFU1AgaXMgdXNlZCwgSVAg cGFja2V0cyBhcmUgZW5jcnlwdGVkIg0KDQoiV2hlbiB1c2luZyBFU1AsIGFsbCBJUCBwYWNrZXRz IGFyZSBlbmNyeXB0ZWQiDQoNCg0KDQpUaGlzIGlzIG5vdCB0cnVlIGFzIEVTUCBjYW4gYmUgdXNl ZCB3aXRoIG9ubHkgaW50ZWdyaXR5IHByb3RlY3Rpb24gKE5VTEwgY2lwaGVyKS4gSW4gZmFjdCwg SSB0aGluayB0aGlzIGlzIGZhciBtb3JlIGNvbW1vbiB0aGFuIHVzaW5nIEFILiBJbnN0ZWFkIG9m IHN0YXJ0IHRhbGtpbmcgYWJvdXQgQUgsIEkgdGhpbmsgdGhlIGRyYWZ0IGNvdWxkIGxpc3QgdGhl IHRocmVlIGRpZmZlcmVudCBFU1Agb3B0aW9ucyAoaW50ZWdyaXR5IGFuZC9vciBlbmNyeXB0aW9u KSBhbmQgdGhlbiBoYXZlIGEgbm90ZSBzdGF0aW5nIHRoYXQgZm9yIEFIIGhhdmUgc2ltaWxhciBw cm9wZXJ0aWVzIGFzIEVTUCB3aXRoIE5VTEwgY2lwaGVyLg0KDQpFbW1hOiBPSyB3aXRoIHRoaXMg c3VnZ2VzdGlvbi4NCg0KDQoNCg0KDQotIFtTZWN0aW9uIDRdDQoNCkZyb20gYSBzZWN1cml0eSBw ZXJzcGVjdGl2ZSBpdCB3b3VsZCBiZSB2ZXJ5IGJhZCB0byBhbGxvdyBleHRyYWN0aW9uIG9mIFNL RVlTRUVEIG9yIEtFWU1BVC4gVGhleSBjb3VsZCBiZSB1c2VkIHRvIHBhc3NpdmVseSBlYXZlc2Ry b3Agb24gdGhlIElQc2VjIHRyYWZmaWMgb3IgdG8gYWx0ZXIvaW5qZWN0IG1lc3NhZ2VzLiBFdmVu IGlmIHdlIHRydXN0IHRoZSBPL1RXQU1QIGFwcGxpY2F0aW9uIHRvIG5vdCBiZSBtYWxpY2lvdXMs IHVzZSBvZiB0aGUgc2FtZSBrZXkgaW4gYW5vdGhlciBhcHBsaWNhdGlvbiBtYXkgY2F1c2Ugc2Vj dXJpdHkgcHJvYmxlbXMgc3VjaCBhcyB0d28tdGltZSBwYWQsIHdoaWNoIGNvbXBsZXRlbHkgY29t cHJvbWlzZXMgdGhlIGNvbmZpZGVudGlhbGl0eS4NCg0KDQoNCkEgc2VjdXJlIHNvbHV0aW9uIHdv dWxkIGJlIHRoYXQgdGhlIElQc2VjIEFQSSByZXR1cm5zIGEga2V5IHRoYXQgaXMgZGVyaXZlZCBm cm9tIHNvbWUgb2YgSVBzZWMga2V5aW5nIG1hdGVyaWFsLiBFLmcuIGEgbmV3ICJLRVlNQVQiIGRl cml2ZWQgdXNpbmcgc29tZSBuZXcgcmFuZG9tIG1hdGVyaWFsIGluc3RlYWQgb2YgKE5pLE5yKSwg ZS5nLjoNCg0KDQoNClNoYXJlZCBzZWNyZXQgPSBwcmYrKCBTS19kLCBTSUQgKQ0KDQoNCg0KT3Ig YSBrZXkgZGVyaXZlZCBmcm9tIEtFWU1BVDoNCg0KDQoNClNoYXJlZCBzZWNyZXQgPSBQUkYoIEtF WU1BVCwgU0lEICkNCg0KDQoNCkkgc3Ryb25nbHkgc3VnZ2VzdCByZW1vdmluZyB0aGUgb3B0aW9u cyB0aGF0IGV4cG9zZXMgdGhlIElQc2VjIGtleWluZyBtYXRlcmlhbCwgb25seSBrZWVwaW5nIHNl Y3VyZSBvcHRpb25zLCBhbmQgYWRkaW5nIHRleHQgZGVzY3JpYmluZyB0aGF0IGl0IGlzIHRoZSBJ UHNlYyBpbXBsZW1lbnRhdGlvbiB0aGF0IHBlcmZvcm1zIHRoZSBrZXkgZGVyaXZhdGlvbnMuDQoN CkVtbWE6IFdlIGFncmVlIHRoYXQgZnJvbSBhIHNlY3VyaXR5IHBvdiBkZXJpdmluZyBzaGFyZWQg a2V5IGF0IElQc2VjIGlzIGEgYmV0dGVyIGNob2ljZS4gV2UgY2FuIGNvbnNpZGVyIHRoYXQgaW4g bmV4dCB2ZXJzaW9uLg0KDQoNCg0KDQoNCi0gW1NlY3Rpb24gNF0NCg0KV2hpbGUgZXh0cmFjdGlu ZyBrZXlpbmcgbWF0ZXJpYWwgZnJvbSBJUHNlYyB3b3VsZCBiZSBuaWNlLCB0byBteSBrbm93bGVk Z2UgdGhlcmUgaXMgbm8gc3RhbmRhcmRpemVkIChvciBkZSBmYWN0byBzdGFuZGFyZCkgQVBJIHRv IGV4dHJhY3QgU0tFWVNFRUQsIFNLX2QsIEtFWU1BVCBvciBldmVuIFNQSSBmcm9tIGFuIElQc2Vj IGltcGxlbWVudGF0aW9uLiBUaGlzIHdhcyBldmVuIG9uZSBvZiB0aGUgcmVhc29ucyBJUHNlYyB3 YXMgbm90IGNob3NlbiBhcyB0aGUgZGVmYXVsdCBzZWN1cml0eSBwcm90b2NvbCBmb3IgTy9UV0FN UC4gWW91IGNvdWxkIG9mIGNvdXJzZSBkbyBpdCB3aXRoIGEgbmV3IHByb3ByaWV0YXJ5IGltcGxl bWVudGF0aW9uLCBidXQgdGhhdCBraW5kIG9mIGJlYXRzIHNvbWUgb2YgdGhlIHB1cnBvc2UgZnJv bSB0aGUgQWJzdHJhY3QgImdhaW5pbmcgcG9wdWxhcml0eSBpbiBzZXZlcmFsIGRlcGxveW1lbnQg c2NlbmFyaW9zIi4NCg0KDQoNCldvcmsgb24gYW4gSVBzZWMgQVBJIHN0YXJ0ZWQgYSBjb3VwbGUg YSB5ZWFycyBhZ28gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1idG5zLWlw c2VjLWFwaXJlcS0wMA0KDQpidXQgZGllZCwgYW5kIGV2ZW4gdGhhdCB3b3JrIGRpZCBwcm9oaWJp dCBleHRyYWN0aW9uIG9mIGtleWluZyBtYXRlcmlhbCBhbmQgZGlzY291cmFnZWQgdGhlIGV4dHJh Y3Rpb24gb2YgU1BJIGFzIHRoZSBTUEkgbWlnaHQgY2hhbmdlLg0KDQoNCg0KSGFzIHRoZSBBUEkg cHJvcG9zYWxzIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBpcHNlY21lIHdvcmtpbmcgZ3JvdXA/DQoN CkVtbWE6IFdlIHJlY2VpdmVkIHRoaXMgY29tbWVudCBhdCB0aGUgbGFzdCBtZWV0aW5nIChJIHRo aW5rIGl0IHdhcyBZb2F2IHdobyBjb21tZW50ZWQgb24gdGhhdCkuIFdlIGJlbGlldmUgdGhhdCB0 aGlzIGlzIGluIGZhY3QgaW1wbGVtZW50YXRpb24tZGVwZW5kZW50LiBGb3IgZXhhbXBsZSwgZm9y IHRob3NlIHdpdGggZXhpc3RpbmcgSVBzZWMgYW5kIE8vVFdBTVAgaW1wbGVtZW50YXRpb25zIHRo aXMgc2hvdWxkIG5vdCBiZSBhIGJsb2NraW5nIHBvaW50LiBJZiB0aGVyZSB3YXMgYSDigJxzdGFu ZGFyZOKAnSBBUEksIHRoaXMgcHJvdG9jb2wgY291bGQgYmVuZWZpdC4gQnV0IHdoYXQgd2XigJly ZSBpbnRlcmVzdGVkIHByaW1hcmlseSBoZXJlIGlzIE8vVFdBTVAgZGVwbG95bWVudCBhdCBsYXJn ZSBzY2FsZSBhbmQgZm9yIG5ldHdvcmtzIHRoYXQgaGF2ZSBhbHJlYWR5IGRlcGxveWVkIElQc2Vj Lg0KDQoNCg0KDQoNCg0KDQotIFtTZWN0aW9uIDRdDQoNCkkgdGhpbmsgdGhlIGFwcHJvYWNoIGlu IFNlY3Rpb24gNCB3aXRoIGV4dHJhY3Rpbmcga2V5aW5nIG1hdGVyaWFsIHdvdWxkIG9ubHkgd29y ayB3aXRoIGEgcHJvcHJpZXRhcnkgSVBzZWMgaW1wbGVtZW50YXRpb24gYW5kIG1vZGlmaWNhdGlv bnMgKGFkZGluZyBuZXcgZmllbGRzKSB0byBPL1RXQU1QLg0KDQoNCg0KSGF2ZSBhcHByb2FjaGVz IHRoYXQgZG8gbm90IHJlcXVpcmUgZXh0cmFjdGluZyBrZXlpbmcgaW5mb3JtYXRpb24gYmVlbiBj b25zaWRlcmVkPw0KDQpFbW1hOiBJIHRoaW5rIHdlIGNvdWxkIGRpc2N1c3MgdGhpcyBpbiBWYW5j b3V2ZXIuIEluIHRoZSBtZWFudGltZSwgZG8geW91IGhhdmUgdGV4dCB0byBzdWdnZXN0Pw0KDQoN Cg0KDQoNCklmIHRoZSBDaGlsZCBTQSBpcyBlbmNyeXB0ZWQsIGEgc2ltcGxlciBhcHByb2FjaCB3 b3VsZCBiZSB0byB0cmFuc2ZlciB0aGUgTy9UV0FNUCBzaGFyZWQgc2VjcmV0IGluIGEgc2ltaWxh ciBtYW5uZXIgYXMgdGhlIE8vVFdBTVAgc2Vzc2lvbiBrZXksIGUuZy4gaW4gdGhlIEtleUlEIGZp ZWxkLiBUaGlzIHdvdWxkIGp1c3QgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSBmdW5jdGlvbiBpbiB0 aGUgTy9UV0FNUCB0aGF0IHJlY2VpdmVzIHRoZSBzaGFyZWQgc2VjcmV0LCBhbmQgbm8gbW9kaWZp Y2F0aW9ucyB0byBJUHNlYy4NCg0KDQoNCkF0IGxlYXN0IGlmIHRoZSBDaGlsZCBTQSBpcyBpbnRl Z3JpdHkgcHJvdGVjdGVkLCBvbmUgYXBwcm9hY2ggd291bGQgYmUgdG8gdXNlIERpZmZpZS1IZWxs bWFuIGluIE8vVFdBTVAuIFRoaXMgd291bGQgc3RpbGwgcmVxdWlyZSBuZXcgTy9UV0FNUCBmaWVs ZHMgYnV0IHN0aWxsIGJlIGVhc2llciB0aGFuIHRoZSBjdXJyZW50IHN1Z2dlc3Rpb24gYXMgaXQg ZG9lcyBub3QgcmVxdWlyZSBhbnkgY2hhbmdlcyB0byBJUHNlYy4NCg0KDQoNCkEgcHJvYmxlbSBp cyBzdGlsbCB0aGUgbGFjayBvZiBBUEkgdG8gZmluZCBvdXQgd2hldGhlciBlbmNyeXB0aW9uIG9y IGludGVncml0eSBpcyBpbiB1c2UuDQoNCg0KDQoNCg0KTWlub3IgZWRpdG9yaWFsIGNvbW1lbnRz IG9uIGRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wMQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCi0gW3MzLjFd ICJPV0FNUC1Db250cm9sIGNvbW1hbmRzIiAtPiAiTy9UV0FNUC1Db250cm9sIGNvbW1hbmRzIg0K DQoNCg0KLSBbczRdICJtdXN0IGJlIGdlbmVyYXRlZCBmaXJzdGx5IiAtPiAibXVzdCBiZSBnZW5l cmF0ZWQgZmlyc3QiDQoNCg0KDQotIFtzNF0gInNlc3Npb24gSUQgaXMgaXMgdGhlIg0KDQpFbW1h OiBPSyB3aXRoIHRoZXNlIGVkaXRvcmlhbCBjb21tZW50cy4NCg0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpKT0hOIE1BVFRTU09ODQoNCk1TYyBFbmdpbmVlcmluZyBQaHlzaWNz LCBNU2MgQnVzaW5lc3MgQWRtaW5pc3RyYXRpb24gYW5kIEVjb25vbWljcyBTZW5pb3IgUmVzZWFy Y2hlciwgU2VjdXJpdHkNCg0KDQoNCkVyaWNzc29uIEFCDQoNClNlY3VyaXR5IFJlc2VhcmNoDQoN CkbDpHLDtmdhdGFuIDYNCg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuDQoNClBob25lICs0 NiAxMCA3MSA0MyA1MDENCg0KU01TL01NUyArNDYgNzYgMTEgNTMgNTAxDQoNCmpvaG4ubWF0dHNz b24gYXQgZXJpY3Nzb24uY29tDQoNCnd3dy5lcmljc3Nvbi5jb208aHR0cDovL3d3dy5lcmljc3Nv bi5jb20+DQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCmlwcG0gbWFpbGluZyBsaXN0DQoNCmlwcG1AaWV0Zi5vcmc8bWFpbHRv OmlwcG1AaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBwbQ0KDQo= --_000_CE92CE3FCF47934CBAE2CCECE119606C6338C6B6nkgeml507mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5 OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+ac rCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv5paH 5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5DaGFyMA0K CXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0ZXh0LWp1c3RpZnktdHJpbTpwdW5jdHVh dGlvbiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIEpvaG4sIGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+TWFueSB0aGFua3MgZm9yIHRoZSByZXZpZXchIFBsZWFzZSBzZWUgdGhlIHJlcGx5IGFzIGJl bGxvdy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCBSZWdhcmRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkVt bWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7pgq7ku7bljp/ku7Y8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTrlrovkvZMiPuWPkeS7tuS6ujwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OiA8YSBocmVm PSJtYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnIj4NCmlwcG0tYm91bmNlc0BpZXRmLm9yZzwv YT4gWzxhIGhyZWY9Im1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppcHBtLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovk vZMiPuS7o+ihqDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IEpvaG4gTWF0dHNzb248YnI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj46IDIwMTM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OuWui+S9kyI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4xMDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk65a6L5L2TIj7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjIzPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPuaXpTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+DQogNTozNzxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L 5L2TIj7mlLbku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjogPGEgaHJlZj0ibWFpbHRv OmlwcG1AaWV0Zi5vcmciPg0KaXBwbUBpZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+5Li76aKYPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj46 IFtpcHBtXSBkcmFmdC1pZXRmLWlwcG0taXBzZWMtMDEgcmV2aWV3PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgcmV2aWV3ZWQgZHJhZnQtaWV0 Zi1pcHBtLWlwc2VjLTAxLCBJIHRoaW5rIHRoZSBpc3N1ZSBpcyBpbXBvcnRhbnQsIGFuZCBJIHRo aW5rIHRoZSBkb2N1bWVudCBpcyBhIGdvb2Qgc3RhcnQuIEkgZG8gaG93ZXZlciBoYXZlIHNvbWUg dGhlIGRvdWJ0cyByZWdhcmRpbmcgdGhlIHN1Z2dlc3RlZCBzb2x1dGlvbiB0byBleHRyYWN0IGtl eWluZyBtYXRlcmlhbCBmcm9tIElQc2VjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGVyZSBh cmUgbXkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ QmVzdCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkpvaG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1pcHBtLWlw c2VjLTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5JbiBnZW5lcmFsIEkgdGhpbmsgdGhlIGFic3RyYWN0IGFuZCBJbnRyb2R1 Y3Rpb24gY291bGQgYmUgY2xlYXJlciBpbiB3aGF0IHRoZSBwcm9ibGVtcyBhbmQgdXNlIGNhc2Vz IGFyZSBhbmQgd2hhdCB0aGUgZG9jdW1lbnQgdHJpZXMgdG8gYWNoaWV2ZS4gRS5nLiBkbyB0aGUg ZG9jdW1lbnQgd2FudCB0byBtZWFzdXJlIHRoZSBwZXJmb3JtYW5jZSBvZiBJUHNlYyBvciB1c2UN CiBJUHNlYyBmb3IgcHJvdGVjdGlvbiwgb3IgYm90aC4gV2hhdCBhcmUgdGhlIHByb2JsZW1zLCBp ZiBhbnksIG9mIGp1c3Qgc2VuZGluZyBPL1RXQU1QIG92ZXIgdGhlIGV4aXN0aW5nIElQc2VjIHR1 bm5lbD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RW1tYTogVGhlIGRyYWZ0 IGN1cnJlbnRseSBhaW1zIHRvIGNhcGl0YWxpemUgb24gSVBzZWMgZm9yIGRlcml2aW5nIGtleXMg Zm9yIE8vVFdBTVAuIFdlIHdpbGwgZnVydGhlciBlZGl0IHRoZSBpbnRyb2R1Y3RvcnkgdGV4dCB0 byBhZGRyZXNzIHRoaXMgcG9pbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+LSBbQWJzdHJhY3RdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O2l0IGV4dGVuZHMgdGhlIGFw cGxpY2FiaWxpdHkgb2YgTy9UV0FNUCB0byBuZXR3b3JrcyB0aGF0IGhhdmUgYWxyZWFkeSBkZXBs b3llZCBJUHNlYyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtVbmZvcnR1bmF0ZWx5LCBob3dldmVyLCBz dGFuZGFyZCBJUCBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBzZWN1cml0eSBtZWNoYW5pc21zIGNh bm5vdCBiZSByZWFkaWx5IHVzZWQgd2l0aCBJUHNlYy4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPlRoaXMgZ2l2ZXMgdGhlIGlkZWEgdGhhdCB5b3UgY2Fubm90IHVzZSBPL1RXQU1QIHdp dGggSVBzZWMsIGJ1dCB0aGlzIGlzIG9mIGNvdXJzZSBub3QgdHJ1ZS4gWW91IGNhbiBlLmcuIHNl bmQgTy9UV0FNUCBvdmVyIElQc2VjLCBhbmQgZGVwZW5kaW5nIG9uIHRoZSBJUHNlYyBzZWN1cml0 eSBwb2xpY3kgZGF0YWJhc2UgKFNQRCkgeW91IGNhbiBzZW5kIE8vVFdBTVAgb3V0c2lkZQ0KIG9m IHRoZSBJUHNlYyB0dW5uZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbW1h OiBUaGFua3MgZm9yIHRoZSBjb21tZW50LiBUaGlzIHdhcyBub3Qgb3VyIGludGVudGlvbi4gSW5k ZWVkIE8vVFdBTVAgc2VjdXJpdHkgYW5kIElQc2VjIGNhbiBiZSBkZXBsb3llZCBhbmQgcnVuIHNl cGFyYXRlbHkuIEJ1dCBnaXZlbiB0aGF0IHRoZSBjdXJyZW50bHkgc3RhbmRhcmRpemVkIE8vVFdB TVAgc2VjdXJpdHkgbWVjaGFuaXNtcw0KIG9ubHkgc3VwcG9ydCBwcmUtc2hhcmVkIGtleSBtb2Rl LCBsYXJnZSBzY2FsZSBkZXBsb3ltZW50IGFuZCB1c2UgaXMgaGluZGVyZWQgc2lnbmlmaWNhbnRs eSBhcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LiBEZXBsb3ltZW50IG9mIOKAnHNoYXJlZCBzZWNy ZXRz4oCdIGZvciBtYXNzaXZlIGVxdWlwbWVudCBpbnN0YWxsYXRpb24gaXMgbm90IHRoZSBiZXN0 IGlkZWEgYWZ0ZXIgYWxsLCBJIGhvcGUgeW91IGFncmVlIHdpdGggdGhhdC4gV2Ugd2lsbCBlZGl0 DQogdGhlIHRleHQgdG8gYWRkcmVzcyB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPi0gW1NlY3Rpb24gMV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7SW4gcGFydGljdWxhciwgd2Ugbm90ZSB0 aGF0IGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gdXNlIGRpc3RpbmN0IGtleXMgaW4gT1dBTVAtQ29u dHJvbCBhbmQgT1dBTVAtVGVzdCBsYXllcnMuJm5ic3A7IE9uZSBrZXkgZm9yIGVuY3J5cHRpb24g YW5kIGFub3RoZXIgZm9yIGF1dGhlbnRpY2F0aW9uIGlzIHN1ZmZpY2llbnQgZm9yIGJvdGggQ29u dHJvbCBhbmQgVGVzdCBsYXllcnMuJm5ic3A7DQogVGhpcyBvYnZpYXRlcyB0aGUgbmVlZCB0byBn ZW5lcmF0ZSB0d28ga2V5cyBmb3IgZWFjaCBsYXllciBhbmQgcmVkdWNlcyB0aGUgY29tcGxleGl0 eSBvZiBPL1RXQU1QIHByb3RvY29scyBpbiBhbiBJUHNlYyBlbnZpcm9ubWVudC4mbmJzcDsgVGhp cyBvYnNlcnZhdGlvbiBjb21lcyBmcm9tIHRoZSBmYWN0IHRoYXQgc2VwYXJhdGUgc2Vzc2lvbiBr ZXlzIGluIHRoZSBPV0FNUC1Db250cm9sIGFuZCBPV0FNUC1UZXN0IGxheWVycyB3ZXJlIGRlc2ln bmVkIGZvcg0KIHByZXZlbnRpbmcgcmVmbGVjdGlvbiBhdHRhY2tzIHdoZW4gZW1wbG95aW5nIHRo ZSBjdXJyZW50IG1lY2hhbmlzbS4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYXNz dW1lIE8vVFdBTVAgdXNlcyBkaWZmZXJlbnQga2V5cyBhcyBpcyBpdCBiYWQgc2VjdXJpdHkgZGVz aWduIHRvIHVzZSB0aGUgc2FtZSBrZXkgZm9yIHR3byBkaWZmZXJlbnQgcHVycG9zZXMuIFVzaW5n IHRoZSBzYW1lIGtleSB0d2ljZSBtYXkgbGVhZHMgYSBudW1iZXIgb2Ygc2VjdXJpdHkgcHJvYmxl bXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+LSBJdCBlYXNpbHkgY2F1c2VzIHNvIGNhbGxlZCAmcXVvdDt0d28tdGltZSBw YWRzJnF1b3Q7IHdlcmUgdGhlIGNvbmZpZGVudGlhbGl0eSBpcyB0b3RhbGx5IGNvbXByb21pc2Vk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4tIEZvciBzb21lIGFsZ29yaXRobXMgdGhlIGludGVncml0eSBtYXkgYmUgY29t cHJvbWlzZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBJZiBvbmUgdXNlIG9mIHRoZSBrZXlzIGhhcyBhIGNyeXB0 b2dyYXBoaWMgd2Vha25lc3Mgc28gdGhhbiBhbiBhdHRhY2tlciBjYW4gcmVjb3ZlciB0aGUga2V5 LCB0aGUgYXR0YWNrZXIgaGFzIHRoZSB1c2UgdGhhdCBrZXkgdG8gYXR0YWNrIGJvdGggdXNlcyBv ZiB0aGUga2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4tIEl0IGdpdmVzIGFuIGF0dGFja2VyIHR3aWNlIGFzIG11Y2gg bWF0ZXJpYWwgKHByb3RlY3RlZCB0cmFmZmljKSB0byB3b3JrIHdpdGguPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhl cmVmb3JlIHN0cm9uZ2x5IHJlY29tbWVuZHMgYWdhaW5zdCB1c2luZyB0aGUgc2FtZSBrZXkgdHdp Y2UgdW5sZXNzIHlvdSBtdXN0LCBhbmQgaW4gdGhpcyBjYXNlIHdlIGRvIG5vdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVtbWE6IFdlbGwsIHRoZSBkcmFmdCBkb2VzIG5vdCBl eGNsdWRlIHRoZSB1c2Ugb2YgZGlzdGluY3Qga2V5cy4gQWN0dWFsbHkgdGhlcmUgYXJlIHRocmVl IG9wdGlvbnMgKGJhc2ljICYjNDM7IDIgYWx0ZXJuYXRpdmVzKSBpbiB0aGUgZHJhZnQgYW5kIHdl IGhhdmUgYWxyZWFkeSBjYWxsZWQgZm9yIGFjdGl2ZSBkaXNjdXNzaW9uIGluIHRoZQ0KIFdHIG9u IHdoaWNoIG9uZSBpcyBiZXR0ZXIsIGFuZCB3ZSBhcHByZWNpYXRlIG9wZW5pbmcgdGhlIHRlY2hu aWNhbCBkaXNjdXNzaW9uIG9uIHRoaXMgbWF0dGVyLiBUaGUgdGhyZWF0cyBhYm92ZSBjYW4gYmUg Y29uc2lkZXJlZCB3aGVuIGRldGVybWluaW5nIHdoaWNoIG9wdGlvbiBzaG91bGQgYmUgc3RhbmRh cmRpemVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gW1NlY3Rpb24gMy4xXTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGUgU2VydmVyLVN0YXJ0IG1lc3NhZ2Ugd2l0aCBTZXJ2ZXItSVYgaXMgbWlzc2luZyBm cm9tIHRoZSB0ZXh0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlN1Z2dlc3Rpb246PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O0luIHRo ZSBhdXRoZW50aWNhdGVkIGFuZCBlbmNyeXB0ZWQgbW9kZXMsIGFsbCBmdXJ0aGVyIGNvbW11bmlj YXRpb24gaXMgZW5jcnlwdGVkIHVzaW5nIHRoZSBBRVMgU2Vzc2lvbi1rZXkgYW5kIGF1dGhlbnRp Y2F0ZWQgd2l0aCB0aGUgSE1BQyBTZXNzaW9uLWtleS4mbmJzcDsgQWZ0ZXIgcmVjZWl2aW5nIFNl dC1VcC1SZXNwb25zZSB0aGUgc2VydmVyIHJlc3BvbmRzIHdpdGggYSBTZXJ2ZXItU3RhcnQNCiBt ZXNzYWdlIGNvbnRhaW5pbmcgU2VydmVyLUlWLiBUaGUgY2xpZW50IGVuY3J5cHRzIGV2ZXJ5dGhp bmcgaXQgdHJhbnNtaXRzIHRocm91Z2ggdGhlIGp1c3QtZXN0YWJsaXNoZWQgTy9UV0FNUC1Db250 cm9sIGNvbm5lY3Rpb24gdXNpbmcgc3RyZWFtIGVuY3J5cHRpb24gd2l0aCBDbGllbnQtSVYgYXMg dGhlIElWLiZxdW90Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbW1hOiBP SyB3aXRoIHRoaXMgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIFtT ZWN0aW9uIDRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgJnF1b3Q7SVBzZWMgU0EmcXVvdDsgaXMgb2xkIHRl cm1pbm9sb2d5IGZvciBJS0UodjEpLCBhbGwgb2NjdXJyZW5jZXMgc2hvdWxkIGJlIGNoYW5nZWQg dG8gJnF1b3Q7Q2hpbGQgU0EmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5FbW1hOiBPSyB3aXRoIHRoaXMgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBbU2VjdGlvbiA0XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtUaGVyZWZv cmUsIGV2ZW4gaWYgdGhlIHBlZXJzIGNob29zZSB0byBvcHQgZm9yIHRoZSB1bmF1dGhlbnRpY2F0 ZWQgbW9kZSwgSVBzZWMgaW50ZWdyaXR5IHByb3RlY3Rpb24gaXMgZXh0ZW5kZWQgdG8gTy9UV0FN UC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgdGhlIGRvY3VtZW50IHdvdWxkIGJl IGltcHJvdmVkIGJ5IGRpc2N1c3NpbmcgdGhpcyBhbmQgb3RoZXIgb3B0aW9uczoNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Ty9UV0FNUCB1bmF1dGhlbnRpY2F0ZWQgb3ZlciBleGlzdGluZyBD aGlsZCBTQSB3aXRoIGludGVncml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Ty9UV0FNUCB1bmF1dGhlbnRpY2F0ZWQg b3ZlciBleGlzdGluZyBDaGlsZCBTQSB3aXRoIGVuY3J5cHRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk8vVFdBTVAg dW5hdXRoZW50aWNhdGVkIG92ZXIgZXhpc3RpbmcgQ2hpbGQgU0Egd2l0aCBlbmNyeXB0aW9uIGFu ZCBpbnRlZ3JpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk8vVFdBTVAgdW5hdXRoZW50aWNhdGVkIG92ZXIgbmV3IENo aWxkIFNBIHdpdGggZW5jcnlwdGlvbiBhbmQgb3IgaW50ZWdyaXR5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+aW4gYSBzZXBhcmF0ZSBzZWN0aW9uIGJlZm9yZSB0aGUgc2VjdGlvbiBvbiBleHRy YWN0aW5nIGtleWluZyBtYXRlcmlhbC4gSXQgbWF5IHZlcnkgd2VsbCBiZSB0aGUgY2FzZSB0aGF0 IE8vVFdBTVAgdW5hdXRoZW50aWNhdGVkIG92ZXIgdGhlIGV4aXN0aW5nIENoaWxkIFNBIGZ1bGZp bGxzIHRoZSB1c2VyJ3Mgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+RW1tYTogVGhlIG9wdGlvbnMgbGlzdGVkIGFib3ZlIGV4aXN0ZWQuIEJ1 dCBpbiB0aGlzIGNhc2UsIE8vVFdBTVAgbGF5ZXIgc2hvdWxkIG9idGFpbiB0aGUgaW5mb3JtYXRp b24gYWJvdXQgSVBzZWMgbGF5ZXIgZmlyc3QgKGUuZy4gQ2hpbGQgU0Egd2l0aCBpbnRlZ3JpdHkg YW5kL29yIGVuY3J5cHRpb24pLiBUaGUgaW50ZXJhY3Rpb24NCiBiZXR3ZWVuIE8vVFdBTVAgbGF5 ZXIgYW5kIElQc2VjIGxheWVyIHdpbGwgaW5jcmVhc2UuPG86cD48L286cD48L3NwYW4+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gW1NlY3Rpb24gMy40XTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtJZiB0 aGUgQUggcHJvdG9jb2wgaXMgdXNlZCwgSVAgcGFja2V0cyBhcmUgdHJhbnNtaXR0ZWQgaW4gcGxh aW50ZXh0LiBUaGUgYXV0aGVudGljYXRpb24gcGFydCBjb3ZlcnMgdGhlIGVudGlyZSBwYWNrZXQu Jm5ic3A7IFNvIGFsbCB0ZXN0IGluZm9ybWF0aW9uLCBzdWNoIGFzIFVEUCBwb3J0IG51bWJlciwg YW5kIHRoZSB0ZXN0IHJlc3VsdHMgd2lsbCBiZSB2aXNpYmxlIHRvIGFueQ0KIGF0dGFja2VyLCB3 aGljaCBjYW4gaW50ZXJjZXB0IHRoZXNlIHRlc3QgcGFja2V0cywgYW5kIGludHJvZHVjZSBlcnJv cnMgb3IgZm9yZ2UgcGFja2V0cyB0aGF0IG1heSBiZSBpbmplY3RlZCBkdXJpbmcgdGhlIHRyYW5z bWlzc2lvbi4mbmJzcDsgSW4gb3JkZXIgdG8gYXZvaWQgdGhpcyBhdHRhY2ssIHRoZSByZWNlaXZl ciBtdXN0IHZhbGlkYXRlIHRoZSBpbnRlZ3JpdHkgb2YgdGhlc2UgcGFja2V0cyB3aXRoIHRoZSBu ZWdvdGlhdGVkIHNlY3JldCBrZXkuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyB0 aGUgcGFja2VnZXMgYXJlIGF1dGhlbnRpY2F0ZWQgYW4gYXR0YWNrZXIgY2Fubm90IGZvcmdlIG9y IGluamVjdCBlcnJvcnMuJm5ic3A7IEFuZCBhcyB0aGUgcGFja2FnZXMgYXJlIG5vdCBlbmNyeXB0 ZWQsIHJlYWRpbmcgdGhlIGluZm9ybWF0aW9uIGNhbm5vdCBiZSBjb25zaWRlcmVkIGFuIGF0dGFj ay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgc3VnZ2VzdCBkZWxldGluZyAmcXVvdDsgdG8g YW55IGF0dGFja2VyLCB3aGljaCBjYW4gaW50ZXJjZXB0IHRoZXNlIHRlc3QgcGFja2V0cywgYW5k IGludHJvZHVjZSBlcnJvcnMgb3IgZm9yZ2UgcGFja2V0cyB0aGF0IG1heSBiZSBpbmplY3RlZCBk dXJpbmcgdGhlIHRyYW5zbWlzc2lvbi4mbmJzcDsgSW4gb3JkZXIgdG8gYXZvaWQgdGhpcyBhdHRh Y2ssIHRoZSByZWNlaXZlciBtdXN0IHZhbGlkYXRlDQogdGhlIGludGVncml0eSBvZiB0aGVzZSBw YWNrZXRzIHdpdGggdGhlIG5lZ290aWF0ZWQgc2VjcmV0IGtleS4gPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5FbW1hOiBPSyB3aXRoIHRoaXMgc3VnZ2VzdGlvbi48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4tIFtTZWN0aW9uIDMuNCwgU2VjdGlvbiA0XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtJZiBFU1AgaXMg dXNlZCwgSVAgcGFja2V0cyBhcmUgZW5jcnlwdGVkJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O1doZW4g dXNpbmcgRVNQLCBhbGwgSVAgcGFja2V0cyBhcmUgZW5jcnlwdGVkJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGlzIGlzIG5vdCB0cnVlIGFzIEVTUCBjYW4gYmUgdXNlZCB3aXRoIG9u bHkgaW50ZWdyaXR5IHByb3RlY3Rpb24gKE5VTEwgY2lwaGVyKS4gSW4gZmFjdCwgSSB0aGluayB0 aGlzIGlzIGZhciBtb3JlIGNvbW1vbiB0aGFuIHVzaW5nIEFILiBJbnN0ZWFkIG9mIHN0YXJ0IHRh bGtpbmcgYWJvdXQgQUgsIEkgdGhpbmsgdGhlIGRyYWZ0IGNvdWxkIGxpc3QgdGhlIHRocmVlIGRp ZmZlcmVudA0KIEVTUCBvcHRpb25zIChpbnRlZ3JpdHkgYW5kL29yIGVuY3J5cHRpb24pIGFuZCB0 aGVuIGhhdmUgYSBub3RlIHN0YXRpbmcgdGhhdCBmb3IgQUggaGF2ZSBzaW1pbGFyIHByb3BlcnRp ZXMgYXMgRVNQIHdpdGggTlVMTCBjaXBoZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5FbW1hOiBPSyB3aXRoIHRoaXMgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBbU2VjdGlvbiA0XTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tIGEgc2Vj dXJpdHkgcGVyc3BlY3RpdmUgaXQgd291bGQgYmUgdmVyeSBiYWQgdG8gYWxsb3cgZXh0cmFjdGlv biBvZiBTS0VZU0VFRCBvciBLRVlNQVQuIFRoZXkgY291bGQgYmUgdXNlZCB0byBwYXNzaXZlbHkg ZWF2ZXNkcm9wIG9uIHRoZSBJUHNlYyB0cmFmZmljIG9yIHRvIGFsdGVyL2luamVjdCBtZXNzYWdl cy4gRXZlbiBpZiB3ZSB0cnVzdCB0aGUgTy9UV0FNUCBhcHBsaWNhdGlvbg0KIHRvIG5vdCBiZSBt YWxpY2lvdXMsIHVzZSBvZiB0aGUgc2FtZSBrZXkgaW4gYW5vdGhlciBhcHBsaWNhdGlvbiBtYXkg Y2F1c2Ugc2VjdXJpdHkgcHJvYmxlbXMgc3VjaCBhcyB0d28tdGltZSBwYWQsIHdoaWNoIGNvbXBs ZXRlbHkgY29tcHJvbWlzZXMgdGhlIGNvbmZpZGVudGlhbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkEgc2VjdXJlIHNvbHV0aW9uIHdvdWxkIGJlIHRoYXQgdGhlIElQc2VjIEFQSSByZXR1 cm5zIGEga2V5IHRoYXQgaXMgZGVyaXZlZCBmcm9tIHNvbWUgb2YgSVBzZWMga2V5aW5nIG1hdGVy aWFsLiBFLmcuIGEgbmV3ICZxdW90O0tFWU1BVCZxdW90OyBkZXJpdmVkIHVzaW5nIHNvbWUgbmV3 IHJhbmRvbSBtYXRlcmlhbCBpbnN0ZWFkIG9mIChOaSxOciksIGUuZy46PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5TaGFyZWQgc2VjcmV0ID0gcHJmJiM0MzsoIFNLX2QsIFNJRCApIDxvOnA+DQo8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5PciBhIGtleSBkZXJpdmVkIGZyb20gS0VZTUFUOiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlNoYXJlZCBzZWNyZXQgPSBQUkYoIEtFWU1BVCwgU0lEICkgPG86 cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgc3Ryb25nbHkgc3VnZ2VzdCByZW1vdmluZyB0aGUg b3B0aW9ucyB0aGF0IGV4cG9zZXMgdGhlIElQc2VjIGtleWluZyBtYXRlcmlhbCwgb25seSBrZWVw aW5nIHNlY3VyZSBvcHRpb25zLCBhbmQgYWRkaW5nIHRleHQgZGVzY3JpYmluZyB0aGF0IGl0IGlz IHRoZSBJUHNlYyBpbXBsZW1lbnRhdGlvbiB0aGF0IHBlcmZvcm1zIHRoZSBrZXkgZGVyaXZhdGlv bnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbW1hOiBXZSBhZ3JlZSB0aGF0 IGZyb20gYSBzZWN1cml0eSBwb3YgZGVyaXZpbmcgc2hhcmVkIGtleSBhdCBJUHNlYyBpcyBhIGJl dHRlciBjaG9pY2UuIFdlIGNhbiBjb25zaWRlciB0aGF0IGluIG5leHQgdmVyc2lvbi48bzpwPjwv bzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LSBbU2VjdGlvbiA0XTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5XaGlsZSBleHRyYWN0aW5nIGtleWluZyBtYXRlcmlhbCBmcm9tIElQc2VjIHdvdWxkIGJl IG5pY2UsIHRvIG15IGtub3dsZWRnZSB0aGVyZSBpcyBubyBzdGFuZGFyZGl6ZWQgKG9yIGRlIGZh Y3RvIHN0YW5kYXJkKSBBUEkgdG8gZXh0cmFjdCBTS0VZU0VFRCwgU0tfZCwgS0VZTUFUIG9yIGV2 ZW4gU1BJIGZyb20gYW4gSVBzZWMgaW1wbGVtZW50YXRpb24uIFRoaXMgd2FzIGV2ZW4NCiBvbmUg b2YgdGhlIHJlYXNvbnMgSVBzZWMgd2FzIG5vdCBjaG9zZW4gYXMgdGhlIGRlZmF1bHQgc2VjdXJp dHkgcHJvdG9jb2wgZm9yIE8vVFdBTVAuIFlvdSBjb3VsZCBvZiBjb3Vyc2UgZG8gaXQgd2l0aCBh IG5ldyBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbiwgYnV0IHRoYXQga2luZCBvZiBiZWF0cyBz b21lIG9mIHRoZSBwdXJwb3NlIGZyb20gdGhlIEFic3RyYWN0ICZxdW90O2dhaW5pbmcgcG9wdWxh cml0eSBpbiBzZXZlcmFsIGRlcGxveW1lbnQgc2NlbmFyaW9zJnF1b3Q7LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+V29yayBvbiBhbiBJUHNlYyBBUEkgc3RhcnRlZCBhIGNvdXBsZSBhIHllYXJz IGFnbw0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1idG5z LWlwc2VjLWFwaXJlcS0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1i dG5zLWlwc2VjLWFwaXJlcS0wMDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+YnV0IGRpZWQsIGFuZCBldmVuIHRoYXQg d29yayBkaWQgcHJvaGliaXQgZXh0cmFjdGlvbiBvZiBrZXlpbmcgbWF0ZXJpYWwgYW5kIGRpc2Nv dXJhZ2VkIHRoZSBleHRyYWN0aW9uIG9mIFNQSSBhcyB0aGUgU1BJIG1pZ2h0IGNoYW5nZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhhcyB0aGUgQVBJIHByb3Bvc2FscyBiZWVuIGRpc2N1c3Nl ZCBpbiB0aGUgaXBzZWNtZSB3b3JraW5nIGdyb3VwPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+RW1tYTogV2UgcmVjZWl2ZWQgdGhpcyBjb21tZW50IGF0IHRoZSBsYXN0IG1lZXRp bmcgKEkgdGhpbmsgaXQgd2FzIFlvYXYgd2hvIGNvbW1lbnRlZCBvbiB0aGF0KS4gV2UgYmVsaWV2 ZSB0aGF0IHRoaXMgaXMgaW4gZmFjdCBpbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQuIEZvciBleGFt cGxlLCBmb3IgdGhvc2Ugd2l0aCBleGlzdGluZw0KIElQc2VjIGFuZCBPL1RXQU1QIGltcGxlbWVu dGF0aW9ucyB0aGlzIHNob3VsZCBub3QgYmUgYSBibG9ja2luZyBwb2ludC4gSWYgdGhlcmUgd2Fz IGEg4oCcc3RhbmRhcmTigJ0gQVBJLCB0aGlzIHByb3RvY29sIGNvdWxkIGJlbmVmaXQuIEJ1dCB3 aGF0IHdl4oCZcmUgaW50ZXJlc3RlZCBwcmltYXJpbHkgaGVyZSBpcyBPL1RXQU1QIGRlcGxveW1l bnQgYXQgbGFyZ2Ugc2NhbGUgYW5kIGZvciBuZXR3b3JrcyB0aGF0IGhhdmUgYWxyZWFkeSBkZXBs b3llZCBJUHNlYy48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0gW1NlY3Rpb24gNF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSB0aGluayB0aGUgYXBwcm9h Y2ggaW4gU2VjdGlvbiA0IHdpdGggZXh0cmFjdGluZyBrZXlpbmcgbWF0ZXJpYWwgd291bGQgb25s eSB3b3JrIHdpdGggYSBwcm9wcmlldGFyeSBJUHNlYyBpbXBsZW1lbnRhdGlvbiBhbmQgbW9kaWZp Y2F0aW9ucyAoYWRkaW5nIG5ldyBmaWVsZHMpIHRvIE8vVFdBTVAuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5IYXZlIGFwcHJvYWNoZXMgdGhhdCBkbyBub3QgcmVxdWlyZSBleHRyYWN0aW5nIGtl eWluZyBpbmZvcm1hdGlvbiBiZWVuIGNvbnNpZGVyZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5FbW1hOiBJIHRoaW5rIHdlIGNvdWxkIGRpc2N1c3MgdGhpcyBpbiBWYW5jb3V2 ZXIuIEluIHRoZSBtZWFudGltZSwgZG8geW91IGhhdmUgdGV4dCB0byBzdWdnZXN0PzxvOnA+PC9v OnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGUgQ2hpbGQgU0EgaXMg ZW5jcnlwdGVkLCBhIHNpbXBsZXIgYXBwcm9hY2ggd291bGQgYmUgdG8gdHJhbnNmZXIgdGhlIE8v VFdBTVAgc2hhcmVkIHNlY3JldCBpbiBhIHNpbWlsYXIgbWFubmVyIGFzIHRoZSBPL1RXQU1QIHNl c3Npb24ga2V5LCBlLmcuIGluIHRoZSBLZXlJRCBmaWVsZC4gVGhpcyB3b3VsZCBqdXN0IHJlcXVp cmUgY2hhbmdlcyB0byB0aGUgZnVuY3Rpb24NCiBpbiB0aGUgTy9UV0FNUCB0aGF0IHJlY2VpdmVz IHRoZSBzaGFyZWQgc2VjcmV0LCBhbmQgbm8gbW9kaWZpY2F0aW9ucyB0byBJUHNlYy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkF0IGxlYXN0IGlmIHRoZSBDaGlsZCBTQSBpcyBpbnRlZ3JpdHkg cHJvdGVjdGVkLCBvbmUgYXBwcm9hY2ggd291bGQgYmUgdG8gdXNlIERpZmZpZS1IZWxsbWFuIGlu IE8vVFdBTVAuIFRoaXMgd291bGQgc3RpbGwgcmVxdWlyZSBuZXcgTy9UV0FNUCBmaWVsZHMgYnV0 IHN0aWxsIGJlIGVhc2llciB0aGFuIHRoZSBjdXJyZW50IHN1Z2dlc3Rpb24gYXMgaXQgZG9lcyBu b3QgcmVxdWlyZQ0KIGFueSBjaGFuZ2VzIHRvIElQc2VjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+QSBwcm9ibGVtIGlzIHN0aWxsIHRoZSBsYWNrIG9mIEFQSSB0byBmaW5kIG91dCB3aGV0aGVy IGVuY3J5cHRpb24gb3IgaW50ZWdyaXR5IGlzIGluIHVzZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1pbm9yIGVkaXRvcmlhbCBjb21tZW50cyBvbiBkcmFmdC1p ZXRmLWlwcG0taXBzZWMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4tIFtzMy4xXSAmcXVvdDtPV0FNUC1Db250cm9sIGNvbW1hbmRzJnF1b3Q7IC0mZ3Q7ICZx dW90O08vVFdBTVAtQ29udHJvbCBjb21tYW5kcyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+LSBbczRdICZxdW90O211c3QgYmUgZ2VuZXJhdGVkIGZpcnN0bHkmcXVvdDsgLSZndDsgJnF1 b3Q7bXVzdCBiZSBnZW5lcmF0ZWQgZmlyc3QmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi Pi0gW3M0XSAmcXVvdDtzZXNzaW9uIElEIGlzIGlzIHRoZSZxdW90OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+RW1tYTogT0sgd2l0aCB0aGVzZSBlZGl0b3JpYWwgY29tbWVudHMu PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkpPSE4gTUFUVFNTT048bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TVNjIEVuZ2luZWVyaW5nIFBoeXNpY3Ms IE1TYyBCdXNpbmVzcyBBZG1pbmlzdHJhdGlvbiBhbmQgRWNvbm9taWNzIFNlbmlvciBSZXNlYXJj aGVyLCBTZWN1cml0eQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Fcmljc3NvbiBBQjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5TZWN1cml0eSBSZXNlYXJjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5GPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPsOkPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj5yPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPsO2PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij5nYXRhbiA2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Q aG9uZSAmIzQzOzQ2IDEwIDcxIDQzIDUwMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TTVMvTU1TICYjNDM7NDYgNzYgMTEg NTMgNTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPmpvaG4ubWF0dHNzb24gYXQgZXJpY3Nzb24uY29tPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxh IGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+d3d3LmVyaWNzc29uLmNvbTwvc3Bhbj48L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPmlw cG0gbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aXBwbUBp ZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXBwbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBwbTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE92CE3FCF47934CBAE2CCECE119606C6338C6B6nkgeml507mbschi_-- From turners@ieca.com Fri Nov 1 06:19:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366FC21E84AC for ; Fri, 1 Nov 2013 06:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJhwH48DTfuw for ; Fri, 1 Nov 2013 06:19:09 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [67.18.65.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2187621E83FA for ; Fri, 1 Nov 2013 06:14:46 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id AD291B7D03CF7; Fri, 1 Nov 2013 08:14:38 -0500 (CDT) Received: from ham07.websitewelcome.com (unknown [192.185.0.198]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 9DE32B7D03CA9 for ; Fri, 1 Nov 2013 08:14:38 -0500 (CDT) Received: by ham07.websitewelcome.com (Postfix, from userid 500) id 95871460004; Fri, 1 Nov 2013 08:14:38 -0500 (CDT) X-Spam-Flag2999: NO X-Spam-Level2999: X-Spam-Status2999: "No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by ham07.websitewelcome.com (Postfix) with ESMTP id 1A299460021 for ; Fri, 1 Nov 2013 08:14:38 -0500 (CDT) Received: from [65.114.90.17] (port=20987 helo=[172.26.31.170]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VcEYf-0005Tn-OH for ipsec@ietf.org; Fri, 01 Nov 2013 08:14:37 -0500 From: Sean Turner Content-Type: multipart/signed; boundary="Apple-Mail=_C57239E6-840D-4A44-9C6F-450C72EFF27D"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Date: Fri, 1 Nov 2013 08:26:59 -0400 References: <52602C06.8040401@gmail.com> <22341.1382110134@sandelman.ca> To: IPsecme WG In-Reply-To: <22341.1382110134@sandelman.ca> X-Mailer: Apple Mail (2.1816) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.26.31.170]) [65.114.90.17]:20987 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 26 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: Re: [IPsec] Call for adoption: draft-kivinen-ipsecme-ikev2-rfc5996bis-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 13:19:14 -0000 --Apple-Mail=_C57239E6-840D-4A44-9C6F-450C72EFF27D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m incredibly biased here but I would really like to see this = document progress. If we have the data that allows up to move to IS = then I think we should do it. spt On Oct 18, 2013, at 11:28, Michael Richardson = wrote: >=20 > Yaron Sheffer wrote: >> We would like to progress IKEv2 to Internet Standard, and the way we = do >> it is by re-publishing it with slight modifications (basically = editing >> for existing errata and adding references to documents published = since >=20 > Good. >=20 >> the original RFC). A draft already exists, thanks Tero [1]. If we do >> not hear significant objections, we would like to adopt the document = as >> a WG document by Monday, Oct. 21. >=20 > +1. >=20 > -- > Michael Richardson , Sandelman Software Works >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_C57239E6-840D-4A44-9C6F-450C72EFF27D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMTEwMTEyMjY1OVowIwYJKoZIhvcNAQkEMRYEFO9TA+zid2hnsOeTaGGFKtPw 9W4xMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQA631Zk6wm8SoarbVovmGTyMc3f mNtu9+rFrKVwhnifFG2dCmYRKKSFcaGiobh2gjRq7jaNuHxJakrQHI4pFi9EfPBB+Te/k6y9D/aZ 0hNTW3pvZwawJqMCNBAixGvJLMhyGL8O6MvKfzkekWAKl//QFgv5XQJIZ7Xrbd3N9Iq831Llh2Bk prGU8LTCh9rh84oRdQqHB9e1ud5nIPhrm6cEKmRf7tp9joACL/vBAH8hVmbm57gBn/oMv+FJ0nQo ninLhXDq+RmahlWQ7Ypr1+a9vG+rnjLPV6rgrA8RTU/xzGRWwUxtB1XrTgYTHULmYCOoF60AdNKf x9LvT/+DdMIAAAAAAAAA --Apple-Mail=_C57239E6-840D-4A44-9C6F-450C72EFF27D-- From paul.hoffman@vpnc.org Fri Nov 1 09:43:56 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4711E825A for ; Fri, 1 Nov 2013 09:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycdLWCeD751x for ; Fri, 1 Nov 2013 09:43:55 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A9DF011E8257 for ; Fri, 1 Nov 2013 09:43:55 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rA1GhpMS008891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Nov 2013 09:43:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Nov 2013 09:43:51 -0700 Message-Id: <29B3A0D8-14C8-4FD8-81DA-039552375DDB@vpnc.org> To: "ipsec@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) X-Mailer: Apple Mail (2.1816) Cc: Valery Smyslov Subject: [IPsec] End of WG LC on draft-ietf-ipsecme-ikev2-fragmentation; next steps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:43:56 -0000 Thank you to everyone for the lively review of = draft-ietf-ipsecme-ikev2-fragmentation; this is the kind of energy we = can really use in the WG. Valery: please prepare a new draft based on = the comments received. Please include discussion of points even if they = don't become technical changes in the draft; this will help future = developers understand more about what the protocol is doing. --Paul Hoffman= From mcr@sandelman.ca Fri Nov 1 16:33:17 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B04221E808D for ; Fri, 1 Nov 2013 16:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3RGFkKgQzw1 for ; Fri, 1 Nov 2013 16:33:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id EE89C11E817B for ; Fri, 1 Nov 2013 16:32:59 -0700 (PDT) Received: from sandelman.ca (unknown [204.239.250.1]) by relay.sandelman.ca (Postfix) with ESMTPS id 6D5962207C for ; Fri, 1 Nov 2013 19:32:58 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1D3DECA0D6 for ; Fri, 1 Nov 2013 16:22:59 -0400 (EDT) From: Michael Richardson To: IPsecme WG In-reply-to: <5268387A.1060509@gmail.com> References: <5268387A.1060509@gmail.com> Comments: In-reply-to Yaron Sheffer message dated "Wed, 23 Oct 2013 23:58:34 +0300." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Message-Id: <20131101202259.1D3DECA0D6@sandelman.ca> Date: Fri, 1 Nov 2013 16:22:59 -0400 (EDT) Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 23:33:17 -0000 : signature: ~/.signature.ietf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Nov 2013 16:22:58 -0400 Message-ID: <13218.1383337378@sandelman.ca> Sender: mcr@sandelman.ca --=-=-= Content-Transfer-Encoding: quoted-printable I have read all three proposals, although I missed the Q&A in Berlin. I am looking forward to further Q&A in Berlin. When I read the NBMA protocol (DMVPN, I think) version what I saw was a ver= y brilliant hack=20=20 that managed to take two code bases (IPsec and ATM) that were likely alread= y present in that vendor's firmware and connect them. Likely, it took only a few wee= ks of brilliant hacking, and it was ready for customer use. I find that this solution for anyone else involves the most amount of new c= ode, and I think it will the most difficult to support on various mobile and lap= top=20 platforms as it requires new encapsulation modes. draft-mao-ipsecme is architecturally the closest to me, and I like the ADS = idea: it seems that it be implemented without any new kernel code, and I think that = if we are trying=20 to get remote warrior and branch office RTP traffic to take a more direct r= oute, then=20 eliminating the need for a more network plumbing, and just doing things in = IKE is the right answer. (%) I don't like having a new protocol: I want it in IKE. While it can and sho= uld run inside the tunnel, I don't see why adding a new port to my IKE daemon m= akes my life easier.=20=20 I do like the way that DMVPN uses probe packets to discover the end points = of the shorter routes, and I would look forward to including that mechanism.= =20=20 I don't like that DMVPN does not let http traffic continue to travel via HQ= 's virus/trojan/netnanny while RTP takes the shortcut. (%)- the plumbing might need a way to sample 5-tuple flows to see if there is traffic that should be shortcut. However, various schemes to put more specific SPD entries in that cause key requests might accomplish this witho= ut=20 new kernel code. Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJSdA2iAAoJEKD0KQ7Gj3P2TSgIAKstL3ktU0yg18WbKEcLAZgo Jk1+kz3uhCVJFPp4xv/yTK7EoLzfLmkq8j9WxOWVUCf6wQwoPVEt3MbVYfmlF2Tb 5fq7+olrzPJbjZDZ6zxMB6M8Em8vhT8SufDlSEpOqXOHsVpok3ptkGJrbAKKLfIK QY3CD72yXiaB2OP3mL1DpGc+QRynFiZ5YKzeA9hxo9KzEHdifCsj4tm87OYLGrsZ vnPJXKsxh4fpgP4jpNPRHj+J5YKpLKPqXLAs9LHLpN4ylzmirKSbGZhynxrb7Agr fqhc9ICcFubyjQO8E0eHU4Vu9P+p/shE21nMANiikffyLd16PJvZ2U45ollKEEY= =JGZg -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 1 16:33:17 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA3921E8091 for ; Fri, 1 Nov 2013 16:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+UpKs-JLCgh for ; Fri, 1 Nov 2013 16:33:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9DA21E8063 for ; Fri, 1 Nov 2013 16:32:59 -0700 (PDT) Received: from sandelman.ca (unknown [204.239.250.1]) by relay.sandelman.ca (Postfix) with ESMTPS id 58ABA2207F; Fri, 1 Nov 2013 19:32:59 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BCA29CA0D4; Fri, 1 Nov 2013 16:07:12 -0400 (EDT) From: Michael Richardson To: Tero Kivinen In-reply-to: <21077.33006.734392.994194@fireball.kivinen.iki.fi> References: <21077.33006.734392.994194@fireball.kivinen.iki.fi> Comments: In-reply-to Tero Kivinen message dated "Wed, 09 Oct 2013 19:14:38 +0300." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Message-Id: <20131101200712.BCA29CA0D4@sandelman.ca> Date: Fri, 1 Nov 2013 16:07:12 -0400 (EDT) Cc: ipsec@ietf.org Subject: Re: [IPsec] Update to RFC4307 too? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 23:33:17 -0000 : signature: ~/.signature.ietf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Nov 2013 16:07:12 -0400 Message-ID: <12617.1383336432@sandelman.ca> Sender: mcr@sandelman.ca --=-=-= {catching up on old email} Tero Kivinen wrote: > Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ to SHOULD. this is the only one which I didn't understand. Michael Richardson -on the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJSdAnwAAoJEKD0KQ7Gj3P2qG4H/RWo1qaMIwUcEzrAaI2oa4C0 UAwm8iEulhpFDv8bbAAD45Zn+DvQG7B/2K+IKK9O5yrgzZgH7elyJx8lCNIVIuGx JqyuV8Z0xUgM1VTx7yRlZFcTZK7k9Sv/wcrsB91LklBphGU/TZwpGUkiGjkmkJQx nXJ+GrnoaTvR8UUIZ+7Zpdb1omYNqcUtd6Nn44Gsw++26jB1h0T5i8KFPPDBtU6o KeF+OwXUHjSS8C0OsXybog1+RLWyB9g3g5y9VRWF39l6ikkqv7JPwTZo715i4irF jQ9m4Hg73rcffXA9cKzKq+rRU3IBySWSdbCvuo4OmmCm2IGwjpvZ5n2qNn2ta+0= =48tP -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Fri Nov 1 18:40:06 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706EB11E810C for ; Fri, 1 Nov 2013 18:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KhHOtLk-YJz for ; Fri, 1 Nov 2013 18:40:00 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2AE11E80E7 for ; Fri, 1 Nov 2013 18:39:59 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA21dr29017657; Sat, 2 Nov 2013 03:39:57 +0200 X-CheckPoint: {527456BD-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sat, 2 Nov 2013 03:39:53 +0200 From: Yoav Nir To: Michael Richardson Thread-Topic: [IPsec] Update to RFC4307 too? Thread-Index: AQHOxQqwKqQBMmw3JUKcFuh5WpFUTpoQ0EoAgABc6oA= Date: Sat, 2 Nov 2013 01:39:52 +0000 Message-ID: <22A8109D-6669-4FBC-9FE8-5522E4AABDC3@checkpoint.com> References: <21077.33006.734392.994194@fireball.kivinen.iki.fi> <20131101200712.BCA29CA0D4@sandelman.ca> In-Reply-To: <20131101200712.BCA29CA0D4@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.206] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <1A953B4B184A7742B37C3BD5A53A210B@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Tero Kivinen Subject: Re: [IPsec] Update to RFC4307 too? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 01:40:06 -0000 On Nov 1, 2013, at 10:07 PM, Michael Richardson wro= te: > Tero Kivinen wrote: >> Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ to S= HOULD. >=20 > this is the only one which I didn't understand. >=20 Which one? There's two parts there. AES-XCBC was supposed to take the world over by storm from the HMAC constru= ctions. Except it didn't - everybody still uses HMAC-SHA1, it's still consi= dered secure, and those who don't use HMAC-SHA1, use GHASH. So we no longer= expect this to become a MUST in the future, hence the removal of the "+". Yoav From mcr@sandelman.ca Sat Nov 2 12:14:13 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB4621E80E2 for ; Sat, 2 Nov 2013 12:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiVPrvVMKWp1 for ; Sat, 2 Nov 2013 12:14:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8821E80D8 for ; Sat, 2 Nov 2013 12:14:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F99B2016D; Sat, 2 Nov 2013 16:25:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D09D863B88; Sat, 2 Nov 2013 15:14:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BE7E663AED; Sat, 2 Nov 2013 15:14:06 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: <22A8109D-6669-4FBC-9FE8-5522E4AABDC3@checkpoint.com> References: <21077.33006.734392.994194@fireball.kivinen.iki.fi> <20131101200712.BCA29CA0D4@sandelman.ca> <22A8109D-6669-4FBC-9FE8-5522E4AABDC3@checkpoint.com> 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: "" , Tero Kivinen Subject: Re: [IPsec] Update to RFC4307 too? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 19:14:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: >>> Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ >>> to SHOULD. >> this is the only one which I didn't understand. > Which one? There's two parts there. True.=20 So, the "_CBC" to "_XCBC" is either a typo in the email or in the spec, and: > AES-XCBC was supposed to take the world over by storm from the HMAC > constructions. Except it didn't - everybody still uses HMAC-SHA1, it's > still considered secure, and those who don't use HMAC-SHA1, use > GHASH. So we no longer expect this to become a MUST in the future, > hence the removal of the "+". Within the IPsec community, I agree that this is the case, thank you for th= e explanation. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnVO/IqHRg3pndX9AQLkZwQAg4Hf661nWN5Sm/u+PMmw4FToYRQ6XZgx BwcI9b0J6aMKXPTP5ZcOENWOKT8tWKTx/XVGjLR6AIsbTWN/FqKyoxRg1j6z9Tgp uMwd09waoRTmby6PT6hqVEJO+aMOCLMr9OxU+Q5TcXNXxOEdr9nCSEdFbRICYj8C OFOIbn9oypw= =UBhi -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sat Nov 2 12:18:05 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD81A11E8177 for ; Sat, 2 Nov 2013 12:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDMAnXKgEYEr for ; Sat, 2 Nov 2013 12:17:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id BBC4911E814D for ; Sat, 2 Nov 2013 12:17:55 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 69C5B2016D for ; Sat, 2 Nov 2013 16:29:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D697063B88; Sat, 2 Nov 2013 15:17:53 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C33DF63AED for ; Sat, 2 Nov 2013 15:17:53 -0400 (EDT) From: Michael Richardson to: IPsecme WG In-Reply-To: <20131101202259.1D3DECA0D6@sandelman.ca> References: <5268387A.1060509@gmail.com> <20131101202259.1D3DECA0D6@sandelman.ca> 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: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 19:18:05 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {Sorry about that, the email configuration my tablet had a \n in a header that did not belong} I have read all three proposals, although I missed the Q&A in Berlin. I am looking forward to further Q&A in Berlin. When I read the NBMA protocol (DMVPN, I think) version what I saw was a very brilliant hack that managed to take two code bases (IPsec and ATM) that were likely already present in that vendor's firmware and connect them. Likely, it took only a few weeks of brilliant hacking, and it was ready for custome= r use. I find that this solution for anyone else involves the most amount of new c= ode, and I think it will the most difficult to support on various mobile and lap= top=20 platforms as it requires new encapsulation modes. draft-mao-ipsecme is architecturally the closest to me, and I like the ADS idea: it seems that it be implemented without any new kernel code, and I think that if we are trying to get remote warrior and branch office RTP traffic to take a more direct route, then eliminating the need for a more network plumbing, and just doing things in IKE is the right answer. (%) I don't like having a new protocol: I want it in IKE. While it can and should run inside the tunnel, I don't see why adding a new port to my IKE daemon makes my life easier.=20=20 I *do* like the way that DMVPN uses probe packets to discover the end point= s of=20 the shorter routes, and I would look forward to including that mechanism somehow. I don't know how to do that without hacks to the data plane, which I'd like to avoid. I can imagine some ways to do this with a traceroute process, but it seems kludgy and brittle. (really, that's still dataplane, but it's using an existing mechanism) I don't like that DMVPN does not let http traffic continue to travel via HQ= 's virus/trojan/netnanny while RTP takes the shortcut. (%)- the plumbing might need a way to sample 5-tuple flows to see if there is traffic that should be shortcut. However, various schemes to put more specific SPD entries in that cause key requests might accomplish this witho= ut=20=20 new kernel code. =2D- Michael Richardson =2Don the road- =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnVP34qHRg3pndX9AQLRbAQAtA9xl+LReQHugCiXaLLoqCbZxIdYvECF ED+8KN5fNINq9TK65gBFG9+Q0rG586D3Gb/tEJ9XwZ3JgSBtECDXpbKAzRDB8xkY mWxUz2lEEJAXQjTA+B5jVH9BEqP58a6WIut2a9/HAOaj1GLQbxBotodGQp10SgWs HvQMy0yB43Q= =gujj -----END PGP SIGNATURE----- --=-=-=-- From paulsimon.c@gmail.com Mon Nov 4 01:06:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5625911E8146 for ; Mon, 4 Nov 2013 01:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+AczK0OPvEn for ; Mon, 4 Nov 2013 01:06:09 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4545E11E8126 for ; Mon, 4 Nov 2013 01:06:05 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so12074904iet.32 for ; Mon, 04 Nov 2013 01:06:05 -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=y/ZTJpOUQbhbVF6D73hY65EHKfBzE34c+mAkZ//25nw=; b=MDqWY+6OgQ98zsIBvnDHgNXUlz4ZDa7SnKQuaUiYebcmYEw/qsoOPhYjT+ad6zMRVL 7FD6aD9A3i3oOkTqh7n3lQ/WjUycEl81ULEy5WSSODlEkMX5M23tOv60zev0hJLEEQM0 jHzlMvl5MAH1CpQurGZbnVLjlLvRe1JueudGBkdT7pST87fV+XCIUILkVteJUYyOMCRl 0LheNbhBfCIT/DcOkfrss3TTlg91JrmINjLGOyvdfcWi3LEm/i2uHKtP6UrVezlL7/8X OxUn22AD3iSFo98t8z75TIqQ6Oifo/xmXWTcrxlkaJNyD8J3u1vOIFyUFGBqLcrfJ2dz J9CQ== MIME-Version: 1.0 X-Received: by 10.50.23.103 with SMTP id l7mr11138603igf.3.1383555965458; Mon, 04 Nov 2013 01:06:05 -0800 (PST) Received: by 10.64.7.12 with HTTP; Mon, 4 Nov 2013 01:06:05 -0800 (PST) Date: Mon, 4 Nov 2013 14:36:05 +0530 Message-ID: From: Paul Simon To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=089e0158aabad9231404ea5639eb Subject: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 09:06:12 -0000 --089e0158aabad9231404ea5639eb Content-Type: text/plain; charset=ISO-8859-1 Hi, We are having a requirement to have Qos per CHILD SA inside one IKE SA or to have Qos per IKE SA. Is it possible to communicate the Qos in IKE handshake ? Or else how can we achieve to use different Qos, atleast per IKE SA. To give a background on the issue we are working on. In usual LTE and 3G mobile networks before establishing a connection, the UE would sent out the desired Qos details to the mobile network. The network will then decide on what Qos can be granted and then communicate this information to UE. Now people are increasingly using WiFi to connect to mobile network. So we need a secure connection from WiFi UE to network. For this IPsec is being recommended in the standards. So here comes the issue how can the mobile communicate what Qos is preferred to network in IKE handshake. so can any one throw some light on the issue ? Thanks and Regards, Paul Simon --089e0158aabad9231404ea5639eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
=A0
We are havi= ng a requirement to have Qos per CHILD SA inside one IKE SA or to have Qos = per IKE SA. Is it possible to communicate the Qos in IKE handshake ? Or els= e how can we achieve to use different Qos, atleast per IKE SA.
=A0
To give a background on the issue we are working on. In = usual LTE and 3G mobile networks before establishing a connection, the UE w= ould sent out the desired Qos details to the mobile network. The network wi= ll then decide on what Qos can be granted and then communicate this informa= tion to UE.
Now people are increasingly using WiFi to connect to mobile network. S= o we need a secure connection from WiFi UE to network. For this IPsec is be= ing recommended in the standards. So here comes the issue how can the mobil= e communicate what Qos is preferred to network in IKE handshake.
=A0
so can any one throw some light on the issue ?
=A0
=A0
Thanks and Regards,
Paul Simon
= --089e0158aabad9231404ea5639eb-- From ynir@checkpoint.com Mon Nov 4 01:44:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F89021E8136 for ; Mon, 4 Nov 2013 01:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNg58Ar-Pfdr for ; Mon, 4 Nov 2013 01:43:04 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 737A811E81B9 for ; Mon, 4 Nov 2013 01:43:00 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA49gvwe021713; Mon, 4 Nov 2013 11:42:57 +0200 X-CheckPoint: {52776AD1-4-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 11:42:57 +0200 From: Yoav Nir To: Paul Simon Thread-Topic: [IPsec] Query regarding Qos with IKE Thread-Index: AQHO2T0lqIBsUjWJEE+iW3Hntr4dIpoUsHkA Date: Mon, 4 Nov 2013 09:42:56 +0000 Message-ID: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.71] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 09:44:13 -0000 Hi, Paul I'm not sure I understand the issue. IPsec is carrying some IP-based protoc= ol from the UE, through some gateway to a host in the service provider's ne= twork. Those IP packets can have QoS indication like any other IP packets, = through the TOS field in IPv4 or the Traffic Class field in IPv6. Those fie= lds get encrypted and encapsulated with the entire IP packet and come out t= he same at the other side, so they go into the provider network with the sa= me properties. According to RFC 4301, the IPsec packet inherits the ECN and DS fields from= the inner packet. See sections 5.1.2.1 and 5.1.2.2. So the DS field set b= y the UE is propagated throughout the packet's path. Hope this helps Yoav On Nov 4, 2013, at 1:06 AM, Paul Simon wrote: > Hi, > =20 > =20 > We are having a requirement to have Qos per CHILD SA inside one IKE SA or= to have Qos per IKE SA. Is it possible to communicate the Qos in IKE hands= hake ? Or else how can we achieve to use different Qos, atleast per IKE SA. > =20 > To give a background on the issue we are working on. In usual LTE and 3G = mobile networks before establishing a connection, the UE would sent out the= desired Qos details to the mobile network. The network will then decide on= what Qos can be granted and then communicate this information to UE. > Now people are increasingly using WiFi to connect to mobile network. So w= e need a secure connection from WiFi UE to network. For this IPsec is being= recommended in the standards. So here comes the issue how can the mobile c= ommunicate what Qos is preferred to network in IKE handshake. > =20 > so can any one throw some light on the issue ? > =20 > =20 > Thanks and Regards, > Paul Simon From mls@cisco.com Mon Nov 4 07:26:17 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AB611E81FA for ; Mon, 4 Nov 2013 07:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGbxgmleaaOc for ; Mon, 4 Nov 2013 07:26:11 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B839611E8204 for ; Mon, 4 Nov 2013 07:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21502; q=dns/txt; s=iport; t=1383578770; x=1384788370; h=from:to:cc:subject:date:message-id:mime-version; bh=XSf4boiCxud5hVbArwU9Ptb33TZ8Dg9PCA3WwcyFObw=; b=dOhRH6W2iFdneFpF4nBQhe6w5lJE+ualHsecbXZkOb8E5V4JrqsnVe4q G+RCmhLf0X3BTfXZf0ezKFWK0v4cFJyfKlbQh8rynHr7sZZuCRUaghc+p dqXcvgJPxi/DGeisPXAEjWzLKj8M8+xIYrSIPcG+1kg0fRi1tEx6TnA4F A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFACW8d1KtJV2Z/2dsb2JhbABZgkNEOFO/PYEoFnSCJQEBAQMBLT8NBQcGAQgRBAEBCx05FAkJAQQOBQgRAodgBr5Djg+BGDENgxqBDgOUK5VogyaBcTk X-IronPort-AV: E=Sophos;i="4.93,632,1378857600"; d="scan'208,217";a="280408277" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 04 Nov 2013 15:26:04 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA4FQ3hR004058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 15:26:03 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 09:26:03 -0600 From: "Mike Sullenberger (mls)" To: Michael Richardson Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/cZ8atWBMdRq20ZJjd3q+R4A== Date: Mon, 4 Nov 2013 15:26:02 +0000 Message-ID: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.176] Content-Type: multipart/alternative; boundary="_000_9D83DE546CB6DC47A3AE04086FDE35F523FC8E74xmbalnx06ciscoc_" MIME-Version: 1.0 Cc: "Stephen Lynn \(stlynn\)" , "draft-detienne-dmvpn@tools.ietf.org" , "Mark Comeadow \(mcomeado\)" , "Mike Sullenberger \(mls\)" , "Michael Guilford \(mguilfor\)" , IPsecme WG Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:26:17 -0000 --_000_9D83DE546CB6DC47A3AE04086FDE35F523FC8E74xmbalnx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, I would say that DMVPN is much more than a "brilliant hack". Of the three = proposals it is the only one that uses layering to create a real VPN with e= mphasis on network. The other two proposals are just adding some dynamic fu= nctionality onto a collection of tunnels, but don't actually form that coll= ection into a network. If we look at the layers (which are based on standard protocols) from top-d= own we see: * Routing/forwarding layer over the VPN. This uses standard routing = protocols (EIGRP, OSPF, BGP, RIP) to advertise and propagate throughout the= VPN the networks (subnets,...) that are available through the VPN. If a n= ew IP based routing protocol comes along no changes would be needed in the = other layers to support it. Also if more forwarding granularity is needed = there are standard mechanism to do policy based forwarding, including SDN (= or SDN like features). These could be implemented without changes to the ot= her layers. * GRE tunneling layer. This provides standards based multi-protocol = tunneling. GRE can tunnel both IPv4, IPv6 and non-IP protocols over the sa= me IPv4 or ipv6 infrastructure transport layer. IPsec doesn't know nor nee= d to know anything about the passenger protocols and therefore doesn't need= to change. Also in the future if a better standard tunneling protocol com= es along, the GRE layer could be replaced with this new layer with minimal = changes to the adjacent layers. * NHRP mapping layer. In any dynamic network there needs to be the e= quivalent of ARP (like on an Ethernet). When you are talking about a coll= ection of tunnels this ARP like protocol must be a bit more complex. NHRP = was specifically designed for "tunnel NBMA networks" (ATM, Frame Relay) and= the VPN networks that we are talking about building here are the exact sam= e thing. So it is best to go with a standard protocol that was specifically= designed for this layer of the network. * IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the co= rrect standard protocol to use. This is what IPsec does really well, encry= pt traffic. The layers above greatly simplifies IPsec's job by presenting t= o it the tunnel to encrypt instead of all of the individual protocols/subne= ts/flows that are within the tunnel. The IPsec selectors are now for the t= unnel, which makes path redundancy and load-balancing doable. IPsec doesn'= t deal well with the same set of selectors to encrypt traffic to more than = one peer. With DMVPN this is handled at the routing/forwarding and GRE tun= nel layers. The other proposals will have to reinvent one or more of these layers, whic= h will end up being less efficient. There are also specific issues with IPs= ec, in particular, IPsec having to deal directly with the data plane flows.= With 10s of thousands of nodes and perhaps 100s of thousands of network/s= ubnets reachable via the VPN the number of IPsec selectors across the VPN w= ould get completely out of hand, especially if each different pair of subne= ts (selector) requires a separate encryption, between the same two nodes. = This doesn't even count the fact that in order to run IPv4 and IPv6 between= the same two nodes you have to use at least double the number of selectors= . Routing protocols are already designed to scale to 100s of thousands and = even millions of routes. So with DMVPN the forwarding and GRE tunneling of = both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selector= . NHRP for spoke-hub tunnels doesn't have to do anything more, routing take= s care of this. NHRP for shortcut tunnels will have to pass and store (in = the routing table) the individual subnets that are to be reachable through = the shortcut tunnel, but this is much more lightweight then IPsec doing the= same thing, which it would have to do with the other proposals. Also, as = mentioned above, IPsec is particular bad at supporting redundancy and load = balancing of the same data subnets via different paths, without having to c= reate an IPsec SA per data flow. Note, with DMVPN at the routing/forwarding level you can use various static= and dynamic features that "split-tunnel" traffic even down to the specific= application or flow. All without having to deal with possibly thousands o= f negotiated IPsec 5-tuples. By dynamic a mean that application traffic fl= ows can be measured over one path and flow by flow can be redirected over a= nother path. Since this is done at the routing/forwarding layer these are = exactly the same mechanisms that are already in use over LAN and physical W= AN networks. My point here is that, why reinvent the same mechanism in IPs= ec when you don't have to and are likely not going to be able to do as good= a job as a mechanism that was designed just for that specific purpose. As far as implementation is concerned, there are now at least 3 main vendor= s other than Cisco that claim they have support for DMVPN, and I pretty muc= h believe their claim is likely to be true. Once DMVPN is a standard then = any differences will be quickly worked out. As for hosts they can join the= network in one of three ways. * As a non-encrypting node behind a gateway node that supports DMVPN. * As a pure IPsec node connecting into a gateway or hub node and thus= gaining access to the DMVPN, but not able to support direct shortcut tunne= ls. * As a full node, in which case the node would have to support a rout= ing protocol (possibly optional), GRE tunneling, NHRP mapping and IPsec. O= f this list the only new thing is NHRP mapping functionality. There will of= course need to be some additions to the code for the layers to work cleanl= y with each other. Many host stacks already have a level of support for th= e other three layers (routing, GRE, IPsec). As for the draft-mao-ipsecme proposal, I think the ADS is the wrong way to = go. The ADS is going to be a single point congestion and failure in the VP= N. Even if you have multiple ADSs in the network they will have to all kee= p their databases in sync, which adds more problems when trying to scale th= ese networks to 10s of thousands of nodes and larger. Mike. Mike Sullenberger, DSE mls@cisco.com .:|:.:|:. Customer Advocacy CISCO > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec= -bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: Saturday, November 02, 2013 12:18 PM > To: IPsecme WG > Subject: Re: [IPsec] AD VPN: discussion kick off > > > {Sorry about that, the email configuration my tablet had a \n in a header > that did not belong} > > I have read all three proposals, although I missed the Q&A in Berlin. > I am looking forward to further Q&A in Berlin. > > When I read the NBMA protocol (DMVPN, I think) version what I saw was a > very brilliant hack that managed to take two code bases (IPsec and ATM) > that were likely already present in that vendor's firmware and connect > them. Likely, it took only a few weeks of brilliant hacking, and it was = ready > for customer use. > > I find that this solution for anyone else involves the most amount of new > code, and I think it will the most difficult to support on various mobile= and > laptop platforms as it requires new encapsulation modes. > > draft-mao-ipsecme is architecturally the closest to me, and I like the AD= S > idea: it seems that it be implemented without any new kernel code, and I > think that if we are trying to get remote warrior and branch office RTP > traffic to take a more direct route, then eliminating the need for a mor= e > network plumbing, and just doing things in IKE is the right answer. (%) > > I don't like having a new protocol: I want it in IKE. While it can and s= hould > run inside the tunnel, I don't see why adding a new port to my IKE daemon > makes my life easier. > > I *do* like the way that DMVPN uses probe packets to discover the end > points of the shorter routes, and I would look forward to including that > mechanism somehow. I don't know how to do that without hacks to the > data plane, which I'd like to avoid. I can imagine some ways to do this = with a > traceroute process, but it seems kludgy and brittle. (really, that's stil= l > dataplane, but it's using an existing mechanism) > > I don't like that DMVPN does not let http traffic continue to travel via = HQ's > virus/trojan/netnanny while RTP takes the shortcut. > > > (%)- the plumbing might need a way to sample 5-tuple flows to see if ther= e > is traffic that should be shortcut. However, various schemes to put more > specific SPD entries in that cause key requests might accomplish this > without new kernel code. > > -- > Michael Richardson > -on the road- > > -- > Michael Richardson >,= Sandelman Software Works > --_000_9D83DE546CB6DC47A3AE04086FDE35F523FC8E74xmbalnx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael,
 
I would say that DMVPN is much more than a "brilliant hack".=   Of the three proposals it is the only one that uses layering to crea= te a real VPN with emphasis on network. The other two proposals are just ad= ding some dynamic functionality onto a collection of tunnels, but don’t actually form that collection into a network.
If we look at the layers (which are based on standard protocols) from = top-down we see:
  • Routing/forwarding layer over the VPN.  This uses standard routing= protocols (EIGRP, OSPF, BGP, RIP) to advertise and propagate throughout th= e VPN the networks (subnets,…) that are available through the VPN.&nb= sp; If a new IP based routing protocol comes along no changes would be needed in the other layers to support it.  Also if= more forwarding granularity is needed there are standard mechanism to do p= olicy based forwarding, including SDN (or SDN like features). These could b= e implemented without changes to the other layers. 
  • GRE tunneling layer.  This provides stand= ards based multi-protocol tunneling.  GRE can tunnel both IPv4, IPv6 a= nd non-IP protocols over the same IPv4 or ipv6 infrastructure transport lay= er.  IPsec doesn't know nor need to know anything about the passenger protocols and therefore doesn't need to change.  Also in the future if= a better standard tunneling protocol comes along, the GRE layer could be r= eplaced with this new layer with minimal changes to the adjacent layers.
  • NHRP mapping layer.  In any dynamic network there needs to be th= e equivalent of ARP (like on an Ethernet).  When  you are talking= about a collection of tunnels this ARP like protocol must be a bit more co= mplex.  NHRP was specifically designed for "tunnel NBMA networks" (ATM, Frame Relay) and the VPN networks that we are tal= king about building here are the exact same thing. So it is best to go with= a standard protocol that was specifically designed for this layer of the n= etwork.
  • IPsec encryption layer.  In this layer ISAKMP/IKEv2/IP= sec is the correct standard protocol to use.  This is what IPsec does = really well, encrypt traffic. The layers above greatly simplifies IPsec's j= ob by presenting to it the tunnel to encrypt instead of all of the individual protocols/subnets/flows that are within the tunnel.&n= bsp; The IPsec selectors are now for the tunnel, which makes path redundanc= y and load-balancing  doable. IPsec doesn't deal well with the same se= t of selectors to encrypt traffic to more than one peer.  With DMVPN this is handled at the routing/forwarding a= nd GRE tunnel layers.
 <= /div>
The other proposals will have to reinvent one or more of these layers,= which will end up being less efficient. There are also specific issues wit= h IPsec, in particular, IPsec having to deal directly with the data plane f= lows.  With 10s of thousands of nodes and perhaps 100s of thousands of network/subnets reachable via the VP= N the number of IPsec selectors across the VPN would get completely out of = hand, especially if each different pair of subnets (selector) requires a se= parate encryption, between the same two nodes.  This doesn’t even count the fact that in order to ru= n IPv4 and IPv6 between the same two nodes you have to use at least double = the number of selectors. Routing protocols are already designed to scale to= 100s of thousands and even millions of routes. So with DMVPN the forwarding and GRE tunneling of both IPv4 and IPv6 is han= dled within a single GRE tunnel and IPsec selector. NHRP for spoke-hub tunn= els doesn’t have to do anything more, routing takes care of this.&nbs= p; NHRP for shortcut tunnels will have to pass and store (in the routing table) the individual subnets that are to be reac= hable through the shortcut tunnel, but this is much more lightweight then I= Psec doing the same thing, which it would have to do with the other proposa= ls.  Also, as mentioned above, IPsec is particular bad at supporting redundancy and load balancing of the same d= ata subnets via different paths, without having to create an IPsec SA per d= ata flow.
 
Note, with DMVPN at the routing/forwarding level you can use various s= tatic and dynamic features that “split-tunnel” traffic even dow= n to the specific application or flow.  All without having to deal wit= h possibly thousands of negotiated IPsec 5-tuples.  By dynamic a mean that application traffic flows can be measured over one p= ath and flow by flow can be redirected over another path.  Since this = is done at the routing/forwarding layer these are exactly the same mechanis= ms that are already in use over LAN and physical WAN networks.  My point here is that, why reinvent the same m= echanism in IPsec when you don’t have to and are likely not going to = be able to do as good a job as a mechanism that was designed just for that = specific purpose.
 
As far as implementation is concerned, there are now at least 3 main v= endors other than Cisco that claim they have support for DMVPN, and I prett= y much believe their claim is likely to be true.  Once DMVPN is a stan= dard then any differences will be quickly worked out.  As for hosts they can join the network in one of three wa= ys.
  • As a non-encrypting node behind a gateway node that supports DMVPN.
  • As a pure IPsec node connecting into a gateway or hub node and thus ga= ining access to the DMVPN, but not able to support direct shortcut tunnels.=
  • As a full node, in which case the node would have to support a rou= ting protocol (possibly optional), GRE tunneling, NHRP mapping and IPsec.&n= bsp; Of this list the only new thing is NHRP mapping functionality. There w= ill of course need to be some additions to the code for the layers to work cleanly with each other.  Many host st= acks already have a level of support for the other three layers (routing, G= RE, IPsec).
 <= /div>
As for the draft-mao-ipsecme proposal, I think the ADS is the wrong wa= y to go.  The ADS is going to be a single point congestion and failure= in the VPN.  Even if you have multiple ADSs in the network they will = have to all keep their databases in sync, which adds more problems when trying to scale these networks to 10s of thou= sands of nodes and larger.
 
Mike.
 
 
Mike Sullenberger, DSE
mls@cisco.com          &n= bsp; .:|:.:|:.
Customer Advocacy         = ; CISCO
 
 
 
 <= /div>
> -----Original Message-----
> Of Michael Richardson
> Sent: Saturday, November 02, 2013 12:18 PM
> To: IPsecme WG
> Subject: Re: [IPsec] AD VPN: discussion kick off
>
>
> {Sorry about that, the email configuration my tablet had a \n in = a header
> that did not belong}
>
> I have read all three proposals, although I missed the Q&A in= Berlin.
> I am looking forward to further Q&A in Berlin.
>
> When I read the NBMA protocol (DMVPN, I think) version what I saw= was a
> very brilliant hack that managed to take two code bases (IPsec an= d ATM)
> that were likely already present in that vendor's firmware and co= nnect
> them.  Likely, it took only a few weeks of brilliant hacking= , and it was ready
> for customer use.
>
> I find that this solution for anyone else involves the most amoun= t of new
> code, and I think it will the most difficult to support on variou= s mobile and
> laptop platforms as it requires new encapsulation modes.
>
> draft-mao-ipsecme is architecturally the closest to me, and I lik= e the ADS
> idea: it seems that it be implemented without any new kernel code= , and I
> think that if we are trying  to get remote warrior and branc= h office RTP
> traffic to take a more direct route, then  eliminating the n= eed for a more
> network plumbing, and just doing things in IKE is the right answe= r.  (%)
>
> I don't like having a new protocol: I want it in IKE.  While= it can and should
> run inside the tunnel, I don't see why adding a new port to my IK= E daemon
> makes my life easier.
>
> I *do* like the way that DMVPN uses probe packets to discover the= end
> points of the shorter routes, and I would look forward to includi= ng that
> mechanism somehow.  I don't know how to do that without hack= s to the
> data plane, which I'd like to avoid.  I can imagine some way= s to do this with a
> traceroute process, but it seems kludgy and brittle. (really, tha= t's still
> dataplane, but it's using an existing mechanism)
>
> I don't like that DMVPN does not let http traffic continue to tra= vel via HQ's
> virus/trojan/netnanny while RTP takes the shortcut.
>
>
> (%)- the plumbing might need a way to sample 5-tuple flows to see= if there
> is traffic that should be shortcut. However, various schemes to p= ut more
> specific SPD entries in that cause key requests might accomplish = this
> without new kernel code.
>
> --
> Michael Richardson
> -on the road-
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>
 <= /div>
 <= /div> --_000_9D83DE546CB6DC47A3AE04086FDE35F523FC8E74xmbalnx06ciscoc_-- From j.piyush@torresnetworks.com Sun Nov 3 21:23:56 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134DF11E82AC for ; Sun, 3 Nov 2013 21:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzE51hh-P+m6 for ; Sun, 3 Nov 2013 21:23:50 -0800 (PST) Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) by ietfa.amsl.com (Postfix) with ESMTP id 350AD11E8182 for ; Sun, 3 Nov 2013 21:23:47 -0800 (PST) Received: from [192.168.172.15] ([182.73.206.242]) by p3plsmtpa06-06.prod.phx3.secureserver.net with id lHPj1m00C5EKH5y01HPlLC; Sun, 03 Nov 2013 22:23:46 -0700 Message-ID: <52772F67.3040502@torresnetworks.com> Date: Mon, 04 Nov 2013 10:53:51 +0530 From: piyush User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <5270CAA0.2070003@torresnetworks.com> In-Reply-To: <5270CAA0.2070003@torresnetworks.com> X-Forwarded-Message-Id: <5270CAA0.2070003@torresnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 04 Nov 2013 09:04:27 -0800 Subject: [IPsec] Qos provisioning using ikev2. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 05:25:43 -0000 Hi Members, I have a query, or rather seeking help from you. I need to implement QoS for IKEv2, but i am unable to find any document, which provides me with an AVP inside IKEv2, which can be used for transmitting QoS information. Can you please let me know that which AVP can be used? Your help will be appreciated. -- Regards Piyush Jaiswal Sr Engg Torres Networks From paulsimon.c@gmail.com Mon Nov 4 01:00:44 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C004021F9DC9 for ; Mon, 4 Nov 2013 01:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byofJKmbG0gy for ; Mon, 4 Nov 2013 01:00:44 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1D86521F9E14 for ; Mon, 4 Nov 2013 01:00:42 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id ar20so11827012iec.14 for ; Mon, 04 Nov 2013 01:00:42 -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=RYvyENMuID5NtEIDvKIouMaf0L3k0VvVHt0z5cKSSEE=; b=n/USgbah6qXqs6uEu+casPK4JxNCzLZN7GMaDy8WUMUD4SUWXgXuNExQack9s7fe2F 1P8pUIfOCycdj2+sZc2G+sswTdiXgS1glwwujvG+pHu8fRseyUtNH8gDPD8z4KRmSsMC C5TUd2bAsV4GRKoNMQaZ8OQXaSNghOMIGXiJYezpatG5NblMwPY0/xZ3vIa7UeoX9bf9 v8fk/GzjBH497MfOQbTI2dMJzr9gpWsyxtjFTPupT4MDKM9vZ9+WBJnpKG1L47MeIUJG bImVpXEMLCg0z53nvpHsosYu9rjTlvR8N+Pmbay8SMfLM7k3DRojoB9x/d2jGqibsAw7 vpRw== MIME-Version: 1.0 X-Received: by 10.50.154.10 with SMTP id vk10mr6930503igb.25.1383555642716; Mon, 04 Nov 2013 01:00:42 -0800 (PST) Received: by 10.64.7.12 with HTTP; Mon, 4 Nov 2013 01:00:42 -0800 (PST) Date: Mon, 4 Nov 2013 14:30:42 +0530 Message-ID: From: Paul Simon To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=047d7bd755c49c7aad04ea5626d1 X-Mailman-Approved-At: Mon, 04 Nov 2013 09:04:30 -0800 Subject: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 09:02:50 -0000 --047d7bd755c49c7aad04ea5626d1 Content-Type: text/plain; charset=ISO-8859-1 Hi, We are having a requirement to have Qos per CHILD SA inside one IKE SA or to have Qos per IKE SA. Is it possible to communicate the Qos in IKE handshake ? Or else how can we achieve to use different Qos, atleast per IKE SA. To give a background on the issue we are working on. In usual LTE and 3G mobile networks before establishing a connection, the UE would sent out the desired Qos details to the mobile network. The network will then decide on what Qos can be granted and then communicate this information to UE. Now people are increasingly using WiFi to connect to mobile network. So we need a secure connection from WiFi UE to network. For this IPsec is being recommended in the standards. So here comes the issue how can the mobile communicate what Qos is preferred to network in IKE handshake. so can any one throw some light on the issue ? Thanks and Regards, Paul Simon --047d7bd755c49c7aad04ea5626d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
=A0
We are havi= ng a requirement to have Qos per CHILD SA inside one IKE SA or to have Qos = per IKE SA. Is it possible to communicate the Qos in IKE handshake ? Or els= e how can we achieve to use different Qos, atleast per IKE SA.
=A0
To give a background on the issue we are working on. In = usual LTE and 3G mobile networks before establishing a connection, the UE w= ould sent out the desired Qos details to the mobile network. The network wi= ll then decide on what Qos can be granted and then communicate this informa= tion to UE.
Now people are increasingly using WiFi to connect to mobile network. S= o we need a secure connection from WiFi UE to network. For this IPsec is be= ing recommended in the standards. So here comes the issue how can the mobil= e communicate what Qos is preferred to network in IKE handshake.
=A0
so can any one throw some light on the issue ?
=A0
=A0
Thanks and Regards,
Paul Simon
=
=A0
=A0
--047d7bd755c49c7aad04ea5626d1-- From paulsimon.c@gmail.com Mon Nov 4 09:40:16 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7418921E80C8 for ; Mon, 4 Nov 2013 09:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNktSk5Xi3gM for ; Mon, 4 Nov 2013 09:40:15 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C5F9521E81D9 for ; Mon, 4 Nov 2013 09:39:44 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id ar20so12599842iec.40 for ; Mon, 04 Nov 2013 09:39:42 -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=5bSj7Z34fTUVyUBY5a1gtY50DexYq1aBgCJMlNTkbiw=; b=Ou3Chph3ulFMoWobjt0IIm4ufrY3xi/Oaw+/CsHDbXYRB1hx1YaYWqFEYp7EY8HqpZ EwgJd/qjgNaJl10tChvhggIafhX+zjeGOUl9/dJhY/YxQQmAJSu2NPX5/+LztMwZsVAO OhvyotpVdlnINO8AoIlzYNyz8ouJB4A3AiU1TH94sIkf4tTdLfsj1wOl2ki2tYzEOCp7 6o9m45l+xtLY74sE1a6SO3OBXaX+wyKUxmvPaJzk6eHLwo6p+dZ54g63XTLyCadb5RWW M1dz8xyY4RTKwOz2P+jcL9FrPPVJAYjBxpdZuo05qxt5/4IlcJdVUzEwTSSvxVHYelYh Qd3Q== MIME-Version: 1.0 X-Received: by 10.43.178.135 with SMTP id ow7mr1777008icc.43.1383586781970; Mon, 04 Nov 2013 09:39:41 -0800 (PST) Received: by 10.64.7.12 with HTTP; Mon, 4 Nov 2013 09:39:41 -0800 (PST) In-Reply-To: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> Date: Mon, 4 Nov 2013 23:09:41 +0530 Message-ID: From: Paul Simon To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c30beca7cb0504ea5d66bf Cc: "" Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:40:16 -0000 --001a11c30beca7cb0504ea5d66bf Content-Type: text/plain; charset=ISO-8859-1 Hi, Thanks for the answer. I would like to know if there is any possibility to negotiate Qos through IKE procedures, so that both the end apply the agreed Qos. In RFC 5996, section 2.8 "Note that IKEv2 deliberately allows parallel SAs with the same Traffic Selectors between common endpoints. One of the purposes of this is to support traffic quality of service (QoS) differences among the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH ], and Section 4.1 of [DIFFTUNNEL ]). " But I have not seen any Qos parameter in the IKE messages. So how the Qos is negotiated between end parties using IKE SAs ? Can you explain little bit on Qos agreement. Thanks, Paul On Mon, Nov 4, 2013 at 3:12 PM, Yoav Nir wrote: > Hi, Paul > > I'm not sure I understand the issue. IPsec is carrying some IP-based > protocol from the UE, through some gateway to a host in the service > provider's network. Those IP packets can have QoS indication like any other > IP packets, through the TOS field in IPv4 or the Traffic Class field in > IPv6. Those fields get encrypted and encapsulated with the entire IP packet > and come out the same at the other side, so they go into the provider > network with the same properties. > > According to RFC 4301, the IPsec packet inherits the ECN and DS fields > from the inner packet. See sections 5.1.2.1 and 5.1.2.2. So the DS field > set by the UE is propagated throughout the packet's path. > > Hope this helps > > Yoav > > On Nov 4, 2013, at 1:06 AM, Paul Simon wrote: > > > Hi, > > > > > > We are having a requirement to have Qos per CHILD SA inside one IKE SA > or to have Qos per IKE SA. Is it possible to communicate the Qos in IKE > handshake ? Or else how can we achieve to use different Qos, atleast per > IKE SA. > > > > To give a background on the issue we are working on. In usual LTE and 3G > mobile networks before establishing a connection, the UE would sent out the > desired Qos details to the mobile network. The network will then decide on > what Qos can be granted and then communicate this information to UE. > > Now people are increasingly using WiFi to connect to mobile network. So > we need a secure connection from WiFi UE to network. For this IPsec is > being recommended in the standards. So here comes the issue how can the > mobile communicate what Qos is preferred to network in IKE handshake. > > > > so can any one throw some light on the issue ? > > > > > > Thanks and Regards, > > Paul Simon > > --001a11c30beca7cb0504ea5d66bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
Thanks for the answer.
=A0
I would like to know if there is any possibility to n= egotiate Qos through IKE procedures, so that both the end apply the agreed = Qos.
=A0
In RFC 5996, section 2.8
=A0"Note that I= KEv2 deliberately allows parallel SAs with the same
=A0=A0 Traffic Selec= tors between common endpoints.=A0 One of the purposes of
=A0=A0 this is = to support traffic quality of service (QoS) differences among
=A0=A0 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of
=A0=A0 [DIFFTUNNEL]). "
=A0
= =A0
But I have not seen any Qos parameter in the IKE messages. So= how the Qos is negotiated between end parties using IKE SAs ?
Can you explain little bit on Qos agreement.
=A0
T= hanks,
Paul


On Mon, Nov 4, 2013 at 3:12 PM, Yoav Nir <ynir@check= point.com> wrote:
Hi, Paul

I'm not sure I understand the issue. IPsec is carrying some IP-based pr= otocol from the UE, through some gateway to a host in the service provider&= #39;s network. Those IP packets can have QoS indication like any other IP p= ackets, through the TOS field in IPv4 or the Traffic Class field in IPv6. T= hose fields get encrypted and encapsulated with the entire IP packet and co= me out the same at the other side, so they go into the provider network wit= h the same properties.

According to RFC 4301, the IPsec packet inherits the ECN and DS fields from= the inner packet. =A0See sections 5.1.2.1 and 5.1.2.2. So the DS field set= by the UE is propagated throughout the packet's path.

Hope this helps

Yoav

On Nov 4, 2013, at 1:06 AM, Paul Simon <paulsimon.c@gmail.com> wrote:

> Hi,
>
>
> We are having a requirement to have Qos per CHILD SA inside one IKE SA= or to have Qos per IKE SA. Is it possible to communicate the Qos in IKE ha= ndshake ? Or else how can we achieve to use different Qos, atleast per IKE = SA.
>
> To give a background on the issue we are working on. In usual LTE and = 3G mobile networks before establishing a connection, the UE would sent out = the desired Qos details to the mobile network. The network will then decide= on what Qos can be granted and then communicate this information to UE. > Now people are increasingly using WiFi to connect to mobile network. S= o we need a secure connection from WiFi UE to network. For this IPsec is be= ing recommended in the standards. So here comes the issue how can the mobil= e communicate what Qos is preferred to network in IKE handshake.
>
> so can any one throw some light on the issue ?
>
>
> Thanks and Regards,
> Paul Simon


--001a11c30beca7cb0504ea5d66bf-- From kivinen@iki.fi Mon Nov 4 09:48:22 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B8921E824B for ; Mon, 4 Nov 2013 09:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO-lvz6QlGcA for ; Mon, 4 Nov 2013 09:48:18 -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 80B1321E8248 for ; Mon, 4 Nov 2013 09:48:12 -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 rA4HltiY020880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Nov 2013 19:47:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rA4Hlt1H023631; Mon, 4 Nov 2013 19:47:55 +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: <21111.56778.982670.112028@fireball.kivinen.iki.fi> Date: Mon, 4 Nov 2013 19:47:54 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <16080.1383419646@sandelman.ca> References: <21077.33006.734392.994194@fireball.kivinen.iki.fi> <20131101200712.BCA29CA0D4@sandelman.ca> <22A8109D-6669-4FBC-9FE8-5522E4AABDC3@checkpoint.com> <16080.1383419646@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 10 min Cc: "" , Yoav Nir Subject: Re: [IPsec] Update to RFC4307 too? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:48:22 -0000 Michael Richardson writes: > Yoav Nir wrote: > >>> Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ > >>> to SHOULD. > >> this is the only one which I didn't understand. > > Which one? There's two parts there. > True. > So, the "_CBC" to "_XCBC" is either a typo in the email or in the spec, and: Yes. The original spec had typo. And the specifications are not exactly consistent with namings. The original (RFC3664) and revised (RFC4434) used name AES-XCBC-PRF-128 for the algorithm, but neither one of them did specific IANA allocations. The IANA Allocation was done in the RFC4306 and it used the name PRF_AES128_XCBC for that algorithm. This is the name that is in the iana registry (http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml). The RFC4307 used PRF_AES128_CBC to refer to same algorithm. There is no problem in the interoperability as it also refers to the correct number and has pointer to the correct specification for the algoritm, but I think we should fix this typo while we are revising this document. -- kivinen@iki.fi From ynir@checkpoint.com Mon Nov 4 09:51:13 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF2B11E82A9 for ; Mon, 4 Nov 2013 09:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mz3t1Mbj9D1 for ; Mon, 4 Nov 2013 09:51:08 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB0121E81DB for ; Mon, 4 Nov 2013 09:50:56 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA4HofTb023661; Mon, 4 Nov 2013 19:50:41 +0200 X-CheckPoint: {5277DD1C-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 19:50:41 +0200 From: Yoav Nir To: Paul Simon Thread-Topic: [IPsec] Query regarding Qos with IKE Thread-Index: AQHO2T0lqIBsUjWJEE+iW3Hntr4dIpoUsHkAgACFNICAAAMQgA== Date: Mon, 4 Nov 2013 17:50:40 +0000 Message-ID: <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.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.194] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_647E2BD8A28B431DA7104F44A1F207E7checkpointcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:51:13 -0000 --_000_647E2BD8A28B431DA7104F44A1F207E7checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are currently no attributes in IKE to negotiate QoS. The reason for that text in 5996 is the issue of IPsec packet re-ordering. = If we use the same SA for packets with different QoS characteristics, then = the QoS could then re-order them. This means that replay protection would d= rop legitimate packets simply because they arrived late. To avoid this, the= sender may use several SAs so as to send packets with different QoS charac= teristics in different tunnels. This requires no negotiation of QoS charact= eristics between the peers, only negotiation of enough SAs for all the diff= erent QoS classes. If I'm missing something, and there is a need to negotiate this, you can al= ways submit an I-D. Yoav On Nov 4, 2013, at 9:39 AM, Paul Simon > wrote: Hi, Thanks for the answer. I would like to know if there is any possibility to negotiate Qos through I= KE procedures, so that both the end apply the agreed Qos. In RFC 5996, section 2.8 "Note that IKEv2 deliberately allows parallel SAs with the same Traffic Selectors between common endpoints. One of the purposes of this is to support traffic quality of service (QoS) differences among the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of [DIFFTUNNEL]). " But I have not seen any Qos parameter in the IKE messages. So how the Qos i= s negotiated between end parties using IKE SAs ? Can you explain little bit on Qos agreement. Thanks, Paul On Mon, Nov 4, 2013 at 3:12 PM, Yoav Nir > wrote: Hi, Paul I'm not sure I understand the issue. IPsec is carrying some IP-based protoc= ol from the UE, through some gateway to a host in the service provider's ne= twork. Those IP packets can have QoS indication like any other IP packets, = through the TOS field in IPv4 or the Traffic Class field in IPv6. Those fie= lds get encrypted and encapsulated with the entire IP packet and come out t= he same at the other side, so they go into the provider network with the sa= me properties. According to RFC 4301, the IPsec packet inherits the ECN and DS fields from= the inner packet. See sections 5.1.2.1 and 5.1.2.2. So the DS field set b= y the UE is propagated throughout the packet's path. Hope this helps Yoav On Nov 4, 2013, at 1:06 AM, Paul Simon > wrote: > Hi, > > > We are having a requirement to have Qos per CHILD SA inside one IKE SA or= to have Qos per IKE SA. Is it possible to communicate the Qos in IKE hands= hake ? Or else how can we achieve to use different Qos, atleast per IKE SA. > > To give a background on the issue we are working on. In usual LTE and 3G = mobile networks before establishing a connection, the UE would sent out the= desired Qos details to the mobile network. The network will then decide on= what Qos can be granted and then communicate this information to UE. > Now people are increasingly using WiFi to connect to mobile network. So w= e need a secure connection from WiFi UE to network. For this IPsec is being= recommended in the standards. So here comes the issue how can the mobile c= ommunicate what Qos is preferred to network in IKE handshake. > > so can any one throw some light on the issue ? > > > Thanks and Regards, > Paul Simon _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_647E2BD8A28B431DA7104F44A1F207E7checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable There are currently no attributes in IKE to negotiate QoS.

The reason for that text in 5996 is the issue of IPsec packet re-order= ing. If we use the same SA for packets with different QoS characteristics, = then the QoS could then re-order them. This means that replay protection wo= uld drop legitimate packets simply because they arrived late. To avoid this, the sender may use several SAs s= o as to send packets with different QoS characteristics in different tunnel= s. This requires no negotiation of QoS characteristics between the peers, o= nly negotiation of enough SAs for all the different QoS classes.

If I'm missing something, and there is a need to negotiate this, you c= an always submit an I-D.

Yoav


On Nov 4, 2013, at 9:39 AM, Paul Simon <paulsimon.c@gmail.com>
 wrote:

Hi,
 
Thanks for the answer.
 
I would like to know if there is any possibility to negotiate Qos thro= ugh IKE procedures, so that both the end apply the agreed Qos.
 
In RFC 5996, section 2.8
 "Note that IKEv2 deliberately allows parallel SAs with the = same
   Traffic Selectors between common endpoints.  One of the p= urposes of
   this is to support traffic quality of service (QoS) difference= s among
   the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of
   [DIFFTUNNEL]). "
 
 
But I have not seen any Qos parameter in the IKE messages. So how the = Qos is negotiated between end parties using IKE SAs ?
Can you explain little bit on Qos agreement.
 
Thanks,
Paul


On Mon, Nov 4, 2013 at 3:12 PM, Yoav Nir <ynir@checkpoin= t.com> wrote:
Hi, Paul

I'm not sure I understand the issue. IPsec is carrying some IP-based protoc= ol from the UE, through some gateway to a host in the service provider's ne= twork. Those IP packets can have QoS indication like any other IP packets, = through the TOS field in IPv4 or the Traffic Class field in IPv6. Those fields get encrypted and encapsulat= ed with the entire IP packet and come out the same at the other side, so th= ey go into the provider network with the same properties.

According to RFC 4301, the IPsec packet inherits the ECN and DS fields from= the inner packet.  See sections 5.1.2.1 and 5.1.2.2. So the DS field = set by the UE is propagated throughout the packet's path.

Hope this helps

Yoav

On Nov 4, 2013, at 1:06 AM, Paul Simon <paulsimon.c@gmail.com> wrote:

> Hi,
>
>
> We are having a requirement to have Qos per CHILD SA inside one IKE SA= or to have Qos per IKE SA. Is it possible to communicate the Qos in IKE ha= ndshake ? Or else how can we achieve to use different Qos, atleast per IKE = SA.
>
> To give a background on the issue we are working on. In usual LTE and = 3G mobile networks before establishing a connection, the UE would sent out = the desired Qos details to the mobile network. The network will then decide= on what Qos can be granted and then communicate this information to UE.
> Now people are increasingly using WiFi to connect to mobile network. S= o we need a secure connection from WiFi UE to network. For this IPsec is be= ing recommended in the standards. So here comes the issue how can the mobil= e communicate what Qos is preferred to network in IKE handshake.
>
> so can any one throw some light on the issue ?
>
>
> Thanks and Regards,
> Paul Simon


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

--_000_647E2BD8A28B431DA7104F44A1F207E7checkpointcom_-- From yaronf.ietf@gmail.com Mon Nov 4 10:03:43 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C353C21E8243 for ; Mon, 4 Nov 2013 10:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AWJLu5HANws for ; Mon, 4 Nov 2013 10:03:33 -0800 (PST) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB9521E8194 for ; Mon, 4 Nov 2013 10:02:58 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id d49so1294475eek.35 for ; Mon, 04 Nov 2013 10:02:56 -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=BAQ/yEpk2Oy+DoLLvPAcqBAXqsXlp0X3n0WQXBuoFYA=; b=gaJ/VIRIybsRK8xeRK37ZI7BnfVV1XDYlZy741eQ4Hi2xII6Huj3L17/hNr2MbV3Zt 2GtN4L0SaD9E/6Chw0B7vtFZFZ5wWiCCM8nVIWBazLeKs0JOqsebcC48U2N4/Gr+4mTY ZvhvDgisNVkrU2vtp1PA4pvyRA06hrj5DY8HSMBcJAjo+oV6bRacr4pYywTR9ln2PbQa /cntKw7axdb7F+cAsvwOyTHPcXbc+bhMYZpsX1Cz3RSanoJKXmLT+om0rFLvoNNqA5Y/ Iiw0bl+TumSHhIRSBlS1taG7AWgHpbSeS+kQEdH38yvBPOMkF6uKE6XDhCZpWZfazNvt dZRw== X-Received: by 10.15.53.68 with SMTP id q44mr5970563eew.70.1383588176460; Mon, 04 Nov 2013 10:02:56 -0800 (PST) Received: from [10.0.0.1] (109-186-48-194.bb.netvision.net.il. [109.186.48.194]) by mx.google.com with ESMTPSA id u46sm49738504eep.17.2013.11.04.10.02.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 10:02:56 -0800 (PST) Message-ID: <5277E14D.3040802@gmail.com> Date: Mon, 04 Nov 2013 20:02:53 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tero Kivinen , Michael Richardson References: <21077.33006.734392.994194@fireball.kivinen.iki.fi> <20131101200712.BCA29CA0D4@sandelman.ca> <22A8109D-6669-4FBC-9FE8-5522E4AABDC3@checkpoint.com> <16080.1383419646@sandelman.ca> <21111.56778.982670.112028@fireball.kivinen.iki.fi> In-Reply-To: <21111.56778.982670.112028@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , Yoav Nir Subject: Re: [IPsec] Update to RFC4307 too? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:03:43 -0000 Hi Tero, Can you please submit an errata to RFC 4307 with this detail? Thanks, Yaron On 2013-11-04 19:47, Tero Kivinen wrote: > Michael Richardson writes: >> Yoav Nir wrote: >> >>> Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ >> >>> to SHOULD. >> >> this is the only one which I didn't understand. >> > Which one? There's two parts there. >> True. >> So, the "_CBC" to "_XCBC" is either a typo in the email or in the spec, and: > > Yes. The original spec had typo. And the specifications are not > exactly consistent with namings. > > The original (RFC3664) and revised (RFC4434) used name > AES-XCBC-PRF-128 for the algorithm, but neither one of them did > specific IANA allocations. The IANA Allocation was done in the RFC4306 > and it used the name PRF_AES128_XCBC for that algorithm. This is the > name that is in the iana registry > (http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml). > > The RFC4307 used PRF_AES128_CBC to refer to same algorithm. There is > no problem in the interoperability as it also refers to the correct > number and has pointer to the correct specification for the algoritm, > but I think we should fix this typo while we are revising this > document. > From praveenys@juniper.net Mon Nov 4 11:44:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F2C21E821C for ; Mon, 4 Nov 2013 11:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.841 X-Spam-Level: X-Spam-Status: No, score=-3.841 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acwf1UlAxy9c for ; Mon, 4 Nov 2013 11:44:00 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3E621E8229 for ; Mon, 4 Nov 2013 11:43:37 -0800 (PST) Received: from mail29-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE020.bigfish.com (10.3.207.142) with Microsoft SMTP Server id 14.1.225.22; Mon, 4 Nov 2013 19:43:36 +0000 Received: from mail29-am1 (localhost [127.0.0.1]) by mail29-am1-R.bigfish.com (Postfix) with ESMTP id 5F1D54000B6; Mon, 4 Nov 2013 19:43:36 +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: -25 X-BigFish: VPS-25(zzdb82h9371Ic85eh1b0bI542Id87dh1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh18c673h1de097hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h1155h) Received-SPF: pass (mail29-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:(13464003)(164054003)(189002)(199002)(377454003)(51704005)(69234005)(81816001)(83072001)(561944002)(63696002)(81686001)(83506001)(53806001)(74662001)(31966008)(4396001)(50986001)(74502001)(47446002)(47976001)(47736001)(65816001)(80022001)(81542001)(81342001)(74706001)(51856001)(74876001)(54356001)(46102001)(74366001)(69226001)(76786001)(77096001)(56816003)(80976001)(554214002)(76176001)(76796001)(79102001)(85306002)(16236675002)(54316002)(19580405001)(77982001)(76482001)(59766001)(49866001)(36756003)(19580395003)(87266001)(83322001)(66066001)(56776001)(2656002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB156; H:BN1PR05MB153.namprd05.prod.outlook.com; CLIP:66.129.224.50; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail29-am1 (localhost.localdomain [127.0.0.1]) by mail29-am1 (MessageSwitch) id 1383594214171346_30190; Mon, 4 Nov 2013 19:43:34 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.236]) by mail29-am1.bigfish.com (Postfix) with ESMTP id 1E9B760063; Mon, 4 Nov 2013 19:43:34 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 4 Nov 2013 19:43:33 +0000 Received: from BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 4 Nov 2013 19:43:33 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) by BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 4 Nov 2013 19:43:32 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.178]) by BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.252]) with mapi id 15.00.0785.001; Mon, 4 Nov 2013 19:43:32 +0000 From: Praveen Sathyanarayan To: "Mike Sullenberger (mls)" , Michael Richardson Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/cf7ViFrHgJk2PKWUIk7f4rv//sSIA Date: Mon, 4 Nov 2013 19:43:31 +0000 Message-ID: In-Reply-To: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [66.129.224.50] x-forefront-prvs: 0020414413 Content-Type: multipart/alternative; boundary="_000_CE9D37811CA4ACpraveenysjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Stephen Lynn \(stlynn\)" , "Michael Guilford \(mguilfor\)" , IPsecme WG , "draft-detienne-dmvpn@tools.ietf.org" , "Mark Comeadow \(mcomeado\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:44:08 -0000 --_000_CE9D37811CA4ACpraveenysjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mike, I am not sure when you refer to other proposal, you meant ours as well :-).= Appreciate your review and feedback. You mentioned 4 points that DMVPN is capable of doing that other proposal f= alls short. I can speak for our proposal * Routing protocol: Our proposal does not prevent running routing proto= col either. You can definitely configuring any of the route protocol that s= upports NBMA or P2MP network (example OSPF, RIP, BGP etc). You need to setu= p right policies, which will allow routing protocol to exchange routing upd= ates and forward the traffic efficiently. Along with Routing protocol suppo= rt, it can be deployed without Routing protocol. As an example, this remov= es requirement of implementing routing protocol on a mobile device, just fo= r establishing a shortcut tunnel with other mobile device. * GRE tunneling: In our experience, IPsec tunneling does good job as tu= nneling protocol. IPsec provides all required structures and protocol exten= sions to support it. And as far as non-IP based traffic, our proposal does = not prevent using GRE over IPSec. So if someone wants to use GRE to encap n= on-IP packet, they should be able to achieve. * NHRP Layer: NHRP is a nice protocol but that is defined ATM/FR networ= k in mind. FYI, Juniper did deploy this protocol to solve Spoke to Spoke s= hortcut tunnel with our AutoConnect VPN feature. But our experience is, thi= s is nice protocol, but not designed with security in mind. It is a protoco= l that is not sufficient for IPsec. This does not provide good authenticat= ion mechanism nor authorization mechanism. You can change NHRP protocol to = support these Security specific feature, that exactly we did with AutoConne= ct VPN. At Juniper, before we came up with our proposal, we took a step bac= k, and used our experience with AutoConnect VPN, asked our self, can we sol= ve NHRP requirement with IKE. We found out that IKE has everything that was= required to solve and NHRP was just hack to use. * IPsec layer: As mentioned by you, IPSec does pretty good job of encry= ption. To add to that, it also does pretty good job of doing tunneling as w= ell. I feel, DMVPN is designed and organized in IOS/Security Gateway architectur= e in mind. Based on the requirements in RFC 7018 and for modern IPsec archi= tecture requirements (Security Gateway, Mobile devices etc), I feel there i= s a requirement for new protocol, which can be solved without any complexit= y that DVMPN or ADS requires. Thanks, Praveen From: "Mike Sullenberger (mls)" > Date: Monday, November 4, 2013 at 8:26 AM To: Michael Richardson = > Cc: "Stephen Lynn (stlynn)" >, "d= raft-detienne-dmvpn@tools.ietf.org" >, "Mark Comeadow (mcomeado)" >, "Mike Sullenberger (mls)" >, "Michael Guilford (mguilfor)" >, IPsecme WG > Subject: Re: [IPsec] AD VPN: discussion kick off Michael, I would say that DMVPN is much more than a "brilliant hack". Of the three = proposals it is the only one that uses layering to create a real VPN with e= mphasis on network. The other two proposals are just adding some dynamic fu= nctionality onto a collection of tunnels, but don=92t actually form that co= llection into a network. If we look at the layers (which are based on standard protocols) from top-d= own we see: * Routing/forwarding layer over the VPN. This uses standard routing pr= otocols (EIGRP, OSPF, BGP, RIP) to advertise and propagate throughout the V= PN the networks (subnets,=85) that are available through the VPN. If a new= IP based routing protocol comes along no changes would be needed in the ot= her layers to support it. Also if more forwarding granularity is needed th= ere are standard mechanism to do policy based forwarding, including SDN (or= SDN like features). These could be implemented without changes to the othe= r layers. * GRE tunneling layer. This provides standards based multi-protocol tu= nneling. GRE can tunnel both IPv4, IPv6 and non-IP protocols over the same= IPv4 or ipv6 infrastructure transport layer. IPsec doesn't know nor need = to know anything about the passenger protocols and therefore doesn't need t= o change. Also in the future if a better standard tunneling protocol comes= along, the GRE layer could be replaced with this new layer with minimal ch= anges to the adjacent layers. * NHRP mapping layer. In any dynamic network there needs to be the equ= ivalent of ARP (like on an Ethernet). When you are talking about a collec= tion of tunnels this ARP like protocol must be a bit more complex. NHRP wa= s specifically designed for "tunnel NBMA networks" (ATM, Frame Relay) and t= he VPN networks that we are talking about building here are the exact same = thing. So it is best to go with a standard protocol that was specifically d= esigned for this layer of the network. * IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the corr= ect standard protocol to use. This is what IPsec does really well, encrypt= traffic. The layers above greatly simplifies IPsec's job by presenting to = it the tunnel to encrypt instead of all of the individual protocols/subnets= /flows that are within the tunnel. The IPsec selectors are now for the tun= nel, which makes path redundancy and load-balancing doable. IPsec doesn't = deal well with the same set of selectors to encrypt traffic to more than on= e peer. With DMVPN this is handled at the routing/forwarding and GRE tunne= l layers. The other proposals will have to reinvent one or more of these layers, whic= h will end up being less efficient. There are also specific issues with IPs= ec, in particular, IPsec having to deal directly with the data plane flows.= With 10s of thousands of nodes and perhaps 100s of thousands of network/s= ubnets reachable via the VPN the number of IPsec selectors across the VPN w= ould get completely out of hand, especially if each different pair of subne= ts (selector) requires a separate encryption, between the same two nodes. = This doesn=92t even count the fact that in order to run IPv4 and IPv6 betwe= en the same two nodes you have to use at least double the number of selecto= rs. Routing protocols are already designed to scale to 100s of thousands an= d even millions of routes. So with DMVPN the forwarding and GRE tunneling o= f both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec select= or. NHRP for spoke-hub tunnels doesn=92t have to do anything more, routing = takes care of this. NHRP for shortcut tunnels will have to pass and store = (in the routing table) the individual subnets that are to be reachable thro= ugh the shortcut tunnel, but this is much more lightweight then IPsec doing= the same thing, which it would have to do with the other proposals. Also,= as mentioned above, IPsec is particular bad at supporting redundancy and l= oad balancing of the same data subnets via different paths, without having = to create an IPsec SA per data flow. Note, with DMVPN at the routing/forwarding level you can use various static= and dynamic features that =93split-tunnel=94 traffic even down to the spec= ific application or flow. All without having to deal with possibly thousan= ds of negotiated IPsec 5-tuples. By dynamic a mean that application traffi= c flows can be measured over one path and flow by flow can be redirected ov= er another path. Since this is done at the routing/forwarding layer these = are exactly the same mechanisms that are already in use over LAN and physic= al WAN networks. My point here is that, why reinvent the same mechanism in= IPsec when you don=92t have to and are likely not going to be able to do a= s good a job as a mechanism that was designed just for that specific purpos= e. As far as implementation is concerned, there are now at least 3 main vendor= s other than Cisco that claim they have support for DMVPN, and I pretty muc= h believe their claim is likely to be true. Once DMVPN is a standard then = any differences will be quickly worked out. As for hosts they can join the= network in one of three ways. * As a non-encrypting node behind a gateway node that supports DMVPN. * As a pure IPsec node connecting into a gateway or hub node and thus g= aining access to the DMVPN, but not able to support direct shortcut tunnels= . * As a full node, in which case the node would have to support a routin= g protocol (possibly optional), GRE tunneling, NHRP mapping and IPsec. Of = this list the only new thing is NHRP mapping functionality. There will of c= ourse need to be some additions to the code for the layers to work cleanly = with each other. Many host stacks already have a level of support for the = other three layers (routing, GRE, IPsec). As for the draft-mao-ipsecme proposal, I think the ADS is the wrong way to = go. The ADS is going to be a single point congestion and failure in the VP= N. Even if you have multiple ADSs in the network they will have to all kee= p their databases in sync, which adds more problems when trying to scale th= ese networks to 10s of thousands of nodes and larger. Mike. Mike Sullenberger, DSE mls@cisco.com .:|:.:|:. Customer Advocacy CISCO > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec= -bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: Saturday, November 02, 2013 12:18 PM > To: IPsecme WG > Subject: Re: [IPsec] AD VPN: discussion kick off > > > {Sorry about that, the email configuration my tablet had a \n in a header > that did not belong} > > I have read all three proposals, although I missed the Q&A in Berlin. > I am looking forward to further Q&A in Berlin. > > When I read the NBMA protocol (DMVPN, I think) version what I saw was a > very brilliant hack that managed to take two code bases (IPsec and ATM) > that were likely already present in that vendor's firmware and connect > them. Likely, it took only a few weeks of brilliant hacking, and it was = ready > for customer use. > > I find that this solution for anyone else involves the most amount of new > code, and I think it will the most difficult to support on various mobile= and > laptop platforms as it requires new encapsulation modes. > > draft-mao-ipsecme is architecturally the closest to me, and I like the AD= S > idea: it seems that it be implemented without any new kernel code, and I > think that if we are trying to get remote warrior and branch office RTP > traffic to take a more direct route, then eliminating the need for a mor= e > network plumbing, and just doing things in IKE is the right answer. (%) > > I don't like having a new protocol: I want it in IKE. While it can and s= hould > run inside the tunnel, I don't see why adding a new port to my IKE daemon > makes my life easier. > > I *do* like the way that DMVPN uses probe packets to discover the end > points of the shorter routes, and I would look forward to including that > mechanism somehow. I don't know how to do that without hacks to the > data plane, which I'd like to avoid. I can imagine some ways to do this = with a > traceroute process, but it seems kludgy and brittle. (really, that's stil= l > dataplane, but it's using an existing mechanism) > > I don't like that DMVPN does not let http traffic continue to travel via = HQ's > virus/trojan/netnanny while RTP takes the shortcut. > > > (%)- the plumbing might need a way to sample 5-tuple flows to see if ther= e > is traffic that should be shortcut. However, various schemes to put more > specific SPD entries in that cause key requests might accomplish this > without new kernel code. > > -- > Michael Richardson > -on the road- > > -- > Michael Richardson >,= Sandelman Software Works > --_000_CE9D37811CA4ACpraveenysjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mike,

I am not sure when you refer to other proposal, you meant ours as well= :-). Appreciate your review and feedback. 

You mentioned 4 points that DMVPN is capable of doing that other propo= sal falls short. I can speak for our proposal 
  • Routing protocol: Our proposal does not prevent running routing protoco= l either. You can definitely configuring any of the route protocol that sup= ports NBMA or P2MP network (example OSPF, RIP, BGP etc). You need to setup = right policies, which will allow routing protocol to exchange routing updates and forward the traffic effic= iently. Along with Routing protocol support, it can be deployed without Rou= ting protocol.  As an example, this removes requirement of implementin= g routing protocol on a mobile device, just for establishing a shortcut tunnel with other mobile device.
  • = GRE tunneling: In our experience, IPsec tunneling does good job as tunnelin= g protocol. IPsec provides all required structures and protocol extensions = to support it. And as far as non-IP based traffic, our proposal does not pr= event using GRE over IPSec. So if someone wants to use GRE to encap non-IP packet, they should be able= to achieve.
  • NHRP Layer: NHRP is a nice protocol but that is define= d ATM/FR network in mind. FYI,  Juniper did deploy this protocol to so= lve Spoke to Spoke shortcut tunnel with our AutoConnect VPN feature. But ou= r experience is, this is nice protocol, but not designed with security in mind. It is a protocol that is not sufficient for IPsec. =  This does not provide good authentication mechanism nor authorization= mechanism. You can change NHRP protocol to support these Security specific= feature, that exactly we did with AutoConnect VPN. At Juniper, before we came up with our proposal, we took a step back,= and used our experience with AutoConnect VPN, asked our self, can we solve= NHRP requirement with IKE. We found out that IKE has everything that was r= equired to solve and NHRP was just hack to use.  
  • IPsec layer: As mentioned by you, IPSec does p= retty good job of encryption. To add to that, it also does pretty good job = of doing tunneling as well.

I feel, DMVPN is designed and organized in IOS/Security Gateway archit= ecture in mind. Based on the requirements in RFC 7018 and for modern IPsec = architecture requirements (Security Gateway, Mobile devices etc), I feel th= ere is a requirement for new protocol, which can be solved without any complexity that DVMPN or ADS requires.

Thanks,
Praveen

From: "Mike Sullenberger (mls)= " <mls@cisco.com>
Date: Monday, November 4, 2013 at 8= :26 AM
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "Stephen Lynn (stlynn)&quo= t; <stlynn@cisco.com>, "= draft-detienne-dmvpn= @tools.ietf.org" <draft-detienne-dmvpn@tools.ietf.org>, "Mark Comeadow (mcomeado)" <mcomeado@cisco.com>, "Mike Sullenberger (mls)" <mls@cisco.com>, "Michael Guilfor= d (mguilfor)" <mguilfor@cisco= .com>, IPsecme WG <ipsec@ietf.org> Subject: Re: [IPsec] AD VPN: discus= sion kick off

Michael,
 
I would say that DMVPN is much more than a "brilliant hack".=   Of the three proposals it is the only one that uses layering to crea= te a real VPN with emphasis on network. The other two proposals are just ad= ding some dynamic functionality onto a collection of tunnels, but don=92t actually form that collection into a network.
If we look at the layers (which are based on standard protocols) from = top-down we see:
  • Routing/forwarding layer over the VPN.  This uses standard routing= protocols (EIGRP, OSPF, BGP, RIP) to advertise and propagate throughout th= e VPN the networks (subnets,=85) that are available through the VPN.  = If a new IP based routing protocol comes along no changes would be needed in the other layers to support it.  Also i= f more forwarding granularity is needed there are standard mechanism to do = policy based forwarding, including SDN (or SDN like features). These could = be implemented without changes to the other layers. 
  • GRE tunneling layer.  This provides stan= dards based multi-protocol tunneling.  GRE can tunnel both IPv4, IPv6 = and non-IP protocols over the same IPv4 or ipv6 infrastructure transport la= yer.  IPsec doesn't know nor need to know anything about the passenger protocols and therefore doesn't need to change.  Also in the future i= f a better standard tunneling protocol comes along, the GRE layer could be = replaced with this new layer with minimal changes to the adjacent layers.
  • NHRP mapping layer.  In any dynamic network there needs to be t= he equivalent of ARP (like on an Ethernet).  When  you are talkin= g about a collection of tunnels this ARP like protocol must be a bit more c= omplex.  NHRP was specifically designed for "tunnel NBMA networks" (ATM, Frame Relay) and the VPN networks that we are ta= lking about building here are the exact same thing. So it is best to go wit= h a standard protocol that was specifically designed for this layer of the = network.
  • IPsec encryption layer.  In this layer ISAKMP/IKEv2/I= Psec is the correct standard protocol to use.  This is what IPsec does= really well, encrypt traffic. The layers above greatly simplifies IPsec's = job by presenting to it the tunnel to encrypt instead of all of the individual protocols/subnets/flows that are within the tunnel.&= nbsp; The IPsec selectors are now for the tunnel, which makes path redundan= cy and load-balancing  doable. IPsec doesn't deal well with the same s= et of selectors to encrypt traffic to more than one peer.  With DMVPN this is handled at the routing/forwarding = and GRE tunnel layers.
 <= /div>
The other proposals will have to reinvent one or more of these layers,= which will end up being less efficient. There are also specific issues wit= h IPsec, in particular, IPsec having to deal directly with the data plane f= lows.  With 10s of thousands of nodes and perhaps 100s of thousands of network/subnets reachable via the V= PN the number of IPsec selectors across the VPN would get completely out of= hand, especially if each different pair of subnets (selector) requires a s= eparate encryption, between the same two nodes.  This doesn=92t even count the fact that in order to = run IPv4 and IPv6 between the same two nodes you have to use at least doubl= e the number of selectors. Routing protocols are already designed to scale = to 100s of thousands and even millions of routes. So with DMVPN the forwarding and GRE tunneling of both IPv4 and= IPv6 is handled within a single GRE tunnel and IPsec selector. NHRP for sp= oke-hub tunnels doesn=92t have to do anything more, routing takes care of t= his.  NHRP for shortcut tunnels will have to pass and store (in the routing table) the individual subnets that = are to be reachable through the shortcut tunnel, but this is much more ligh= tweight then IPsec doing the same thing, which it would have to do with the= other proposals.  Also, as mentioned above, IPsec is particular bad at supporting redundancy and load balancing= of the same data subnets via different paths, without having to create an = IPsec SA per data flow.
 
Note, with DMVPN at the routing/forwarding level you can use various s= tatic and dynamic features that =93split-tunnel=94 traffic even down to the= specific application or flow.  All without having to deal with possib= ly thousands of negotiated IPsec 5-tuples.  By dynamic a mean that application traffic flows can be measured over one = path and flow by flow can be redirected over another path.  Since this= is done at the routing/forwarding layer these are exactly the same mechani= sms that are already in use over LAN and physical WAN networks.  My point here is that, why reinvent the s= ame mechanism in IPsec when you don=92t have to and are likely not going to= be able to do as good a job as a mechanism that was designed just for that= specific purpose.
 
As far as implementation is concerned, there are now at least 3 main v= endors other than Cisco that claim they have support for DMVPN, and I prett= y much believe their claim is likely to be true.  Once DMVPN is a stan= dard then any differences will be quickly worked out.  As for hosts they can join the network in one of three w= ays.
  • As a non-encrypting node behind a gateway node that supports DMVPN.
  • As a pure IPsec node connecting into a gateway or hub node and thus ga= ining access to the DMVPN, but not able to support direct shortcut tunnels.=
  • As a full node, in which case the node would have to support a rou= ting protocol (possibly optional), GRE tunneling, NHRP mapping and IPsec.&n= bsp; Of this list the only new thing is NHRP mapping functionality. There w= ill of course need to be some additions to the code for the layers to work cleanly with each other.  Many host s= tacks already have a level of support for the other three layers (routing, = GRE, IPsec).
 <= /div>
As for the draft-mao-ipsecme proposal, I think the ADS is the wrong wa= y to go.  The ADS is going to be a single point congestion and failure= in the VPN.  Even if you have multiple ADSs in the network they will = have to all keep their databases in sync, which adds more problems when trying to scale these networks to 10s of tho= usands of nodes and larger.
 
Mike.
 
 
Mike Sullenberger, DSE
mls@cisco.com          &n= bsp; .:|:.:|:.
Customer Advocacy         = ; CISCO
 
 
 
 <= /div>
> -----Original Message-----
> Of Michael Richardson
> Sent: Saturday, November 02, 2013 12:18 PM
> To: IPsecme WG
> Subject: Re: [IPsec] AD VPN: discussion kick off
>
>
> {Sorry about that, the email configuration my tablet had a \n in = a header
> that did not belong}
>
> I have read all three proposals, although I missed the Q&A in= Berlin.
> I am looking forward to further Q&A in Berlin.
>
> When I read the NBMA protocol (DMVPN, I think) version what I saw= was a
> very brilliant hack that managed to take two code bases (IPsec an= d ATM)
> that were likely already present in that vendor's firmware and co= nnect
> them.  Likely, it took only a few weeks of brilliant hacking= , and it was ready
> for customer use.
>
> I find that this solution for anyone else involves the most amoun= t of new
> code, and I think it will the most difficult to support on variou= s mobile and
> laptop platforms as it requires new encapsulation modes.
>
> draft-mao-ipsecme is architecturally the closest to me, and I lik= e the ADS
> idea: it seems that it be implemented without any new kernel code= , and I
> think that if we are trying  to get remote warrior and branc= h office RTP
> traffic to take a more direct route, then  eliminating the n= eed for a more
> network plumbing, and just doing things in IKE is the right answe= r.  (%)
>
> I don't like having a new protocol: I want it in IKE.  While= it can and should
> run inside the tunnel, I don't see why adding a new port to my IK= E daemon
> makes my life easier.
>
> I *do* like the way that DMVPN uses probe packets to discover the= end
> points of the shorter routes, and I would look forward to includi= ng that
> mechanism somehow.  I don't know how to do that without hack= s to the
> data plane, which I'd like to avoid.  I can imagine some way= s to do this with a
> traceroute process, but it seems kludgy and brittle. (really, tha= t's still
> dataplane, but it's using an existing mechanism)
>
> I don't like that DMVPN does not let http traffic continue to tra= vel via HQ's
> virus/trojan/netnanny while RTP takes the shortcut.
>
>
> (%)- the plumbing might need a way to sample 5-tuple flows to see= if there
> is traffic that should be shortcut. However, various schemes to p= ut more
> specific SPD entries in that cause key requests might accomplish = this
> without new kernel code.
>
> --
> Michael Richardson
> -on the road-
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>
 <= /div>
 <= /div>
--_000_CE9D37811CA4ACpraveenysjunipernet_-- From kent@bbn.com Mon Nov 4 13:57:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDE621F9A40 for ; Mon, 4 Nov 2013 13:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.329 X-Spam-Level: X-Spam-Status: No, score=-106.329 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INt9W2ckdRJ9 for ; Mon, 4 Nov 2013 13:57:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AB51821F9FB9 for ; Mon, 4 Nov 2013 13:57:22 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:57804 helo=dhcp-a369.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VdS98-000ECz-Ng; Mon, 04 Nov 2013 16:57:19 -0500 Message-ID: <5278183E.500@bbn.com> Date: Mon, 04 Nov 2013 16:57:18 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Mike Sullenberger (mls)" , Michael Richardson References: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> In-Reply-To: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> Content-Type: multipart/alternative; boundary="------------010707020002000608090004" Cc: "Stephen Lynn \(stlynn\)" , "Michael Guilford \(mguilfor\)" , IPsecme WG , "draft-detienne-dmvpn@tools.ietf.org" , "Mark Comeadow \(mcomeado\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:57:51 -0000 This is a multi-part message in MIME format. --------------010707020002000608090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, A couple of your comments caught my attention, as an author of 4301, 02, and 03. I admit to not having read the DMVPN proposal, so my comments are based only on your message, which argues why DMVPN is the preferred solution. > IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the > correct standard protocol to use. This is what IPsec does really well, > encrypt traffic. The layers above greatly simplifies IPsec's job by > presenting to it the tunnel to encrypt instead of all of the > individual protocols/subnets/flows that are within the tunnel. The > IPsec selectors are now for the tunnel, which makes path redundancy > and load-balancing doable. IPsec doesn't deal well with the same set > of selectors to encrypt traffic to more than one peer. With DMVPN this > is handled at the routing/forwarding and GRE tunnel layers. IPsec is not just about encryption, although the DMVPN proposal may relegate it to that. IPsec provides access control, and, typically, authentication. Does DMVPN preserve the access control features of IPsec, or are users now relying on a hub to do this, or what? > ... With 10s of thousands of nodes and perhaps 100s of thousands of > network/subnets reachable via the VPN the number of IPsec selectors > across the VPN would get completely out of hand, especially if each > different pair of subnets (selector) requires a separate encryption, > between the same two nodes. More properly, a separate SA, and only if the folks who manage policies at each end of the SA decide to provide fine-grained access control for the traffic flows. It was not clear to me that the problem statement for this work envisioned VPNs of the scale you mention. Also, the comments above are a bit confusing. Both end points and security gateways are "nodes" wrt IPsec, in the general sense. I can create a selector that secures traffic from my node (and point of subnet) to all hosts on a subnet, irrespective of how many are present there. > This doesn't even count the fact that in order to run IPv4 and IPv6 > between the same two nodes you have to use at least double the number > of selectors. At least? Under what circumstances would the number grow by more than a factor of two? > Routing protocols are already designed to scale to 100s of thousands > and even millions of routes. So with DMVPN the forwarding and GRE > tunneling of both IPv4 and IPv6 is handled within a single GRE tunnel > and IPsec selector. So, the proposal simplifies use of IPsec by limiting the granularity at which SAs may be created? Does it also cause each SA to terminate at a hub, so that the security services are no longer e-t-e? In the context of the perpass discussions, this seems like a questionable design decision. Steve --------------010707020002000608090004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

A couple of your comments caught my attention, as an author of 4301, 02, and 03. I admit to not having read the DMVPN proposal, so my comments are based only on your message, which argues why DMVPN is the preferred solution.
IPsec encryption layer.  In this layer ISAKMP/IKEv2/IPsec is the correct standard protocol to use.  This is what IPsec does really well, encrypt traffic. The layers above greatly simplifies IPsec's job by presenting to it the tunnel to encrypt instead of all of the individual protocols/subnets/flows that are within the tunnel.  The IPsec selectors are now for the tunnel, which makes path redundancy and load-balancing  doable. IPsec doesn't deal well with the same set of selectors to encrypt traffic to more than one peer.  With DMVPN this is handled at the routing/forwarding and GRE tunnel layers.
IPsec is not just about encryption, although the DMVPN proposal may relegate it to that. IPsec provides access control, and, typically, authentication.  Does DMVPN preserve the access control features of IPsec, or are users now relying on a hub to do this, or what?
 ...  With 10s of thousands of nodes and perhaps 100s of thousands of network/subnets reachable via the VPN the number of IPsec selectors across the VPN would get completely out of hand, especially if each different pair of subnets (selector) requires a separate encryption, between the same two nodes. 
More properly, a separate SA, and only if the folks who manage policies at each end of the SA decide to provide fine-grained access control for the traffic flows. It was not clear to me that the problem statement for this work envisioned VPNs of the scale you mention. Also, the comments above are a bit confusing. Both end points and security gateways are "nodes" wrt IPsec, in the general sense. I can create a selector that secures traffic from my node (and point of subnet) to all hosts on a subnet, irrespective of how many are present there. 
This doesn’t even count the fact that in order to run IPv4 and IPv6 between the same two nodes you have to use at least double the number of selectors.
At least? Under what circumstances would the number grow by more than a factor of two?
Routing protocols are already designed to scale to 100s of thousands and even millions of routes. So with DMVPN the forwarding and GRE tunneling of both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selector.
So, the proposal simplifies use of IPsec by limiting the granularity at which SAs may be created? Does it also cause each SA to terminate at a hub, so that the security services are no longer e-t-e?  In the context of the perpass discussions, this seems like a questionable design decision.
 
Steve
--------------010707020002000608090004-- From mcr@sandelman.ca Mon Nov 4 15:18:24 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0004321E8273 for ; Mon, 4 Nov 2013 15:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j322-be6KcCz for ; Mon, 4 Nov 2013 15:18:19 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id ED6D321E82A9 for ; Mon, 4 Nov 2013 15:18:12 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 65B11E0B7; Mon, 4 Nov 2013 19:29:48 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 56D9463B88; Mon, 4 Nov 2013 18:18:09 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4623163AED; Mon, 4 Nov 2013 18:18:09 -0500 (EST) From: Michael Richardson To: "\" , Paul Simon In-Reply-To: <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> 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: Yoav Nir Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:18:24 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > There are currently no attributes in IKE to negotiate QoS. > The reason for that text in 5996 is the issue of IPsec packet > re-ordering. If we use the same SA for packets with different QoS > characteristics, then the QoS could then re-order them. This means th= at > replay protection would drop legitimate packets simply because they > arrived late. To avoid this, the sender may use several SAs so as to > send packets with different QoS characteristics in different > tunnels. This requires no negotiation of QoS characteristics between > the peers, only negotiation of enough SAs for all the different QoS > classes. > If I'm missing something, and there is a need to negotiate this, you > can always submit an I-D. I think you are missing the point. Paul said: > We are having a requirement to have Qos per CHILD SA inside one IKE SA or= to > have Qos per IKE SA. Is it possible to communicate the Qos in IKE handsha= ke ? > Or else how can we achieve to use different Qos, atleast per IKE SA. so, you'd see that actually he wants to have multiple CHILD SAs already. The point is that the packets coming into the tunnel may not be marked in a= ny particular way, and the "network" (as Paul calls it. I assume he means some more specific LTE element) needs to inform the UE what markings to use. 4301, section 5.1.2 includes: > Another will allow the outer DS field to be mapped to a > fixed value, which MAY be configured on a per-SA basis. (The value > might really be fixed for all traffic outbound from a device, but > per-SA granularity allows that as well.) This configuration option and this is what Paul wants to do. The "network" (i.e. the access concentrator) needs to tell the UE located at the client/device what DS to use on that network. My suggestion is, since this is not something is subject to negotiation, th= at=20 simply defining a new notification value. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUngrLoqHRg3pndX9AQIiRQP+N1fv1+CkNvjQjOYH1L6EBaM3JL9ZwUpC EJjyiZssBeAWoqKXq1NA7FGJiTEuGDyeBqR91HDfcYi3j7D87b/O8LmdTPTkNPux IJOrw94uJ9EcZHMB6hmb9cCqCwYUzLeV65YK/Y1+IoJlNx5dmBzPW9dlthHWXrnP e3Iz03pKIao= =2ws8 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Nov 4 15:34:03 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F236021E8277 for ; Mon, 4 Nov 2013 15:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S65Ju4SyBea9 for ; Mon, 4 Nov 2013 15:33:57 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id E865021E8274 for ; Mon, 4 Nov 2013 15:33:50 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id AEABCE0B7; Mon, 4 Nov 2013 19:45:24 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 65F0D63B88; Mon, 4 Nov 2013 18:33:46 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 549E263AED; Mon, 4 Nov 2013 18:33:46 -0500 (EST) From: Michael Richardson To: piyush In-Reply-To: <52772F67.3040502@torresnetworks.com> References: <5270CAA0.2070003@torresnetworks.com> <52772F67.3040502@torresnetworks.com> 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] Qos provisioning using ikev2. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:34:03 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable piyush wrote: > I have a query, or rather seeking help from you. I need to implement > QoS for IKEv2, but i am unable to find any document, which provides me > with an AVP inside IKEv2, which can be used for transmitting QoS > information. Can you please let me know that which AVP can be used? > Your help will be appreciated. > --=20 Does this thread help you: http://www.ietf.org/mail-archive/web/ipsec/current/msg08740.html Do you have the same problem as Paul? =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUngu14qHRg3pndX9AQIFlQQAoU0CohLBqSuvoXZHbE2ANgOVHFRrUaZJ fivBgzVVUyDkspwBYDSr3BV3cKusj4BgLxVF7Nsh1KSo7xiN8qgpxZN5sxW0GuRc UZFMvAXUMa9Wzlk1YC1CZwq2bp0BzKqPAsDeqd01jZm+loeNuGm4sOL6V4Wy/4bA G6gzOF+99Jk= =a15/ -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Mon Nov 4 15:34:49 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD7621E82B1 for ; Mon, 4 Nov 2013 15:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE5X9VEN+JvF for ; Mon, 4 Nov 2013 15:34:44 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 825DA11E82E2 for ; Mon, 4 Nov 2013 15:34:41 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA4NYbdo023452; Tue, 5 Nov 2013 01:34:37 +0200 X-CheckPoint: {52782DB4-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 01:34:36 +0200 From: Yoav Nir To: Michael Richardson Thread-Topic: [IPsec] Query regarding Qos with IKE Thread-Index: AQHO2T0lqIBsUjWJEE+iW3Hntr4dIpoUsHkAgACFNICAAAMQgIAAW4GAgAAEl4A= Date: Mon, 4 Nov 2013 23:34:36 +0000 Message-ID: <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> In-Reply-To: <31580.1383607089@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.194] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <5BEB3875BBEEF948A65568DE4327DB7C@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Paul Simon Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:34:49 -0000 Like I said, Paul can submit an I-D.=20 But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no? And you really need = to do this for the clear packet anyways, because it needs to be handled wit= h QoS at the provider network too. If you do it in the app layer, it doesn'= t require any modifications to IKE. Yoav On Nov 4, 2013, at 3:18 PM, Michael Richardson wrot= e: >=20 > Yoav Nir wrote: >> There are currently no attributes in IKE to negotiate QoS. >=20 >> The reason for that text in 5996 is the issue of IPsec packet >> re-ordering. If we use the same SA for packets with different QoS >> characteristics, then the QoS could then re-order them. This means that >> replay protection would drop legitimate packets simply because they >> arrived late. To avoid this, the sender may use several SAs so as to >> send packets with different QoS characteristics in different >> tunnels. This requires no negotiation of QoS characteristics between >> the peers, only negotiation of enough SAs for all the different QoS >> classes. >=20 >> If I'm missing something, and there is a need to negotiate this, you >> can always submit an I-D. >=20 > I think you are missing the point. >=20 > Paul said: >> We are having a requirement to have Qos per CHILD SA inside one IKE SA o= r to >> have Qos per IKE SA. Is it possible to communicate the Qos in IKE handsh= ake ? >> Or else how can we achieve to use different Qos, atleast per IKE SA. >=20 > so, you'd see that actually he wants to have multiple CHILD SAs already. > The point is that the packets coming into the tunnel may not be marked in= any > particular way, and the "network" (as Paul calls it. I assume he means > some more specific LTE element) needs to inform the UE what markings to u= se. >=20 > 4301, section 5.1.2 includes: >> Another will allow the outer DS field to be mapped to a >> fixed value, which MAY be configured on a per-SA basis. (The value >> might really be fixed for all traffic outbound from a device, but >> per-SA granularity allows that as well.) This configuration option >=20 > and this is what Paul wants to do. The "network" (i.e. the access > concentrator) needs to tell the UE located at the client/device what DS t= o > use on that network. >=20 > My suggestion is, since this is not something is subject to negotiation, = that=20 > simply defining a new notification value. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh netwo= rks [=20 > ] Michael Richardson, Sandelman Software Works | network archite= ct [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [=20 From paulsimon.c@gmail.com Mon Nov 4 22:34:35 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9464711E8176 for ; Mon, 4 Nov 2013 22:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCzCSpQmbuUc for ; Mon, 4 Nov 2013 22:34:34 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 33C3121F9E36 for ; Mon, 4 Nov 2013 22:34:34 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so13954745iec.20 for ; Mon, 04 Nov 2013 22:34:33 -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 :content-type; bh=m+/AVeJKjStphU5/vGqvdaqI9aT3png5zEcGM/hrmTo=; b=KIG4QjD5sXW9QWLzhYYIvV/syAR1/GcvCaHG3UtGf+naa248WI2OOtSgn9jETHzF/X k7/aJ8Iasle6bVhCRg+DBZOoTQ62vLRQh/GViRc941qcqDYI6TJ160f0RvYqyLEYbQ9x vM/BnaVgfdEquXMPNEPZBARbtuedUDoJjpjzWFt4dArRu/+FAXz2+aQ978fB7sq0mVwL nbyf3B3ZC87T/bvtdP3cjj1+nYVCw3LK1AqlswmqL97EXhreVA8jJ6DdIMUTBjzH5xpr g/WMUMYjC3q5/2eWOooWt90EErDwl4aLdo/OR5JlhqzRitS7r2CbNvQiN6z65sAo+6om Db4w== MIME-Version: 1.0 X-Received: by 10.50.23.103 with SMTP id l7mr14782422igf.3.1383633273607; Mon, 04 Nov 2013 22:34:33 -0800 (PST) Received: by 10.64.7.12 with HTTP; Mon, 4 Nov 2013 22:34:33 -0800 (PST) In-Reply-To: <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> Date: Tue, 5 Nov 2013 12:04:33 +0530 Message-ID: From: Paul Simon To: Michael Richardson , "" , Yoav Nir Content-Type: multipart/alternative; boundary=089e0158aabac5dede04ea68399f Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 06:34:35 -0000 --089e0158aabac5dede04ea68399f Content-Type: text/plain; charset=ISO-8859-1 As indicated by Richardson [ The "network" (i.e. the access concentrator) needs to tell the UE located at the client/device what DS to use on that network. ] This is exactly I need. The UE tells the network element what is the desired Qos that UE is willing to use for an SA and Network in turn replies to UE what Qos can really be used. (because finally it is the network which decides what characteristics the traffic can hold). So as I understand currently Qos cannot be indicated through IKE messages and it has to be done through some application level protocols. But since the Qos based traffic is gaining more importance these days, it would be better if we can accommodate Qos as one of the parameter in IKE negotiation messages. Thanks, Paul On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir wrote: > Like I said, Paul can submit an I-D. > > But if the UE applies the diffserv to the clear packet, 4301 says that > these attributes are copied to the ESP packet. There has to be some > handshake at the application layer to pass this information, no? And you > really need to do this for the clear packet anyways, because it needs to be > handled with QoS at the provider network too. If you do it in the app > layer, it doesn't require any modifications to IKE. > > Yoav > > On Nov 4, 2013, at 3:18 PM, Michael Richardson > wrote: > > > > > Yoav Nir wrote: > >> There are currently no attributes in IKE to negotiate QoS. > > > >> The reason for that text in 5996 is the issue of IPsec packet > >> re-ordering. If we use the same SA for packets with different QoS > >> characteristics, then the QoS could then re-order them. This means that > >> replay protection would drop legitimate packets simply because they > >> arrived late. To avoid this, the sender may use several SAs so as to > >> send packets with different QoS characteristics in different > >> tunnels. This requires no negotiation of QoS characteristics between > >> the peers, only negotiation of enough SAs for all the different QoS > >> classes. > > > >> If I'm missing something, and there is a need to negotiate this, you > >> can always submit an I-D. > > > > I think you are missing the point. > > > > Paul said: > >> We are having a requirement to have Qos per CHILD SA inside one IKE SA > or to > >> have Qos per IKE SA. Is it possible to communicate the Qos in IKE > handshake ? > >> Or else how can we achieve to use different Qos, atleast per IKE SA. > > > > so, you'd see that actually he wants to have multiple CHILD SAs already. > > The point is that the packets coming into the tunnel may not be marked > in any > > particular way, and the "network" (as Paul calls it. I assume he means > > some more specific LTE element) needs to inform the UE what markings to > use. > > > > 4301, section 5.1.2 includes: > >> Another will allow the outer DS field to be mapped to a > >> fixed value, which MAY be configured on a per-SA basis. (The value > >> might really be fixed for all traffic outbound from a device, but > >> per-SA granularity allows that as well.) This configuration option > > > > and this is what Paul wants to do. The "network" (i.e. the access > > concentrator) needs to tell the UE located at the client/device what DS > to > > use on that network. > > > > My suggestion is, since this is not something is subject to negotiation, > that > > simply defining a new notification value. > > > > -- > > ] Never tell me the odds! | ipv6 mesh > networks [ > > ] Michael Richardson, Sandelman Software Works | network > architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > --089e0158aabac5dede04ea68399f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
As indicated by Richardson [ The "= network" (i.e. the access
concentrator) needs to tell the UE locat= ed at the client/device what DS to
use on that network. ]
= =A0
This is exactly I need. The UE tells the network element what is the d= esired Qos that UE is willing to use for an SA and=A0Network in turn replie= s to UE what Qos can really be used. (because finally it is the network whi= ch decides what characteristics the traffic can hold).
=A0
So as I understand currently Qos cannot be indicated thr= ough IKE messages and it has to be done through some application level prot= ocols.
=A0
But=A0since the Qos based traffic=A0is gaini= ng more importance=A0these days, it would be better if we can accommodate Q= os as one of the parameter in IKE negotiation messages.
=A0
Thanks,
Paul
=A0


On Tue, Nov 5, 20= 13 at 5:04 AM, Yoav Nir <ynir@checkpoint.com> wrote:
Like I said, Paul can submit an I-D.

But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no? =A0And you really nee= d to do this for the clear packet anyways, because it needs to be handled w= ith QoS at the provider network too. If you do it in the app layer, it does= n't require any modifications to IKE.

Yoav

On Nov 4, 2013, at 3:18 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

>
> Yoav Nir <ynir@checkpoint.co= m> wrote:
>> There are currently no attributes in IKE to negotiate QoS.
>
>> The reason for that text in 5996 is the issue of IPsec packet
>> re-ordering. If we use the same SA for packets with different QoS<= br> >> characteristics, then the QoS could then re-order them. This means= that
>> replay protection would drop legitimate packets simply because the= y
>> arrived late. To avoid this, the sender may use several SAs so as = to
>> send packets with different QoS characteristics in different
>> tunnels. This requires no negotiation of QoS characteristics betwe= en
>> the peers, only negotiation of enough SAs for all the different Qo= S
>> classes.
>
>> If I'm missing something, and there is a need to negotiate thi= s, you
>> can always submit an I-D.
>
> I think you are missing the point.
>
> Paul said:
>> We are having a requirement to have Qos per CHILD SA inside one IK= E SA or to
>> have Qos per IKE SA. Is it possible to communicate the Qos in IKE = handshake ?
>> Or else how can we achieve to use different Qos, atleast per IKE S= A.
>
> so, you'd see that actually he wants to have multiple CHILD SAs al= ready.
> The point is that the packets coming into the tunnel may not be marked= in any
> particular way, and the "network" (as Paul calls it. I assum= e he means
> some more specific LTE element) needs to inform the UE what markings t= o use.
>
> 4301, section 5.1.2 includes:
>> Another will allow the outer DS field to be mapped to a
>> fixed value, which MAY be configured on a per-SA basis. (The value=
>> might really be fixed for all traffic outbound from a device, but<= br> >> per-SA granularity allows that as well.) This configuration option=
>
> and this is what Paul wants to do. =A0The "network" (i.e. th= e access
> concentrator) needs to tell the UE located at the client/device what D= S to
> use on that network.
>
> My suggestion is, since this is not something is subject to negotiatio= n, that
> simply defining a new notification value.
>
> --
> ] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | ipv6 mesh networks [
> ] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| ne= twork architect =A0[
> ] =A0 =A0 mcr@sandelman.ca =A0= http://www.sandelman= .ca/ =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[


--089e0158aabac5dede04ea68399f-- From ynir@checkpoint.com Mon Nov 4 22:45:39 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2CF21E811D for ; Mon, 4 Nov 2013 22:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pppIwkoE-lfY for ; Mon, 4 Nov 2013 22:45:34 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2020B21E809E for ; Mon, 4 Nov 2013 22:45:33 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA56jQTl021235; Tue, 5 Nov 2013 08:45:26 +0200 X-CheckPoint: {527892A8-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 08:45:26 +0200 From: Yoav Nir To: Paul Simon Thread-Topic: [IPsec] Query regarding Qos with IKE Thread-Index: AQHO2T0lqIBsUjWJEE+iW3Hntr4dIpoUsHkAgACFNICAAAMQgIAAW4GAgAAEl4CAAHVWgIAAAwqA Date: Tue, 5 Nov 2013 06:45:25 +0000 Message-ID: <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.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.53] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_6FACBED82A914532AF3B8FE065B95CE8checkpointcom_" MIME-Version: 1.0 Cc: "" , Michael Richardson Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 06:45:39 -0000 --_000_6FACBED82A914532AF3B8FE065B95CE8checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is what you're looking for multiple DS for the same selectors, or just a si= ngle DS for each set of selectors, that is determined by the AC? On Nov 4, 2013, at 10:34 PM, Paul Simon > wrote: As indicated by Richardson [ The "network" (i.e. the access concentrator) needs to tell the UE located at the client/device what DS to use on that network. ] This is exactly I need. The UE tells the network element what is the desire= d Qos that UE is willing to use for an SA and Network in turn replies to UE= what Qos can really be used. (because finally it is the network which deci= des what characteristics the traffic can hold). So as I understand currently Qos cannot be indicated through IKE messages a= nd it has to be done through some application level protocols. But since the Qos based traffic is gaining more importance these days, it w= ould be better if we can accommodate Qos as one of the parameter in IKE neg= otiation messages. Thanks, Paul On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir > wrote: Like I said, Paul can submit an I-D. But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no? And you really need = to do this for the clear packet anyways, because it needs to be handled wit= h QoS at the provider network too. If you do it in the app layer, it doesn'= t require any modifications to IKE. Yoav On Nov 4, 2013, at 3:18 PM, Michael Richardson > wrote: > > Yoav Nir > wrote: >> There are currently no attributes in IKE to negotiate QoS. > >> The reason for that text in 5996 is the issue of IPsec packet >> re-ordering. If we use the same SA for packets with different QoS >> characteristics, then the QoS could then re-order them. This means that >> replay protection would drop legitimate packets simply because they >> arrived late. To avoid this, the sender may use several SAs so as to >> send packets with different QoS characteristics in different >> tunnels. This requires no negotiation of QoS characteristics between >> the peers, only negotiation of enough SAs for all the different QoS >> classes. > >> If I'm missing something, and there is a need to negotiate this, you >> can always submit an I-D. > > I think you are missing the point. > > Paul said: >> We are having a requirement to have Qos per CHILD SA inside one IKE SA o= r to >> have Qos per IKE SA. Is it possible to communicate the Qos in IKE handsh= ake ? >> Or else how can we achieve to use different Qos, atleast per IKE SA. > > so, you'd see that actually he wants to have multiple CHILD SAs already. > The point is that the packets coming into the tunnel may not be marked in= any > particular way, and the "network" (as Paul calls it. I assume he means > some more specific LTE element) needs to inform the UE what markings to u= se. > > 4301, section 5.1.2 includes: >> Another will allow the outer DS field to be mapped to a >> fixed value, which MAY be configured on a per-SA basis. (The value >> might really be fixed for all traffic outbound from a device, but >> per-SA granularity allows that as well.) This configuration option > > and this is what Paul wants to do. The "network" (i.e. the access > concentrator) needs to tell the UE located at the client/device what DS t= o > use on that network. > > My suggestion is, since this is not something is subject to negotiation, = that > simply defining a new notification value. > > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/= | ruby on rails [ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_6FACBED82A914532AF3B8FE065B95CE8checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Is what you're looking for multiple DS for the same selectors, or just a si= ngle DS for each set of selectors, that is determined by the AC?

On Nov 4, 2013, at 10:34 PM, Paul Simon <paulsimon.c@gmail.com> wrote:

 
As indicated by Richardson [ The "network" (i.e. the access<= br> concentrator) needs to tell the UE located at the client/device what DS to<= br> use on that network. ]
 
This is exactly I need. The UE tells the network element what is the d= esired Qos that UE is willing to use for an SA and Network in turn rep= lies to UE what Qos can really be used. (because finally it is the network = which decides what characteristics the traffic can hold).
 
So as I understand currently Qos cannot be indicated through IKE messa= ges and it has to be done through some application level protocols.
 
But since the Qos based traffic is gaining more importance&n= bsp;these days, it would be better if we can accommodate Qos as one of the = parameter in IKE negotiation messages.
 
Thanks,
Paul
 


On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir <ynir@checkpoin= t.com> wrote:
Like I said, Paul can submit an I-D.

But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no?  And you really = need to do this for the clear packet anyways, because it needs to be handled with QoS at the provider network t= oo. If you do it in the app layer, it doesn't require any modifications to = IKE.

Yoav

On Nov 4, 2013, at 3:18 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

>
> Yoav Nir <ynir@checkpoint.co= m> wrote:
>> There are currently no attributes in IKE to negotiate QoS.
>
>> The reason for that text in 5996 is the issue of IPsec packet
>> re-ordering. If we use the same SA for packets with different QoS<= br> >> characteristics, then the QoS could then re-order them. This means= that
>> replay protection would drop legitimate packets simply because the= y
>> arrived late. To avoid this, the sender may use several SAs so as = to
>> send packets with different QoS characteristics in different
>> tunnels. This requires no negotiation of QoS characteristics betwe= en
>> the peers, only negotiation of enough SAs for all the different Qo= S
>> classes.
>
>> If I'm missing something, and there is a need to negotiate this, y= ou
>> can always submit an I-D.
>
> I think you are missing the point.
>
> Paul said:
>> We are having a requirement to have Qos per CHILD SA inside one IK= E SA or to
>> have Qos per IKE SA. Is it possible to communicate the Qos in IKE = handshake ?
>> Or else how can we achieve to use different Qos, atleast per IKE S= A.
>
> so, you'd see that actually he wants to have multiple CHILD SAs alread= y.
> The point is that the packets coming into the tunnel may not be marked= in any
> particular way, and the "network" (as Paul calls it. I assum= e he means
> some more specific LTE element) needs to inform the UE what markings t= o use.
>
> 4301, section 5.1.2 includes:
>> Another will allow the outer DS field to be mapped to a
>> fixed value, which MAY be configured on a per-SA basis. (The value=
>> might really be fixed for all traffic outbound from a device, but<= br> >> per-SA granularity allows that as well.) This configuration option=
>
> and this is what Paul wants to do.  The "network" (i.e.= the access
> concentrator) needs to tell the UE located at the client/device what D= S to
> use on that network.
>
> My suggestion is, since this is not something is subject to negotiatio= n, that
> simply defining a new notification value.
>
> --
> ]               Never tell me the o= dds!                 | ipv6 mesh ne= tworks [
> ]   Michael Richardson, Sandelman Software Works     &n= bsp;  | network architect  [
> ]     mcr@sandelman.ca  http://www.= sandelman.ca/        |   ruby on rails   =  [


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

--_000_6FACBED82A914532AF3B8FE065B95CE8checkpointcom_-- From jyotiranjans@huawei.com Mon Nov 4 22:49:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E46321E809E for ; Mon, 4 Nov 2013 22:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un+nWUB6XAvT for ; Mon, 4 Nov 2013 22:49:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9743321E8139 for ; Mon, 4 Nov 2013 22:49:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXO04968; Tue, 05 Nov 2013 06:49:05 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 06:48:25 +0000 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 06:49:03 +0000 Received: from SZXEML521-MBX.china.huawei.com ([169.254.1.34]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 14:48:59 +0800 From: Jyoti Ranjan Senapati To: "" Thread-Topic: //Please remove me from this group ..// Thread-Index: AQHO2fMaJFZDwAnJvUyygRQ96Juypg== Date: Tue, 5 Nov 2013 06:48:58 +0000 Message-ID: <8999380B202BD2438A46E07634CA7FDA5ECA8F01@szxeml521-mbx.china.huawei.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> In-Reply-To: <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.47.210] Content-Type: multipart/alternative; boundary="_000_8999380B202BD2438A46E07634CA7FDA5ECA8F01szxeml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [IPsec] //Please remove me from this group ..// X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 06:49:14 -0000 --_000_8999380B202BD2438A46E07634CA7FDA5ECA8F01szxeml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi ,, I want to unfriend from this group. Can you please help . Thanks and Regards, Jyoti Ranjan Senapati ***************************************************************************= ***************************************************************************= *********************************** This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! ***************************************************************************= ***************************************************************************= ****************************** From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Tuesday, November 05, 2013 12:15 PM To: Paul Simon Cc: ; Michael Richardson Subject: Re: [IPsec] Query regarding Qos with IKE Is what you're looking for multiple DS for the same selectors, or just a si= ngle DS for each set of selectors, that is determined by the AC? On Nov 4, 2013, at 10:34 PM, Paul Simon > wrote: As indicated by Richardson [ The "network" (i.e. the access concentrator) needs to tell the UE located at the client/device what DS to use on that network. ] This is exactly I need. The UE tells the network element what is the desire= d Qos that UE is willing to use for an SA and Network in turn replies to UE= what Qos can really be used. (because finally it is the network which deci= des what characteristics the traffic can hold). So as I understand currently Qos cannot be indicated through IKE messages a= nd it has to be done through some application level protocols. But since the Qos based traffic is gaining more importance these days, it w= ould be better if we can accommodate Qos as one of the parameter in IKE neg= otiation messages. Thanks, Paul On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir > wrote: Like I said, Paul can submit an I-D. But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no? And you really need = to do this for the clear packet anyways, because it needs to be handled wit= h QoS at the provider network too. If you do it in the app layer, it doesn'= t require any modifications to IKE. Yoav On Nov 4, 2013, at 3:18 PM, Michael Richardson > wrote: > > Yoav Nir > wrote: >> There are currently no attributes in IKE to negotiate QoS. > >> The reason for that text in 5996 is the issue of IPsec packet >> re-ordering. If we use the same SA for packets with different QoS >> characteristics, then the QoS could then re-order them. This means that >> replay protection would drop legitimate packets simply because they >> arrived late. To avoid this, the sender may use several SAs so as to >> send packets with different QoS characteristics in different >> tunnels. This requires no negotiation of QoS characteristics between >> the peers, only negotiation of enough SAs for all the different QoS >> classes. > >> If I'm missing something, and there is a need to negotiate this, you >> can always submit an I-D. > > I think you are missing the point. > > Paul said: >> We are having a requirement to have Qos per CHILD SA inside one IKE SA o= r to >> have Qos per IKE SA. Is it possible to communicate the Qos in IKE handsh= ake ? >> Or else how can we achieve to use different Qos, atleast per IKE SA. > > so, you'd see that actually he wants to have multiple CHILD SAs already. > The point is that the packets coming into the tunnel may not be marked in= any > particular way, and the "network" (as Paul calls it. I assume he means > some more specific LTE element) needs to inform the UE what markings to u= se. > > 4301, section 5.1.2 includes: >> Another will allow the outer DS field to be mapped to a >> fixed value, which MAY be configured on a per-SA basis. (The value >> might really be fixed for all traffic outbound from a device, but >> per-SA granularity allows that as well.) This configuration option > > and this is what Paul wants to do. The "network" (i.e. the access > concentrator) needs to tell the UE located at the client/device what DS t= o > use on that network. > > My suggestion is, since this is not something is subject to negotiation, = that > simply defining a new notification value. > > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/= | ruby on rails [ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_8999380B202BD2438A46E07634CA7FDA5ECA8F01szxeml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi ,,

 <= /p>

I want to unfriend from t= his group. Can you please help .

 <= /p>

=  

= Thanks and Regards,

= Jyoti Ranjan Senapati

=  

=  

=  

= ***************************************************************************= ***************************************************************************= ***********************************

= This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (i= ncluding, but not limited to, total or partial disclosure, reproduction, or= dissemination) by persons other than the intended recipient's) is prohibit= ed. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete i= t!

******************************= ***************************************************************************= ***************************************************************************=

 <= /p>

From: ipsec-bo= unces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Tuesday, November 05, 2013 12:15 PM
To: Paul Simon
Cc: <ipsec@ietf.org>; Michael Richardson
Subject: Re: [IPsec] Query regarding Qos with IKE<= /p>

 

Is what you're looking for multiple DS for the same = selectors, or just a single DS for each set of selectors, that is determine= d by the AC?

 

On Nov 4, 2013, at 10:34 PM, Paul Simon <paulsimon.c@gmail.com> wrote:=



 

As indicated by Richardson [ The "network"= (i.e. the access
concentrator) needs to tell the UE located at the client/device what DS to<= br> use on that network. ]

 

This is exactly I need. The UE tells the network ele= ment what is the desired Qos that UE is willing to use for an SA and N= etwork in turn replies to UE what Qos can really be used. (because finally = it is the network which decides what characteristics the traffic can hold).

 

So as I understand currently Qos cannot be indicated= through IKE messages and it has to be done through some application level = protocols.

 

But since the Qos based traffic is gaining= more importance these days, it would be better if we can accommodate = Qos as one of the parameter in IKE negotiation messages.

 

Thanks,

Paul

 

 

On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir <ynir@checkpoint.com&g= t; wrote:

Like I said, Paul can submit an I-D.

But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no?  And you really = need to do this for the clear packet anyways, because it needs to be handled with QoS at the provider network t= oo. If you do it in the app layer, it doesn't require any modifications to = IKE.

Yoav


On Nov 4, 2013, at 3:18 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

>
> Yoav Nir <ynir@checkpoint.co= m> wrote:
>> There are currently no attributes in IKE to negotiate QoS.
>
>> The reason for that text in 5996 is the issue of IPsec packet
>> re-ordering. If we use the same SA for packets with different QoS<= br> >> characteristics, then the QoS could then re-order them. This means= that
>> replay protection would drop legitimate packets simply because the= y
>> arrived late. To avoid this, the sender may use several SAs so as = to
>> send packets with different QoS characteristics in different
>> tunnels. This requires no negotiation of QoS characteristics betwe= en
>> the peers, only negotiation of enough SAs for all the different Qo= S
>> classes.
>
>> If I'm missing something, and there is a need to negotiate this, y= ou
>> can always submit an I-D.
>
> I think you are missing the point.
>
> Paul said:
>> We are having a requirement to have Qos per CHILD SA inside one IK= E SA or to
>> have Qos per IKE SA. Is it possible to communicate the Qos in IKE = handshake ?
>> Or else how can we achieve to use different Qos, atleast per IKE S= A.
>
> so, you'd see that actually he wants to have multiple CHILD SAs alread= y.
> The point is that the packets coming into the tunnel may not be marked= in any
> particular way, and the "network" (as Paul calls it. I assum= e he means
> some more specific LTE element) needs to inform the UE what markings t= o use.
>
> 4301, section 5.1.2 includes:
>> Another will allow the outer DS field to be mapped to a
>> fixed value, which MAY be configured on a per-SA basis. (The value=
>> might really be fixed for all traffic outbound from a device, but<= br> >> per-SA granularity allows that as well.) This configuration option=
>
> and this is what Paul wants to do.  The "network" (i.e.= the access
> concentrator) needs to tell the UE located at the client/device what D= S to
> use on that network.
>
> My suggestion is, since this is not something is subject to negotiatio= n, that
> simply defining a new notification value.
>
> --
> ]               Never tell me the o= dds!                 | ipv6 mesh ne= tworks [
> ]   Michael Richardson, Sandelman Software Works     &n= bsp;  | network architect  [
> ]     mcr@sandelman.ca  http://www.= sandelman.ca/        |   ruby on rails   =  [

 

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

 

--_000_8999380B202BD2438A46E07634CA7FDA5ECA8F01szxeml521mbxchi_-- From paulsimon.c@gmail.com Mon Nov 4 22:53:39 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0946921E8163 for ; Mon, 4 Nov 2013 22:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfsDoqBaWvQW for ; Mon, 4 Nov 2013 22:53:37 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9749011E81F0 for ; Mon, 4 Nov 2013 22:53:32 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id e14so13855833iej.8 for ; Mon, 04 Nov 2013 22:53:32 -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=MNZbmSATyoZca8t544lRrn0AuilunpqWkXlLNkx2fY8=; b=bK04xZkgz6D8ENFtSelpouHt4fHykKBemoFHC66RVENOZEbq1bLr8ZgmTFr9tOVnM5 Ph1u52bP21Zy+c2YgAFoEiRj8T+8hSuvpc1dlPPNO+E/LAlDSYh3aX6q+4YaLlwtcHJe wWRNogpv3pEJx0edA+2BI/uN0KsFbZy1w0EKF/i6BIXRQoB/yrULDwtw+T7IptIAZ1oI 5mtzlTmgFd0A5IqwBC8Wi9GXEQGECEK/vZKcuNIHXnkmhH7IQOTInUNsHxiN20JwZih7 bFfDsoN1tOj/Gbexd1ksjL9P52RWL1o9iPl0H5qDTRy5CUnrOaIPy6C90/yHJIHtwA8M o1DQ== MIME-Version: 1.0 X-Received: by 10.42.40.83 with SMTP id k19mr11908810ice.3.1383634412033; Mon, 04 Nov 2013 22:53:32 -0800 (PST) Received: by 10.64.7.12 with HTTP; Mon, 4 Nov 2013 22:53:31 -0800 (PST) In-Reply-To: <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> Date: Tue, 5 Nov 2013 12:23:31 +0530 Message-ID: From: Paul Simon To: Yoav Nir Content-Type: multipart/alternative; boundary=90e6ba1efbf4a0dc8c04ea687d64 Cc: "" , Michael Richardson Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 06:53:39 -0000 --90e6ba1efbf4a0dc8c04ea687d64 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am looking for both the solutions. But lets take the simpler case first, "single DS for each set of selectors". In this simple case as well, the DS should be negotiated (communicated ) from UE to Network Element and back from Network Element to UE before using the DS. Is it possible some way ? My requirement is that both the end points agree on the DS before it is getting used. Thanks, Paul On Tue, Nov 5, 2013 at 12:15 PM, Yoav Nir wrote: > Is what you're looking for multiple DS for the same selectors, or just a > single DS for each set of selectors, that is determined by the AC? > > On Nov 4, 2013, at 10:34 PM, Paul Simon wrote: > > > As indicated by Richardson [ The "network" (i.e. the access > concentrator) needs to tell the UE located at the client/device what DS to > use on that network. ] > > This is exactly I need. The UE tells the network element what is the > desired Qos that UE is willing to use for an SA and Network in turn replies > to UE what Qos can really be used. (because finally it is the network which > decides what characteristics the traffic can hold). > > So as I understand currently Qos cannot be indicated through IKE messages > and it has to be done through some application level protocols. > > But since the Qos based traffic is gaining more importance these days, it > would be better if we can accommodate Qos as one of the parameter in IKE > negotiation messages. > > Thanks, > Paul > > > > On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir wrote: > >> Like I said, Paul can submit an I-D. >> >> But if the UE applies the diffserv to the clear packet, 4301 says that >> these attributes are copied to the ESP packet. There has to be some >> handshake at the application layer to pass this information, no? And you >> really need to do this for the clear packet anyways, because it needs to be >> handled with QoS at the provider network too. If you do it in the app >> layer, it doesn't require any modifications to IKE. >> >> Yoav >> >> On Nov 4, 2013, at 3:18 PM, Michael Richardson >> wrote: >> >> > >> > Yoav Nir wrote: >> >> There are currently no attributes in IKE to negotiate QoS. >> > >> >> The reason for that text in 5996 is the issue of IPsec packet >> >> re-ordering. If we use the same SA for packets with different QoS >> >> characteristics, then the QoS could then re-order them. This means that >> >> replay protection would drop legitimate packets simply because they >> >> arrived late. To avoid this, the sender may use several SAs so as to >> >> send packets with different QoS characteristics in different >> >> tunnels. This requires no negotiation of QoS characteristics between >> >> the peers, only negotiation of enough SAs for all the different QoS >> >> classes. >> > >> >> If I'm missing something, and there is a need to negotiate this, you >> >> can always submit an I-D. >> > >> > I think you are missing the point. >> > >> > Paul said: >> >> We are having a requirement to have Qos per CHILD SA inside one IKE SA >> or to >> >> have Qos per IKE SA. Is it possible to communicate the Qos in IKE >> handshake ? >> >> Or else how can we achieve to use different Qos, atleast per IKE SA. >> > >> > so, you'd see that actually he wants to have multiple CHILD SAs already. >> > The point is that the packets coming into the tunnel may not be marked >> in any >> > particular way, and the "network" (as Paul calls it. I assume he means >> > some more specific LTE element) needs to inform the UE what markings to >> use. >> > >> > 4301, section 5.1.2 includes: >> >> Another will allow the outer DS field to be mapped to a >> >> fixed value, which MAY be configured on a per-SA basis. (The value >> >> might really be fixed for all traffic outbound from a device, but >> >> per-SA granularity allows that as well.) This configuration option >> > >> > and this is what Paul wants to do. The "network" (i.e. the access >> > concentrator) needs to tell the UE located at the client/device what DS >> to >> > use on that network. >> > >> > My suggestion is, since this is not something is subject to >> negotiation, that >> > simply defining a new notification value. >> > >> > -- >> > ] Never tell me the odds! | ipv6 mesh >> networks [ >> > ] Michael Richardson, Sandelman Software Works | network >> architect [ >> > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on >> rails [ >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > --90e6ba1efbf4a0dc8c04ea687d64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I am looking for both the= solutions.
=A0
But lets take the=A0simpler case first,= "single DS for each set of selectors".=A0
In this sim= ple case as well, the DS should be negotiated (communicated ) from UE to Ne= twork Element and back from Network Element to UE before using the DS.
Is it possible some way ?
=A0
My requirement is th= at both the end points agree on the DS before it is getting used.
=A0
Thanks,
Paul
=A0


On Tue, Nov 5, 2013 at 12:15 PM, Yoav Ni= r <ynir@checkpoint.com> wrote:
Is what you're looking for multiple DS for the same selectors, or just = a single DS for each set of selectors, that is determined by the AC?

On Nov 4, 2013, at 10:34 PM, Paul Simon <paulsimon.c@gmail.com> wrote:

=A0
As indicated by Richardson [ The "network" (i.e. the access<= br> concentrator) needs to tell the UE located at the client/device what DS to<= br> use on that network. ]
=A0
This is exactly I need. The UE tells the network element what is the d= esired Qos that UE is willing to use for an SA and=A0Network in turn replie= s to UE what Qos can really be used. (because finally it is the network whi= ch decides what characteristics the traffic can hold).
=A0
So as I understand currently Qos cannot be indicated through IKE messa= ges and it has to be done through some application level protocols.
=A0
But=A0since the Qos based traffic=A0is gaining more importance=A0these= days, it would be better if we can accommodate Qos as one of the parameter= in IKE negotiation messages.
=A0
Thanks,
Paul
=A0


On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir <ynir@checkpoin= t.com> wrote:
Like I said, Paul can submit an I-D.

But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no? =A0And you really nee= d to do this for the clear packet anyways, because it needs to be handled with QoS at the provider network t= oo. If you do it in the app layer, it doesn't require any modifications= to IKE.

Yoav

On Nov 4, 2013, at 3:18 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
> Yoav Nir <= ynir@checkpoint.com> wrote:
>> There are currently no attributes in IKE to negotiate QoS.
>
>> The reason for that text in 5996 is the issue of IPsec packet
>> re-ordering. If we use the same SA for packets with different QoS<= br> >> characteristics, then the QoS could then re-order them. This means= that
>> replay protection would drop legitimate packets simply because the= y
>> arrived late. To avoid this, the sender may use several SAs so as = to
>> send packets with different QoS characteristics in different
>> tunnels. This requires no negotiation of QoS characteristics betwe= en
>> the peers, only negotiation of enough SAs for all the different Qo= S
>> classes.
>
>> If I'm missing something, and there is a need to negotiate thi= s, you
>> can always submit an I-D.
>
> I think you are missing the point.
>
> Paul said:
>> We are having a requirement to have Qos per CHILD SA inside one IK= E SA or to
>> have Qos per IKE SA. Is it possible to communicate the Qos in IKE = handshake ?
>> Or else how can we achieve to use different Qos, atleast per IKE S= A.
>
> so, you'd see that actually he wants to have multiple CHILD SAs al= ready.
> The point is that the packets coming into the tunnel may not be marked= in any
> particular way, and the "network" (as Paul calls it. I assum= e he means
> some more specific LTE element) needs to inform the UE what markings t= o use.
>
> 4301, section 5.1.2 includes:
>> Another will allow the outer DS field to be mapped to a
>> fixed value, which MAY be configured on a per-SA basis. (The value=
>> might really be fixed for all traffic outbound from a device, but<= br> >> per-SA granularity allows that as well.) This configuration option=
>
> and this is what Paul wants to do. =A0The "network" (i.e. th= e access
> concentrator) needs to tell the UE located at the client/device what D= S to
> use on that network.
>
> My suggestion is, since this is not something is subject to negotiatio= n, that
> simply defining a new notification value.
>
> --
> ] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | ipv6 mesh networks [
> ] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| ne= twork architect =A0[
> ] =A0 =A0 mcr@sa= ndelman.ca =A0ht= tp://www.sandelman.ca/ =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[


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


--90e6ba1efbf4a0dc8c04ea687d64-- From ynir@checkpoint.com Mon Nov 4 23:31:43 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2867621F9FBA for ; Mon, 4 Nov 2013 23:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKEvalQnWJ54 for ; Mon, 4 Nov 2013 23:31:38 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BE82A21F84F9 for ; Mon, 4 Nov 2013 23:31:37 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA57VPWG030844; Tue, 5 Nov 2013 09:31:25 +0200 X-CheckPoint: {52789D6F-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 09:31:25 +0200 From: Yoav Nir To: Jyoti Ranjan Senapati Thread-Topic: [IPsec] //Please remove me from this group ..// Thread-Index: AQHO2fMr9+GiJqVsVk+UtkyhSFz/dJoWHKCA Date: Tue, 5 Nov 2013 07:31:24 +0000 Message-ID: <4A837940-121F-4830-9A48-76BEB013BACA@checkpoint.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> <8999380B202BD2438A46E07634CA7FDA5ECA8F01@szxeml521-mbx.china.huawei.com> In-Reply-To: <8999380B202BD2438A46E07634CA7FDA5ECA8F01@szxeml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.53] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_4A837940121F48309A4876BEB013BACAcheckpointcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] //Please remove me from this group ..// X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 07:31:43 -0000 --_000_4A837940121F48309A4876BEB013BACAcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We can't, but you can: https://www.ietf.org/mailman/listinfo/ipsec On Nov 4, 2013, at 10:48 PM, Jyoti Ranjan Senapati > wrote: Hi ,, I want to unfriend from this group. Can you please help . Thanks and Regards, Jyoti Ranjan Senapati ***************************************************************************= ***************************************************************************= *********************************** This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination)= by persons other than the intended recipient's) is prohibited. If you rece= ive this e-mail in error, please notify the sender by phone or email immedi= ately and delete it! ***************************************************************************= ***************************************************************************= ****************************** From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, November 05, 2013 12:15 PM To: Paul Simon Cc: >; Michael Richardson Subject: Re: [IPsec] Query regarding Qos with IKE Is what you're looking for multiple DS for the same selectors, or just a si= ngle DS for each set of selectors, that is determined by the AC? On Nov 4, 2013, at 10:34 PM, Paul Simon > wrote: As indicated by Richardson [ The "network" (i.e. the access concentrator) needs to tell the UE located at the client/device what DS to use on that network. ] This is exactly I need. The UE tells the network element what is the desire= d Qos that UE is willing to use for an SA and Network in turn replies to UE= what Qos can really be used. (because finally it is the network which deci= des what characteristics the traffic can hold). So as I understand currently Qos cannot be indicated through IKE messages a= nd it has to be done through some application level protocols. But since the Qos based traffic is gaining more importance these days, it w= ould be better if we can accommodate Qos as one of the parameter in IKE neg= otiation messages. Thanks, Paul On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir > wrote: Like I said, Paul can submit an I-D. But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no? And you really need = to do this for the clear packet anyways, because it needs to be handled wit= h QoS at the provider network too. If you do it in the app layer, it doesn'= t require any modifications to IKE. Yoav On Nov 4, 2013, at 3:18 PM, Michael Richardson > wrote: > > Yoav Nir > wrote: >> There are currently no attributes in IKE to negotiate QoS. > >> The reason for that text in 5996 is the issue of IPsec packet >> re-ordering. If we use the same SA for packets with different QoS >> characteristics, then the QoS could then re-order them. This means that >> replay protection would drop legitimate packets simply because they >> arrived late. To avoid this, the sender may use several SAs so as to >> send packets with different QoS characteristics in different >> tunnels. This requires no negotiation of QoS characteristics between >> the peers, only negotiation of enough SAs for all the different QoS >> classes. > >> If I'm missing something, and there is a need to negotiate this, you >> can always submit an I-D. > > I think you are missing the point. > > Paul said: >> We are having a requirement to have Qos per CHILD SA inside one IKE SA o= r to >> have Qos per IKE SA. Is it possible to communicate the Qos in IKE handsh= ake ? >> Or else how can we achieve to use different Qos, atleast per IKE SA. > > so, you'd see that actually he wants to have multiple CHILD SAs already. > The point is that the packets coming into the tunnel may not be marked in= any > particular way, and the "network" (as Paul calls it. I assume he means > some more specific LTE element) needs to inform the UE what markings to u= se. > > 4301, section 5.1.2 includes: >> Another will allow the outer DS field to be mapped to a >> fixed value, which MAY be configured on a per-SA basis. (The value >> might really be fixed for all traffic outbound from a device, but >> per-SA granularity allows that as well.) This configuration option > > and this is what Paul wants to do. The "network" (i.e. the access > concentrator) needs to tell the UE located at the client/device what DS t= o > use on that network. > > My suggestion is, since this is not something is subject to negotiation, = that > simply defining a new notification value. > > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/= | ruby on rails [ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_4A837940121F48309A4876BEB013BACAcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable We can't, but you can:

On Nov 4, 2013, at 10:48 PM, Jyoti Ranjan Senapati <jyotiranjans@huawei.com> wrote:

Hi ,,
 
I want to unfriend from this group. Can you please help .=
 
 
Thanks and Regards,
Jyoti Ranjan Senapati
 
 
 
***********************************************************************= ***************************************************************************= ***************************************
This e-mail and attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, but not limited to, total or parti= al disclosure, reproduction, or dissemination) by persons other than the in= tended recipient's) is prohibited. If you receive this e-mail in error, ple= ase notify the sender by phone or email immediately and delete it!
***********************************************************************= ***************************************************************************= **********************************
 
From:=  = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, Nov= ember 05, 2013 12:15 PM
To: Paul Simon
Cc: <ipsec@ietf.org>; Michael Richardson
Subject: Re: [IPse= c] Query regarding Qos with IKE
 
Is what you're looking for multiple DS for the same selectors, or just a si= ngle DS for each set of selectors, that is determined by the AC?=
 
On Nov 4, 2013, at 10:34 PM, Paul Simon <paulsimon.c= @gmail.com> wrote:


 
As indicated by Richardson [ The "network" (i.e. the access
concentrator) needs to tell the UE located at the client/device what DS to<= br> use on that network. ]
 
This is exactly I need. The UE tells the network element what is the desire= d Qos that UE is willing to use for an SA and Network in turn replies = to UE what Qos can really be used. (because finally it is the network which= decides what characteristics the traffic can hold).
 
So as I understand currently Qos cannot be indicated through IKE messages a= nd it has to be done through some application level protocols.
 
But since the Qos based traffic is gaining more importance t= hese days, it would be better if we can accommodate Qos as one of the param= eter in IKE negotiation messages.
 
Thanks,
Paul
 

 

On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir <ynir@checkpoint.com> wrote:
Like I said, Paul can submit an I-D.

But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no?  And you really = need to do this for the clear packet anyways, because it needs to be handled with QoS at the provider network t= oo. If you do it in the app layer, it doesn't require any modifications to = IKE.

Yoav


On Nov 4, 2013, at 3:18 PM, Michael Richardson <mc= r+ietf@sandelman.ca> wrote:

>
> Yoav Nir <ynir@checkpoint.com> wrote:
>> There are currently no attributes in IKE to negotiate QoS.
>
>> The reason for that text in 5996 is the issue of IPsec packet
>> re-ordering. If we use the same SA for packets with different QoS<= br> >> characteristics, then the QoS could then re-order them. This means= that
>> replay protection would drop legitimate packets simply because the= y
>> arrived late. To avoid this, the sender may use several SAs so as = to
>> send packets with different QoS characteristics in different
>> tunnels. This requires no negotiation of QoS characteristics betwe= en
>> the peers, only negotiation of enough SAs for all the different Qo= S
>> classes.
>
>> If I'm missing something, and there is a need to negotiate this, y= ou
>> can always submit an I-D.
>
> I think you are missing the point.
>
> Paul said:
>> We are having a requirement to have Qos per CHILD SA inside one IK= E SA or to
>> have Qos per IKE SA. Is it possible to communicate the Qos in IKE = handshake ?
>> Or else how can we achieve to use different Qos, atleast per IKE S= A.
>
> so, you'd see that actually he wants to have multiple CHILD SAs alread= y.
> The point is that the packets coming into the tunnel may not be marked= in any
> particular way, and the "network" (as Paul calls it. I assum= e he means
> some more specific LTE element) needs to inform the UE what markings t= o use.
>
> 4301, section 5.1.2 includes:
>> Another will allow the outer DS field to be mapped to a
>> fixed value, which MAY be configured on a per-SA basis. (The value=
>> might really be fixed for all traffic outbound from a device, but<= br> >> per-SA granularity allows that as well.) This configuration option=
>
> and this is what Paul wants to do.  The "network" (i.e.= the access
> concentrator) needs to tell the UE located at the client/device what D= S to
> use on that network.
>
> My suggestion is, since this is not something is subject to negotiatio= n, that
> simply defining a new notification value.
>
> --
> ]               Never tell me the o= dds!                 | ipv6 mesh ne= tworks [
> ]   Michael Richardson, Sandelman Software Works     &n= bsp;  | network architect  [
> ]     mcr@sandelman.ca =  http://www.sandelman.ca/        |   ruby on rails    [

 
 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ip= sec

--_000_4A837940121F48309A4876BEB013BACAcheckpointcom_-- From david.black@emc.com Tue Nov 5 06:21:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF8911E80E6 for ; Tue, 5 Nov 2013 06:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBmCkKp4JBzU for ; Tue, 5 Nov 2013 06:21:08 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C82CA11E8141 for ; Tue, 5 Nov 2013 06:21:05 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA5EL2jX025561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Nov 2013 09:21:03 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com rA5EL2jX025561 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1383661263; bh=fSe9EjmkrdtsZh+Ws0lv2adnEHY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=ZHX2TF5XwYpMmZsB9Cnx50BQT/2iX3qy3BU+zavXkjs0wiUqdbnBCWkx/G4sopcAa 7vwe5S8Mmz5UlNs8oSy0rPIQBYQbLEZmWDDfKs037cjMfYmi1XAxopEcLy2d+zqaG3 VoNl76uQohFzdcjtkZravtP9rabBNhZ7AXk5q8Bk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com rA5EL2jX025561 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 5 Nov 2013 06:20:45 -0800 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA5EKj3K029395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 09:20:45 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Tue, 5 Nov 2013 09:20:45 -0500 From: "Black, David" To: Paul Simon Date: Tue, 5 Nov 2013 09:20:43 -0500 Thread-Topic: [IPsec] Query regarding Qos with IKE Thread-Index: Ac7Z88r1CukaiaM9SsWb9ytJSiSqTQAPF1Jg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026AAEBD32@MX15A.corp.emc.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712026AAEBD32MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Cc: "" Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 14:21:12 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712026AAEBD32MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Be careful - if the IPsec SA or tunnel crosses diffserv domains, the outer = DSCP won't have the same meaning at both ends. The initial solution looks like it's single-domain - access concentrator to= client on a single network. Nonetheless, the solution needs to be designe= d for at least a couple of things beyond one DSCP and one domain, even if t= hey won't be used initially: - Detect Diffserv domain crossing that makes DSCP not usable by client (e.g., transit over a second network happens between the client and access = concentrator). - Multiple DSCPs are involved, e.g., AF drop precedence with multiple DSCPs= is being used with rate-based traffic shaping. These don't have to fully work in the first solution, but the design needs = to have some means to detect the first and accommodate the second in the fu= ture. I would suggest looking at extending IKEv2's configuration support a= s a possible approach - see Section 3.15 in RFC 5996. Thanks, --David (an author of RFCs 2474, 2475 and 2983) From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Simon Sent: Tuesday, November 05, 2013 1:54 AM To: Yoav Nir Cc: ; Michael Richardson Subject: Re: [IPsec] Query regarding Qos with IKE Hi, I am looking for both the solutions. But lets take the simpler case first, "single DS for each set of selectors"= . In this simple case as well, the DS should be negotiated (communicated ) fr= om UE to Network Element and back from Network Element to UE before using t= he DS. Is it possible some way ? My requirement is that both the end points agree on the DS before it is get= ting used. Thanks, Paul On Tue, Nov 5, 2013 at 12:15 PM, Yoav Nir > wrote: Is what you're looking for multiple DS for the same selectors, or just a si= ngle DS for each set of selectors, that is determined by the AC? On Nov 4, 2013, at 10:34 PM, Paul Simon > wrote: As indicated by Richardson [ The "network" (i.e. the access concentrator) needs to tell the UE located at the client/device what DS to use on that network. ] This is exactly I need. The UE tells the network element what is the desire= d Qos that UE is willing to use for an SA and Network in turn replies to UE= what Qos can really be used. (because finally it is the network which deci= des what characteristics the traffic can hold). So as I understand currently Qos cannot be indicated through IKE messages a= nd it has to be done through some application level protocols. But since the Qos based traffic is gaining more importance these days, it w= ould be better if we can accommodate Qos as one of the parameter in IKE neg= otiation messages. Thanks, Paul On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir > wrote: Like I said, Paul can submit an I-D. But if the UE applies the diffserv to the clear packet, 4301 says that thes= e attributes are copied to the ESP packet. There has to be some handshake a= t the application layer to pass this information, no? And you really need = to do this for the clear packet anyways, because it needs to be handled wit= h QoS at the provider network too. If you do it in the app layer, it doesn'= t require any modifications to IKE. Yoav On Nov 4, 2013, at 3:18 PM, Michael Richardson > wrote: > > Yoav Nir > wrote: >> There are currently no attributes in IKE to negotiate QoS. > >> The reason for that text in 5996 is the issue of IPsec packet >> re-ordering. If we use the same SA for packets with different QoS >> characteristics, then the QoS could then re-order them. This means that >> replay protection would drop legitimate packets simply because they >> arrived late. To avoid this, the sender may use several SAs so as to >> send packets with different QoS characteristics in different >> tunnels. This requires no negotiation of QoS characteristics between >> the peers, only negotiation of enough SAs for all the different QoS >> classes. > >> If I'm missing something, and there is a need to negotiate this, you >> can always submit an I-D. > > I think you are missing the point. > > Paul said: >> We are having a requirement to have Qos per CHILD SA inside one IKE SA o= r to >> have Qos per IKE SA. Is it possible to communicate the Qos in IKE handsh= ake ? >> Or else how can we achieve to use different Qos, atleast per IKE SA. > > so, you'd see that actually he wants to have multiple CHILD SAs already. > The point is that the packets coming into the tunnel may not be marked in= any > particular way, and the "network" (as Paul calls it. I assume he means > some more specific LTE element) needs to inform the UE what markings to u= se. > > 4301, section 5.1.2 includes: >> Another will allow the outer DS field to be mapped to a >> fixed value, which MAY be configured on a per-SA basis. (The value >> might really be fixed for all traffic outbound from a device, but >> per-SA granularity allows that as well.) This configuration option > > and this is what Paul wants to do. The "network" (i.e. the access > concentrator) needs to tell the UE located at the client/device what DS t= o > use on that network. > > My suggestion is, since this is not something is subject to negotiation, = that > simply defining a new notification value. > > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/= | ruby on rails [ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_8D3D17ACE214DC429325B2B98F3AE712026AAEBD32MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Be careful – i= f the IPsec SA or tunnel crosses diffserv domains, the outer DSCP won’= ;t have the same meaning at both ends.

The initial solution looks l= ike it’s single-domain – access concentrator to client on a sin= gle network.  Nonetheless, the solution needs to be designed for at le= ast a couple of things beyond one DSCP and one domain, even if they wonR= 17;t be used initially:

 

- Detect Diffserv domain crossing that make= s DSCP not usable by client

(e.g., transit over a second network happens between the = client and access concentrator).

= - Mu= ltiple DSCPs are involved, e.g., AF drop precedence with multiple DSCPs is = being used with rate-based traffic shaping.

 

These don’t hav= e to fully work in the first solution, but the design needs to have some me= ans to detect the first and accommodate the second in the future.  I w= ould suggest looking at extending IKEv2’s configuration support as a = possible approach – see Section 3.15 in RFC 5996.

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>Thank= s,
--David (an author of RFCs 2474, 2475 and 2983)<= /p>

 

=

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.= org] On Behalf Of Paul Simon
Sent: Tuesday, November 05, 2= 013 1:54 AM
To: Yoav Nir
Cc: <ipsec@ietf.org>; Mi= chael Richardson
Subject: Re: [IPsec] Query regarding Qos with IK= E

 

Hi,

 

I am looking f= or both the solutions.

 =

But lets take the simpl= er case first, "single DS for each set of selectors".  =

In this simple case as well, the = DS should be negotiated (communicated ) from UE to Network Element and back= from Network Element to UE before using the DS.

<= p class=3DMsoNormal>Is it possible some way ?

 

My re= quirement is that both the end points agree on the DS before it is getting = used.

 

Thanks,

Paul

 

=  

On Tue, Nov 5, 2013 at 12:15= PM, Yoav Nir <= ynir@checkpoint.com> wrote:

= Is what you're looking for multiple DS for the same selectors, or just a si= ngle DS for each set of selectors, that is determined by the AC?

 

On Nov 4, 2013, at 10:34 PM, Paul Simon <paulsimon.c@gmail.com>= wrote:

 

 

As indicated by Richardson [ The "network" (i.e. the ac= cess
concentrator) needs to tell the UE located at the client/device wha= t DS to
use on that network. ]

 

This is exactly = I need. The UE tells the network element what is the desired Qos that UE is= willing to use for an SA and Network in turn replies to UE what Qos c= an really be used. (because finally it is the network which decides what ch= aracteristics the traffic can hold).

 

So as I unders= tand currently Qos cannot be indicated through IKE messages and it has to b= e done through some application level protocols.

<= p class=3DMsoNormal> 

Bu= t since the Qos based traffic is gaining more importance the= se days, it would be better if we can accommodate Qos as one of the paramet= er in IKE negotiation messages.

 

Thanks,<= /p>

Paul

 

 

= On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir <ynir@checkpoint.com> wrote:

Like I said, Paul can submit an I-D.

But if th= e UE applies the diffserv to the clear packet, 4301 says that these attribu= tes are copied to the ESP packet. There has to be some handshake at the app= lication layer to pass this information, no?  And you really need to d= o this for the clear packet anyways, because it needs to be handled with Qo= S at the provider network too. If you do it in the app layer, it doesn't re= quire any modifications to IKE.

Yoav


On Nov 4, 2013, at 3:18 PM, Michael Richardson <mcr+ietf@sandelman.ca&g= t; wrote:

>
> Yoav Nir <ynir@checkpoint.com> wrote:
>> The= re are currently no attributes in IKE to negotiate QoS.
>
>>= The reason for that text in 5996 is the issue of IPsec packet
>> = re-ordering. If we use the same SA for packets with different QoS
>&g= t; characteristics, then the QoS could then re-order them. This means that<= br>>> replay protection would drop legitimate packets simply because = they
>> arrived late. To avoid this, the sender may use several SA= s so as to
>> send packets with different QoS characteristics in d= ifferent
>> tunnels. This requires no negotiation of QoS character= istics between
>> the peers, only negotiation of enough SAs for al= l the different QoS
>> classes.
>
>> If I'm missing= something, and there is a need to negotiate this, you
>> can alwa= ys submit an I-D.
>
> I think you are missing the point.
>= ;
> Paul said:
>> We are having a requirement to have Qos pe= r CHILD SA inside one IKE SA or to
>> have Qos per IKE SA. Is it p= ossible to communicate the Qos in IKE handshake ?
>> Or else how c= an we achieve to use different Qos, atleast per IKE SA.
>
> so,= you'd see that actually he wants to have multiple CHILD SAs already.
&g= t; The point is that the packets coming into the tunnel may not be marked i= n any
> particular way, and the "network" (as Paul calls it= . I assume he means
> some more specific LTE element) needs to inform= the UE what markings to use.
>
> 4301, section 5.1.2 includes:=
>> Another will allow the outer DS field to be mapped to a
>= ;> fixed value, which MAY be configured on a per-SA basis. (The value>> might really be fixed for all traffic outbound from a device, but=
>> per-SA granularity allows that as well.) This configuration op= tion
>
> and this is what Paul wants to do.  The "net= work" (i.e. the access
> concentrator) needs to tell the UE loca= ted at the client/device what DS to
> use on that network.
>> My suggestion is, since this is not something is subject to negotiati= on, that
> simply defining a new notification value.
>
> = --
> ]               Never tell me= the odds!                 | ipv6 m= esh networks [
> ]   Michael Richardson, Sandelman Software Work= s        | network architect  [
> ]   &= nbsp; mcr@sandelman.c= a  http://w= ww.sandelman.ca/        |   ruby on rails &nbs= p;  [

 =

_____________________= __________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mail= man/listinfo/ipsec

 

&n= bsp;

= --_000_8D3D17ACE214DC429325B2B98F3AE712026AAEBD32MX15Acorpemcc_-- From mcr@sandelman.ca Tue Nov 5 09:34:00 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFD911E817C for ; Tue, 5 Nov 2013 09:34: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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sneHXo+mABzg for ; Tue, 5 Nov 2013 09:33:59 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id AB34E11E80F9 for ; Tue, 5 Nov 2013 09:33:59 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 483012027B; Tue, 5 Nov 2013 13:45:37 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id EB58763B88; Tue, 5 Nov 2013 12:33:55 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D8F6463AED; Tue, 5 Nov 2013 12:33:55 -0500 (EST) From: Michael Richardson To: "\" In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026AAEBD32@MX15A.corp.emc.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> <8D3D17ACE214DC429325B2B98F3AE712026AAEBD32@MX15A.corp.emc.com> 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: "Black, David" , Paul Simon Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:34:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Black, David wrote: > Be careful ? if the IPsec SA or tunnel crosses diffserv domains, the = outer DSCP > won?t have the same meaning at both ends. True, but let's no boil any oceans here. > The initial solution looks like it?s single-domain ? access concentra= tor to > client on a single network. Nonetheless, the solution needs to be de= signed for > at least a couple of things beyond one DSCP and one domain, even if t= hey won?t > be used initially: Yes. > - Detect Diffserv domain crossing that makes DSCP not usable by client How could one do this? > - Multiple DSCPs are involved, e.g., AF drop precedence with multiple= DSCPs is > being used with rate-based traffic shaping. I don't think that they need multiple DSCPs. I think that they simply want to ask the UE to use a particular code point. It seems like a very simple Notification would work fine, and I think that the people doing this are in control of the IKE/IPsec stack on the UE, and the IKE/IPsec stack on the peer, with the intervening network under their influence, but not their control.=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnksAYqHRg3pndX9AQL0KgQAiLMja2yJZOP3BLth1G2WofHzl5YTxv+f hiAArpC9H6VUktbB1KQtBOiSCdxy9NuDGDMnushDGbPeYYyo5lpW4vpB6LDPs0ne K7BWanetfnaz7o4xY/B+gjs2K3W3dqE7+QACTYlQeIRbQtk3X5gvl2f69iFZvbQS AGANwY5VRBQ= =m1bn -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Nov 5 09:36:49 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F2D11E81DA for ; Tue, 5 Nov 2013 09:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu4JbBt-2XWy for ; Tue, 5 Nov 2013 09:36:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id AC58311E80F9 for ; Tue, 5 Nov 2013 09:36:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AE5702027B; Tue, 5 Nov 2013 13:48:20 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5AB9163B88; Tue, 5 Nov 2013 12:36:39 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4480663AED; Tue, 5 Nov 2013 12:36:39 -0500 (EST) From: Michael Richardson To: "\" In-Reply-To: <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> 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: Paul Simon Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:36:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > Is what you're looking for multiple DS for the same selectors, or jus= t a single > DS for each set of selectors, that is determined by the AC? For a given IPsec SA, they want to overwrite/force/set the DSCP to a particular value. It will not depend upon the traffic goes into it (but, the SPD selectors may quite specificly pick the traffic). =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnkspIqHRg3pndX9AQIpSwQAjRjw1K+/GiwR6sP26OhSUP1QhHHW/f5C +vly6CuusYjAjWI1klabNP54+w3/pNmQVUZLr8LU/AGdrXtgzx7hXjGuobHvtnE7 GkmG+s+p8rJ9w6N/ppUVqTnj7+HklN/3aiyLeeWFHVh7CglE0u7InFckmgZ1lUeb 4Tad7DwACAw= =cc/q -----END PGP SIGNATURE----- --=-=-=-- From praveenys@juniper.net Tue Nov 5 10:16:11 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0ED21E808A for ; Tue, 5 Nov 2013 10:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mokpIPBbfZdO for ; Tue, 5 Nov 2013 10:16:05 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id AD08911E8118 for ; Tue, 5 Nov 2013 10:16:04 -0800 (PST) Received: from mail27-db9-R.bigfish.com (10.174.16.244) by DB9EHSOBE035.bigfish.com (10.174.14.98) with Microsoft SMTP Server id 14.1.225.22; Tue, 5 Nov 2013 18:16:03 +0000 Received: from mail27-db9 (localhost [127.0.0.1]) by mail27-db9-R.bigfish.com (Postfix) with ESMTP id 71B654019B; Tue, 5 Nov 2013 18:16:03 +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: 1 X-BigFish: VPS1(zzzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hz31izz2fh109h2a8h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail27-db9: 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:(189002)(199002)(4396001)(74876001)(50986001)(49866001)(47976001)(83072001)(47736001)(81342001)(54356001)(81542001)(56776001)(74502001)(74662001)(31966008)(74366001)(59766001)(83506001)(36756003)(77982001)(63696002)(65816001)(81816001)(83322001)(80022001)(66066001)(80976001)(47446002)(69226001)(46102001)(76786001)(85306002)(76796001)(81686001)(87266001)(53806001)(51856001)(76482001)(77096001)(56816003)(74706001)(54316002)(76176001)(79102001)(2656002)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB155; H:BN1PR05MB153.namprd05.prod.outlook.com; CLIP:66.129.224.50; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail27-db9 (localhost.localdomain [127.0.0.1]) by mail27-db9 (MessageSwitch) id 1383675362273857_31693; Tue, 5 Nov 2013 18:16:02 +0000 (UTC) Received: from DB9EHSMHS001.bigfish.com (unknown [10.174.16.228]) by mail27-db9.bigfish.com (Postfix) with ESMTP id 3E7E24E0054; Tue, 5 Nov 2013 18:16:02 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS001.bigfish.com (10.174.14.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 5 Nov 2013 18:16:01 +0000 Received: from BN1PR05MB155.namprd05.prod.outlook.com (10.255.205.17) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 5 Nov 2013 18:16:01 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) by BN1PR05MB155.namprd05.prod.outlook.com (10.255.205.17) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 5 Nov 2013 18:15:59 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.252]) by BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.252]) with mapi id 15.00.0785.001; Tue, 5 Nov 2013 18:15:59 +0000 From: Praveen Sathyanarayan To: "" Thread-Topic: [IPsec] Query regarding Qos with IKE Thread-Index: AQHO2T0nomsDE9nsJkCiDBV/C+/JIpoU0gAAgACFNICAAAMRAIAAW4CAgAAEmACAAHVVgIAAAwqAgAC184D//3QYAA== Date: Tue, 5 Nov 2013 18:15:58 +0000 Message-ID: In-Reply-To: <25430.1383672999@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [66.129.224.50] x-forefront-prvs: 0021920B5A Content-Type: text/plain; charset="Windows-1252" Content-ID: <66660647CB3CB048A41AF90B009A555B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Paul Simon Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:16:11 -0000 Hi Paul, Extracts from 4301: Section 4.1 Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by IKE. The receiver MUST process the packets from the different SAs without prejudice. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism. DISCUSSION: Although the DSCP , Gro02 and Explicit Congestion Notification (ECN) fields are not "selectors", as that term in used in this architecture, the sender will need a mechanism to direct packets with a given (set of) DSCP values to the appropriate SA. This mechanism might be termed a "classifier". [PRAVEEN] Does this answers your question? Looks like it was intentionally not negotiated in IKE. And it looks like implementation decision on when to negotiate multiple child SAs and how senders makes decision to put which packet in which SA. =8B Praveen=20 From kivinen@iki.fi Tue Nov 5 10:41:43 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC3711E81C9 for ; Tue, 5 Nov 2013 10:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHI-8yoj7F5c for ; Tue, 5 Nov 2013 10:41:41 -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 E788721E8087 for ; Tue, 5 Nov 2013 10:41:32 -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 rA5IfSa1003628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Nov 2013 20:41:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rA5IfSCn018914; Tue, 5 Nov 2013 20:41: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: <21113.15320.449575.240995@fireball.kivinen.iki.fi> Date: Tue, 5 Nov 2013 20:41:28 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <25430.1383672999@sandelman.ca> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> <25430.1383672999@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Cc: "" , Paul Simon Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:41:43 -0000 Michael Richardson writes: > For a given IPsec SA, they want to overwrite/force/set the DSCP to a > particular value. It will not depend upon the traffic goes into it > (but, the SPD selectors may quite specificly pick the traffic). If I think RFC4301 already requires that. I.e. it requires implementations to be able to map DSCP values to suitable value. If the sender knows how to pick up suitable DSCP values and they are then tunneled through the IPsec tunnel, then the receiving GW can use those to map those values to the suitable values for the other domain. As the IPsec processing is not affected by that mapping, there is no point of negotiating it in the IKE. The DSCP can be used as classifier which selects which packets are put to which SA, and this is required because of the reordering problems, and this is already handled in the IPsec. I am missing how does the trasmitting this information from SGW to SGW affect the IPsec processing? I do not think we should use IKE as transmitting all kind of stuff that other end might be interested in. It is better to use some protocol suitable for it. For example our configuration payload tries to send only minimal set of parameters which affect the IPsec processing (yes, there are some extra there like DNS, and NBNS), and rest of the configuration parameters should be gotten from the DHCP server (whose address is sent inside the configuration payload). -- kivinen@iki.fi From fdetienn@cisco.com Tue Nov 5 11:41:56 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9875621E8089 for ; Tue, 5 Nov 2013 11:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.542 X-Spam-Level: X-Spam-Status: No, score=-9.542 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP94boEOs8gv for ; Tue, 5 Nov 2013 11:41:48 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8D96B21E8099 for ; Tue, 5 Nov 2013 11:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3853; q=dns/txt; s=iport; t=1383680507; x=1384890107; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OBRqzf4o65tm2w8YxKVxuwU1De7uJMCuMVqeoMJEU5o=; b=EJaPeL5HhsGHhChNDb1HddxL/H5dY5pscythZvAb7vClObHAnUfTv5lX yu23x4RWo1iz0KPSbEAwIzjbi9DVDMiEE8Wjf5U3DQPr275EHlexXCF1n d3JKazr8StAaUHJ1zrXXTvIMOu/LRRadQc1/9WPl8f7zeYf30e/Bt7d4k U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFALBIeVKtJV2Y/2dsb2JhbABZgweBC784gSwWdIIlAQEBAwF5BQsCAQhGMiUBAQQOBRuHYAa+fI8mMweDIIEPA5Qrg1+SCYMmgio X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208";a="281067534" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 05 Nov 2013 19:41:46 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA5Jfk5c032580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 19:41:46 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 13:41:46 -0600 From: "Frederic Detienne (fdetienn)" To: Stephen Kent Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/ccvJ1By/2h0ikF2yPhA3xNAAaP8MAAC2OsYA= Date: Tue, 5 Nov 2013 19:41:45 +0000 Message-ID: References: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> <5278183E.500@bbn.com> In-Reply-To: <5278183E.500@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.74.186] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Michael Guilford \(mguilfor\)" , "draft-detienne-dmvpn@tools.ietf.org" , "Mark Comeadow \(mcomeado\)" , Michael Richardson , "Mike Sullenberger \(mls\)" , IPsecme WG , "Stephen Lynn \(stlynn\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:41:56 -0000 Hi Stephen, please find some answers inline. On 04 Nov 2013, at 22:57, Stephen Kent wrote: > Mike, >=20 > A couple of your comments caught my attention, as an author of 4301, 02, = and 03. I admit to not having read the DMVPN proposal, so my comments are b= ased only on your message, which argues why DMVPN is the preferred solution= . >> IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the correct= standard protocol to use. This is what IPsec does really well, encrypt tr= affic. The layers above greatly simplifies IPsec's job by presenting to it = the tunnel to encrypt instead of all of the individual protocols/subnets/fl= ows that are within the tunnel. The IPsec selectors are now for the tunnel= , which makes path redundancy and load-balancing doable. IPsec doesn't dea= l well with the same set of selectors to encrypt traffic to more than one p= eer. With DMVPN this is handled at the routing/forwarding and GRE tunnel l= ayers. > IPsec is not just about encryption, although the DMVPN proposal may releg= ate it to that. IPsec provides access control, and, typically, authen= tication. Does DMVPN preserve the access control features of IPsec, or are= users now relying on a hub to do this, or what? The proposal relies on everything IKE and IPsec do today. All the cryptogra= phy and authentication/authorization mechanisms remain between hub&spokes a= s well as between spokes. All the access control features of IPsec and IKE remain untouched. NHRP only facilitates the network and peer discovery. >> ... With 10s of thousands of nodes and perhaps 100s of thousands of ne= twork/subnets reachable via the VPN the number of IPsec selectors across th= e VPN would get completely out of hand, especially if each different pair o= f subnets (selector) requires a separate encryption, between the same two n= odes.=20 > More properly, a separate SA, and only if the folks who manage policies a= t each end of the SA decide to provide fine-grained access control for the = traffic flows. It was not clear to me that the problem statement for this w= ork envisioned VPNs of the scale you mention. Also, the comments above are = a bit confusing. Both end points and security gateways are "nodes" wrt IPse= c, in the general sense. I can create a selector that secures traffic from = my node (and point of subnet) to all hosts on a subnet, irrespective of how= many are present there. =20 >> This doesn=92t even count the fact that in order to run IPv4 and IPv6 be= tween the same two nodes you have to use at least double the number of sele= ctors. > At least? Under what circumstances would the number grow by more than a f= actor of two? I am not sure I understand your comment. Here is what we are trying to say:= Assuming two nodes A and B hosting subnets A1, A2 and B1, B2 respectively = (A* and B* not summarizable), the selectors between A and B have a form A1-B1 A1-B2 A2-B1 A2-B2 yielding up to A# x B# selectors. There can be thousands of A* and B*. Can you elaborate please ? >> Routing protocols are already designed to scale to 100s of thousands and= even millions of routes. So with DMVPN the forwarding and GRE tunneling of= both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selecto= r. > So, the proposal simplifies use of IPsec by limiting the granularity at w= hich SAs may be created? Does it also cause each SA to terminate at a hub, = so that the security services are no longer e-t-e? In the context of the p= erpass discussions, this seems like a questionable design decision. Each SA is established between the spokes and the entire IKE/IPsec negotiat= ion takes place between the spokes. The hub does not act as a broker. thanks, fred > =20 > Steve From mls@cisco.com Tue Nov 5 11:55:18 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971E021F9AF0 for ; Tue, 5 Nov 2013 11:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.888 X-Spam-Level: X-Spam-Status: No, score=-9.888 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3c96IP8U-46 for ; Tue, 5 Nov 2013 11:55:03 -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 E61D521F9609 for ; Tue, 5 Nov 2013 11:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29510; q=dns/txt; s=iport; t=1383681303; x=1384890903; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iAx9L1FFplEPcvoyIN/vhYZtw4TXekSEzHc+QrlXR7Y=; b=EQazZInY8PGJ5MR/jmd0u+TJW3InuWKfXUdS+rJhRObw9OC2oBvXeKg7 Q6QGHB9os5Uuur2mCETzAE3syXx6QVdVgftpVGpTVSGLnHnZFR26pIhZY lfLnkTYg3Vpk/p28vJKVzKRbj4Sgjg2hdbcUWNdOlNnit15x1+epe6Rz1 o=; X-Files: Picture (Device Independent Bitmap) 1.jpg : 10254 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAG5MeVKtJXHB/2dsb2JhbABZgkNEgQu/OoEsFnSCJQEBAQQFKEwQAgEIEQQBAQYBAQECCBUHAgUQAQ4MFAkIAQEEAQkEBAEGAgYNh2a/Bo8oMQYBBoMagQ8DkV+CTJVogyaCKg X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="jpg'145?scan'145,208,217,145";a="281060527" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2013 19:55:01 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA5Jt1Vx020954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 19:55:01 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 13:55:00 -0600 From: "Mike Sullenberger (mls)" To: Stephen Kent , Michael Richardson Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/cZ8atWBMdRq20ZJjd3q+R4AAaP8MAACAyyTA= Date: Tue, 5 Nov 2013 19:55:00 +0000 Message-ID: <9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0@xmb-aln-x06.cisco.com> References: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> <5278183E.500@bbn.com> In-Reply-To: <5278183E.500@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.84.106] Content-Type: multipart/related; boundary="_004_9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0xmbalnx06ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "Stephen Lynn \(stlynn\)" , "Michael Guilford \(mguilfor\)" , IPsecme WG , "draft-detienne-dmvpn@tools.ietf.org" , "Mark Comeadow \(mcomeado\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:55:18 -0000 --_004_9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0xmbalnx06ciscoc_ Content-Type: multipart/alternative; boundary="_000_9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0xmbalnx06ciscoc_" --_000_9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0xmbalnx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, Sorry, I wasn't clear on our use of IPsec. We definitely use both the authe= ntication and encryption capabilities of IPsec. We do the following when br= inging up a new tunnel. 1. Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer= IP, GRE). 2. ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the I= Psec/Child encryption SAs. 3. IPsec signals it has authenticated and encryption is ready, the GRE= tunnel is activated. 4. NHRP registration (for spoke-hub) or resolution reply (for final ph= ase of spoke-spoke) are sent over the tunnel. 5. Routing is brought up over the spoke-hub tunnels. Also to be clear there are NO packets, control or data plan, that are trans= ferred between the peers outside of the GRE/IPsec encrypted tunnel, except = for ISAKMP/IKEv2. On a router/FW in the middle it would only "see" UDP 500= /4500 and ESP (IP 50) packets. Note, you can also use AH, but we generally = recommend not to use AH and AH breaks NAT support. As for scaling, we already have DMVPN networks of 10000+ nodes and looking = at building networks of 40000+ nodes. In many cases customers have multiple subnets behind each node, therefore w= ith just IPsec I would need to have multiple SAs/encryption between the sam= e two nodes, even if you are only doing subnet to subnet SPDs. Take the ca= se of two nodes that each have 4 subnets. I could need as many as 16 SAs to= cover all cases. Or even a simpler case between a host (1 local address) = and a node at a data center (say 20 subnets), I would need up to 20 SAs to = cover this. In many of our networks we are asked to support at least 5 (so= metimes 10) subnets per spoke location. As far as IPv4 and IPv6 support, you are correct it would only double the n= umber of SAs needed, assuming that there are the same number of subnets for= IPv4 and IPv6. From what I have seen IPv6 tends to increase the number of= subnets. For end-to-end encryption, take the case where a spoke node is a host. The= n initially the spoke/host will connect to one or more hubs (we recommend a= t least 2 for redundancy). Communication between two such connected hosts = would be through the hub and would be two hops (Host1 encrypt-decrypt Hub e= ncrypt-decrypt Host2). Once the shortcut tunnel is setup then communication= would be direct between the hosts (Host1 encrypt-decrypt Host2). Thanks, Mike. [X] Mike Sullenberger, DSE mls@cisco.com .:|:.:|:. Customer Advocacy CISCO From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, November 04, 2013 1:57 PM To: Mike Sullenberger (mls); Michael Richardson Cc: Stephen Lynn (stlynn); draft-detienne-dmvpn@tools.ietf.org; Mark Comead= ow (mcomeado); Michael Guilford (mguilfor); IPsecme WG Subject: Re: [IPsec] AD VPN: discussion kick off Mike, A couple of your comments caught my attention, as an author of 4301, 02, an= d 03. I admit to not having read the DMVPN proposal, so my comments are bas= ed only on your message, which argues why DMVPN is the preferred solution. IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the correct st= andard protocol to use. This is what IPsec does really well, encrypt traff= ic. The layers above greatly simplifies IPsec's job by presenting to it the= tunnel to encrypt instead of all of the individual protocols/subnets/flows= that are within the tunnel. The IPsec selectors are now for the tunnel, w= hich makes path redundancy and load-balancing doable. IPsec doesn't deal w= ell with the same set of selectors to encrypt traffic to more than one peer= . With DMVPN this is handled at the routing/forwarding and GRE tunnel laye= rs. IPsec is not just about encryption, although the DMVPN proposal may relegat= e it to that. IPsec provides access control, and, typically, authentication= . Does DMVPN preserve the access control features of IPsec, or are users n= ow relying on a hub to do this, or what? ... With 10s of thousands of nodes and perhaps 100s of thousands of netwo= rk/subnets reachable via the VPN the number of IPsec selectors across the V= PN would get completely out of hand, especially if each different pair of s= ubnets (selector) requires a separate encryption, between the same two node= s. More properly, a separate SA, and only if the folks who manage policies at = each end of the SA decide to provide fine-grained access control for the tr= affic flows. It was not clear to me that the problem statement for this wor= k envisioned VPNs of the scale you mention. Also, the comments above are a = bit confusing. Both end points and security gateways are "nodes" wrt IPsec,= in the general sense. I can create a selector that secures traffic from my= node (and point of subnet) to all hosts on a subnet, irrespective of how m= any are present there. This doesn't even count the fact that in order to run IPv4 and IPv6 between= the same two nodes you have to use at least double the number of selectors= . At least? Under what circumstances would the number grow by more than a fac= tor of two? Routing protocols are already designed to scale to 100s of thousands and ev= en millions of routes. So with DMVPN the forwarding and GRE tunneling of bo= th IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selector. So, the proposal simplifies use of IPsec by limiting the granularity at whi= ch SAs may be created? Does it also cause each SA to terminate at a hub, so= that the security services are no longer e-t-e? In the context of the per= pass discussions, this seems like a questionable design decision. Steve --_000_9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0xmbalnx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Steve,
 
Sorry, I wasn’t clear on our use of IPsec. We definitely use bot= h the authentication and encryption capabilities of IPsec. We do the follow= ing when bringing up a new tunnel.
  1. Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer IP,= GRE).
  2. ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs an= d the IPsec/Child encryption SAs.
  3. IPsec signals it has authenticate= d and encryption is ready, the GRE tunnel is activated.
  4. NHRP regist= ration (for spoke-hub) or resolution reply (for final phase of spoke-spoke)= are sent over the tunnel.
  5. Routing is brought up over the spoke-hub= tunnels.
Also to be clear there are NO packets, control or data plan, that are = transferred between the peers outside of the GRE/IPsec encrypted tunnel, ex= cept for ISAKMP/IKEv2.  On a router/FW in the middle it would only = 220;see” UDP 500/4500 and ESP (IP 50) packets. Note, you can also use AH, but we generally recommend not to use AH and AH = breaks NAT support.
 <= /div>
As for scaling, we already have DMVPN networks of 10000+ nodes and= looking at building networks of 40000+ nodes.
In many cases customers have multiple subnets behind each node, theref= ore with just IPsec I would need to have multiple SAs/encryption between th= e same two nodes, even if you are only doing subnet to subnet SPDs.  T= ake the case of two nodes that each have 4 subnets. I could need as many as 16 SAs to cover all cases.  Or even= a simpler case between a host (1 local address) and a node at a data cente= r (say 20 subnets), I would need up to 20 SAs to cover this.  In many = of our networks we are asked to support at least 5 (sometimes 10) subnets per spoke location.
 <= /div>
As far as IPv4 and IPv6 support, you are correct it would only double = the number of SAs needed, assuming that there are the same number of subnet= s for IPv4 and IPv6.  From what I have seen IPv6 tends to increase the= number of subnets.
 <= /div>
For end-to-end encryption, take the case where a spoke node is a host.=   Then initially the spoke/host will connect to one or more hubs (we r= ecommend at least 2 for redundancy).  Communication between two such c= onnected hosts would be through the hub and would be two hops (Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once t= he shortcut tunnel is setup then communication would be direct between the = hosts (Host1 encrypt-decrypt Host2).
 <= /div>
Thanks,
 
Mike.
 <= /div>
Mike Sullenberger, DSE
mls@cisco.com          &n= bsp; .:|:.:|:.
Customer Advocacy          CIS= CO

 
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Monday, November 04, 2013 1:57 PM
To: Mike Sullenberger (mls); Michael Richardson
Cc: Stephen Lynn (stlynn); draft-detienne-dmvpn@tools.ietf.org; Mark= Comeadow (mcomeado); Michael Guilford (mguilfor); IPsecme WG
Subject: Re: [IPsec] AD VPN: discussion kick off
 
Mike,

A couple of your comments caught my attention, as an author of 4301, 02, an= d 03. I admit to not having read the DMVPN proposal, so my comments are bas= ed only on your message, which argues why DMVPN is the preferred solution.<= br>
IPsec encryption layer.  In this layer ISAKMP/IKEv2/IPsec is the = correct standard protocol to use.  This is what IPsec does really well= , encrypt traffic. The layers above greatly simplifies IPsec's job by prese= nting to it the tunnel to encrypt instead of all of the individual protocols/subnets/flows that are within the tunnel= .  The IPsec selectors are now for the tunnel, which makes path redund= ancy and load-balancing  doable. IPsec doesn't deal well with the same= set of selectors to encrypt traffic to more than one peer.  With DMVPN this is handled at the routing/forwarding a= nd GRE tunnel layers.
IPsec is not just about encryption, althoug= h the DMVPN proposal may relegate it to that. IPsec provides access control= , and, typically, authentication.  Does DMVPN preserve the access cont= rol features of IPsec, or are users now relying on a hub to do this, or what?=
 ...  With 10s of thousands of nodes and perhaps 100s of tho= usands of network/subnets reachable via the VPN the number of IPsec selecto= rs across the VPN would get completely out of hand, especially if each diff= erent pair of subnets (selector) requires a separate encryption, between the same two nodes. 
More properly, a separate SA, and only if t= he folks who manage policies at each end of the SA decide to provide fine-g= rained access control for the traffic flows. It was not clear to me that th= e problem statement for this work envisioned VPNs of the scale you mention. Also, the comments above are a bit confusing. Both end points and secu= rity gateways are "nodes" wrt IPsec, in the general sense. I can = create a selector that secures traffic from my node (and point of subnet) to all hosts on a subnet, irrespective of how= many are present there. 
This doesn’t even count the fact that in order to run IPv4 and I= Pv6 between the same two nodes you have to use at least double the number o= f selectors.
At least? Under what circumstances would th= e number grow by more than a factor of two?
Routing protocols are already designed to scale to 100s of thousands a= nd even millions of routes. So with DMVPN the forwarding and GRE tunneling = of both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selec= tor.
So, the proposal simplifies use of IPsec by= limiting the granularity at which SAs may be created? Does it also cause each SA to terminate at a hub, so that= the security services are no longer e-t-e?  In the context of the perpass discussions, this seems like a q= uestionable design decision.
 
Steve
 
 --_000_9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0xmbalnx06ciscoc_-- --_004_9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0xmbalnx06ciscoc_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 1.jpg" Content-Description: Picture (Device Independent Bitmap) 1.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 1.jpg"; creation-date="Tue, 05 Nov 2013 19:54:57 GMT"; modification-date="Tue, 05 Nov 2013 19:54:57 GMT" Content-ID: <6D9E63749A5BE248BDD71B5F589C391D@emea.cisco.com> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABFAh8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKxvFGqyaNoM13CVEwIVNwyMk1F4T1ybXtJNzcQiORHKEr0b3FZ+0 jz8nUjnXNydTeooorQsKKKKACiimu6xozscKoyT6CgDI1TxPpmkX0NndSuJpcYCrkDJwM+lbNeWa Tbf8Jd42uLybJtYn349QD8or1OsKNSVS7e3QypTc7vp0PE/jl4p17w/rGjQ6Pq1xYpNBI0giIAYh lAJyPevKj8RvHK/e8S6iB67l/wAK9B/aFieXXdCCDJFrN/6EteTWj/uzbTrw33CfX0rp2RcpWOhb x744EsSjxRqBWQjB3L/hVi98c+NFvkgt/E+oHI5yy8fpWJNAsUdu65CowFO0+RHvLq5lOQnyj61l 7TS6MXUe5eufiH40gmMa+KdQYr1O5ev5VF/wsjxt/wBDPqH/AH0v+FZkoha4e5mHyk8AdzVKVTIz SJEVT2HFbQaaNYyudB/wsjxt/wBDPqH/AH0v+FH/AAsjxt/0M+of99L/AIVzaxsxwqlj6AZq1Zae 13NLESY2SMuMjrjtVvlSuym7HZ+E/H/i+88TWlvc+Ib6WF1l3IzDBxE5Hb1ANcwPil432nPiXUCe 37wcfpW74N0XydStr+4OxgbhEGfvHyXrzWNmAKqASwxyM1mpRk/dFe51q/FHxweT4mv8Dr84/wAK kT4peNVV93iS/clcL+8xtOevSuNAweelODDByT9PWrSQM7GP4m+OHVm/4SXUMKMt+8Xp+VJ/ws/x x/0M1+f+Bj/CuRGCfQ05DzjaW9Qa0SRLZ1w+J3jY8nxNqGP98f4U5fiZ432knxNqGM4zvH+Fci+B IcD5e1AI6VVkuhN2dh/wsvxwFGfEuoDPPJH+FOHxM8akD/ipb/P+8Of0rlVuCuC6iTCbB5gzgdsf SmA801y9iG2dg3xK8ak8eJb/AI/2h/hS/wDCy/GTcDxLf49dw/wrkkbnPUDqPWkLKTkcA9qr3exN 2dgPiT40xz4kvzkcEOP8KU/ErxkxUDxJf+hIcc/pXHBuw/KpA3Bx0/lR7vYluXc61/iT41wX/wCE jvwM46jH8qRPiX4yIIPiO/Pp8w/wrk8/KcsfpmlJw4IAUHGBnNTZdgu7bnXj4keMycL4jviM+oz/ ACqRfiL4x7+JL7Of7w6flXJIW3A59+O1TK2OM/LnNFo9jKU5dzqj8QfGW7jxJfY9mH+FTRfEHxeM F/EV8w7jcP8ACuUDYOcbcjjFSxv+7CZGCc5I5ppRvsZSqTtudhF498WzuANfvQAM/eHP6US+OvF4 kCp4ivCe/wAw/wAK5NJtuSD83Y9KnhG8s+7aV+96VquV9CVOXc6238beKZi4fxPdRlRjJYYJ/KnX XjLxTBArjxRcuxHRXH+FcawRt2D04x61HFIh3RydO2BVLktsgvPuzph8QvFoY/8AFQ3pPYbx/hU0 fxA8WKTv1+8445YdfyrmniROSrFm5BxgVLBEH3MZVBUZ5bqPapcI9g55p7s66Pxt4rJ/5D92fUAg 4/StL/hKfFYiWQa1dtGerZHH6VwqXEkQVV3YQnbn3rVi1eXYcnoOmOKhq2yN4TTVm2b8njHxMgDD XrojHPzDr+VQHxx4k3Jt168yPvAkf4VgNdu+Txx2I4NVhuLZP40JR7ETcr6NnYJ4y8TSI4XWbxmI 3A7gNuOvamJ4y8UMcDW7skcn5l/wrmo5pDhEJyTwakclsBnb8RQ1HsL3u7Oh/wCE38SD/mN3ZyO5 H+FN/wCE38S9tbu/++h/hWCY8EYHzD7zZzmmsFIJHBPYU0o9hOM31Zv/APCceJcHOt3gPbkf4Uxv HPifr/bl0APcf4VgF2T5ux4z/Sq8sh25zx70ckexm1P+Z/edDJ488ULyNdusf7w/wqtP4/8AFCu3 l+Ib4p2JK5P6Vzby9G4HpxVaafe5Y5ye9HLHsEXNdWdE3xC8W7sDxFej6sP8K9E+DnifXdd8QalD qup3F1FFahkSUghW3Yz0rw6WTJBJ5PJr1f4AyBvE+rqpbb9jUgE/7YqKqjyvQ66Dk5q7Pf6KKK4j 0AooooAKKKKACiiigAooooA4H4l3JaKwsE+9I5f8uB/Our0TT00fQoLZRzHHuf3bqa4bWj/a/wAS re16xwsiEfT5j/OtXxl4svdF1W2t7LYQE3yqwzuz0FcUakYznVl6HIppSlUfobHhbUtU1S2uLjUI Fii8wiA4wWX3H9a365TUvF0uk6Xpt5caa2LpcsofGw9h+I5rY0TXLXXrI3NqHUK21lcYINb05x+C 92bQnH4b3ZoSypDE8srqkajLMxwAKrafqljqkbPZXKTKhw209K5b4g6g5tLfR7XL3N04JRepUdB+ JrEvZT4J0ddPtZB/al2N9xIP+Wa9gKieI5ZtdFuROtyya6I9QzmuZ8c6r/Zvh2REbE1yfKX1x3P5 Vxfh/UNc0q8sJGld4L6XaIJGyXGeWA7fWrHje5fVfFtvpsZykRWMAf3m5P6YrOeJ5qTaVnt95Eq/ NTdlZnT+AdKFhoC3DLiW6O8+y9hXV1HBEsFvHCoG2NQox7CpK6qcFCKijphHlionhXx6AbXdDU9G t5QcHBHzLXk07wITbuuZMhi2OcCvX/jtbvNqujssYOLeUbweVO5e3p715HqE2y0trb7Kv245BkUc sOxqXP3rIxmm5B5kc9t5KPiSTna3b39qtHS2trEqjh8He4UdR7etZlozhHVXCqRtYkZ3exNbf251 UxKhU4wMjHHc56YrCo5KSUSoQVjOihUSCaeMEqOIyeB9alvNVSRXjjYLEy7TGi8Cn/6LdSbXKsf7 wOAalubexsFAuNOkdWHBD1o5R5lzJ37afqaRizEsLj7NMJohmVDwrdHHcV0sE9pqXl31nGUmhbbN C33tpH6j3qzFd3KQoLfQo3Vl486L/CplMs0TXI01bSeIEMqt1X/ZPUCuaviW9bfihxoc8ibw95o1 K1RlDoBcEZPKfunwRXkKgsQoGSegr1vw1qscmupaRv8AI6Tc7Dz+5fv6V5FXRg+blfMupc4pWSJG ZCiBUKsoIY5zu/wpQq5O0lm7YHWo+/vWhp+pXeiXcd5p12EuChG4IDtz1BDAiu1MzZVMch4KODnn 5TgUoDM4CBy2ORjJr0jxH4u8QWFp4csra9Ivp7JZ7gi3j3O8rEoD8vYYFUPEWtz+FNQk0bRpEjvY sHUdRCKZZ5zywU4+VFJwAMdKrmYrHDEFXw4ZT6EYNKCR26+tdnJeT+KPAup3eqBZ9R0y4gEF3tAk dZCwMbEfe6ZGea1fiHZ2sfh3S4rWBEfRpf7NndVwXby1fJ9TkkfhT5hWPOecAEc9MClBzgDJJ42i vSfAdja6Do97rmoQRy3c+nzy20cq5EUIwvmEHuzkBfYE96yLq6/4QrS7G3sI411y+gW7uruRA7W6 PykaA8Kcck9ecU+bsTynINvXAZSjHpuGKEy5LbC69wBXZaVql54r0jXNP1uQXZtrFry2upFHmQOj KMBuu0hiCD7VLf6lrHhzw74c0/SPMiMlmbu5ZLcMXaRiy5JU9FxT5g5UcPyr7f61Lh1jBKfLnriv SEsZNWuvBya3BFHrc928twqxKkj2i4YGRVA5O18cZIrMt/EnjHWPE/kWMZkjmuDtt5LNPKWPd0bK 4CgdaOYHA4kOVYOCAQetPxLnc6sAf4mBGa7rU00Xw6+reIdPtoLgT38lrpEUi74kC4LygH7wBICg 8dfSqvhfxVrGt+I7LS9Xm/tDTr+Zbaa3mRcAOcZTj5SM5GMdKfMS4HJo/Td09asbwIzhM843ensK 3NWtVj8E2MUSh3t9XurcMB8zDahAzXQX8FtpvgXVdAWKJrzT1t7q8m2jd57sQyZ9FBVfqDQ5GTpn CqSyfdPA5NTKdw3Z6DAHtWzcBNF8HQWzBf7Q1gi4cuOYrZT8g9tzZb6AVU0TShqVreX1zeLZ2FkF 8+baXbLHCqqjqTg/lTTMJU3sikWJGcjr0qQyKRgLj15rat9A0291DS4rPWlltb2f7OWMJEsT8YBT 0ORgjjrU+p6Pok/iDUBp+qQQaVbFmkeSNh5YDbQig8uT7U1JC9kzBtxyxPJ+tXIbYJNuwDkduatz 6JD9gtdQ0i+a7gmufshEkRjdZCMjjuCPStW40Sx0zWF0mXXEk1H7QIZEt4GdEGcfe9fYVXOioxdz HnglEQYkKM4J9KgtpojKRKSY24cqvI+ld1qug6bdatf22n36w2Fip+1SGNv3e0hOP7xLfzrFOg6d Dbi7s9QW5iL7HjljKSKcZBx3U+opKqjaVFyd0YkrwNJmEFU6KDknH+NBdSccCut8K+Hjc+I7O4ZY jbwFpmDkYAQE8+1VbvwtBLY3d7aaj9oubdfPnjMJQFS2CUPfk9KPapuxnKhNLY57d+7J28ZxmnpJ hTwM45rYfw9a2FpC+saoLOa4UMsEcRkZFPQv6cc464qKHwrdNquo2c15bwRWNuLl7lifLaM42kY5 5DAgU+aI1CS3RnxSoDj+dTlX7Hgc46ircekaa0T339rBdJQiMXMsBV5ZOpVE6nA5z0FRavZJb2Ft fafffbNPmZkDldrI6gZVh9CKLpuxXLoR+crj5cAc5yarByzHAHPA9qprcZyxOPYVZRg20NhSRxT2 BRT3GksMgn9ailZTGVCZfP3s9KmlKqwJ4PUGqkjK0mSSQTyaFIUqbRTd9vUcY4xUUrFvvkAqOKfO VJAHHvVWXCOy7gwB+8O9PmM/ZWY185wwxxk16z+z9/yNOr4HH2Jef+B15G8oJX/Oa9b/AGfWz4q1 kAgp9jXB/wCB1lUd4s3pQtI+hK8p+IvjfWl8SW3g/wALfJqM+3zZ8cpu5AGenHJNerV4dql3FoH7 RQvdRxFbXKIElfhRmMLnP1GK5DsHar4U+I/hXTjrVp4nm1CWHDTWy5bI74B+8K1te8SX+teBtH1G TXh4Uu3mKT+ejDzGA5AGM4716B4k8S2PhnQJ9XunV40XMaKwzKewX1rxv4n+JR4t+H+iautlJaRy XzqiSHJYBcZ+mc/lQM9Yv/GGheGdMsTrGrwrJLChU8lpePvAdcGp9A8ZeH/E7Omk6lFPKgy0XRgP XBry3xH4Vvr7xRpWsaFd6dd6lFZw79MunG4bUHRT1GOaj0LW7KHx4IdY8KLpHicxMIJrdyEdypxl OnPrQI9P1zx/4Y8O3X2XUtVhjuO8S5Zl+uOlaWi+INK8Q2Ru9KvorqEHDFD90+47V4/8FdK03XJt cv8AV4IrvUjMAwnAYgHOTg+9XNX03w34Z03xbL4T1RzqbWzrcWccuVhXcNxAxxjP4UAdzf8AxO8H 6dfNZ3GtQech2tsywU+5FdLZahaajZJeWVxHcW7jKyRtkGvK/hZ4Z8O6h8NZJ7u0t55ZzJ9olkUF lx2z2wOao/Aya48vxHYROz2MTgw5PAY5HH1AFAG14RY3/j65uzyMyvn6nAqHUY/7c+I5tzygmCH/ AHV61Y+HKGLxBfJKCsqwkbT1B3DNVvDhY/EYknB82XP615UdYRT6yPOWsIp9WdJ8SYgfD9uwHEc4 /kRVL4eXUdnoep3EzhYonDHPbg1r/EJN3hSVv7sqH9a4HQGuNQVdBhBWO6nV5nH9xeorSrLkxF12 NKj5a9/I7Xw1b+e154p1FRvl3NAG/wCWcYrjtNtJfGHiqVpnZUkYyOw6qo6D+Veh+LEa08G3cVqh CpEEwo6LwD+lc/8ADqKCz0u/1O4dY13bS7HACjk0507zjSe27CcPfjTe27OqsPD1pZXQvHaS5uwo QTTHJVfRR0ArCl8K3CePYtUjAe0Y+a5Y8q2MYq/qHiGe28M3WreUIw5xaqw5IPAYj9ai8CXep3+l T3WoTtKJJf3Rb0HX8M1s/ZylGCXmavklJQt5nVUUUV1HQeOfGo28eoadJOu3/RZV84n5UyR26k+1 eN6FALqL7bGxFzb5EjN6HoRXtnxj086hc2KBQzLbyFR3J3CvJrDw5JHFLDJIvmzKQAGxtPY1wVWk 5a66HO60XUdNqxnwaXcoonSQNyQrMMAH0x61p2RinkEE2xJx2I2sD6j1+laaWEw01CtvuaMrKU9N pwxHqKfL5Vqj6naRLJtbeC6Z5HVeeornjWjOVpvTuuh0xptw59kznpZ2tLt4poIWjOVLRpjPuK6H ThaXhWIThpY8OsTAZx/snv8ASqeoaZ/aEwntTFiYeZzJjJ6nAPNW/Dng9dagknh1q2t7iGTasRUl s9c9uK9KeBjWpLWz7rZ+dg5uSVjQu9cvrLBjYTR42+TGcMW9WJ6D6Vj2cfmx3WqahMETJSPy84kY 9hnqB60moyyWt9fw3jQNdR4gZoTlX55INVLuG3ubW3lMrPFbgp5YOAM15SwFSmrNW6XX9fI7YVFN XuWfCcIOso7zHeEuNmTgSKIn5FeUCvUPDUSx+JbZUO5FjmC88AeS/SvLq9anSdNa9dTknJSloOJJ JycmpbWEXN5BAXVBLIqb2OAuTjJqHPNHWtbkHXeK9agPxEkv7YrNbWVxEkO08MkWAMexxV/xB4am 13xBc6to17ZXVhqEpnSR7lI2i3clZFYggiuCzTwpJ24+b0qkJnotjNpNldaL4Vt9QgnhOoJearfA 4idk5Eak9VUA89yafo9/pviP/hJ4NZvktrWW7TUdzNguEZtyJ/tMpAFebA9uKcCD1NBLO9uvEC6h 4c8R6i8kUMt/NBZW1qp5it0y2APQAKPrTvEOmyeL7m21zR7i1lEtvFFPbvOsclvIihSCGIypxkEV wOc8+neg474NUI7iX7L4d0KfQ4L23uNY1Vo4buWB90VtCGzs392LYJxwABV/WPiBqWk+O2fS795N K0+VIYrdWBjkiQBSB7EA8+9ecg+nQUu4bcYpgejwyWmheLvEOt22qrcImnvPp87TbpGabCqMnnco Zs+mKqaL4mv9d0jWPD2razJm4h8+0nll2jzYwTsJ/uuuRg8ZArgxgjjGffvQwxkMP/rUWC52Vvbr 4l8Eadp1ndQRajpUs2+2nkEfnRudwZCeCQcgj6VNpVtH4JY6xqd1bS6qiMNPsYJRIyyMMCRyOAFz kDqTiuF6j+lPB2cA8Z5xTBnovhS/0+18F3F/qFxC1xpmom8t7Vjlp5WjCpx6BhuP+7VTwNPaapca /b65qCQQ3dt580sjfM+yVXYD1YgECuFD4JwcZ68UmR7+o+tAjb13XJdd1u4v3AjV2xFEBxHGOFQe wAArc8MrqcGmtf6FqFsblpDDdWMzIMpwVYq/DAnPuMVxW4Ajg59+ppytk/wnvzVdCHHqer27aZD4 10aUHTodVitJZbpbVwtubgK5jUHoG+7nHGaoaNYNbaNcS2kGnXOvreGOVbuVG+zx4BDICdrZJOTz jFedK+5QOw4qQMvTC9amxDR66NVgF54WtdQ1SyuWtZJ7+6eHasaMv3Y+AAT8n61y3hC7hufHFlcX 0saZuWnZ5GwGcZYAk+pwPxrjS2enanq2ACRwfWqREu56NpMOsWc97e2eo241QS4uLRpExJG3O7J+ VhnqK19VltpU09Z/sSaptc3gs8eWASNgOON3XOPavKBL2JB9PpV60vWgYBWwMYPpQ0OFRrQ9U0W8 g0/S9VlWRAxhWGNC3LbmGcD6A/nV+yvbCLw9cvMVZ7mWOJkB+baPmP4ZArzJNQzH87gZ/SnDVpYk JXPI4GKzcWdUah6prM1zd388ou9JSzZt63MqIdkfoR1yBxiuH1jVRJ4e1e4e8Se5vryKBSFCHyYw SDtHQcJXPG68x3lkwCV4yM5qhcgnLAhgRiqho9Sar5lodxp19e3fhHS7bQzp8sloZRd29wqb1ZmB Djd2I4/CoNVku9SlttGOqae3lo88piCxQRSbTldw+8cD8+K4NSUB6j3H8vpS7gF29xWuiM4xbRZ8 7jhse3pUkN1iRd5JA7Csx5gG6jA7VYtrS71JrqWytZJY7WIzzhf+WaA4JPtT5g9mXmvAwwwGaZNI pUbW4A7d66vwx4Sgi8TeFP7RMN7aaxC85t2U4UDIwfXpWDeeHJhoM+tQTJ5R1R7GO2AOQecYP6Yr PmTZpbujFkcsBk8Cq743cE1vQeEdRls9ee7c2txo0Alkt5F+ZskDHt1zXT6n4NtdV1fwvpWnJDYS 3ukfaJpApO51BJJHcnFHMHKeZsSMrng9q9f/AGeC3/CVawOQv2JcA/79eT3em6hb2SajJbSraPO1 uk7D5WdeoH4V6p+zp/yNesjOcWS8/wDAxRN+6xxjZn0bXOeLvBOj+MrNINSjZZY8+VPGcOn0Pce1 dHXKeI31e41KBNNs7lWsyZfOGNkgIHA9T1GDXMaHI23wK077Qh1DXL+7tYzlYCQoPtn/AArqvFPw 80vxPothpRllsbWxbdEtuBwMYxyKhEviq6ea6iWeEK6mCCRFAcGQgh+/CYNWdDbW5NI1D+2o7iZv LG2JV2OWwdyoeOM4xQBQ8QfDHTNaubO/t7+60/UraJYlu7dgGcKMDPv9KXw58MLDRtcGt32oXeq6 mo+Sa6PCdsgetUzp19JoShdN1GK7klLxRgti35HyZ3cZH8fPeu7db43MBjeFbcD96rAlifY0AcJq /wAJNOutYn1PSNVvNHuJ8mZbZvlbPU47ZrX8KfDvRPC1ldxRB7yW8Upcz3GGaRT1X6Ul3aTT+LJ3 /s6+W3iiYtKGJW6Yr9wc4VR+prT8OWkml6fDZzQzCeZXuJDkskZJHybie2cAexoA4qf4L2CSzppu v6jYWM5zLaxuCuPT/wDXXceGPC+meEtJXT9MiKx53O7nLSN6k1yxsL2aW7nGmajFaicCS03sWnQE /PnPJJ7DtV620u/gMc15bXdwrad5c0aTHLMHyFHP3tv50Abz6BanWo9WtnaC4H+t2Y2yj0I/rVVv CtnH4ji1i3maCbcS8fBV89fpUehWurQaD5UWIJvtRZftSnmLOT8ucqcZAGaoa3p95Nqd/myubiac ILC4iYhbcjrk5+XnnPeodKD6eZHs4vodZe2VvqFnJaXKB4pBhlrF8P8AhC08P3k1zFM8rONq7wPk FYk8HieBEuibua5eOWN/L2jyh5o24Hf5RnuaVW8Zm1W4/efaDiMwlV2hdpy3+9nFDpxclJrVDcIt qT3O6dVkRkYBlIwQe4rl4/BFjDc5a7nNgJPNFmWxHu9/UVjQr4mha6eBdS2TSF4TIi72kwoG8dAn 3umK3tdgvdb0a1ihgeOX7WglWRSAAD8xIyCV/nRKnGXxIJQjLcu69oUWv6fHaNOYo1cOSgByB2rR s7SGws4rW3XbFEoVRWBoq3Wna7f2k1ncmCZkMMyrmIAJz3457V01NQSlzdR8qTv1CiiiqGeffEuf 7HEtyIld0tnEe7j5iRjmvF9OW7ufD2q6tdRqJUKxxhTwuThq9R+LFzer4g0W0hlRLa4jdZBJDvVj uUYz2NeZaxrUmiWN1osaRJDOTlVi3kMD+WK8qrQl7aTitW19y3/I7ITpKC76m9DO0WlCRJQrWxRQ /wB5JFYfy60xbRzBJaSMY7d9wVWJYLnuPrXJ2WrRvCtvBYzhJ2USSlsDcOwA6c12txr8OnkRLJKl 0p3t0ILY7DHNZrD8lTltvr+X6m0KkJQauZmi2X7yCKa3eSRPMVdr7c8dq5+7s7qa8mCB1W36IM5X 24612GnT289w++R1kcOzIVwckflmq2kTxRXt3GYbsW8isrytGANuPrXp0qyjaM+n+bOOrBKnzROO EUrWEO2Ty2Dvksfeulsru40TS7TU7clJi7BRMokGCPcc1AtnHdxRJDBgbjvzzjnr+VXtcmt5bCJF YkQTGIALjHHp6UqtX3opPrcVOF73Rf0Xw/PdabY+JVVGeR7v7SykKAPKfGB/hXghxgYznvX074Oi S5+GtwA6N9lluHAU5x+5f/GvmGuqc+axjazaCrFnZXGoXAgtYzJIQTjIAAHUkngD3NV60tH1CGxl uEuUdre5hMMhjxvUEg5GfcdKgZI3h+8jgnMkbieOSONYwAwffnGCD7ds0h8O6otxHD9nBd84KyKV GPvZYHAx3yauJrOn21tLbW0N2IzNBIjGQbyEzk5/hJzxjpVybxPp82YnhuJEmjeOe48tElKsQRgL wcEdTyaAMUaDqTXklr9mxJGoZizqFAPQ7icc9ueatWfh2W5iDSu8Un2lrdovLyylU356j0xTk1TT BDc2Hk3a2U3lkOGDS7kzyQeMHJ4zxV9fFdt9p8+WCXc1205VccKYvLAyep7mmIwpNHv4pJ0eAgwI ryfMOFbG0++cjpReaVe6eivdQ7ELbchg2D1wcHg+xrUm8URtpVnGlu322ORDO7Y2yJGcxj1781Pq XiPTdSHlSxXS280/nTrHHEhBwcAED5uT1PancLGNb6NqF3ZtdwWxeEZOQwBbHXaM5OPamvpV+lgL 1oCICA2cjO08BivXHv0q6uqafLp1tHdQXRuLSN44REwVWDEkFj1BBPbrUk2v20lrLIIZft01mtm4 OPLCjHzDvnCjii4WIW8MatGWElvGpQjfunQbM9N3PGe2etRQ6PMxv1nJge0UblYZLOWAC/jz+VWt R1+3vP7Y8uKVftzwmPdj5Qmc5596l1fXra6jlktA4kuLsTyI4wQqABQT0PO40+YVjNOj6gHlQWze ZFOLdwpBPmHOF/Q1Hfadd6ds+0xgCTO1ldWBI6jIJGRW1ceI9PfznijvBLcXyXb8quzAbIUgn14O Ko67q1rqS24hR2kj3GSeSNY2kz0BC8cevU0+YLGRkdT06UmSPpSA/N0/ClPU4+mKaYCjkk05RxkH 2z71GMgjilzuHTmi4miTcAev5VIrNweAfYVX3EdKVTg9SKaYnEthhjqc/pSq3vVZHyp5I9qeXJbg 9fai5m4FgPk8d6mSYgjDdOQMVQMmMZpRLk9adxezuasUxBwWqylwT3Oe3esZZQPfP6VYS5AFDZtC mkafmEoSQfpipY42mUc/N6Vni6XOATn1qRb5YyPn5781DZsoJGgbKSLiQY4zzVGVcMWbA9hTp9eW WPbLNvKjC9yBWTcakJG+QHHpSvqU0kTSHnk//Wqzp+sX+kRXq2Vw0K3sBt58Y+eM8ke1Y32pwQcA +xoku3kPCInzE4Ufp9KvnRi0elaa/jLRbXRfFVzp7z6ZpieXaCYhRsc4GB1xk9aqQ6T40vZrvQ4L WVfs9yNQlgyqrE7chix+vrUPijxponibTbK5eLVrfWbe3hgMSSIbQhCOQM5GR7da1rP4oaTH401T VriPU/7NvY4o5LERxOswVQCHDHjpwRzUcw7FPT4vG/iV9fmtYri5kuR5Woy/KFbb/Dk8Z47elXLe bx14hh0/XND0iWIaTaGySaLGZAMhsA/eOPSs6Dxt4cuvDNzoOoWWq2dqmoS3lmdOkXKh/wCB9xGc cVd0L4jaBa6d4eGqWusC80Et9nWylVYZwTuHmAnOc9cUcwHD3OtalNpEejXE7/ZLe4adYWX7sh4J 9a9W/Zzx/wAJZrAByBYrg/8AAxXjerak+q6xe6iyLG11O8xRei7jnFev/s2knxVrOf8AnyX/ANDF JyuB9J0UUVIBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGD4h8NjxBPZNJeGKK 2fzDF5YYOfr2rmJPhHp81wJpb+R9rlwDEOpOfXpRRUOnFu7QX0sbUPgazht5og1v+9XBItVG0+o9 DTrfwPYW5iY+VKyLjMsAbPvRRQ6cW1K2qJUUlykl54PgvLeWFp0jEihcpAoK47j3p9l4QtLK0W3D rIoHJkjBLfU5oopuEXuhpJbEcfgnT4ZJZItsbycHZGAOuelQX3w/0y/QRysVizkhFALH3NFFR7Gn e9i+eXc04vC+m2mj3Gm2MKWyTRNGzovOWUruPqea8k/4Zp0//oZbn/wFX/4qiitSErB/wzTp/wD0 Mtz/AOAq/wDxVH/DNOn/APQy3P8A4Cr/APFUUUDD/hmnT/8AoZbn/wABV/8AiqP+GadP/wChluf/ AAFX/wCKoooAP+GadPH/ADMt1/4Cr/8AFUf8M06f/wBDLdf+Aq//ABVFFAB/wzTp/wD0Mtz/AOAq /wDxVH/DNOn/APQy3X/gKv8A8VRRQAv/AAzVYD/mZbr/AMBV/wDiqT/hmnT/APoZbn/wFX/4qiig BR+zVYD/AJmW5/8AAVf/AIqj/hmnT/8AoZbr/wABV/8AiqKKAD/hmrT/APoZbr/wFX/4qj/hmnT/ APoZbr/wFX/4qiii4B/wzVp//Qy3X/gKv/xVH/DNVhjH/CS3X/gKv/xVFFO4B/wzVp56+Jbn/wAB V/8AiqP+GatP/wChluv/AAFX/wCKoopXAP8AhmrT+f8Aipbr/wABV/8AiqP+GatP/wChluv/AAGX /wCKoop3AX/hmuwxj/hJbr/wFX/4qg/s12B5Pia6/wDAVf8A4qiii7Cwn/DNVh/0Mt1/4Cr/APFU D9mrT88+JbrH/Xsv/wAVRRSuAv8AwzZYDp4muv8AwFX/AOKpR+zbZDp4muv/AAFX/wCKoop3AQ/s 2WJ/5me6/wDAZf8A4qm/8M02B/5mW6/8BV/+KoopAH/DNOn/APQy3P8A4Cr/APFUf8M06f8A9DLc /wDgKv8A8VRRQAf8M06f/wBDLc/+Aq//ABVH/DNOn/8AQy3P/gKv/wAVRRQAf8M06f8A9DLc/wDg Kv8A8VR/wzTp/wD0Mtz/AOAq/wDxVFFAB/wzTp//AEMtz/4Cr/8AFUf8M06f/wBDLc/+Aq//ABVF FAB/wzTp/wD0Mtz/AOAq/wDxVdj8PPhRbfD7VLu9g1aa8NzCISjwhAvzA54J9KKKAP/Z --_004_9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0xmbalnx06ciscoc_-- From manishkr@cisco.com Tue Nov 5 12:49:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CD421E80F3 for ; Tue, 5 Nov 2013 12:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.54 X-Spam-Level: X-Spam-Status: No, score=-9.54 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuQ518VCHT7x for ; Tue, 5 Nov 2013 12:49:46 -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 8B0F721E8160 for ; Tue, 5 Nov 2013 12:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20963; q=dns/txt; s=iport; t=1383684582; x=1384894182; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=F+X861BU2ULA4L7VzuNlIdgMvkKRsrcyvs8C++WlGGs=; b=F039V8EQuwvNmCZOrGSX1FGfdhDL+8UvYu8X7x4MDsnlEp+w5tgMf0Bh KnVx/pin9uJOyLo/c6UZKA/YPIPMheqOK37E5PlveVTmKxpR2SqDKFpHG h+Zcadm2GlGMKhZ1IjMs4enxOYdhFFQ1UiAbV+8yoIFyBMZFZqW4V/9XM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFABZZeVKtJV2a/2dsb2JhbABZgkNEgQu/OoEsFnSCJQECBCcGRAgSAQgRAwECKDkUCQgBAQQBDQUbh2a+d49IEQcGhCkDlCuDX5IJgyaCKg X-IronPort-AV: E=Sophos;i="4.93,641,1378857600"; d="scan'208,217";a="281089930" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2013 20:49:40 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA5Kndc9010384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 20:49:39 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 14:49:39 -0600 From: "Manish Kumar (manishkr)" To: Stephen Kent , "Mike Sullenberger (mls)" , Michael Richardson Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/cpYuJultjCkmeRXpQLS+S3gAaP8MAAB8qFQA= Date: Tue, 5 Nov 2013 20:49:39 +0000 Message-ID: In-Reply-To: <5278183E.500@bbn.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.122.172] Content-Type: multipart/alternative; boundary="_000_CE9DD2ED9468manishkrciscocom_" MIME-Version: 1.0 Cc: "Stephen Lynn \(stlynn\)" , "Michael Guilford \(mguilfor\)" , IPsecme WG , "draft-detienne-dmvpn@tools.ietf.org" , "Mark Comeadow \(mcomeado\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:49:52 -0000 --_000_CE9DD2ED9468manishkrciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Stephen, Thanks for your inputs vis-a-vis 4301/2/3. I concur that IPSec is not jus= t about encryption but don't quite buy into what somebody spelled out durin= g the meeting as 'IPSec is an access control mechanism that also provides o= ther security services'; IMO, strict access control is more a firewall func= tionality. RFC 4301 spells out the access control rationale as "IPsec includes a specification for minimal firewall functionality, since t= hat is an essential aspect of access control at the IP layer=85 The IPsec f= irewall function makes use of the cryptographically-enforced authentication= and integrity provided for all IPsec traffic to offer better access contro= l than could be obtained through use of a firewall (one not privy to IPsec = internal parameters) plus separate cryptographic protection." I know that we might have ruffled a few feathers wrt making the SPD relativ= ely trivial but let's get down to some details as far as the comparison goe= s. The first ADVPN proposal does talk about the shortcut suggester possibly= including traffic selectors in the shortcut exchange. While this seems to = give the notion of the ability to provide SA granularity, the source of suc= h information is a third party (even though both peers have an active conne= ction with this third party) and doesn't quite stand up to the very reason = of including access control in IPSec (The IPsec firewall function makes use= of the cryptographically-enforced authentication and integrity provided fo= r all IPsec traffic to offer better access control than could be obtained t= hrough use of a firewall (one not privy to IPsec internal parameters) plus = separate cryptographic protection.) - this is a case of the information not= even privy to the same device, leave alone the same layer in the same devi= ce. Let's say, the shortcut suggester passes on an information in the shortcut = exchange to the two peers about the selectors (X->Y) to be used for the sho= rtcut while selectors (X'->Y') be still allowed through the spoke-hub-spoke= path. It's entirely upto the peers (shortcut partners) to choose what to d= o with that; well, the draft prescribes that the shortcut partners should u= se this but when we are talking about multi-vendor, multiple administrative= domains, how do we trust that the shortcut partners do that. We must reali= se that the role of the suggester/hub is more advisory in nature; it can on= ly advise not enforce. The problem is a system wide design problem not one = to be sorted out just between two nodes (and IKE is intrinsically designed = to operate in a peer-to-peer model), so e.g. even if policies prescribe (as= obtained from the shortcut exchange) that a certain traffic be routed via = the hub, once the two peers(shortcut partners) have all the authentication = information for each other, they might give a damn and say we don't care, l= ets bypass the policy and use the shortcut for everything leaving the hub i= n dark. Unlike a traditional IPSec case, where each peer could enforce spec= ific access control policies (e.g. if the peer you negotiated an SA with se= nds a traffic using an SA which was not supposed to be used for that traffi= c, you could simply drop it post decryption), the hub can't enforce such po= licies =96 it can dictate what doesn't pass through it but not what MUST pa= ss through it, which is what the common requirement is. What all this effectively means is if really need to enforce access-control= policies, it has to be agreed between the spokes/shortcut partners, not pr= escribed by the hub. IPSec typically deals with a case where the SPD is in = place apriori based on which SAs are negotiated but here we end up with a c= ase where the SPDs need to be negotiated and agreed upon as well !!! In tha= t sense, I would say DMVPN still provides better access control =96 it alre= ady determines what portion of the network should use the shortcut depends = on the address/subnet sent in NHRP resolution reply. This is used to instal= l shortcut routes and/or policy based routes and the same can be used to al= so install an ACL if we suspect the peer to play foul. It's another matter = that this is not as part of IPSec access control directly. This is on top o= f the route/forwarding policy based tunnel selection. - Manish From: Stephen Kent > Date: Tuesday, 5 November 2013 3:27 AM To: Mike Sullenberger >, Michael Richar= dson > Cc: "Stephen Lynn (stlynn)" >, "d= raft-detienne-dmvpn@tools.ietf.org" >, Mark Comeadow >,= "Michael Guilford (mguilfor)" >, IPsecme WG > Subject: Re: [IPsec] AD VPN: discussion kick off Resent-From: > Resent-To: Frederic Detienne >, Manish Ku= mar >, Mike Sullenberger > Resent-Date: Tuesday, 5 November 2013 3:27 AM Mike, A couple of your comments caught my attention, as an author of 4301, 02, an= d 03. I admit to not having read the DMVPN proposal, so my comments are bas= ed only on your message, which argues why DMVPN is the preferred solution. IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the correct st= andard protocol to use. This is what IPsec does really well, encrypt traff= ic. The layers above greatly simplifies IPsec's job by presenting to it the= tunnel to encrypt instead of all of the individual protocols/subnets/flows= that are within the tunnel. The IPsec selectors are now for the tunnel, w= hich makes path redundancy and load-balancing doable. IPsec doesn't deal w= ell with the same set of selectors to encrypt traffic to more than one peer= . With DMVPN this is handled at the routing/forwarding and GRE tunnel laye= rs. IPsec is not just about encryption, although the DMVPN proposal may relegat= e it tothat. IPsec provides access control, and, typically, authentication.= Does DMVPN preserve the access control features of IPsec, or are users no= w relying on a hub to do this, or what? ... With 10s of thousands of nodes and perhaps 100s of thousands of netwo= rk/subnets reachable via the VPN the number of IPsec selectors across the V= PN would get completely out of hand, especially if each different pair of s= ubnets (selector) requires a separate encryption, between the same two node= s. More properly, a separate SA, and only if the folks who manage policies at = each end of the SA decide to provide fine-grained access control for the tr= affic flows. It was not clear to me that the problem statement for this wor= k envisioned VPNs of the scale you mention. Also, the comments above are a = bit confusing. Both end points and security gateways are "nodes" wrt IPsec,= in the general sense. I can create a selector that secures traffic from my= node (and point of subnet) to all hosts on a subnet, irrespective of how m= any are present there. This doesn=92t even count the fact that in order to run IPv4 and IPv6 betwe= en the same two nodes you have to use at least double the number of selecto= rs. At least? Under what circumstances would the number grow by more than a fac= tor of two? Routing protocols are already designed to scale to 100s of thousands and ev= en millions of routes. So with DMVPN the forwarding and GRE tunneling of bo= th IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selector. So, the proposal simplifies use of IPsec by limiting the granularity at whi= ch SAs may be created?Does it also cause each SA to terminate at a hub, so = that the security services are no longer e-t-e? In the context of the perp= ass discussions, this seems like a questionable design decision. Steve --_000_CE9DD2ED9468manishkrciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thanks for your inputs  vis-a-vis  4301/2/3. I concur t= hat IPSec is not just about encryption but don't quite buy into what somebo= dy spelled out during the meeting as 'IPSec is an access control mechanism = that also provides other security services'; IMO, strict access control is more a firewall functionality. RFC 4301 spel= ls out the access control rationale as
"IPsec includes a specification for minimal firewall functionalit= y, since that is an essential aspect of access control at the IP layer=85 T= he IPsec firewall function makes use of the cryptographically-enforced auth= entication and integrity provided for all IPsec traffic to offer better access control than could be obtained throug= h use of a firewall (one not privy to IPsec internal parameters) plus separ= ate cryptographic protection."

I know that we might have ruffled a few feathers wrt making the SPD re= latively trivial but let's get down to some details as far as the compariso= n goes. The first ADVPN proposal does talk about the shortcut suggester pos= sibly including traffic selectors in the shortcut exchange. While this seems to give the notion of the abili= ty to provide SA granularity, the source of such information is a third par= ty (even though both peers have an active connection with this third party)= and doesn't quite stand up to the very reason of including access control in IPSec (The IPsec firewall funct= ion makes use of the cryptographically-enforced authentication and integrit= y provided for all IPsec traffic to offer better access control than could = be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic p= rotection.) - this is a case of the information not even privy to the same = device, leave alone the same layer in the same device.

Let's say, the shortcut suggester passes on an information in the shor= tcut exchange to the two peers about the selectors (X->Y) to b= e used for the shortcut while selectors (X'->Y') be still allowed throug= h the spoke-hub-spoke path. It's entirely upto the peers (shortcut partners) to choose what to do with that; well, the draft = prescribes that the shortcut partners should use this but when we are talki= ng about multi-vendor, multiple administrative domains, how do we trust tha= t the shortcut partners do that. We must realise that the role of the suggester/hub is more advisory in nat= ure; it can only advise not enforce. The problem is a system wide design pr= oblem not one to be sorted out just between two nodes (and IKE is intrinsic= ally designed to operate in a peer-to-peer model), so e.g. even if policies prescribe (as obtained from the shortcut = exchange) that a certain traffic be routed via the hub, once the two peers(= shortcut partners) have all the authentication information for each other, = they might give a damn and say we don't care, lets bypass the policy and use the shortcut for everything lea= ving the hub in dark. Unlike a traditional IPSec case, where each peer coul= d enforce specific access control policies (e.g. if the peer you negotiated= an SA with sends a traffic using an SA which was not supposed to be used for that traffic, you could simply= drop it post decryption), the hub can't enforce such policies =96 it can d= ictate what doesn't pass through it but not what MUST pass through it, whic= h is what the common requirement is. 

What all this effectively means is if really need to enforce access-co= ntrol policies, it has to be agreed between the spokes/shortcut partners, n= ot prescribed by the hub. IPSec typically deals with a case where the SPD i= s in place apriori based on which SAs are negotiated but here we end up with a case where the SPDs need to b= e negotiated and agreed upon as well !!! In that sense, I would say DMVPN s= till provides better access control =96 it already determines what portion = of the network should use the shortcut depends on the address/subnet sent in NHRP resolution reply. This is used = to install shortcut routes and/or policy based routes and the same can be u= sed to also install an ACL if we suspect the peer to play foul. It's anothe= r matter that this is not as part of IPSec access control directly. This is on top of the route/forwarding p= olicy based tunnel selection.

- Manish

From: Stephen Kent <kent@bbn.com>
Date: Tuesday, 5 November 2013 3:27= AM
To: Mike Sullenberger <mls@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>=
Cc: "Stephen Lynn (stlynn)&quo= t; <stlynn@cisco.com>, "= draft-detienne-dmvpn= @tools.ietf.org" <draft-detienne-dmvpn@tools.ietf.org>, Mark Comeadow <mcomeado@cisco.com= >, "Michael Guilford (mguilfor)" <mguilfor@cisco.com>, IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] AD VPN: discus= sion kick off
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: Frederic Detienne <fd@cisco.com>, Manish Kumar <manishkr@cisco.com>, Mike Sullenberg= er <mls@cisco.com>
Resent-Date: Tuesday, 5 November 20= 13 3:27 AM

Mike,

A couple of your comments caught my attention, as an author of 4301, 02, an= d 03. I admit to not having read the DMVPN proposal, so my comments are bas= ed only on your message, which argues why DMVPN is the preferred solution.<= /font>
IPsec encryption layer.  In this layer ISAKMP/IKEv2/IPsec is t= he correct standard protocol to use.  This is what IPsec does really well, encrypt traffic. The layers above greatly = simplifies IPsec's job by presenting to it the tunnel to encrypt instead of= all of the individual protocols/subnets/flows that are within the tunnel.&= nbsp; The IPsec selectors are now for the tunnel, which makes path redundancy and load-balancing  doable. I= Psec doesn't deal well with the same set of selectors to encrypt traffic to= more than one peer.  With DMVPN this is handled at the routing/forwar= ding and GRE tunnel layers.
IPsec is not just about encryption, although the DMVPN proposal may = relegate it tothat. IPsec provides access con= trol, and, typically, authentication.  Does DMVPN preserve the access control features of IPsec, or are user= s now relying on a= hub to do this, or what?
 .= ..  With 10s of thousands of nodes and perhaps 100s of thousands of ne= twork/subnets reachable via the VPN the number of IPsec selectors across th= e VPN would get completely out of hand, especially if each different pair of subnets (selector) requires a separate encryptio= n, between the same two nodes. 
More properly, a separate= SA, and only if the folks who manage policies at each end of the SA decide= to provide fine-grained access control for the traffic flows. It was not c= lear to me that the problem statement for this work envisioned VPNs of the scale you mention. = Also, the comments above are a bit confusing. Both end p= oints and security gateways are "nodes" wrt IPsec, in the general= sense. I can create a selector that secures traffic from my node (and point of su= bnet) to all hosts on a subnet, irrespective of how many are present there.=  
This doesn=92t even count the fact that in order to run IPv4 and IPv6 = between the same two nodes you have to use at least double the number of se= lectors.
At least? Under what circumstances would th= e number grow by more than a factor of two?
Routing protocols are already designed to scale to 100s of thousands a= nd even millions of routes. So with DMVPN the forwarding and GRE tunneling = of both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selec= tor.
So, the proposal simplifies use of IPsec by limiting the granularity at wh= ich SAs may be created?Does it also cause each SA to terminate at a hub, so that the security services are no longer= e-t-e?  In the context of the perpass discussions, this seems li= ke a questionable design decision.
 
Steve
 --_000_CE9DD2ED9468manishkrciscocom_-- From manishkr@cisco.com Tue Nov 5 13:09:23 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1F811E812A for ; Tue, 5 Nov 2013 13:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQWmh2yoYqBl for ; Tue, 5 Nov 2013 13:09:16 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1F55211E814D for ; Tue, 5 Nov 2013 13:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3402; q=dns/txt; s=iport; t=1383685719; x=1384895319; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=p+v0MTi+3azVToRpJ1aCuu9sDJgU8uBFQ+JvcX7fuFs=; b=VwUNxWulDWbjnN/XGphDTDfWcfvA2KxXq1nyVBtaSlrb86CSCJUEiUgP v+TPFyJDPzGrJBa4BhwApTpnZ6StE/zLd8vzSO/Y4CuqH4A3GkG7uW8B7 kMKEDsqcat6VkzrteQn2yMUK5j/hZTyc7fJYiSzx9NfF2HkoBYV6BtnjY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAMpdeVKtJV2b/2dsb2JhbABYgwc4U786gSwWdIIsOlEBCDZCJQIEARIZAodmvnaOEIFQhC8DmAqSCYMmgXE5 X-IronPort-AV: E=Sophos;i="4.93,641,1378857600"; d="scan'208";a="281073277" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2013 21:08:28 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA5L8Swn019135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 21:08:28 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 15:08:28 -0600 From: "Manish Kumar (manishkr)" To: Michael Richardson , IPsecme WG Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: AQHO0DKypYuJultjCkmeRXpQLS+S3poRM7yAgAGAJICABGCKgA== Date: Tue, 5 Nov 2013 21:08:27 +0000 Message-ID: In-Reply-To: <16853.1383419873@sandelman.ca> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.122.172] Content-Type: text/plain; charset="us-ascii" Content-ID: <02058DAFF9C989468FA3B4529C786EB5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:09:23 -0000 Michael, "I don't like that DMVPN does not let http traffic continue to travel via HQ's virus/trojan/netnanny while RTP takes the shortcut." While I do appreciate that the following could represent a valid used case, it would be inaccurate to say DMVPN doesn't allow this. It does allow but not using the IPSec tools; the protocol programming the forwarding layer(could be policy based) controls what goes via the hub as opposed to what goes on the shortcut tunnel. Also, I would see this more as a path selection problem more than 'the kind of security treatment a certain class of traffic needs' - it's another matter that different paths provide different security services/treatment. Since, the network topology information and hence the path that a class of traffic may take is not privy to IKE/IPSec, it's only appropriate that a protocol aware about this takes this call. This is the reason I don't concur with your other comment about doing this in IKE. Cheers, Manish On 03/11/13 12:47 AM, "Michael Richardson" wrote: > >{Sorry about that, the email configuration my tablet had a \n in a header >that did not belong} > >I have read all three proposals, although I missed the Q&A in Berlin. >I am looking forward to further Q&A in Berlin. > >When I read the NBMA protocol (DMVPN, I think) version what I saw was a >very >brilliant hack that managed to take two code bases (IPsec and ATM) that >were >likely already present in that vendor's firmware and connect them. >Likely, >it took only a few weeks of brilliant hacking, and it was ready for >customer use. > >I find that this solution for anyone else involves the most amount of new >code, >and I think it will the most difficult to support on various mobile and >laptop=20 >platforms as it requires new encapsulation modes. > >draft-mao-ipsecme is architecturally the closest to me, and I like the ADS >idea: it seems that it be implemented without any new kernel code, and I >think that if we are trying to get remote warrior and branch office RTP >traffic to take a more direct route, then eliminating the need for a more >network plumbing, and just doing things in IKE is the right answer. (%) > >I don't like having a new protocol: I want it in IKE. While it can and >should run inside the tunnel, I don't see why adding a new port to my IKE >daemon makes my life easier. > >I *do* like the way that DMVPN uses probe packets to discover the end >points of=20 >the shorter routes, and I would look forward to including that mechanism >somehow. I don't know how to do that without hacks to the data plane, >which >I'd like to avoid. I can imagine some ways to do this with a traceroute >process, but it seems kludgy and brittle. (really, that's still dataplane, >but it's using an existing mechanism) > >I don't like that DMVPN does not let http traffic continue to travel via >HQ's >virus/trojan/netnanny while RTP takes the shortcut. > > >(%)- the plumbing might need a way to sample 5-tuple flows to see if there >is traffic that should be shortcut. However, various schemes to put more >specific SPD entries in that cause key requests might accomplish this >without =20 >new kernel code. > >-- >Michael Richardson >-on the road- > >--=20 >Michael Richardson , Sandelman Software Works > > From paul@cypherpunks.ca Tue Nov 5 13:46:04 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6341211E814D for ; Tue, 5 Nov 2013 13:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaN3DCl0MZ+y for ; Tue, 5 Nov 2013 13:45:58 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1126321F9E26 for ; Tue, 5 Nov 2013 13:45:42 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3dDkvQ42dCz6f; Tue, 5 Nov 2013 16:45:38 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 0VxLdiTXcmrO; Tue, 5 Nov 2013 16:45:37 -0500 (EST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 5 Nov 2013 16:45:37 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 169E3807CA; Tue, 5 Nov 2013 16:45:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 04A16800A9; Tue, 5 Nov 2013 16:45:38 -0500 (EST) Date: Tue, 5 Nov 2013 16:45:37 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: "Manish Kumar (manishkr)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:46:04 -0000 On Tue, 5 Nov 2013, Manish Kumar (manishkr) wrote: > "I don't like that DMVPN does not let http traffic continue to travel via > HQ's > virus/trojan/netnanny while RTP takes the shortcut." > > While I do appreciate that the following could represent a valid used > case, it would be inaccurate to say DMVPN doesn't allow this. It does > allow but not using the IPSec tools; the protocol programming the > forwarding layer(could be policy based) controls what goes via the hub as > opposed to what goes on the shortcut tunnel. Also, I would see this more > as a path selection problem more than 'the kind of security treatment a > certain class of traffic needs' - it's another matter that different paths > provide different security services/treatment. Since, the network topology > information and hence the path that a class of traffic may take is not > privy to IKE/IPSec, it's only appropriate that a protocol aware about this > takes this call. This is the reason I don't concur with your other comment > about doing this in IKE. Couldn't that policy be exposed in IKE using traffic selectors for port 80 or 443? In all of the three proposed solutions? Paul From kent@bbn.com Tue Nov 5 14:22:00 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027C411E8103 for ; Tue, 5 Nov 2013 14:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd7WU6D08yRv for ; Tue, 5 Nov 2013 14:21:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 257F111E80E3 for ; Tue, 5 Nov 2013 14:21:53 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:36246 helo=dhcp-a369.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vdp0S-0006wu-6I; Tue, 05 Nov 2013 17:21:52 -0500 Message-ID: <52796F7F.7060500@bbn.com> Date: Tue, 05 Nov 2013 17:21:51 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Mike Sullenberger (mls)" , ipsec References: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> <5278183E.500@bbn.com> <9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0@xmb-aln-x06.cisco.com> In-Reply-To: <9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0@xmb-aln-x06.cisco.com> Content-Type: multipart/alternative; boundary="------------050008020008090607020604" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:22:00 -0000 This is a multi-part message in MIME format. --------------050008020008090607020604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, Thanks for the responses to my comments, including ones from yesterday's meeting. > Steve, > Sorry, I wasn't clear on our use of IPsec. We definitely use both the > authentication and encryption capabilities of IPsec. We do the > following when bringing up a new tunnel. > > 1. Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, > RemotePeer IP, GRE). > 2. ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the > IPsec/Child encryption SAs. > 3. IPsec signals it has authenticated and encryption is ready, the > GRE tunnel is activated. > 4. NHRP registration (for spoke-hub) or resolution reply (for final > phase of spoke-spoke) are sent over the tunnel. > 5. Routing is brought up over the spoke-hub tunnels. > If a shortcut between two spokes is available, as advised by a hub, that requires an SDP entry. Did that entry preexist in the spoke, or was it provisioned by a hub in some fashion? If it existed in the spoke, initially, "normal" IPsec operation would cause traffic to that spoke to trigger formation of an SA to that destination. Can you clarify? > As for scaling, we already have DMVPN networks of 10000+ nodes and > looking at building networks of 40000+ nodes. > In many cases customers have multiple subnets behind each node, > therefore with just IPsec I would need to have multiple SAs/encryption > between the same two nodes, even if you are only doing subnet to > subnet SPDs. Take the case of two nodes that each have 4 subnets. I > could need as many as 16 SAs to cover all cases. Or even a simpler > case between a host (1 local address) and a node at a data center (say > 20 subnets), I would need up to 20 SAs to cover this. In many of our > networks we are asked to support at least 5 (sometimes 10) subnets per > spoke location. That's a helpful clarification. It does not appear to be the sort of environment that initially seemed to be the focus of this work, e.g., road warriors calling home or home/satellite offices for a moderate size enterprise. > As far as IPv4 and IPv6 support, you are correct it would only double > the number of SAs needed, assuming that there are the same number of > subnets for IPv4 and IPv6. From what I have seen IPv6 tends to > increase the number of subnets. I'm glad we're on the same page here. > For end-to-end encryption, take the case where a spoke node is a > host. Then initially the spoke/host will connect to one or more hubs > (we recommend at least 2 for redundancy). Communication between two > such connected hosts would be through the hub and would be two hops > (Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once the shortcut > tunnel is setup then communication would be direct between the hosts > (Host1 encrypt-decrypt Host2). see my question re the shortcut SPD entries. Steve --------------050008020008090607020604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

Thanks for the responses to my comments, including ones from yesterday's meeting.
Steve,
 
Sorry, I wasn’t clear on our use of IPsec. We definitely use both the authentication and encryption capabilities of IPsec. We do the following when bringing up a new tunnel.
  1. Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer IP, GRE).
  2. ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the IPsec/Child encryption SAs.
  3. IPsec signals it has authenticated and encryption is ready, the GRE tunnel is activated.
  4. NHRP registration (for spoke-hub) or resolution reply (for final phase of spoke-spoke) are sent over the tunnel.
  5. Routing is brought up over the spoke-hub tunnels.
If a shortcut between two spokes is available, as advised by a hub, that requires an SDP entry. Did that entry preexist in the spoke, or was it provisioned by a hub in some fashion? If it existed in the spoke, initially, "normal" IPsec operation would cause traffic to that spoke to trigger formation of an SA to that destination. Can you clarify?
 As for scaling, we already have DMVPN networks of 10000+ nodes and looking at building networks of 40000+ nodes.
In many cases customers have multiple subnets behind each node, therefore with just IPsec I would need to have multiple SAs/encryption between the same two nodes, even if you are only doing subnet to subnet SPDs.  Take the case of two nodes that each have 4 subnets. I could need as many as 16 SAs to cover all cases.  Or even a simpler case between a host (1 local address) and a node at a data center (say 20 subnets), I would need up to 20 SAs to cover this.  In many of our networks we are asked to support at least 5 (sometimes 10) subnets per spoke location.
That's a helpful clarification. It does not appear to be the sort of environment that initially seemed to be the focus of this work, e.g., road warriors calling home or home/satellite offices for a moderate size enterprise.
 As far as IPv4 and IPv6 support, you are correct it would only double the number of SAs needed, assuming that there are the same number of subnets for IPv4 and IPv6.  From what I have seen IPv6 tends to increase the number of subnets.
I'm glad we're on the same page here.
 For end-to-end encryption, take the case where a spoke node is a host.  Then initially the spoke/host will connect to one or more hubs (we recommend at least 2 for redundancy).  Communication between two such connected hosts would be through the hub and would be two hops (Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once the shortcut tunnel is setup then communication would be direct between the hosts (Host1 encrypt-decrypt Host2).
see my question re the shortcut SPD entries.

Steve
 --------------050008020008090607020604-- From kent@bbn.com Tue Nov 5 14:23:01 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DEB11E8123 for ; Tue, 5 Nov 2013 14:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liQkzsiHH4p0 for ; Tue, 5 Nov 2013 14:22:55 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC7E11E80E3 for ; Tue, 5 Nov 2013 14:22:55 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:36250 helo=dhcp-a369.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vdp1S-0006yD-IY; Tue, 05 Nov 2013 17:22:55 -0500 Message-ID: <52796FBE.7070301@bbn.com> Date: Tue, 05 Nov 2013 17:22:54 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Manish Kumar (manishkr)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090504070603040402040800" Cc: IPsecme WG Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:23:01 -0000 This is a multi-part message in MIME format. --------------090504070603040402040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Manish, > Hi Stephen, > > Thanks for your inputs vis-a-vis 4301/2/3. I concur that IPSec is > not just about encryption but don't quite buy into what somebody > spelled out during the meeting as 'IPSec is an access control > mechanism that also provides other security services'; IMO, strict > access control is more a firewall functionality. RFC 4301 spells out > the access control rationale as > "IPsec includes a specification for minimal firewall functionality, > since that is an essential aspect of access control at the IP layer... > The IPsec firewall function makes use of the > cryptographically-enforced authentication and integrity provided for > all IPsec traffic to offer better access control than could be > obtained through use of a firewall (one not privy to IPsec internal > parameters) plus separate cryptographic protection." You cited one of several sentences that mention access control in 4301, in Section 2.1. Other quotes, very close to the one you chose, make a stronger case for access control as an important element of IPsec: The set of security services offered includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic flow confidentiality. and The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection. This second quote notes that a separate firewall, operating at the Internet layer, is NOT as secure as the one integrated into IPsec. > I know that we might have ruffled a few feathers wrt making the SPD > relatively trivial but let's get down to some details as far as the > comparison goes. The first ADVPN proposal does talk about the shortcut > suggester possibly including traffic selectors in the shortcut > exchange. While this seems to give the notion of the ability to > provide SA granularity, the source of such information is a third > party (even though both peers have an active connection with this > third party) and doesn't quite stand up to the very reason of > including access control in IPSec (The IPsec firewall function makes > use of the cryptographically-enforced authentication and integrity > provided for all IPsec traffic to offer better access control than > could be obtained through use of a firewall (one not privy to IPsec > internal parameters) plus separate cryptographic protection.) - this > is a case of the information not even privy to the same device, leave > alone the same layer in the same device. OK, this paragraph shows that you do understand the importance of the internal firewall in an IPsec implementation. I'm not asserting that ADVPN is better or worse in this regard. I just happened to be alerted to the issue by the DMVPN message from Mike. I'm equally disappointed with any proposal that essentially eliminates the access control feature ;-) . Steve --------------090504070603040402040800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Manish,
Hi Stephen,

Thanks for your inputs  vis-a-vis  4301/2/3. I concur that IPSec is not just about encryption but don't quite buy into what somebody spelled out during the meeting as 'IPSec is an access control mechanism that also provides other security services'; IMO, strict access control is more a firewall functionality. RFC 4301 spells out the access control rationale as
"IPsec includes a specification for minimal firewall functionality, since that is an essential aspect of access control at the IP layer… The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection."

You cited one of several sentences that mention access control in 4301, in Section 2.1.  Other quotes, very close to the one you chose, make a stronger case for access control as an important element of IPsec:

   The set of

   security services offered includes access control, connectionless

   integrity, data origin authentication, detection and rejection of

   replays (a form of partial sequence integrity), confidentiality (via

      encryption), and limited traffic flow confidentiality.

and

   The IPsec firewall function makes use of the

   cryptographically-enforced authentication and integrity provided for

   all IPsec traffic to offer better access control than could be

   obtained through use of a firewall (one not privy to IPsec internal

   parameters) plus separate cryptographic protection.


This second quote notes that a separate firewall, operating at the Internet layer, is
NOT as secure as the one integrated into IPsec.

I know that we might have ruffled a few feathers wrt making the SPD relatively trivial but let's get down to some details as far as the comparison goes. The first ADVPN proposal does talk about the shortcut suggester possibly including traffic selectors in the shortcut exchange. While this seems to give the notion of the ability to provide SA granularity, the source of such information is a third party (even though both peers have an active connection with this third party) and doesn't quite stand up to the very reason of including access control in IPSec (The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection.) - this is a case of the information not even privy to the same device, leave alone the same layer in the same device.
OK, this paragraph shows that you do understand the importance of the internal firewall in an IPsec implementation. I'm not asserting that ADVPN is better or worse in this regard. I just happened to be alerted to the issue by the DMVPN message from Mike. I'm equally disappointed with any proposal that essentially eliminates the access control feature ;-) .

Steve
--------------090504070603040402040800-- From manishkr@cisco.com Tue Nov 5 15:44:56 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D7121E80D9 for ; Tue, 5 Nov 2013 15:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.069 X-Spam-Level: X-Spam-Status: No, score=-10.069 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjCPxyUMgYLP for ; Tue, 5 Nov 2013 15:44:45 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6CB21E80AF for ; Tue, 5 Nov 2013 15:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10902; q=dns/txt; s=iport; t=1383695085; x=1384904685; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=2DVdBra0/ppdGfSIrmAd0a0PHpeap/BsKPlSkrk+Bh0=; b=L1XzdWf0M236rILA9P8wUP7HHidl4PTcojtFGSg6v7GasxWmetHRXrU2 YhEPqCdNoualCbkz9+MXO+Z2m4yZt+Z0kzHOlgM/uyOniDErcCIx9yKFp g2PrSlGyFTnNyN31CVgRWNRscE8IvaYe9xYCSskOwm/57RXfhwAHANFWr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAFOCeVKtJXHA/2dsb2JhbABZgkNEgQu/R4EmFnSCJQECBC1eAQgRAwECKDkUCQgBAQQBEogBvnCPSBgGhCkDmAqSCYMmgio X-IronPort-AV: E=Sophos;i="4.93,642,1378857600"; d="scan'208,217";a="281177105" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 05 Nov 2013 23:44:40 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA5NieqE011697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 23:44:40 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 17:44:39 -0600 From: "Manish Kumar (manishkr)" To: Stephen Kent , "Mike Sullenberger (mls)" , ipsec Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/cpYuJultjCkmeRXpQLS+S3gAaP8MAAC4FKAAABSDxgP//kQaA Date: Tue, 5 Nov 2013 23:44:39 +0000 Message-ID: In-Reply-To: <52796F7F.7060500@bbn.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.87.135] Content-Type: multipart/alternative; boundary="_000_CE9EBEF79B18manishkrciscocom_" MIME-Version: 1.0 Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:44:58 -0000 --_000_CE9EBEF79B18manishkrciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Steve, To answer your question, the SPD entries are not already there, they are cr= eated as the result of a message exchange between the two spokes; it's the = spokes that choose the policy, not the hub. If the SPDs were already there,= every IPSec node in the network would need to know about all the networks = in the overall topology apriori =96 to solve this is one of the main driver= s of the whole exercise. This becomes even more complex if the hosts (not n= ecessarily an IPSec node) acquire address dynamically and/or are mobile. Thanks, Manish From: Stephen Kent > Date: Wednesday, 6 November 2013 3:51 AM To: Mike Sullenberger >, ipsec > Subject: Re: [IPsec] AD VPN: discussion kick off Mike, Thanks for the responses to my comments, including ones from yesterday's me= eting. Steve, Sorry, I wasn=92t clear on our use of IPsec. We definitely use both the aut= hentication and encryption capabilities of IPsec. We do the following when = bringing up a new tunnel. 1. Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer I= P, GRE). 2. ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the IPs= ec/Child encryption SAs. 3. IPsec signals it has authenticated and encryption is ready, the GRE t= unnel is activated. 4. NHRP registration (for spoke-hub) or resolution reply (for final phas= e of spoke-spoke) are sent over the tunnel. 5. Routing is brought up over the spoke-hub tunnels. If a shortcut between two spokes is available, as advised by a hub, that re= quires an SDP entry. Did that entry preexist in the spoke, or was it provis= ioned by a hub in some fashion? If it existed in the spoke, initially, "nor= mal" IPsec operation would cause traffic to that spoke to trigger formation= of an SA to that destination. Can you clarify? As for scaling, we already have DMVPN networks of 10000+ nodes and looking= at building networks of 40000+ nodes. In many cases customers have multiple subnets behind each node, therefore w= ith just IPsec I would need to have multiple SAs/encryption between the sam= e two nodes, even if you are only doing subnet to subnet SPDs. Take the ca= se of two nodes that each have 4 subnets. I could need as many as 16 SAs to= cover all cases. Or even a simpler case between a host (1 local address) = and a node at a data center (say 20 subnets), I would need up to 20 SAs to = cover this. In many of our networks we are asked to support at least 5 (so= metimes 10) subnets per spoke location. That's a helpful clarification. It does not appear to be the sort of enviro= nment that initially seemed to be the focus of this work, e.g., road warrio= rs calling home or home/satellite offices for a moderate size enterprise. As far as IPv4 and IPv6 support, you are correct it would only double the = number of SAs needed, assuming that there are the same number of subnets fo= r IPv4 and IPv6. From what I have seen IPv6 tends to increase the number o= f subnets. I'm glad we're on the same page here. For end-to-end encryption, take the case where a spoke node is a host. Th= en initially the spoke/host will connect to one or more hubs (we recommend = at least 2 for redundancy). Communication between two such connected hosts= would be through the hub and would be two hops (Host1 encrypt-decrypt Hub = encrypt-decrypt Host2). Once the shortcut tunnel is setup then communicatio= n would be direct between the hosts (Host1 encrypt-decrypt Host2). see my question re the shortcut SPD entries. Steve --_000_CE9EBEF79B18manishkrciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2475883C0EA7B14CADF0B86292B52281@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Steve,

To answer your question, the SPD entries are not already there, they a= re created as the result of a message exchange between the two spokes; it's= the spokes that choose the policy, not the hub. If the SPDs were already t= here, every IPSec node in the network would need to know about all the networks in the overall topology apriori = =96 to solve this is one of the main drivers of the whole exercise. This be= comes even more complex if the hosts (not necessarily an IPSec node) acquir= e address dynamically and/or are mobile.

Thanks,
Manish

From: Stephen Kent <kent@bbn.com>
Date: Wednesday, 6 November 2013 3:= 51 AM
To: Mike Sullenberger <mls@cisco.com>, ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] AD VPN: discus= sion kick off

Mike,

Thanks for the responses to my comments, including ones from yesterday's me= eting.
Steve,
 
Sorry, I wasn=92t clear on our use of IPsec. We definitely use both th= e authentication and encryption capabilities of IPsec. We do the following = when bringing up a new tunnel.
  1. Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer IP,= GRE).
  2. ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the = IPsec/Child encryption SAs.
  3. IPsec signals it has authenticated and encryption is ready, the GR= E tunnel is activated.
  4. NHRP registration (for spoke-hub) or resolution reply (for final p= hase of spoke-spoke) are sent over the tunnel.
  5. Routing is brought up over the spoke-hub tunnels.
If a shortcut between two spokes is avail= able, as advised by a hub, that requires an SDP entry. Did that entry preexist in the spoke, or was it provisioned by a hub in some fashion? If it existed in the spoke= , initially, "normal" IPsec operation would cause traffic to that= spoke to trigger formation of an SA to that destination. Can you clarify?<= br>
 A= s for scaling, we already have DMVPN networks of 10000+ nodes and looki= ng at building networks of 40000+ nodes.
In many cases customers have multiple subnets behind each node, theref= ore with just IPsec I would need to have multiple SAs/encryption between th= e same two nodes, even if you are only doing subnet to subnet SPDs.  T= ake the case of two nodes that each have 4 subnets. I could need as many as 16 SAs to cover all cases.  Or eve= n a simpler case between a host (1 local address) and a node at a data cent= er (say 20 subnets), I would need up to 20 SAs to cover this.  In many= of our networks we are asked to support at least 5 (sometimes 10) subnets per spoke location.
That's a = helpful clarification. It does not appear to be the sort= of environment that initially seemed to be the focus of this work, e.g., r= oad warriors calling home or home/satellite offices for a moderate size enterprise.
 A= s far as IPv4 and IPv6 support, you are correct it would only double the nu= mber of SAs needed, assuming that there are the same number of subnets for = IPv4 and IPv6.  From what I have seen IPv6 tends to increase the number of subnets.
I'm glad = we're on the same page here.
 F= or end-to-end encryption, take the case where a spoke node is a host. = Then initially the spoke/host will connect to one or more hubs (we recomme= nd at least 2 for redundancy).  Communication between two such connected hosts would be through the hub and would be two= hops (Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once the shortcut = tunnel is setup then communication would be direct between the hosts (Host1= encrypt-decrypt Host2).
see my question re the shortcut SPD entries.=

Steve
 --_000_CE9EBEF79B18manishkrciscocom_-- From ynir@checkpoint.com Tue Nov 5 15:51:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665DA21F9D87 for ; Tue, 5 Nov 2013 15:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.216 X-Spam-Level: X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHFWaWAa5Duk for ; Tue, 5 Nov 2013 15:51:06 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ABFF121F9F2B for ; Tue, 5 Nov 2013 15:50:42 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA5NoG5E019095; Wed, 6 Nov 2013 01:50:17 +0200 X-CheckPoint: {527982CF-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 01:50:16 +0200 From: Yoav Nir To: Paul Wouters Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: AQHO0DKq3uGh8NKKjkSYLkYxqARjppoQvmOAgAGAJYCABNXjgIAACmKAgAAi0QA= Date: Tue, 5 Nov 2013 23:50:15 +0000 Message-ID: <632249FB-2527-4E2C-85A8-B1DD0F70CC6B@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.11] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <9B8B032483EC774A94563B8E4719F855@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , "Manish Kumar \(manishkr\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:51:12 -0000 On Nov 5, 2013, at 1:45 PM, Paul Wouters wrote: > On Tue, 5 Nov 2013, Manish Kumar (manishkr) wrote: >=20 >> "I don't like that DMVPN does not let http traffic continue to travel vi= a >> HQ's >> virus/trojan/netnanny while RTP takes the shortcut." >>=20 >> While I do appreciate that the following could represent a valid used >> case, it would be inaccurate to say DMVPN doesn't allow this. It does >> allow but not using the IPSec tools; the protocol programming the >> forwarding layer(could be policy based) controls what goes via the hub a= s >> opposed to what goes on the shortcut tunnel. Also, I would see this more >> as a path selection problem more than 'the kind of security treatment a >> certain class of traffic needs' - it's another matter that different pat= hs >> provide different security services/treatment. Since, the network topolo= gy >> information and hence the path that a class of traffic may take is not >> privy to IKE/IPSec, it's only appropriate that a protocol aware about th= is >> takes this call. This is the reason I don't concur with your other comme= nt >> about doing this in IKE. >=20 > Couldn't that policy be exposed in IKE using traffic selectors for port > 80 or 443? In all of the three proposed solutions? Not really. In DMVPN the only selectors are {Gw-IP, GW-IP, Proto=3D47}, bec= ause everything goes through a GRE tunnel.=20 In draft-mao it's IPsec tunnels, but they still use universal selectors and= selecting traffic through a routing protocol.=20 In both cases you can get what you're looking for if you have routing based= on port. It's only in draft-sathyanarayan that you can do that with IPsec = traffic selectors.= From mcr@sandelman.ca Tue Nov 5 16:18:23 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E639711E8125 for ; Tue, 5 Nov 2013 16:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNOJ5jbG8A2E for ; Tue, 5 Nov 2013 16:18:17 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5D621E808F for ; Tue, 5 Nov 2013 16:18:17 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C5D120289; Tue, 5 Nov 2013 20:29:56 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2644663B88; Tue, 5 Nov 2013 19:18:14 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 127FB63AED; Tue, 5 Nov 2013 19:18:14 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <21113.15320.449575.240995@fireball.kivinen.iki.fi> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> <25430.1383672999@sandelman.ca> <21113.15320.449575.240995@fireball.kivinen.iki.fi> 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: Paul Simon , Tero Kivinen Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:18:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > Michael Richardson writes: >> For a given IPsec SA, they want to overwrite/force/set the DSCP to a >> particular value. It will not depend upon the traffic goes into it >> (but, the SPD selectors may quite specificly pick the traffic). > If I think RFC4301 already requires that. I.e. it requires > implementations to be able to map DSCP values to suitable value. If > the sender knows how to pick up suitable DSCP values and they are then > tunneled through the IPsec tunnel, then the receiving GW can use those > to map those values to the suitable values for the other domain. Yes, I did quote the part of 4301 that mandates that it be settable. > I am missing how does the trasmitting this information from SGW to SGW > affect the IPsec processing? I do not think we should use IKE as > transmitting all kind of stuff that other end might be interested in. It does not affect any processing. Who said that it did? The question is, how does the UE know what DSCP to put on the ESP packet? Yes, it could come from another protocol, but which? IKE already did the authentication, and so already established what entity is asking for servic= e. One might statically configure things, but if the UE moves around the exact DSCP might change.=20=20 As David Black pointed out, there might be Diffserv boundaries. In that case, the UE has to put the DSCP appropriate for the network the UE is attached to, and for things to work, there either has to be DSCP rewriting occuring at the diffserv boundary. But, all that matters is that the UE put the DSCP in, the network takes care of the rest.h The gateway might know where the diffserv boundaries are by special knowledge, but there is no reason to need to tell the UE about it. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnmKw4qHRg3pndX9AQJL+QQA70y+un0SSbZmLEEZX52ocKtRtioNdFsc SpmaFoLCeFD/ocC/lj4SodN6MneTnWEF8W8cLB05mEkGXlQn0akQXeSjwJGGZMdK ASkKTF11RW0/cJytDQhnXkR45udYvaSh5cFFPUd+Qfh1JVJ87qTbdvM9Q1GAKIB8 gGggInkogWs= =j+4o -----END PGP SIGNATURE----- --=-=-=-- From kivinen@iki.fi Tue Nov 5 16:23:47 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E36021E808F for ; Tue, 5 Nov 2013 16:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2TbooeDCbFB for ; Tue, 5 Nov 2013 16:23:47 -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 936B411E8125 for ; Tue, 5 Nov 2013 16:23:46 -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 rA60NdaA026672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Nov 2013 02:23:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rA60NdvW004170; Wed, 6 Nov 2013 02:23:39 +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: <21113.35851.639220.396901@fireball.kivinen.iki.fi> Date: Wed, 6 Nov 2013 02:23:39 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Cc: Sean Turner Subject: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:23:47 -0000 While we are working on the ESP, AH, IKEv2, and Architecture documents, I think we should do also the easy ones: - RFC2451 "The ESP CBC-Mode Cipher Algorithms" - RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange" - RFC3948 "UDP Encapsulation of IPsec ESP Packets" None of them has Errata, and they are all widely used, so we should just upgrade them on in place (i.e. no need to get new RFC). -- kivinen@iki.fi From kent@bbn.com Tue Nov 5 19:34:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B99321E8108 for ; Tue, 5 Nov 2013 19:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZNVRQ8hPgpN for ; Tue, 5 Nov 2013 19:34:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9E011E81F8 for ; Tue, 5 Nov 2013 19:34:30 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:50896 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vdtsz-0009i3-Ce; Tue, 05 Nov 2013 22:34:29 -0500 Message-ID: <5279B8C4.5090100@bbn.com> Date: Tue, 05 Nov 2013 22:34:28 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Manish Kumar (manishkr)" , "Mike Sullenberger (mls)" , ipsec References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020008070708020400080907" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 03:34:37 -0000 This is a multi-part message in MIME format. --------------020008070708020400080907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Manish, > Steve, > > To answer your question, the SPD entries are not already there, they > are created as the result of a message exchange between the two > spokes; it's the spokes that choose the policy, not the hub. If the > SPDs were already there, every IPSec node in the network would need to > know about all the networks in the overall topology apriori -- to > solve this is one of the main drivers of the whole exercise. This > becomes even more complex if the hosts (not necessarily an IPSec node) > acquire address dynamically and/or are mobile. So the spokes, while connected through the hub, exchange messages to cause SPD entries to be created. What protocol is used to do this? Steve p.s. please use the correct (vs.the Cisco-preferred?) spelling, i.e., IPsec, vs. IPSec. --------------020008070708020400080907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Manish,
Steve,

To answer your question, the SPD entries are not already there, they are created as the result of a message exchange between the two spokes; it's the spokes that choose the policy, not the hub. If the SPDs were already there, every IPSec node in the network would need to know about all the networks in the overall topology apriori – to solve this is one of the main drivers of the whole exercise. This becomes even more complex if the hosts (not necessarily an IPSec node) acquire address dynamically and/or are mobile.
So the spokes, while connected through the hub, exchange messages to cause SPD entries to be created. What protocol is used to do this?

Steve

p.s. please use the correct (vs.the Cisco-preferred?) spelling, i.e., IPsec, vs. IPSec.
--------------020008070708020400080907-- From yaronf.ietf@gmail.com Tue Nov 5 21:58:56 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7CE11E81C6 for ; Tue, 5 Nov 2013 21:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF0h+zM0X4kT for ; Tue, 5 Nov 2013 21:58:55 -0800 (PST) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66E11E818B for ; Tue, 5 Nov 2013 21:58:54 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id h15so1242034eak.16 for ; Tue, 05 Nov 2013 21:58:54 -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=kMwjLKpd/BErWMF8hhd4AMiPFImtbezKyXECR68X9eQ=; b=ChDEvbnL+DcsgBk64tdhaPPvCLBzghPLGlrKLxvkt1KB4BKrWxDKE/xrguCDI4QnpH 9Xro3LOMLRMKio1qOwf9nwoe+pwjbVESZROq5XMNT5ztEsYNNq54XsBqJhDW9AjQc7gn Yg4rtIu8L3yKWCp/zELProqLs/+pIcDj4ok7q1u9ViMpyTQtQ7xT5m+DTdvAHuRWZD1O 7VDPsGBJqiMQkw3TlukI8ecnqNhnqvQCjmB5kGaGLjv0Hj8V+QmvOtdMDuLjWkEqmCrA LVxz2Wg+4Om9TNnhC9zh5uGH/63rk2QdY4ehTKb5Wpzt3hH9yRCzi2zmzE4va+MkRK7U ttjg== X-Received: by 10.15.76.8 with SMTP id m8mr1208780eey.86.1383717534291; Tue, 05 Nov 2013 21:58:54 -0800 (PST) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id u46sm69715000eep.17.2013.11.05.21.58.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 21:58:53 -0800 (PST) Message-ID: <5279DA9B.70209@gmail.com> Date: Wed, 06 Nov 2013 07:58:51 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tero Kivinen , ipsec@ietf.org References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> In-Reply-To: <21113.35851.639220.396901@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sean Turner Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 05:58:56 -0000 Hi Tero, On 2013-11-06 02:23, Tero Kivinen wrote: > While we are working on the ESP, AH, IKEv2, and Architecture > documents, I think we should do also the easy ones: > > - RFC2451 "The ESP CBC-Mode Cipher Algorithms" This is nominally a generic document, but it's really about a list of specific algorithms, none of which is in wide use today (we are trying to phase out 3DES and in general 64-bit block algorithms). This document is not referenced by RFC 4303. So I don't think we should upgrade it. > - RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for > Internet Key Exchange" Yes, probably. Although crypto recommendations are time-dependent, this RFC describes the actual algorithms and not just their use in IKE. Do we have enough implementations of EC groups to progress RFC 5903? I realize that NSA RFCs are not that popular nowadays... > - RFC3948 "UDP Encapsulation of IPsec ESP Packets" Definitely. > > None of them has Errata, and they are all widely used, so we should > just upgrade them on in place (i.e. no need to get new RFC). > From ynir@checkpoint.com Wed Nov 6 00:24:48 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BF411E8192 for ; Wed, 6 Nov 2013 00:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-Y2HWvEVPBK for ; Wed, 6 Nov 2013 00:24:42 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 466A711E810A for ; Wed, 6 Nov 2013 00:24:42 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA68OZjq003448; Wed, 6 Nov 2013 10:24:35 +0200 X-CheckPoint: {5279FB55-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 10:24:35 +0200 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] Other documents to upgrade to internet standard Thread-Index: AQHO2oZ8uEAlBW3CfEmmLY6/BhxXNpoXk/SAgAAotYA= Date: Wed, 6 Nov 2013 08:24:34 +0000 Message-ID: References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> In-Reply-To: <5279DA9B.70209@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.133] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Sean Turner , Tero Kivinen Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 08:24:48 -0000 On Nov 5, 2013, at 9:58 PM, Yaron Sheffer wrote: >=20 > Do we have enough implementations of EC groups to progress RFC 5903? I re= alize that NSA RFCs are not that popular nowadays=85 How many is "enough"? I have one. Besides, the NSA is very popular nowadays. In fact, where dedicating both t= omorrow's plenary *and* the perpass session to celebrate our appreciation o= f the NSA. Yoav From paulsimon.c@gmail.com Wed Nov 6 00:32:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B3E11E8171 for ; Wed, 6 Nov 2013 00:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAEv0X48-eWh for ; Wed, 6 Nov 2013 00:32:36 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC7421E809B for ; Wed, 6 Nov 2013 00:32:36 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id at1so17199985iec.15 for ; Wed, 06 Nov 2013 00:32:36 -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=KWTeCHJNhtEy4w67IuJ9F8HC7jO+ZwxsrfQQZVzbXcU=; b=TnrurvHC/uArQnRjxcrbb1mogt/ZVQD68Gq6kKSJI+hzQfaQQYgit/smEHIj/HU4A0 emjSYISnWbkxE0+Zqbbz6qN8+fiaLJhMnqBfFMJJ0UXXLmzubFu1NWxiVCqCR1vXgISs HVfLyrbkaEbIPjwuVOtGVFR5SALWb8xDku82PsrAlQLelZFjxy7/rZikVMFKN5ejXZ+N 7evxbV00uUumfzl4rs4rOecSxqYj/ACib+uh8Inqpz4d5qqqay57+zzCR+5BFvLS8D0F Ef6iSQ82eGh5weZ5tE2OTK0lE/11lY0aLzNW+eiR2nDJcvK1YcB3HDcM6AMy/dG+CGAc aqmw== MIME-Version: 1.0 X-Received: by 10.50.23.103 with SMTP id l7mr19293384igf.3.1383726755909; Wed, 06 Nov 2013 00:32:35 -0800 (PST) Received: by 10.64.7.12 with HTTP; Wed, 6 Nov 2013 00:32:35 -0800 (PST) In-Reply-To: <9994.1383697094@sandelman.ca> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> <25430.1383672999@sandelman.ca> <21113.15320.449575.240995@fireball.kivinen.iki.fi> <9994.1383697094@sandelman.ca> Date: Wed, 6 Nov 2013 14:02:35 +0530 Message-ID: From: Paul Simon To: Michael Richardson Content-Type: multipart/alternative; boundary=089e0158aabac0dfc004ea7dfd28 Cc: "" , Tero Kivinen Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 08:32:37 -0000 --089e0158aabac0dfc004ea7dfd28 Content-Type: text/plain; charset=ISO-8859-1 Yes now it is clear that IKE is not supposed to do DSCP negotiation Thanks for the explanations. Richardson's comment. >>> >>>I don't think that they need multiple DSCPs. >>>I think that they simply want to ask the UE to use a particular code point. >>>It seems like a very simple Notification would work fine, and I think that >>>the people doing this are in control of the IKE/IPsec stack on the UE, and >>>the IKE/IPsec stack on the peer, with the intervening network under their >>>influence, but not their control [PAUL] I have gone through RFC 5996 section 3.10.1 notify message types. But could not find a suitable message type to convey dscp information. Can you suggest which notification message should be used here ? Thanks, Paul On Wed, Nov 6, 2013 at 5:48 AM, Michael Richardson wrote: > > Tero Kivinen wrote: > > Michael Richardson writes: > >> For a given IPsec SA, they want to overwrite/force/set the DSCP to a > >> particular value. It will not depend upon the traffic goes into it > >> (but, the SPD selectors may quite specificly pick the traffic). > > > If I think RFC4301 already requires that. I.e. it requires > > implementations to be able to map DSCP values to suitable value. If > > the sender knows how to pick up suitable DSCP values and they are > then > > tunneled through the IPsec tunnel, then the receiving GW can use > those > > to map those values to the suitable values for the other domain. > > Yes, I did quote the part of 4301 that mandates that it be settable. > > > I am missing how does the trasmitting this information from SGW to > SGW > > affect the IPsec processing? I do not think we should use IKE as > > transmitting all kind of stuff that other end might be interested in. > > It does not affect any processing. Who said that it did? > > The question is, how does the UE know what DSCP to put on the ESP packet? > Yes, it could come from another protocol, but which? IKE already did the > authentication, and so already established what entity is asking for > service. > One might statically configure things, but if the UE moves around the exact > DSCP might change. > > As David Black pointed out, there might be Diffserv boundaries. In that > case, the UE has to put the DSCP appropriate for the network the UE is > attached to, and for things to work, there either has to be DSCP rewriting > occuring at the diffserv boundary. But, all that matters is that the UE put > the DSCP in, the network takes care of the rest.h > The gateway might know where the diffserv boundaries are by special > knowledge, but there is no reason to need to tell the UE about it. > > -- > Michael Richardson , Sandelman Software Works > > > --089e0158aabac0dfc004ea7dfd28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes now it is clear that IKE is not supposed to do DS= CP negotiation
Thanks for the explanations.
=A0
<= div>=A0
Richardson's comment.
>>>
>>>I don't think that they need multiple DSCPs.
>>>I think that they simply want to ask the UE to use a particula= r code point.

>>>It seems like a very simple Notification = would work fine, and I think that
>>>the people doing this are= in control of the IKE/IPsec stack on the UE, and
>>>the IKE/IPsec stack on the peer, with the intervening network = under their
>>>influence, but not their control
=A0<= /div>
[PAUL] I=A0have gone through RFC 5996 section 3.10.1 notify messa= ge types.
But could not find a suitable message type to convey dscp information.=
Can you suggest which notification message should be used here ?=
=A0
Thanks,
Paul
=A0
=A0=


On Wed,= Nov 6, 2013 at 5:48 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Tero Kivinen <kivinen@iki.fi> w= rote:
=A0 =A0 > Michael Richardson writes:
=A0 =A0 >> For a given IPsec SA, they want to overwrite/force/set the= DSCP to a
=A0 =A0 >> particular value. =A0It will not depend upon the traffic g= oes into it
=A0 =A0 >> (but, the SPD selectors may quite specificly pick the traf= fic).

=A0 =A0 > If I think RFC4301 already requires that. I.e. it requires
=A0 =A0 > implementations to be able to map DSCP values to suitable valu= e. If
=A0 =A0 > the sender knows how to pick up suitable DSCP values and they = are then
=A0 =A0 > tunneled through the IPsec tunnel, then the receiving GW can u= se those
=A0 =A0 > to map those values to the suitable values for the other domai= n.

Yes, I did quote the part of 4301 that mandates that it be settable.<= br>

=A0 =A0 > I am missing how does the trasmitting this information from SG= W to SGW
=A0 =A0 > affect the IPsec processing? I do not think we should use IKE = as
=A0 =A0 > transmitting all kind of stuff that other end might be interes= ted in.

It does not affect any processing. Who said that it did?

The question is, how does the UE know what DSCP to put on the ESP packet? Yes, it could come from another protocol, but which? =A0IKE already did the=
authentication, and so already established what entity is asking for servic= e.
One might statically configure things, but if the UE moves around the exact=
DSCP might change.

As David Black pointed out, there might be Diffserv boundaries. =A0In that<= br> case, the UE has to put the DSCP appropriate for the network the UE is
attached to, and for things to work, there either has to be DSCP rewriting<= br> occuring at the diffserv boundary. But, all that matters is that the UE put=
the DSCP in, the network takes care of the rest.h
The gateway might know where the diffserv boundaries are by special
knowledge, but there is no reason to need to tell the UE about it.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works



--089e0158aabac0dfc004ea7dfd28-- From manishkr@cisco.com Wed Nov 6 07:53:19 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9030721E812C for ; Wed, 6 Nov 2013 07:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd0HeNRWwUEH for ; Wed, 6 Nov 2013 07:53:14 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id ED01221E80DF for ; Wed, 6 Nov 2013 07:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4258; q=dns/txt; s=iport; t=1383753194; x=1384962794; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=dPSBBD4Mc8/luwS7oDD+hjCl+ngzS2GvLQC66wryQdQ=; b=fqVl85A1c4FtMdhif0tPy/o5+7SqUmTQSz+epht9F4qo+xEHlVjInLo8 VyBqXWSC5354ZKx25aYAQFNY3EqH2MaWwh3Kln9SeC2uM+hvTg5+9Dt20 GrgAHSEY0ZiH2WgNJ+ltztLZPam8IkCT/F8OIqdLZ69f0qxMySL11PI+I U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFADVlelKtJXG+/2dsb2JhbABagkNEgQu/NoEkFnSCJQECBIELAQgEDQMBAig5FAkIAgQBEogBvyKPSBgGhCoDmAySCoMmgio X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208,217";a="281526354" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 06 Nov 2013 15:53:13 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA6FrDGO007445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 15:53:13 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 09:53:12 -0600 From: "Manish Kumar (manishkr)" To: Stephen Kent , "Mike Sullenberger (mls)" , ipsec Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/cpYuJultjCkmeRXpQLS+S3gAaP8MAAC4FKAAABSDxgP//kQaAgADGUgCAAEhIgA== Date: Wed, 6 Nov 2013 15:53:12 +0000 Message-ID: In-Reply-To: <5279B8C4.5090100@bbn.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.65.209] Content-Type: multipart/alternative; boundary="_000_CE9FA21C9C6Fmanishkrciscocom_" MIME-Version: 1.0 Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:53:19 -0000 --_000_CE9FA21C9C6Fmanishkrciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Steve, NHRP is used to resolve the remote peer which serves/owns the address we're= interested in. The information in this resolution culminates in the creati= on of SPD. Manish From: Stephen Kent > Date: Wednesday, 6 November 2013 9:04 AM To: Manish Kumar >, Mike Sull= enberger >, ipsec > Subject: Re: [IPsec] AD VPN: discussion kick off Manish, Steve, To answer your question, the SPD entries are not already there, they are cr= eated as the result of a message exchange between the two spokes; it's the = spokes that choose the policy, not the hub. If the SPDs were already there,= every IPSec node in the network would need to know about all the networks = in the overall topology apriori =96 to solve this is one of the main driver= s of the whole exercise. This becomes even more complex if the hosts (not n= ecessarily an IPSec node) acquire address dynamically and/or are mobile. So the spokes, while connected through the hub, exchange messages to cause = SPD entries to be created. What protocol is used to do this? Steve p.s. please use the correct (vs.the Cisco-preferred?) spelling, i.e., IPsec= , vs. IPSec. --_000_CE9FA21C9C6Fmanishkrciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <184286CB3216274E8298EF7B6BB4A00F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Steve,

NHRP is used to resolve the remote peer which serves/owns the address = we're interested in. The information in this resolution culminates in the c= reation of SPD.

Manish

From: Stephen Kent <kent@bbn.com>
Date: Wednesday, 6 November 2013 9:= 04 AM
To: Manish Kumar <manishkr@cisco.com>, Mike Sullenberger <<= a href=3D"mailto:mls@cisco.com">mls@cisco.com>, ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] AD VPN: discus= sion kick off

Manish,
Steve,

To answer your question, the SPD entries are not already there, they a= re created as the result of a message exchange between the two spokes; it's= the spokes that choose the policy, not the hub. If the SPDs were already t= here, every IPSec node in the network would need to know about all the networks in the overall topology apriori = =96 to solve this is one of the main drivers of the whole exercise. This be= comes even more complex if the hosts (not necessarily an IPSec node) acquir= e address dynamically and/or are mobile.
So the spokes, while connected through the hub, exchange messages to cause = SPD entries to be created. What protocol is used to do this?

Steve

p.s. please use the correct (vs.the Cisco-preferred?) spelling, i.e., IPsec= , vs. IPSec.
 --_000_CE9FA21C9C6Fmanishkrciscocom_-- From kent@bbn.com Wed Nov 6 08:09:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A1021E8141 for ; Wed, 6 Nov 2013 08:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c20s+HwnhVJv for ; Wed, 6 Nov 2013 08:09:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3951B21E8145 for ; Wed, 6 Nov 2013 08:09:45 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:49584 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ve5fs-000Hhp-D9; Wed, 06 Nov 2013 11:09:44 -0500 Message-ID: <527A69C8.2060805@bbn.com> Date: Wed, 06 Nov 2013 11:09:44 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Manish Kumar (manishkr)" , "Mike Sullenberger (mls)" , ipsec References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070908090707020408070602" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:09:51 -0000 This is a multi-part message in MIME format. --------------070908090707020408070602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Manish, > Steve, > > NHRP is used to resolve the remote peer which serves/owns the address > we're interested in. The information in this resolution culminates in > the creation of SPD. So the NHRP interaction creates a new SPD entry as a side effect? This entry is more specific re selector values (for IP addresses), and that causes traffic to trigger an IKE SA for the shortcut route, and then child SAs are created, right? I presume this is new functionality for NHRP (given te age of that RFC), and is viewed as an external management interface to IPsec, for SDP maintenance. Is it safe to assume that the SPD selectors are the same for every NHRP-triggered SA pair? Since (I believe) that NHRP doesn't care about higher layer protocols, and since the SA is transport mode and encapsulating GRE, that means that no transport protocol/port access controls are imposed on the SA, right? Is there a corresponding management mechanism, tied to NHRP, to cause these SAs to terminate, or do you rely on the SA lifetime values to time out these shortcut SAs? How are these values managed? Steve --------------070908090707020408070602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Manish,
Steve,

NHRP is used to resolve the remote peer which serves/owns the address we're interested in. The information in this resolution culminates in the creation of SPD.
So the NHRP interaction creates a new SPD entry as a side effect? This entry is
more specific re selector values (for IP addresses), and that causes traffic to trigger
an IKE SA for the shortcut route, and then child SAs are created, right?

I presume this is new functionality for NHRP (given te age of that RFC), and is viewed as
an external management interface to IPsec, for SDP maintenance. Is it safe to assume that
the SPD  selectors are the same for every NHRP-triggered SA pair? Since (I believe) that NHRP
doesn't care about higher layer protocols, and since the SA is transport mode and
encapsulating GRE, that means that no transport protocol/port access controls are imposed on
the SA, right?

Is there a corresponding management mechanism, tied to NHRP, to cause these SAs to
terminate, or do you rely on the SA lifetime values to time out these shortcut SAs?
How are these values managed?

Steve
--------------070908090707020408070602-- From mcr@sandelman.ca Wed Nov 6 09:17:54 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CCD21E812A for ; Wed, 6 Nov 2013 09:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auMgEqjOUCND for ; Wed, 6 Nov 2013 09:17:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 877D221E811B for ; Wed, 6 Nov 2013 09:17:53 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E5AAA202BF; Wed, 6 Nov 2013 13:29:30 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7AB0063B88; Wed, 6 Nov 2013 12:17:44 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6E70063AED; Wed, 6 Nov 2013 12:17:44 -0500 (EST) From: Michael Richardson To: Paul Simon In-Reply-To: References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> <25430.1383672999@sandelman.ca> <21113.15320.449575.240995@fireball.kivinen.iki.fi> <9994.1383697094@sandelman.ca> 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: "" , Tero Kivinen Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:17:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Simon wrote: > Yes now it is clear that IKE is not supposed to do DSCP negotiation > Thanks for the explanations. *negotiation* is the key word. negotiation !=3D notification > [PAUL] I=C2=A0have gone through RFC 5996 section 3.10.1 notify messag= e types. > But could not find a suitable message type to convey dscp information. > Can you suggest which notification message should be used here ? Correct. you'd have to write an ID on a new Notify type. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnp5tYqHRg3pndX9AQLzZwQA5qiOQCv5b7TpbDiCP39c2pBNsNFuDOKx VesaINkZ/RR5kuChWdbh3Qou1f0M0a2jxNONhDzvLnW7ZGsL2K7oYQ00knsefMNz zhvxfpzz1z0Qa3RPfByNlztN56PVIK6DUJ+76iJ/c9vMGEWqyCuRwSpGp0iMVW6t 4Q9UGI5+Xxg= =DRH8 -----END PGP SIGNATURE----- --=-=-=-- From internet-drafts@ietf.org Wed Nov 6 09:55:35 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B5421E808D; Wed, 6 Nov 2013 09:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkpaM44lgT7m; Wed, 6 Nov 2013 09:55:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29511E80D9; Wed, 6 Nov 2013 09:55:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131106175535.12229.39351.idtracker@ietfa.amsl.com> Date: Wed, 06 Nov 2013 09:55:35 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:55:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : IKEv2 Fragmentation Author(s) : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-fragmentation-05.txt Pages : 22 Date : 2013-11-05 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ikev2-fragmentation-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Wed Nov 6 10:01:36 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABAF21E8178 for ; Wed, 6 Nov 2013 10:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4NT3Kt8z6mM for ; Wed, 6 Nov 2013 10:01:30 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AC32F21E814B for ; Wed, 6 Nov 2013 10:01:20 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA6I18AO028334; Wed, 6 Nov 2013 20:01:08 +0200 X-CheckPoint: {527A8270-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 20:01:08 +0200 From: Yoav Nir To: "Manish Kumar (manishkr)" Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/c3uGh8NKKjkSYLkYxqARjpgAJfDoAAC4FKAAABSDxgAAC5EqAAAgGuQAAGczKAAADecCA Date: Wed, 6 Nov 2013 18:01:08 +0000 Message-ID: References: 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.10] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_AF7632B00EE147CF945100FCE892031Fcheckpointcom_" MIME-Version: 1.0 Cc: ipsec , Stephen Kent , "Mike Sullenberger \(mls\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:01:36 -0000 --_000_AF7632B00EE147CF945100FCE892031Fcheckpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Nov 6, 2013, at 7:53 AM, Manish Kumar (manishkr) > wrote: Steve, NHRP is used to resolve the remote peer which serves/owns the address we're= interested in. The information in this resolution culminates in the creati= on of SPD. Manish Hi, Manish Wouldn't it be more correct to say that the side effect of NHRP resolution = creates a PAD entry for the discovered node, and an SPD entry for GRE traff= ic to that newly discovered node? Yoav --_000_AF7632B00EE147CF945100FCE892031Fcheckpointcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0DF0F12D4B722A43B89E01A24830F271@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable
On Nov 6, 2013, at 7:53 AM, Manish Kumar (manishkr) <manishkr@cisco.com> wrote:

Steve,

NHRP is used to resolve the remote peer which serves/owns the address = we're interested in. The information in this resolution culminates in the c= reation of SPD.

Manish

Hi, Manish

Wouldn't it be more correct to say that the side effect of NHRP resolu= tion creates a PAD entry for the discovered node, and an SPD entry for GRE = traffic to that newly discovered node?

Yoav


--_000_AF7632B00EE147CF945100FCE892031Fcheckpointcom_-- From mcr@sandelman.ca Wed Nov 6 10:10:29 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CA521E808D for ; Wed, 6 Nov 2013 10:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv1q8PjNQcH9 for ; Wed, 6 Nov 2013 10:10:28 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1E21E8157 for ; Wed, 6 Nov 2013 10:10:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 54E1C202C4; Wed, 6 Nov 2013 14:22:03 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E50D963B88; Wed, 6 Nov 2013 13:10:17 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D4E4363AED; Wed, 6 Nov 2013 13:10:17 -0500 (EST) From: Michael Richardson To: ipsec In-Reply-To: References: 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: Stephen Kent , "Manish Kumar \(manishkr\)" , "Mike Sullenberger \(mls\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:10:29 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Manish Kumar (manishkr) wrote: > NHRP is used to resolve the remote peer which serves/owns the address > we're=20 > interested in. The information in this resolution culminates in the > creation of=20 > SPD. I think your description is not quite precise enough for SK; so I want to restate this for the list, even though we discussed this at the meeting. The result of the NHRP (which runs inside the GRE/IPsec tunnels) creates a new GRE/IPsec SPD to connect the spokes that have the remote peers. The SPD that gets created does not mention the remote peers, that part is done in the routing algorithm.=20 =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnqGB4qHRg3pndX9AQLnJwP/bqNY9ZCFELBX6P6okhsCd6vOwjovAPzc QsMKc1N7WPo4cjHuLCCTc9zXxtNNK9h52KmaG1wp8lLmTve1Tijix3IMsit9Apad I74srE47jDJyo6rPlGv+mLd+5NZob5cgYPeF4MpR2OvUMxunNZ1NBaeOqe/fxqjT Yx2FCcI+RNo= =q6vT -----END PGP SIGNATURE----- --=-=-=-- From kivinen@iki.fi Wed Nov 6 10:41:32 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3980721E815F for ; Wed, 6 Nov 2013 10:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZNzXWCrWseA for ; Wed, 6 Nov 2013 10:41:31 -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 54D1D21E814D for ; Wed, 6 Nov 2013 10:41:28 -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 rA6IfKxn029407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Nov 2013 20:41:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rA6IfJRW019055; Wed, 6 Nov 2013 20:41:19 +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: <21114.36175.642611.890719@fireball.kivinen.iki.fi> Date: Wed, 6 Nov 2013 20:41:19 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <5279DA9B.70209@gmail.com> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 10 min Cc: ipsec@ietf.org, Sean Turner Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:41:32 -0000 Yaron Sheffer writes: > > - RFC2451 "The ESP CBC-Mode Cipher Algorithms" > > This is nominally a generic document, but it's really about a list of > specific algorithms, none of which is in wide use today (we are trying > to phase out 3DES and in general 64-bit block algorithms). This document > is not referenced by RFC 4303. So I don't think we should upgrade it. True, but it is one of the normative references to the RFC5996, but I agree that if we downgrade 3DES from MUST to MAY, then we skip this one. > > - RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for > > Internet Key Exchange" > > Yes, probably. Although crypto recommendations are time-dependent, this > RFC describes the actual algorithms and not just their use in IKE. Yep. Meaning there is lots of use for these groups. > Do we have enough implementations of EC groups to progress RFC 5903? I > realize that NSA RFCs are not that popular nowadays... No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same IANA values for two different non-interoperable uses of the groups, I cannot say there is enough interoperable use for that RFC. I have recommended everybody not to use them, as you never know if they work, as you do not know if the other end is upgraded to Errata version of 4753 (i.e. RFC5903). Thats why I would not recommend RFC5903 to be upgraded at this time. And there is errata for RFC5903, so it does not go in my category of "Easy, no need to revise document", which was my original list selection criteria. Hmm.. actually I see that both errata entries for the RFC5903 are actually rejected, so perhaps it could still be done inplace. > > - RFC3948 "UDP Encapsulation of IPsec ESP Packets" > > Definitely. -- kivinen@iki.fi From svanru@gmail.com Wed Nov 6 10:58:53 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE25B21E815C for ; Wed, 6 Nov 2013 10:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpU6m80RhmnV for ; Wed, 6 Nov 2013 10:58:53 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 88EFB21E819A for ; Wed, 6 Nov 2013 10:58:50 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id ar20so18725640iec.28 for ; Wed, 06 Nov 2013 10:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:importance; bh=vQk7CtRVRRfBgSt/eGGg6oPW1A8dLXrBLcpxBbuprvY=; b=fGYAFPSx0JbD13zTfxBGGnq06SWz5sLuYnDbMHvQBHvkZtPpwKi4TbzsMfkkmJtn62 0ubNqjSlQFeNyzoKS8znZsw6/dFmidH0b8B+jEZmlufC4WIo9DkHAWSiU89zA+Syv7ol ZxC5Gv/5EUWL/iDYRU/PsGxFT8ym+XNrwBZd55vH1w6SlqBy7aRnrlVu4EVG8rXsAutU LxZKGs+5sTOZUN4JYirCI93bRhJT+o1y8/mqs0Tzd8HUbjnkHs0W6wAFRqvzW2eQH09V mHHsmzo3AQqRqtnLskyzaTGgRVbnzZjr5AxanG9nAX3srfyVhWkxKMzGHaV8q71ogMSb G3zA== X-Received: by 10.42.61.147 with SMTP id u19mr2975364ich.36.1383764330095; Wed, 06 Nov 2013 10:58:50 -0800 (PST) Received: from notebook (dhcp-a4ac.meeting.ietf.org. [31.133.164.172]) by mx.google.com with ESMTPSA id qi3sm619435igc.8.2013.11.06.10.58.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Nov 2013 10:58:49 -0800 (PST) Message-ID: From: "Valery Smyslov" To: References: <20131106175535.12229.39351.idtracker@ietfa.amsl.com> In-Reply-To: <20131106175535.12229.39351.idtracker@ietfa.amsl.com> Date: Wed, 6 Nov 2013 10:58:40 -0800 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3508.205 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3508.205 Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:58:53 -0000 Hi all, I've just posted new version of IKEv2 Fragmentation draft. It addresses comments that were received during WG LC. In particular: 1. More words in introduction regarding the problem. 2. Some text in introduction regarding avoiding IP Fragmentation in IKE in general. 3. PMTU Discovery clarified regarding probe timeouts. 4. More words about why PMTUD is done this way and not another, its applicability and the situations when it may be useful. 4. More words in Security Consideration section about benefits of avoiding IP Fragmentation in IKE. Regards, Valery Smyslov. -----Original Message----- From: internet-drafts@ietf.org Sent: Wednesday, November 6, 2013 9:55 AM To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IKEv2 Fragmentation Author(s) : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-fragmentation-05.txt Pages : 22 Date : 2013-11-05 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From david.black@emc.com Wed Nov 6 10:59:05 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B291921E809D for ; Wed, 6 Nov 2013 10:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udhzgsLxznQF for ; Wed, 6 Nov 2013 10:59:00 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0821E819C for ; Wed, 6 Nov 2013 10:58:55 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA6IwnLb027640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Nov 2013 13:58:51 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com rA6IwnLb027640 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1383764331; bh=kjvdLypMV4ztvgNc0koZZ6KYG2Y=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=vMu7eQxieVUlQmd/eCldYnGiCs2GUGde5wG5RWXcCvBQ3XbG2zn4UUW/ufdbJfRTP gIKp5/1EuttZRabnD4QSUTc67ZdHko4TwQB7UDjGz1NKO9XK17e44WuW5ld6Fsw/mU /eVFV4hyo9mOUbJuvKtJrzpmGYuG1yBgSCniuWkA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com rA6IwnLb027640 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 6 Nov 2013 10:58:40 -0800 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA6IwY14011714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 13:58:35 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Wed, 6 Nov 2013 13:58:34 -0500 From: "Black, David" To: Michael Richardson , Paul Simon Date: Wed, 6 Nov 2013 13:58:32 -0500 Thread-Topic: [IPsec] Query regarding Qos with IKE Thread-Index: Ac7bFELIjwLf6y46TRyCQhJNXpr0lAADYuxQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026AAEBFDE@MX15A.corp.emc.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> <25430.1383672999@sandelman.ca> <21113.15320.449575.240995@fireball.kivinen.iki.fi> <9994.1383697094@sandelman.ca> <19182.1383758264@sandelman.ca> In-Reply-To: <19182.1383758264@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Cc: "" , "Black, David" , Tero Kivinen Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:59:06 -0000 PiBDb3JyZWN0Lg0KPiB5b3UnZCBoYXZlIHRvIHdyaXRlIGFuIElEIG9uIGEgbmV3IE5vdGlmeSB0 eXBlLg0KDQpPciBvbiBhIG5ldyBDb25maWd1cmF0aW9uIEF0dHJpYnV0ZSBpZiB0aGF0J3MgbW9y ZSBhcHByb3ByaWF0ZSAtDQpzZWUgc2VjdGlvbiAzLjE1LjEgb2YgUkZDIDU5OTYuDQoNClRoYW5r cywNCi0tRGF2aWQNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlw c2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YNCj4gTWljaGFlbCBSaWNoYXJkc29uDQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1i ZXIgMDYsIDIwMTMgMTI6MTggUE0NCj4gVG86IFBhdWwgU2ltb24NCj4gQ2M6IDxpcHNlY0BpZXRm Lm9yZz47IFRlcm8gS2l2aW5lbg0KPiBTdWJqZWN0OiBSZTogW0lQc2VjXSBRdWVyeSByZWdhcmRp bmcgUW9zIHdpdGggSUtFDQo+IA0KPiANCj4gUGF1bCBTaW1vbiA8cGF1bHNpbW9uLmNAZ21haWwu Y29tPiB3cm90ZToNCj4gICAgID4gWWVzIG5vdyBpdCBpcyBjbGVhciB0aGF0IElLRSBpcyBub3Qg c3VwcG9zZWQgdG8gZG8gRFNDUCBuZWdvdGlhdGlvbg0KPiAgICAgPiBUaGFua3MgZm9yIHRoZSBl eHBsYW5hdGlvbnMuDQo+IA0KPiAqbmVnb3RpYXRpb24qIGlzIHRoZSBrZXkgd29yZC4NCj4gbmVn b3RpYXRpb24gIT0gbm90aWZpY2F0aW9uDQo+IA0KPiAgICAgPiBbUEFVTF0gScKgaGF2ZSBnb25l IHRocm91Z2ggUkZDIDU5OTYgc2VjdGlvbiAzLjEwLjEgbm90aWZ5IG1lc3NhZ2UgdHlwZXMuDQo+ ICAgICA+IEJ1dCBjb3VsZCBub3QgZmluZCBhIHN1aXRhYmxlIG1lc3NhZ2UgdHlwZSB0byBjb252 ZXkgZHNjcCBpbmZvcm1hdGlvbi4NCj4gICAgID4gQ2FuIHlvdSBzdWdnZXN0IHdoaWNoIG5vdGlm aWNhdGlvbiBtZXNzYWdlIHNob3VsZCBiZSB1c2VkIGhlcmUgPw0KPiANCj4gQ29ycmVjdC4NCj4g eW91J2QgaGF2ZSB0byB3cml0ZSBhbiBJRCBvbiBhIG5ldyBOb3RpZnkgdHlwZS4NCj4gDQo+IA0K PiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRl bG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiANCg0K From yaronf.ietf@gmail.com Wed Nov 6 11:11:36 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0768111E80DE for ; Wed, 6 Nov 2013 11:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXxf35aLYSCT for ; Wed, 6 Nov 2013 11:11:35 -0800 (PST) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0287D21F9D35 for ; Wed, 6 Nov 2013 11:11:26 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id d49so2739048eek.21 for ; Wed, 06 Nov 2013 11:11:26 -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=ZTLLAM6H+5hi7lQbjqokJToz6/H/rSRGFNDGYzlko68=; b=mVOJzbFQFVgjEpDKPGEc2IR9ShcHpfUx1/6Ub6KU5BWXfucYQBfafQ/sGwxjrslNGd 6/cnGZbaz/Axamb5hqqJ9KvR8d0p1ovxjLpHyfnYo1yUwhRRm8vMAdBUwfLWQjZKXq+L e/fqH/XtKbsjQzGcaf7cU0VMMJjNksP+xQ9ITT0TPDurGHn1ClB08eB7AWWLV1feIl8X K2Yx6DVY/7Oc/0lYivnEt/LJ0FownIdfjLPhz1k8kC3V2+bxdVDHg2anq+XKDlbaOLtJ GtdWSPUMz9UO4ZlTlGzB/LFS+NjtdHhtLzu/YZQOWfJqs9vkBnSCYZle66WFBmfA2vd4 DXyw== X-Received: by 10.14.241.74 with SMTP id f50mr5431308eer.29.1383765086159; Wed, 06 Nov 2013 11:11:26 -0800 (PST) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id a6sm77319393eei.10.2013.11.06.11.11.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 11:11:25 -0800 (PST) Message-ID: <527A945B.8050309@gmail.com> Date: Wed, 06 Nov 2013 21:11:23 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Valery Smyslov , ipsec@ietf.org References: <20131106175535.12229.39351.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:11:36 -0000 Valery, thanks for updating the draft! Everyone, if you made any comments during the WG last call, can you please ensure that they are addressed in this latest version. Please send your ack/nack within a week. Thanks, Yaron On 2013-11-06 20:58, Valery Smyslov wrote: > Hi all, > > I've just posted new version of IKEv2 Fragmentation draft. > It addresses comments that were received during WG LC. > > In particular: > 1. More words in introduction regarding the problem. > 2. Some text in introduction regarding avoiding IP Fragmentation in IKE > in general. > 3. PMTU Discovery clarified regarding probe timeouts. > 4. More words about why PMTUD is done this way and not another, > its applicability and the situations when it may be useful. > 4. More words in Security Consideration section about benefits > of avoiding IP Fragmentation in IKE. > > Regards, > Valery Smyslov. > > > > -----Original Message----- From: internet-drafts@ietf.org > Sent: Wednesday, November 6, 2013 9:55 AM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : IKEv2 Fragmentation > Author(s) : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-fragmentation-05.txt > Pages : 22 > Date : 2013-11-05 > > 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 IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Wed Nov 6 18:32:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C8321E80E5 for ; Wed, 6 Nov 2013 18:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T711Fs+TjkWg for ; Wed, 6 Nov 2013 18:32:08 -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 7750311E81A7 for ; Wed, 6 Nov 2013 18:32:06 -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 rA72Ux8X021529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Nov 2013 04:30:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rA72UxNA021311; Thu, 7 Nov 2013 04:30:59 +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: <21114.64354.914023.267513@fireball.kivinen.iki.fi> Date: Thu, 7 Nov 2013 04:30:58 +0200 From: Tero Kivinen To: "Mike Sullenberger \(mls\)" In-Reply-To: <9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0@xmb-aln-x06.cisco.com> References: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> <5278183E.500@bbn.com> <9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0@xmb-aln-x06.cisco.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 16 min Cc: IPsecme WG , Stephen Kent , "draft-detienne-dmvpn@tools.ietf.org" , "Michael Guilford \(mguilfor\)" , Michael Richardson , "Mark Comeadow \(mcomeado\)" , "Stephen Lynn \(stlynn\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 02:32:08 -0000 Mike Sullenberger (mls) writes: > As for scaling, we already have DMVPN networks of 10000+ nodes and > looking at building networks of 40000+ nodes. In many cases > customers have multiple subnets behind each node, therefore with > just IPsec I would need to have multiple SAs/encryption between the > same two nodes, even if you are only doing subnet to subnet SPDs. Why do you need multiple SAs even if there is multiple subnets? IKEv2 allows you to create Child SAs covering multiple subnets in both ends, so you should be able to use just one Child SA as long as the number of subnets is less than few hundred... There is limit of 255 traffic selector per Child SA, but I would except that implementations might not support that high number, but tens of selectors should be ok. > Take the case of two nodes that each have 4 subnets. I could need as > many as 16 SAs to cover all cases. Or even a simpler case between a > host (1 local address) and a node at a data center (say 20 subnets), > I would need up to 20 SAs to cover this. In many of our networks we > are asked to support at least 5 (sometimes 10) subnets per spoke > location. All of those would require one Child SA in IKEv2. If talking about obsolete protocols from the historic times, then you might have needed multiple SAs.... > As far as IPv4 and IPv6 support, you are correct it would only double the > number of SAs needed, assuming that there are the same number of subnets for > IPv4 and IPv6. From what I have seen IPv6 tends to increase the number of > subnets. IPv4 and IPv6 traffic most likely do need separate SAs, as some implementations do things that way, i.e. if you offer both IPv4 and IPv6 addresses in the proposal the other end will narrow it down to include only IPv4 or IPv6 addresses (or it can accept the SA if it understand internally that even if there is both IPv4 and IPv6 address in traffic selector list, that does not mean you can have packets where source address is IPv4 and destination IPv6 :-) -- kivinen@iki.fi From yaronf.ietf@gmail.com Wed Nov 6 23:11:35 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9734211E8245 for ; Wed, 6 Nov 2013 23:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ0VdbhEB1wd for ; Wed, 6 Nov 2013 23:11:35 -0800 (PST) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1E11E8244 for ; Wed, 6 Nov 2013 23:11:34 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id e50so68080eek.18 for ; Wed, 06 Nov 2013 23:11:33 -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=p0hZhR01AeVxuu3AarPWfTIk4OJ2XH8fQAqFIIo7mQU=; b=gn+pvwy9/jEgLtTYCqmHtWQyGPjDbIiGrD8CqweGP4yP29vc4wTxJ3cFJ9WDglrc8N 0YYwREadu1x4gYaFfKtyHgV8UTONyYiaqX0kq6cjV2X/vp5uFd7MxWgLMsKHtdkYJKHE 3hG7bSRjFHAy7kJZD4QFwKH8r5mPlY8jicMwMPzEy3vlouuTsm3lXxPsvUJJl88v0J5M /KGPLVjiY4x1bVn3luXSV4TzNDlqO4XZy/3WGrIsWc6u4J04rou1rZIIrvbw7WDUR/FU XQmFg2qynX+MlWJ+d6ZaBTLSNgHJNBv1/som0aDdPfqQOm0tuBQuYP2l9XnOTenaEyr7 f5mQ== X-Received: by 10.14.224.132 with SMTP id x4mr7737155eep.5.1383808293776; Wed, 06 Nov 2013 23:11:33 -0800 (PST) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id z12sm5496626eev.6.2013.11.06.23.11.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 23:11:33 -0800 (PST) Message-ID: <527B3D23.8060609@gmail.com> Date: Thu, 07 Nov 2013 09:11:31 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tero Kivinen References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> In-Reply-To: <21114.36175.642611.890719@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Sean Turner Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 07:11:35 -0000 > >> Do we have enough implementations of EC groups to progress RFC 5903? I >> realize that NSA RFCs are not that popular nowadays... > > No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same > IANA values for two different non-interoperable uses of the groups, I > cannot say there is enough interoperable use for that RFC. > > I have recommended everybody not to use them, as you never know if > they work, as you do not know if the other end is upgraded to Errata > version of 4753 (i.e. RFC5903). > > Thats why I would not recommend RFC5903 to be upgraded at this time. > And there is errata for RFC5903, so it does not go in my category of > "Easy, no need to revise document", which was my original list > selection criteria. Hmm.. actually I see that both errata entries for > the RFC5903 are actually rejected, so perhaps it could still be done > inplace. > IIRC we published RFC 5903 using the old code points because there was no objection, i.e. no indication that people had deployed pre-errata 4753. Whether this was the right thing to do or not is not very interesting now. So, seeing that people are slowly moving to ECC, I would like some input from the group on whether to progress RFC 5903. We will need to demonstrate implementation experience to do that. Thanks, Yaron From paulsimon.c@gmail.com Thu Nov 7 01:24:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC1A21E80ED for ; Thu, 7 Nov 2013 01:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FItjKNvXCdbr for ; Thu, 7 Nov 2013 01:23:58 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3D20511E8114 for ; Thu, 7 Nov 2013 01:23:58 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so364559iec.20 for ; Thu, 07 Nov 2013 01:23:57 -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=DJ2spAVC/Epv9lE1uD/Cq9kQufYMKuNTJ6evUcaK7aI=; b=clzqjF5w5feL/vcZ3MHj17g1bCTZ8JyqO8MTS9nM5HcfFejbwWCWgq6qvSiGJ4zuGe r2zF3x4MjrYDp7ux1vK8YOB4WRU6dbdbDtCKnO6s7jb/v9x1DZGpEeL8cJLzL3dll4qU uDrpM98Sr+73F3V0+eqKrgJ4wq8L8BSafT9OvKlO0+n2b+uY8i89xhsC7wD+XCnfaTtL 7pifd8AB1lQquUfWOUyXaZw2G6iSgsk7kLRPTjk/zo8VMTpUhVUTIB0MzMSxErC8kZep X5J/jWS2AhxMOo94wfPHSX6p9Ox0ZRfloSGItaSBO7U3HeXo7VY9JmkDTGwS14X826c6 5/Fg== MIME-Version: 1.0 X-Received: by 10.50.17.9 with SMTP id k9mr1264193igd.3.1383816237643; Thu, 07 Nov 2013 01:23:57 -0800 (PST) Received: by 10.64.7.12 with HTTP; Thu, 7 Nov 2013 01:23:57 -0800 (PST) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026AAEBFDE@MX15A.corp.emc.com> References: <4693F1D4-13A1-4CE0-A986-1154D87307ED@checkpoint.com> <647E2BD8-A28B-431D-A710-4F44A1F207E7@checkpoint.com> <31580.1383607089@sandelman.ca> <767FD6FB-D73F-4B38-B408-2F40A03680B7@checkpoint.com> <6FACBED8-2A91-4532-AF3B-8FE065B95CE8@checkpoint.com> <25430.1383672999@sandelman.ca> <21113.15320.449575.240995@fireball.kivinen.iki.fi> <9994.1383697094@sandelman.ca> <19182.1383758264@sandelman.ca> <8D3D17ACE214DC429325B2B98F3AE712026AAEBFDE@MX15A.corp.emc.com> Date: Thu, 7 Nov 2013 14:53:57 +0530 Message-ID: From: Paul Simon To: "Black, David" Content-Type: multipart/alternative; boundary=089e01182a3447d38a04ea92d34f Cc: "" , Michael Richardson , Tero Kivinen Subject: Re: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 09:24:08 -0000 --089e01182a3447d38a04ea92d34f Content-Type: text/plain; charset=ISO-8859-1 ok thank you. I will try notification. On Thu, Nov 7, 2013 at 12:28 AM, Black, David wrote: > > Correct. > > you'd have to write an ID on a new Notify type. > > Or on a new Configuration Attribute if that's more appropriate - > see section 3.15.1 of RFC 5996. > > Thanks, > --David > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of > > Michael Richardson > > Sent: Wednesday, November 06, 2013 12:18 PM > > To: Paul Simon > > Cc: ; Tero Kivinen > > Subject: Re: [IPsec] Query regarding Qos with IKE > > > > > > Paul Simon wrote: > > > Yes now it is clear that IKE is not supposed to do DSCP negotiation > > > Thanks for the explanations. > > > > *negotiation* is the key word. > > negotiation != notification > > > > > [PAUL] I have gone through RFC 5996 section 3.10.1 notify message > types. > > > But could not find a suitable message type to convey dscp > information. > > > Can you suggest which notification message should be used here ? > > > > Correct. > > you'd have to write an ID on a new Notify type. > > > > > > -- > > Michael Richardson , Sandelman Software Works > > > > --089e01182a3447d38a04ea92d34f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
ok thank you. I will try notification.


On Thu, Nov 7, 2013 at 12:2= 8 AM, Black, David <david.black@emc.com> wrote:
> Correct.
> you'd have to write an ID on a new Notify type.

Or on a new Configuration Attribute if that's more appropriate -<= br> see section 3.15.1 of RFC 5996.

Thanks,
--David


> -----Original Message-----
> From: ipsec-bounces@ietf.org= [mailto:ipsec-bounces@ietf.o= rg] On Behalf Of
> Michael Richardson
> Sent: Wednesday, November 06, 2013 12:18 PM
> To: Paul Simon
> Cc: <ipsec@ietf.org>; Tero= Kivinen
> Subject: Re: [IPsec] Query regarding Qos with IKE
>
>
> Paul Simon <paulsimon.c@gmail.com> wrote:
> =A0 =A0 > Yes now it is clear that IKE is not supposed to do DSCP n= egotiation
> =A0 =A0 > Thanks for the explanations.
>
> *negotiation* is the key word.
> negotiation !=3D notification
>
> =A0 =A0 > [PAUL] I=A0have gone through RFC 5996 section 3.10.1 noti= fy message types.
> =A0 =A0 > But could not find a suitable message type to convey dscp= information.
> =A0 =A0 > Can you suggest which notification message should be used= here ?
>
> Correct.
> you'd have to write an ID on a new Notify type.
>
>
> --
> Michael Richardson <mcr+= IETF@sandelman.ca>, Sandelman Software Works
>


--089e01182a3447d38a04ea92d34f-- From Paul_Koning@Dell.com Thu Nov 7 06:47:00 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA31321E820F for ; Thu, 7 Nov 2013 06:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmTcKtv2x5og for ; Thu, 7 Nov 2013 06:46:55 -0800 (PST) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id A018221E8205 for ; Thu, 7 Nov 2013 06:46:55 -0800 (PST) X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="4.93,652,1378875600"; d="scan'208";a="374219554" From: To: Thread-Topic: [IPsec] Other documents to upgrade to internet standard Thread-Index: AQHO24icj/6IitKk60GhvzwDso0hcJoaPeaA Date: Thu, 7 Nov 2013 14:46:52 +0000 Message-ID: References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> In-Reply-To: <527B3D23.8060609@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.216.26] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ipsec@ietf.org, turners@ieca.com, kivinen@iki.fi Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:47:00 -0000 On Nov 7, 2013, at 2:11 AM, Yaron Sheffer wrote: > ... > IIRC we published RFC 5903 using the old code points because there was no= objection, i.e. no indication that people had deployed pre-errata 4753. Wh= ether this was the right thing to do or not is not very interesting now. >=20 > So, seeing that people are slowly moving to ECC, I would like some input = from the group on whether to progress RFC 5903. We will need to demonstrate= implementation experience to do that. "Slowly moving"? I'm not sure they are moving at all. It may be there are= implementations of IPSec/IKE with ECC, but I've never encountered one in t= he wild. paul From ynir@checkpoint.com Thu Nov 7 07:30:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B167621E822F for ; Thu, 7 Nov 2013 07:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzcJz6+dBtux for ; Thu, 7 Nov 2013 07:30:12 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9394B21E821E for ; Thu, 7 Nov 2013 07:29:57 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA7FTOqm000791; Thu, 7 Nov 2013 17:29:25 +0200 X-CheckPoint: {527BB052-2F-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 17:29:24 +0200 From: Yoav Nir To: " " Thread-Topic: [IPsec] Other documents to upgrade to internet standard Thread-Index: AQHO2oZ8uEAlBW3CfEmmLY6/BhxXNpoXk/SAgADVCICAANGagIAAfzoAgAAL4gA= Date: Thu, 7 Nov 2013 15:29:24 +0000 Message-ID: <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.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.20.53] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <38CC30D9C801F34AA062E3D6C735897D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:30:21 -0000 On Nov 7, 2013, at 6:46 AM, wrote: >=20 > On Nov 7, 2013, at 2:11 AM, Yaron Sheffer wrote: >=20 >> ... >> IIRC we published RFC 5903 using the old code points because there was n= o objection, i.e. no indication that people had deployed pre-errata 4753. W= hether this was the right thing to do or not is not very interesting now. >>=20 >> So, seeing that people are slowly moving to ECC, I would like some input= from the group on whether to progress RFC 5903. We will need to demonstrat= e implementation experience to do that. >=20 > "Slowly moving"? I'm not sure they are moving at all. It may be there a= re implementations of IPSec/IKE with ECC, but I've never encountered one in= the wild. Huh? The VPN products from Cisco, Juniper and Check Point support them, as well = as both StrongSwan and OpenSwan. I'm sure there are others as well. Yoav From paul@nohats.ca Thu Nov 7 07:47:06 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EDB21E8125 for ; Thu, 7 Nov 2013 07:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EFLxCnBXIgI for ; Thu, 7 Nov 2013 07:46:59 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0088621F9B21 for ; Thu, 7 Nov 2013 07:46:58 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3dFprZ41m6z7MM; Thu, 7 Nov 2013 10:46:54 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id M3nJscAdD4Be; Thu, 7 Nov 2013 10:46:53 -0500 (EST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 7 Nov 2013 10:46:52 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 1B2EB807CA; Thu, 7 Nov 2013 10:46:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0CDDF800A9; Thu, 7 Nov 2013 10:46:52 -0500 (EST) Date: Thu, 7 Nov 2013 10:46:52 -0500 (EST) From: Paul Wouters To: Yoav Nir In-Reply-To: <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> Message-ID: References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:47:06 -0000 On Thu, 7 Nov 2013, Yoav Nir wrote: >>> So, seeing that people are slowly moving to ECC, I would like some input from the group on whether to progress RFC 5903. We will need to demonstrate implementation experience to do that. >> >> "Slowly moving"? I'm not sure they are moving at all. It may be there are implementations of IPSec/IKE with ECC, but I've never encountered one in the wild. > > Huh? > > The VPN products from Cisco, Juniper and Check Point support them, as well as both StrongSwan and OpenSwan. I'm sure there are others as well. openswan / libreswan do not support ecc at this moment. Paul From ynir@checkpoint.com Thu Nov 7 08:03:28 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542F711E810F for ; Thu, 7 Nov 2013 08:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bOvpNyTgrX2 for ; Thu, 7 Nov 2013 08:03:22 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B469C11E80E6 for ; Thu, 7 Nov 2013 08:03:08 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA7G32dH011557; Thu, 7 Nov 2013 18:03:02 +0200 X-CheckPoint: {527BB834-10-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 18:03:02 +0200 From: Yoav Nir To: Paul Wouters Thread-Topic: [IPsec] Other documents to upgrade to internet standard Thread-Index: AQHO2oZ8uEAlBW3CfEmmLY6/BhxXNpoXk/SAgADVCICAANGagIAAfzoAgAAL4gCAAAThAIAABIQA Date: Thu, 7 Nov 2013 16:03:02 +0000 Message-ID: References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.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.20.53] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <77F8C8B809D1EF42876860EC1B6E0E76@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:03:28 -0000 On Nov 7, 2013, at 7:46 AM, Paul Wouters wrote: > On Thu, 7 Nov 2013, Yoav Nir wrote: >=20 >>>> So, seeing that people are slowly moving to ECC, I would like some inp= ut from the group on whether to progress RFC 5903. We will need to demonstr= ate implementation experience to do that. >>>=20 >>> "Slowly moving"? I'm not sure they are moving at all. It may be there= are implementations of IPSec/IKE with ECC, but I've never encountered one = in the wild. >>=20 >> Huh? >>=20 >> The VPN products from Cisco, Juniper and Check Point support them, as we= ll as both StrongSwan and OpenSwan. I'm sure there are others as well. >=20 > openswan / libreswan do not support ecc at this moment. That's the trouble with open source. You never know which fork. https://rhn.redhat.com/errata/RHEA-2010-0411.html From paul@cypherpunks.ca Thu Nov 7 08:33:09 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544D421E8128 for ; Thu, 7 Nov 2013 08:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM0TlAOLvYyV for ; Thu, 7 Nov 2013 08:33:03 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5359411E81C1 for ; Thu, 7 Nov 2013 08:33:03 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3dFqsn0xlrz7MM; Thu, 7 Nov 2013 11:33:01 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1BtPiPpimnvN; Thu, 7 Nov 2013 11:32:59 -0500 (EST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 7 Nov 2013 11:32:58 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 0396F807CA; Thu, 7 Nov 2013 11:32:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E9238800A9; Thu, 7 Nov 2013 11:32:58 -0500 (EST) Date: Thu, 7 Nov 2013 11:32:58 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: Message-ID: References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:33:09 -0000 On Thu, 7 Nov 2013, Yoav Nir wrote: >> openswan / libreswan do not support ecc at this moment. > > That's the trouble with open source. You never know which fork. > https://rhn.redhat.com/errata/RHEA-2010-0411.html Only the modp groups from RFC 5114 were added, not the ecp groups. Paul From ynir@checkpoint.com Thu Nov 7 09:10:26 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA40121E8219 for ; Thu, 7 Nov 2013 09:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.522 X-Spam-Level: X-Spam-Status: No, score=-10.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iIFe4i055dY for ; Thu, 7 Nov 2013 09:10:19 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DDC5621F9DBD for ; Thu, 7 Nov 2013 09:10:01 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA7H9iBY001269; Thu, 7 Nov 2013 19:09:44 +0200 X-CheckPoint: {527BC7D5-8-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 19:09:43 +0200 From: Yoav Nir To: Paul Wouters Thread-Topic: [IPsec] Other documents to upgrade to internet standard Thread-Index: AQHO2oZ8uEAlBW3CfEmmLY6/BhxXNpoXk/SAgADVCICAANGagIAAfzoAgAAL4gCAAAThAIAABIQAgAAIXQCAAApFgA== Date: Thu, 7 Nov 2013 17:09:42 +0000 Message-ID: <35A30354-B208-46E3-B2A0-E200F30E93A5@checkpoint.com> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.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.20.53] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:10:26 -0000 On Nov 7, 2013, at 8:32 AM, Paul Wouters wrote: > On Thu, 7 Nov 2013, Yoav Nir wrote: >=20 >>> openswan / libreswan do not support ecc at this moment. >>=20 >> That's the trouble with open source. You never know which fork. >> https://rhn.redhat.com/errata/RHEA-2010-0411.html >=20 > Only the modp groups from RFC 5114 were added, not the ecp groups. I stand corrected. From kivinen@iki.fi Thu Nov 7 09:25:57 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E55311E821E for ; Thu, 7 Nov 2013 09:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRt7wwUeUzGP for ; Thu, 7 Nov 2013 09:25:56 -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 A120711E81B6 for ; Thu, 7 Nov 2013 09:25:47 -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 rA7HPY0q026669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Nov 2013 19:25:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rA7HPYxF025748; Thu, 7 Nov 2013 19:25:34 +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: <21115.52493.945545.723877@fireball.kivinen.iki.fi> Date: Thu, 7 Nov 2013 19:25:33 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <527B3D23.8060609@gmail.com> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 16 min Cc: ipsec@ietf.org, Sean Turner Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:25:57 -0000 Yaron Sheffer writes: > IIRC we published RFC 5903 using the old code points because there was > no objection, i.e. no indication that people had deployed pre-errata > 4753. Whether this was the right thing to do or not is not very > interesting now. There was very strong objection, at least from me. http://www.ietf.org/mail-archive/web/ipsec/current/msg05445.html And as I pointed out at that time was that our code for example was changed to use pre errata 4753 because other implementor complained that we did things wrong, so our toolkits are using either pre-errata or post-errata 4753 depending on the version (very old ones use post-errata, then several years for per-errata, and then again post-errata). This was discussed in the email. As an IANA expert I said we are going to allocate new numbers for this, but area directors were against this and they managed to talk me out it (unfortunately, I still think it would have been much better to allocate new numbers). The only comment why keep original numbers was that there was ONE implementation out there that used them, and that implementation would never get updated to include new numbers if we allocated them. I myself considered this as very weak reason, but other people had different opinions. BTW most of this discussion happened face-to-face, not in the mailing list. I did point out at that time, that this will mean that those ECP groups cannot get wide use as people cannot enable them unless they are using exactly same version of IPsec in all of their devices, and I have been recommending to our customers to stay away from thse groups. > So, seeing that people are slowly moving to ECC, I would like some input > from the group on whether to progress RFC 5903. We will need to > demonstrate implementation experience to do that. I am against for RFC5903 going forward as we KNOW there is known implemnetation issues with the groups defined there, and those problems manifest by just causing timeouts during the IKE_AUTH exchange, i.e. there is no proper way to do good fallback. -- kivinen@iki.fi From kivinen@iki.fi Thu Nov 7 09:44:26 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F7C21E8127 for ; Thu, 7 Nov 2013 09:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdHFDqMRSVOe for ; Thu, 7 Nov 2013 09:44:26 -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 84A0321E81CD for ; Thu, 7 Nov 2013 09:44:06 -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 rA7HhckL008699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Nov 2013 19:43:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rA7HhaaC019209; Thu, 7 Nov 2013 19:43:36 +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: <21115.53576.367047.460636@fireball.kivinen.iki.fi> Date: Thu, 7 Nov 2013 19:43:36 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Cc: "" , "" , " " Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:44:26 -0000 Yoav Nir writes: > The VPN products from Cisco, Juniper and Check Point support them, > as well as both StrongSwan and OpenSwan. I'm sure there are others > as well. But which version of their products support which version of the ECC groups? For example I have no idea which version our toolkit, our customers are using in their products, so I cannot know which version of groups they support. I do know that some of them do use very old versions, because there release cycle is very long. So have you actually seen anyone actually using those groups between different vendors? I think quite a lot of our customers still have IKEv1 configured by default, and they have not yet moved to IKEv2 unless they want to use EAP or MOBIKE or something like that which is only supported by IKEv2. -- kivinen@iki.fi From paul@cypherpunks.ca Thu Nov 7 09:53:36 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF2911E80FB for ; Thu, 7 Nov 2013 09:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itzy5DJd6mSR for ; Thu, 7 Nov 2013 09:53:29 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 268EE21E81EA for ; Thu, 7 Nov 2013 09:53:03 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3dFsf35WBtz7P9; Thu, 7 Nov 2013 12:52:59 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 4ikLfmKGv9hg; Thu, 7 Nov 2013 12:52:59 -0500 (EST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 7 Nov 2013 12:52:58 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 675A5807CA; Thu, 7 Nov 2013 12:52:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 59667800A9; Thu, 7 Nov 2013 12:52:59 -0500 (EST) Date: Thu, 7 Nov 2013 12:52:59 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <21115.53576.367047.460636@fireball.kivinen.iki.fi> Message-ID: References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> <21115.53576.367047.460636@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:53:36 -0000 On Thu, 7 Nov 2013, Tero Kivinen wrote: >> The VPN products from Cisco, Juniper and Check Point support them, >> as well as both StrongSwan and OpenSwan. I'm sure there are others >> as well. > > But which version of their products support which version of the ECC > groups? > So have you actually seen anyone actually using those groups between > different vendors? I think quite a lot of our customers still have > IKEv1 configured by default Yes, with 3des-md5 and pfs disabled. Every single time I talk to a sysadmin configuring interop to a Cisco. I don't think it is the vendor's fault. It's that IPsec is too complicated for sysadmins, so the documentation from 15 years ago is still re-used today. Paul From ynir@checkpoint.com Thu Nov 7 09:54:34 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A88111E8149 for ; Thu, 7 Nov 2013 09:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5RW4SdxFHh4 for ; Thu, 7 Nov 2013 09:54:28 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED6921E8140 for ; Thu, 7 Nov 2013 09:54:10 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA7Hqb9V012605; Thu, 7 Nov 2013 19:52:37 +0200 X-CheckPoint: {527BD1E1-E-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 19:52:37 +0200 From: Yoav Nir To: Tero Kivinen Thread-Topic: [IPsec] Other documents to upgrade to internet standard Thread-Index: AQHO2oZ8uEAlBW3CfEmmLY6/BhxXNpoXk/SAgADVCICAANGagIAAfzoAgAAL4gCAACV/AIAAAoCA Date: Thu, 7 Nov 2013 17:52:36 +0000 Message-ID: <8F5BE7F0-2D4F-49EA-88FE-2A18C60C3061@checkpoint.com> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> <21115.53576.367047.460636@fireball.kivinen.iki.fi> In-Reply-To: <21115.53576.367047.460636@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.53] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:54:36 -0000 On Nov 7, 2013, at 9:43 AM, Tero Kivinen wrote: > Yoav Nir writes: >> The VPN products from Cisco, Juniper and Check Point support them, >> as well as both StrongSwan and OpenSwan. I'm sure there are others >> as well.=20 >=20 > But which version of their products support which version of the ECC > groups? For example I have no idea which version our toolkit, our > customers are using in their products, so I cannot know which version > of groups they support. I do know that some of them do use very old > versions, because there release cycle is very long. I'm pretty sure that is true for my company's customers as well. > So have you actually seen anyone actually using those groups between > different vendors? Perhaps we should have an interop event. How about the Sunday of the London= meeting? > I think quite a lot of our customers still have > IKEv1 configured by default, and they have not yet moved to IKEv2 > unless they want to use EAP or MOBIKE or something like that which is > only supported by IKEv2. I know our default is IKEv1 and I don't think many of our customers switche= d to IKEv2. Perhaps now they will, because we only support IPv6 with IKEv2. Yoav From fdetienn@cisco.com Fri Nov 8 01:44:02 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFDD11E8192 for ; Fri, 8 Nov 2013 01:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYch0MWOxofp for ; Fri, 8 Nov 2013 01:43:56 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE5911E8162 for ; Fri, 8 Nov 2013 01:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2721; q=dns/txt; s=iport; t=1383903836; x=1385113436; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zxx7wCMPwwOn9neVSeHQFzn1m/QMuUajDbBaimhmhDo=; b=OsRogolFBLdqG6A5yPdDE0fnNoaYITw5Ed+4romCx7wjXHsQxDIAUzf+ D8Sg2PuvdKuDNcv2aUYiXM4q/VY7mRapUFqGXOY1VHr1Mx6d9L9Lq68l7 p1F7mSZDBooPgZ1pzFWg/JhfBtI1CQdX+ubWISJAQ2gGySU1dVXvwjfdj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAPKxfFKtJV2Z/2dsb2JhbABagweBC78UgS0WdIIlAQEBAwE6PwULAgEINhAyJQEBBA4Fh3sGvRSOKYELMweDIIEQA5gPkguDJoFpQQ X-IronPort-AV: E=Sophos;i="4.93,658,1378857600"; d="scan'208";a="282384359" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 08 Nov 2013 09:43:55 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA89hthl008094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 09:43:55 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 03:43:55 -0600 From: "Frederic Detienne (fdetienn)" To: Tero Kivinen Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/ccvJ1By/2h0ikF2yPhA3xNAAaP8MAAC4FKAAAQB7SAABBaOKA Date: Fri, 8 Nov 2013 09:43:54 +0000 Message-ID: References: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> <5278183E.500@bbn.com> <9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0@xmb-aln-x06.cisco.com> <21114.64354.914023.267513@fireball.kivinen.iki.fi> In-Reply-To: <21114.64354.914023.267513@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.74.186] Content-Type: text/plain; charset="us-ascii" Content-ID: <97844B561D312440AFB37119D6A0BB17@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Stephen Kent , "draft-detienne-dmvpn@tools.ietf.org" , "Michael Guilford \(mguilfor\)" , Michael Richardson , "Mike Sullenberger \(mls\)" , "Stephen Lynn \(stlynn\)" , "Mark Comeadow \(mcomeado\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 09:44:03 -0000 Hi Tero, yes you are right about the Child SA and definition. I think what Mike had = in mind is that in some platform architectures the selectors have to be exp= anded in TSi x TSr entries which is not very friendly. When we developed the protocol with IKEv1, multiple SA's simply were a no-n= o. When we evaluated IKEv2, the 255 limit was anyway still a problem and we ke= pt tunneling method unchanged. The 255 limit is definitely too short for pr= actical designs. Thanks! fred On 07 Nov 2013, at 03:30, Tero Kivinen wrote: > Mike Sullenberger (mls) writes: >> As for scaling, we already have DMVPN networks of 10000+ nodes and >> looking at building networks of 40000+ nodes. In many cases >> customers have multiple subnets behind each node, therefore with >> just IPsec I would need to have multiple SAs/encryption between the >> same two nodes, even if you are only doing subnet to subnet SPDs. >=20 > Why do you need multiple SAs even if there is multiple subnets? IKEv2 > allows you to create Child SAs covering multiple subnets in both ends, > so you should be able to use just one Child SA as long as the number > of subnets is less than few hundred... There is limit of 255 traffic > selector per Child SA, but I would except that implementations might > not support that high number, but tens of selectors should be ok.=20 >=20 >> Take the case of two nodes that each have 4 subnets. I could need as >> many as 16 SAs to cover all cases. Or even a simpler case between a >> host (1 local address) and a node at a data center (say 20 subnets), >> I would need up to 20 SAs to cover this. In many of our networks we >> are asked to support at least 5 (sometimes 10) subnets per spoke >> location. >=20 > All of those would require one Child SA in IKEv2. If talking about > obsolete protocols from the historic times, then you might have needed > multiple SAs.... >=20 >> As far as IPv4 and IPv6 support, you are correct it would only double th= e >> number of SAs needed, assuming that there are the same number of subnets= for >> IPv4 and IPv6. From what I have seen IPv6 tends to increase the number = of >> subnets. >=20 > IPv4 and IPv6 traffic most likely do need separate SAs, as some > implementations do things that way, i.e. if you offer both IPv4 and > IPv6 addresses in the proposal the other end will narrow it down to > include only IPv4 or IPv6 addresses (or it can accept the SA if it > understand internally that even if there is both IPv4 and IPv6 address > in traffic selector list, that does not mean you can have packets > where source address is IPv4 and destination IPv6 :-) > --=20 > kivinen@iki.fi From fdetienn@cisco.com Fri Nov 8 05:01:19 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163E121E8088 for ; Fri, 8 Nov 2013 05:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w19x2VDKJA70 for ; Fri, 8 Nov 2013 05:01:14 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 385EB11E80FE for ; Fri, 8 Nov 2013 05:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2925; q=dns/txt; s=iport; t=1383915674; x=1385125274; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=afh/gNyVN10y+HHd4AwL+6w0vEhjuWMpZ/H7XEYEDMI=; b=dwPvijLdY/yOv8ktqGuOqzayVC8PEee4iAh1KyvJBqcG3wBPlyj1RzNB c/bZHjaEKU7HxMf1p7MAclUaSmeA8Vrqc+7t9EyFRUlZDrtmnCa767reO I/AT49hYMCzj/Ru/ATw0AXg07eKEceNs8rUTRjn2QBVyL9iBmLguszMP+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAK7ffFKtJXG9/2dsb2JhbABagwc4U78TgS0WdIIlAQEBAwEBAQFrCwULAgEIRicLJQIEDgWHewYNvG0EjzQzB4MggRADmA+SC4Mmgio X-IronPort-AV: E=Sophos;i="4.93,660,1378857600"; d="scan'208";a="282429252" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 08 Nov 2013 13:01:13 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA8D1D3D003926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 13:01:13 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 07:01:13 -0600 From: "Frederic Detienne (fdetienn)" To: Stephen Kent Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/ccvJ1By/2h0ikF2yPhA3xNAAaP8MAAC4FKAAABSDxgAAC5EqAAAgGuQAAGczKAAAAk9IAAF3/cIA= Date: Fri, 8 Nov 2013 13:01:12 +0000 Message-ID: References: <527A69C8.2060805@bbn.com> In-Reply-To: <527A69C8.2060805@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.74.186] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2324CE659A6F33498DAB0FC18C9B59AF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ipsec , "Manish Kumar \(manishkr\)" , "Mike Sullenberger \(mls\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 13:01:19 -0000 On 06 Nov 2013, at 17:09, Stephen Kent wrote: > Manish, >> Steve, >>=20 >> NHRP is used to resolve the remote peer which serves/owns the address we= 're interested in. The information in this resolution culminates in the cre= ation of SPD. > So the NHRP interaction creates a new SPD entry as a side effect? This en= try is > more specific re selector values (for IP addresses), and that causes traf= fic to trigger > an IKE SA for the shortcut route, and then child SAs are created, right? NHRP create a new SPD entry that protects GRE between two spokes. It also c= reates a new GRE tunnel (or a new tunnel endpoint) to that same spoke. NHRP finally creates a prefix in the routing table or a policy that forces = the traffic into that new tunnel. > I presume this is new functionality for NHRP (given te age of that RFC), = and is viewed as=20 > an external management interface to IPsec, for SDP maintenance. Is it saf= e to assume that=20 > the SPD selectors are the same for every NHRP-triggered SA pair? Since (= I believe) that NHRP=20 > doesn't care about higher layer protocols, and since the SA is transport = mode and=20 > encapsulating GRE, that means that no transport protocol/port access cont= rols are imposed on=20 > the SA, right? The selectors are GRE-hostA-hostB and are traffic agnostic. NHRP installs policies that decide the traffic needs to be forwarded (and g= iven to a particular SA). I.e. instead of having IPsec determine the peer after matching specific sel= ectors, the peer is first selected based on a policy (routing table, policy= route=85) and the traffic is then protect with the generic GRE traffic sel= ector leading to host-B. NHRP alone only cares about network prefixes and not traffic types. When we= reach to use cases, we tend to revert to policy routing that would provide= the granularity you are talking about. > Is there a corresponding management mechanism, tied to NHRP, to cause the= se SAs to > terminate, or do you rely on the SA lifetime values to time out these sho= rtcut SAs? > How are these values managed? Both IPsec and NHRP have hold timers. We refresh the entries if they have b= een used before expiration. The IPsec/IKE SA's can be torn down for the same reasons a classical IKE/IP= sec session can be torn down (eg. peer certificate expiry, explicit adminis= trative control, receiving of a delete-notify, liveness checks =85) It is sufficient for one of the entries (NHRP or SA) to disappear to take d= own the other entries. E.g. if the IPsec SA is deleted, the corresponding t= unnel or tunnel endpoint is torn down, the NHRP entries are deleted and the= forwarding policies are removed. regards, fred > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From fdetienn@cisco.com Fri Nov 8 05:02:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89EE11E80FE for ; Fri, 8 Nov 2013 05:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s76CcLo5BxDc for ; Fri, 8 Nov 2013 05:02:16 -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 ED4F621E809C for ; Fri, 8 Nov 2013 05:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=908; q=dns/txt; s=iport; t=1383915736; x=1385125336; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JUUegtEuq1Yj7AkXjph+ZATZjktUzoRKIPDl+6dGCRA=; b=AwwzX6wHVH4gl1lJCVbunIxGS2aUIjc4f6EDTHrMMkEw0UQu+sGAfEIR SJdP5A2DfKt7qKrtZN/UzBXcTZrURinZui1KlYX0C6oTWHfReDubEoID+ tJFQKrZlR/GmdeC1wOqaDESp5Bk+pzC3bL3Pv8xmU63z2dLRrPzZKZD1S I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFABvgfFKtJXG+/2dsb2JhbABagwc4U78TgS0WdIIlAQEBAwEBAQFrCwULAgEIDgouJwslAgQOBYd7Bg28agSPNDMHgyCBEAOYD5ILgyaCKg X-IronPort-AV: E=Sophos;i="4.93,660,1378857600"; d="scan'208";a="282220842" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 08 Nov 2013 13:02:15 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA8D2FkD003125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 13:02:15 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 07:02:15 -0600 From: "Frederic Detienne (fdetienn)" To: Yoav Nir Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/ccvJ1By/2h0ikF2yPhA3xNAAaP8MAAC4FKAAABSDxgAAC5EqAAAgGuQAAGczKAAAEd9AAAFok1QA= Date: Fri, 8 Nov 2013 13:02:14 +0000 Message-ID: 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.186] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ipsec , "Mike Sullenberger \(mls\)" , "Manish Kumar \(manishkr\)" , Stephen Kent Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 13:02:21 -0000 On 06 Nov 2013, at 19:01, Yoav Nir wrote: >=20 > On Nov 6, 2013, at 7:53 AM, Manish Kumar (manishkr) = wrote: >=20 >> Steve, >>=20 >> NHRP is used to resolve the remote peer which serves/owns the address we= 're interested in. The information in this resolution culminates in the cre= ation of SPD. >>=20 >> Manish >=20 > Hi, Manish >=20 > Wouldn't it be more correct to say that the side effect of NHRP resolutio= n creates a PAD entry for the discovered node, and an SPD entry for GRE tra= ffic to that newly discovered node? that is one of seeing it. I think it is correct. It depends on the point of= view but from an IPsec point of view, this is the net effect. fred > Yoav >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From fdetienn@cisco.com Fri Nov 8 05:05:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B64F11E8147 for ; Fri, 8 Nov 2013 05:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgjJFkuzEcAx for ; Fri, 8 Nov 2013 05:05:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8E421E80D8 for ; Fri, 8 Nov 2013 05:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1450; q=dns/txt; s=iport; t=1383915931; x=1385125531; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0szndFEVBaIAjg7H/8qgzq3EwWeun/cUbDV21cVPh3I=; b=KvxrWZ9JE5Bq5eCWQHalFQA5X9Iu46hq2YZa7CeOmNFj0w5H3nLPWwcB f1cbUJSDg+dR75m7HhYBJ7mqW1MHoczK4MF6vFOYS+CGNYbz5tqBYGhRZ NjCuTrBNgD0seftQTPstm3RXHOJJ02NrQUjDQO0Q1fCGuzFYyX0bRyaBQ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAF7gfFKtJV2a/2dsb2JhbABagwc4U78TgS0WdIIlAQEBAwEBAQE3NAsQAgEIGB4QJwslAgQOBYd7Bg28agSPNDMHgyCBEAOYD5ILgyaCKg X-IronPort-AV: E=Sophos;i="4.93,660,1378857600"; d="scan'208";a="279421447" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 08 Nov 2013 13:05:29 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA8D5Tup007965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 13:05:29 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 07:05:28 -0600 From: "Frederic Detienne (fdetienn)" To: Michael Richardson Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/ccvJ1By/2h0ikF2yPhA3xNAAaP8MAAC4FKAAABSDxgAAC5EqAAAgGuQAAGczKAAAEyZ+AAFnvyYA= Date: Fri, 8 Nov 2013 13:05:27 +0000 Message-ID: References: <30352.1383761417@sandelman.ca> In-Reply-To: <30352.1383761417@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.74.186] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ipsec , "Mike Sullenberger \(mls\)" , Stephen Kent , "Manish Kumar \(manishkr\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 13:05:52 -0000 X-List-Received-Date: Fri, 08 Nov 2013 13:05:52 -0000 On 06 Nov 2013, at 19:10, Michael Richardson wrote: >=20 > Manish Kumar (manishkr) wrote: >> NHRP is used to resolve the remote peer which serves/owns the address >> we're=20 >> interested in. The information in this resolution culminates in the >> creation of=20 >> SPD. >=20 > I think your description is not quite precise enough for SK; so I want to > restate this for the list, even though we discussed this at the meeting. >=20 > The result of the NHRP (which runs inside the GRE/IPsec tunnels) creates = a > new GRE/IPsec SPD to connect the spokes that have the remote peers. >=20 > The SPD that gets created does not mention the remote peers, that part is > done in the routing algorithm.=20 this is another way of doing it. Technically, we create a full fledged SA (protecting GRE hostA hostB) but t= he selection of the remote host is done before the SPD lookup. We first det= ermine the host (forwarding algorithm) and then we pass the packet to the S= A for that specific host. I think Yoav's view of calling is a PAD more accurately describes our imple= mentation but we do not mandate an implementation. thx, fred > --=20 > Michael Richardson , Sandelman Software Works=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From fdetienn@cisco.com Fri Nov 8 05:06:33 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71BC21E80C9 for ; Fri, 8 Nov 2013 05:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.089 X-Spam-Level: X-Spam-Status: No, score=-10.089 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNDJ1xei1Vlj for ; Fri, 8 Nov 2013 05:06:15 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5F11E8147 for ; Fri, 8 Nov 2013 05:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13612; q=dns/txt; s=iport; t=1383915970; x=1385125570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4rHYKEeOW9PuS2CeCdLP1bQa2Ia0gd+4q0q1gmdrGHo=; b=l2wDQK9KUx3QHA/QSuGehZRjfx/SMkWgHdqoGVxu0Ply9si/ropJmrF2 In6gGw60GtiY8Ns1sFc7iTTNe/kVpbEE7B2+E/tfCDfMkA9N8j3jUv9dO x5Nrg2MDfY0087cUUNBV2xSwiXVNeMULrxqBSnqQkPwZpbdS1+81q75ha U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFABLhfFKtJV2c/2dsb2JhbABagwc4U78TgS0WdIIlAQEBAwFsDQUHBAIBCBEBAgEBASgHMhQDBggBAQQOBRkCh2AGvHeOHoEWMwcGgxqBEAOULoNhkguDJoFxOQ X-IronPort-AV: E=Sophos;i="4.93,660,1378857600"; d="scan'208";a="282426096" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 08 Nov 2013 13:05:58 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA8D5wVq017987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 13:05:58 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 07:05:58 -0600 From: "Frederic Detienne (fdetienn)" To: Praveen Sathyanarayan Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/ccvJ1By/2h0ikF2yPhA3xNAAVk6WAALtHvgA= Date: Fri, 8 Nov 2013 13:05:57 +0000 Message-ID: <6D1C717E-B42F-41C3-96D0-5BB657100F5F@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.186] Content-Type: text/plain; charset="Windows-1252" Content-ID: <43F48F60BBEEE245ACD8F1F600CBC5B8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Michael Guilford \(mguilfor\)" , "draft-detienne-dmvpn@tools.ietf.org" , "Mark Comeadow \(mcomeado\)" , Michael Richardson , "Mike Sullenberger \(mls\)" , IPsecme WG , "Stephen Lynn \(stlynn\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 13:06:33 -0000 Hi Praveen, I think the discussion has been somewhat use case centric. Like I said, we can take policy information from any source. The routing pr= otocol captures a mindshare in some deployments but it is not the only one. In our last iteration (product called FlexVPN but compliant with the draft = we issued), we also support a prefix exchange mechanism over IKEv2 using co= nfig exchange (INTERNAL_IP4_ADDRESS/MASK and INTERNAL_IP6_ADDRESS/MASK). Th= is turns out to be extremely friendly on the software client (Remote Access= scenario) as well as for branch deployments having less requirements on dy= namic routing. We did not feel it necessary to document this since our proposal supports I= KEv2 entirely as we repeatedly said. I guess we could... The network discovery system based on a different protocol allows decouplin= g from IKE which also means it can be ported to SSL for instance. This means the DMVPN proposal is suitable for both "small branches" (few pr= efixes or even PC client) and extremely large and complex networks alike. regards, fred On 04 Nov 2013, at 20:43, Praveen Sathyanarayan wro= te: > Hi Mike, >=20 > I am not sure when you refer to other proposal, you meant ours as well :-= ). Appreciate your review and feedback.=20 >=20 > You mentioned 4 points that DMVPN is capable of doing that other proposal= falls short. I can speak for our proposal=20 > =95 Routing protocol: Our proposal does not prevent running routing prot= ocol either. You can definitely configuring any of the route protocol that = supports NBMA or P2MP network (example OSPF, RIP, BGP etc). You need to set= up right policies, which will allow routing protocol to exchange routing up= dates and forward the traffic efficiently. Along with Routing protocol supp= ort, it can be deployed without Routing protocol. As an example, this remo= ves requirement of implementing routing protocol on a mobile device, just f= or establishing a shortcut tunnel with other mobile device. > =95 GRE tunneling: In our experience, IPsec tunneling does good job as t= unneling protocol. IPsec provides all required structures and protocol exte= nsions to support it. And as far as non-IP based traffic, our proposal does= not prevent using GRE over IPSec. So if someone wants to use GRE to encap = non-IP packet, they should be able to achieve. > =95 NHRP Layer: NHRP is a nice protocol but that is defined ATM/FR netwo= rk in mind. FYI, Juniper did deploy this protocol to solve Spoke to Spoke = shortcut tunnel with our AutoConnect VPN feature. But our experience is, th= is is nice protocol, but not designed with security in mind. It is a protoc= ol that is not sufficient for IPsec. This does not provide good authentica= tion mechanism nor authorization mechanism. You can change NHRP protocol to= support these Security specific feature, that exactly we did with AutoConn= ect VPN. At Juniper, before we came up with our proposal, we took a step ba= ck, and used our experience with AutoConnect VPN, asked our self, can we so= lve NHRP requirement with IKE. We found out that IKE has everything that wa= s required to solve and NHRP was just hack to use. =20 > =95 IPsec layer: As mentioned by you, IPSec does pretty good job of encr= yption. To add to that, it also does pretty good job of doing tunneling as = well. >=20 > I feel, DMVPN is designed and organized in IOS/Security Gateway architect= ure in mind. Based on the requirements in RFC 7018 and for modern IPsec arc= hitecture requirements (Security Gateway, Mobile devices etc), I feel there= is a requirement for new protocol, which can be solved without any complex= ity that DVMPN or ADS requires. >=20 > Thanks, > Praveen >=20 > From: "Mike Sullenberger (mls)" > Date: Monday, November 4, 2013 at 8:26 AM > To: Michael Richardson > Cc: "Stephen Lynn (stlynn)" , "draft-detienne-dmvpn@too= ls.ietf.org" , "Mark Comeadow (mcomead= o)" , "Mike Sullenberger (mls)" , "Micha= el Guilford (mguilfor)" , IPsecme WG > Subject: Re: [IPsec] AD VPN: discussion kick off >=20 > Michael, > =20 > I would say that DMVPN is much more than a "brilliant hack". Of the thre= e proposals it is the only one that uses layering to create a real VPN with= emphasis on network. The other two proposals are just adding some dynamic = functionality onto a collection of tunnels, but don=92t actually form that = collection into a network. > If we look at the layers (which are based on standard protocols) from top= -down we see: > =95 Routing/forwarding layer over the VPN. This uses standard routing p= rotocols (EIGRP, OSPF, BGP, RIP) to advertise and propagate throughout the = VPN the networks (subnets,=85) that are available through the VPN. If a ne= w IP based routing protocol comes along no changes would be needed in the o= ther layers to support it. Also if more forwarding granularity is needed t= here are standard mechanism to do policy based forwarding, including SDN (o= r SDN like features). These could be implemented without changes to the oth= er layers.=20 > =95 GRE tunneling layer. This provides standards based multi-protocol t= unneling. GRE can tunnel both IPv4, IPv6 and non-IP protocols over the sam= e IPv4 or ipv6 infrastructure transport layer. IPsec doesn't know nor need= to know anything about the passenger protocols and therefore doesn't need = to change. Also in the future if a better standard tunneling protocol come= s along, the GRE layer could be replaced with this new layer with minimal c= hanges to the adjacent layers. > =95 NHRP mapping layer. In any dynamic network there needs to be the eq= uivalent of ARP (like on an Ethernet). When you are talking about a colle= ction of tunnels this ARP like protocol must be a bit more complex. NHRP w= as specifically designed for "tunnel NBMA networks" (ATM, Frame Relay) and = the VPN networks that we are talking about building here are the exact same= thing. So it is best to go with a standard protocol that was specifically = designed for this layer of the network. > =95 IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the cor= rect standard protocol to use. This is what IPsec does really well, encryp= t traffic. The layers above greatly simplifies IPsec's job by presenting to= it the tunnel to encrypt instead of all of the individual protocols/subnet= s/flows that are within the tunnel. The IPsec selectors are now for the tu= nnel, which makes path redundancy and load-balancing doable. IPsec doesn't= deal well with the same set of selectors to encrypt traffic to more than o= ne peer. With DMVPN this is handled at the routing/forwarding and GRE tunn= el layers. > =20 > The other proposals will have to reinvent one or more of these layers, wh= ich will end up being less efficient. There are also specific issues with I= Psec, in particular, IPsec having to deal directly with the data plane flow= s. With 10s of thousands of nodes and perhaps 100s of thousands of network= /subnets reachable via the VPN the number of IPsec selectors across the VPN= would get completely out of hand, especially if each different pair of sub= nets (selector) requires a separate encryption, between the same two nodes.= This doesn=92t even count the fact that in order to run IPv4 and IPv6 bet= ween the same two nodes you have to use at least double the number of selec= tors. Routing protocols are already designed to scale to 100s of thousands = and even millions of routes. So with DMVPN the forwarding and GRE tunneling= of both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec sele= ctor. NHRP for spoke-hub tunnels doesn=92t have to do anything more, routin= g takes care of this. NHRP for shortcut tunnels will have to pass and stor= e (in the routing table) the individual subnets that are to be reachable th= rough the shortcut tunnel, but this is much more lightweight then IPsec doi= ng the same thing, which it would have to do with the other proposals. Als= o, as mentioned above, IPsec is particular bad at supporting redundancy and= load balancing of the same data subnets via different paths, without havin= g to create an IPsec SA per data flow. > =20 > Note, with DMVPN at the routing/forwarding level you can use various stat= ic and dynamic features that =93split-tunnel=94 traffic even down to the sp= ecific application or flow. All without having to deal with possibly thous= ands of negotiated IPsec 5-tuples. By dynamic a mean that application tra= ffic flows can be measured over one path and flow by flow can be redirected= over another path. Since this is done at the routing/forwarding layer the= se are exactly the same mechanisms that are already in use over LAN and phy= sical WAN networks. My point here is that, why reinvent the same mechanism= in IPsec when you don=92t have to and are likely not going to be able to d= o as good a job as a mechanism that was designed just for that specific pur= pose. > =20 > As far as implementation is concerned, there are now at least 3 main vend= ors other than Cisco that claim they have support for DMVPN, and I pretty m= uch believe their claim is likely to be true. Once DMVPN is a standard the= n any differences will be quickly worked out. As for hosts they can join t= he network in one of three ways. > =95 As a non-encrypting node behind a gateway node that supports DMVPN. > =95 As a pure IPsec node connecting into a gateway or hub node and thus = gaining access to the DMVPN, but not able to support direct shortcut tunnel= s. > =95 As a full node, in which case the node would have to support a routi= ng protocol (possibly optional), GRE tunneling, NHRP mapping and IPsec. Of= this list the only new thing is NHRP mapping functionality. There will of = course need to be some additions to the code for the layers to work cleanly= with each other. Many host stacks already have a level of support for the= other three layers (routing, GRE, IPsec). > =20 > As for the draft-mao-ipsecme proposal, I think the ADS is the wrong way t= o go. The ADS is going to be a single point congestion and failure in the = VPN. Even if you have multiple ADSs in the network they will have to all k= eep their databases in sync, which adds more problems when trying to scale = these networks to 10s of thousands of nodes and larger. > =20 > Mike. > =20 > =20 > Mike Sullenberger, DSE > mls@cisco.com .:|:.:|:. > Customer Advocacy CISCO > =20 > =20 > =20 > =20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Michael Richardson > > Sent: Saturday, November 02, 2013 12:18 PM > > To: IPsecme WG > > Subject: Re: [IPsec] AD VPN: discussion kick off > > > > > > {Sorry about that, the email configuration my tablet had a \n in a head= er > > that did not belong} > > > > I have read all three proposals, although I missed the Q&A in Berlin. > > I am looking forward to further Q&A in Berlin. > > > > When I read the NBMA protocol (DMVPN, I think) version what I saw was a > > very brilliant hack that managed to take two code bases (IPsec and ATM) > > that were likely already present in that vendor's firmware and connect > > them. Likely, it took only a few weeks of brilliant hacking, and it wa= s ready > > for customer use. > > > > I find that this solution for anyone else involves the most amount of n= ew > > code, and I think it will the most difficult to support on various mobi= le and > > laptop platforms as it requires new encapsulation modes. > > > > draft-mao-ipsecme is architecturally the closest to me, and I like the = ADS > > idea: it seems that it be implemented without any new kernel code, and = I > > think that if we are trying to get remote warrior and branch office RT= P > > traffic to take a more direct route, then eliminating the need for a m= ore > > network plumbing, and just doing things in IKE is the right answer. (%= ) > > > > I don't like having a new protocol: I want it in IKE. While it can and= should > > run inside the tunnel, I don't see why adding a new port to my IKE daem= on > > makes my life easier. > > > > I *do* like the way that DMVPN uses probe packets to discover the end > > points of the shorter routes, and I would look forward to including tha= t > > mechanism somehow. I don't know how to do that without hacks to the > > data plane, which I'd like to avoid. I can imagine some ways to do thi= s with a > > traceroute process, but it seems kludgy and brittle. (really, that's st= ill > > dataplane, but it's using an existing mechanism) > > > > I don't like that DMVPN does not let http traffic continue to travel vi= a HQ's > > virus/trojan/netnanny while RTP takes the shortcut. > > > > > > (%)- the plumbing might need a way to sample 5-tuple flows to see if th= ere > > is traffic that should be shortcut. However, various schemes to put mor= e > > specific SPD entries in that cause key requests might accomplish this > > without new kernel code. > > > > -- > > Michael Richardson > > -on the road- > > > > -- > > Michael Richardson , Sandelman Software Works > > > =20 > =20 From fdetienn@cisco.com Fri Nov 8 05:10:01 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B0411E81AF for ; Fri, 8 Nov 2013 05:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.295 X-Spam-Level: X-Spam-Status: No, score=-10.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGBQ8XWH2HFo for ; Fri, 8 Nov 2013 05:09:55 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7844F21E80CF for ; Fri, 8 Nov 2013 05:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1191; q=dns/txt; s=iport; t=1383916192; x=1385125792; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3pBJBVEfFeLB5EFdIBi7HFKjoslNUoNSEM34kn1N1wc=; b=JrUDadbiH8B4pyoEte4EGwr9cHsETUFIxUdMDuiTyx9hJOfJYFaAdXwl LozWQjzPZ5ibIQvUB/8teXn6vCD82Q/dXbRHs4bbPK9jt0wK7tf3Ut8gl fB7OhqB7f2sAKj4FxZ2V00ugKWnv6zfbZeC5Iv07lzOUoB9n+DhmV48fX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAD7ifFKtJV2a/2dsb2JhbABagweBC78TgS0WdIIlAQEBAwF5EAIBCEYyJQEBBA4Fh3sGvQePNDMHgyCBEAOJCo8FkguDJoIq X-IronPort-AV: E=Sophos;i="4.93,660,1378857600"; d="scan'208";a="282427354" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 08 Nov 2013 13:09:52 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA8D9qr3015211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 13:09:52 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 07:09:51 -0600 From: "Frederic Detienne (fdetienn)" To: Stephen Kent Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: Ac7Zch/ccvJ1By/2h0ikF2yPhA3xNAAaP8MAAC4FKAAABSDxgACDmGUA Date: Fri, 8 Nov 2013 13:09:51 +0000 Message-ID: <5E782C15-C042-40F1-BB1E-6CB06238B127@cisco.com> References: <9D83DE546CB6DC47A3AE04086FDE35F523FC8E74@xmb-aln-x06.cisco.com> <5278183E.500@bbn.com> <9D83DE546CB6DC47A3AE04086FDE35F523FCAEF0@xmb-aln-x06.cisco.com> <52796F7F.7060500@bbn.com> In-Reply-To: <52796F7F.7060500@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.74.186] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ipsec , "Mike Sullenberger \(mls\)" Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 13:10:01 -0000 Hi Stephen, On 05 Nov 2013, at 23:21, Stephen Kent wrote: >=20 >> As for scaling, we already have DMVPN networks of 10000+ nodes and look= ing at building networks of 40000+ nodes. >> In many cases customers have multiple subnets behind each node, therefor= e with just IPsec I would need to have multiple SAs/encryption between the = same two nodes, even if you are only doing subnet to subnet SPDs. Take the= case of two nodes that each have 4 subnets. I could need as many as 16 SAs= to cover all cases. Or even a simpler case between a host (1 local addres= s) and a node at a data center (say 20 subnets), I would need up to 20 SAs = to cover this. In many of our networks we are asked to support at least 5 = (sometimes 10) subnets per spoke location. > That's a helpful clarification. It does not appear to be the sort of envi= ronment that initially seemed to be the focus of this work, e.g., road warr= iors calling home or home/satellite offices for a moderate size enterprise.= =20 In fact, there are multiple environments in play. From simple networks to c= omplex network. The DMVPN proposal addresses both. regards, fred= From kent@bbn.com Fri Nov 8 09:56:09 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EB311E81E4 for ; Fri, 8 Nov 2013 09:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AZpMg2C2b6p for ; Fri, 8 Nov 2013 09:56:03 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6A49511E8150 for ; Fri, 8 Nov 2013 09:56:03 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:43462 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VeqHq-0006F6-FR for ipsec@ietf.org; Fri, 08 Nov 2013 12:56:02 -0500 Message-ID: <527D25B3.2040104@bbn.com> Date: Fri, 08 Nov 2013 12:56:03 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <527A69C8.2060805@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] AD VPN: discussion kick off X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 17:56:09 -0000 Fred, Thanks for the detailed answers to all of my questions. I look forward to seeing the description of how DMVPN relates to the processing model defined in RFC 4301 (Figures 1, 2, and 3). Steve From paul.hoffman@vpnc.org Sun Nov 10 08:30:55 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB50711E81B8 for ; Sun, 10 Nov 2013 08:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ykBOvMorq45 for ; Sun, 10 Nov 2013 08:30: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 C098B11E81C8 for ; Sun, 10 Nov 2013 08:30:43 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAAGUakO043629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Nov 2013 09:30:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <21114.36175.642611.890719@fireball.kivinen.iki.fi> Date: Sun, 10 Nov 2013 08:30:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E1F107E-76DE-495F-9A3F-484576EEFDA3@vpnc.org> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1822) Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 16:30:56 -0000 On Nov 6, 2013, at 10:41 AM, Tero Kivinen wrote: >> Do we have enough implementations of EC groups to progress RFC 5903? = I=20 >> realize that NSA RFCs are not that popular nowadays... >=20 > No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same > IANA values for two different non-interoperable uses of the groups, I > cannot say there is enough interoperable use for that RFC. Nor can you say that there is *not* enough interoperable use. As others = have pointed out, there are lots implementations, and as far as I have = heard, all current implementations are using RFC 5930. > I have recommended everybody not to use them, as you never know if > they work, as you do not know if the other end is upgraded to Errata > version of 4753 (i.e. RFC5903). That's fine if you want to recommend it; many implementors are ignoring = you and interoperating just fine. On Nov 7, 2013, at 9:25 AM, Tero Kivinen wrote: > As an IANA expert I said we are going to allocate new numbers for > this, but area directors were against this and they managed to talk me > out it (unfortunately, I still think it would have been much better to > allocate new numbers). The only comment why keep original numbers was > that there was ONE implementation out there that used them, and that > implementation would never get updated to include new numbers if we > allocated them. I myself considered this as very weak reason, but > other people had different opinions. BTW most of this discussion > happened face-to-face, not in the mailing list. That may all be true, but it is also irrelevant to whether the RFC = itself should advance. The IANA values are not in question: only the = bits on the wire are covered in the RFCs. The bits on the wire in RFC = 5930 are highly interoperable, as shown by many different = implementations (possibly even yours). Do others in the WG feel that the issues Tero brought up are significant = enough to prevent RFC 5930 from advancing on the standards track? --Paul Hoffman From kivinen@iki.fi Sun Nov 10 10:12:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EF411E81C7 for ; Sun, 10 Nov 2013 10:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6c9cXc-4o9o for ; Sun, 10 Nov 2013 10:12:36 -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 5F0A821F9EF2 for ; Sun, 10 Nov 2013 10:12:35 -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 rAAICXDR018746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Nov 2013 20:12:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rAAICWqY020968; Sun, 10 Nov 2013 20:12:32 +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: <21119.52368.275498.727447@fireball.kivinen.iki.fi> Date: Sun, 10 Nov 2013 20:12:32 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <5E1F107E-76DE-495F-9A3F-484576EEFDA3@vpnc.org> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <5E1F107E-76DE-495F-9A3F-484576EEFDA3@vpnc.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 21 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 18:12:37 -0000 Paul Hoffman writes: > > No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same > > IANA values for two different non-interoperable uses of the groups, I > > cannot say there is enough interoperable use for that RFC. > > Nor can you say that there is *not* enough interoperable use. As > others have pointed out, there are lots implementations, and as far > as I have heard, all current implementations are using RFC 5930. I agree there is enough interoperable implementations, I do not know if they are "widely used". As far as I know people are still using MODP DH groups when they are actually using IKEv2 in the field. > > I have recommended everybody not to use them, as you never know if > > they work, as you do not know if the other end is upgraded to Errata > > version of 4753 (i.e. RFC5903). > > That's fine if you want to recommend it; many implementors are > ignoring you and interoperating just fine. Again I did not recommend implementors not to implement it or fix their code to use RFC5930 way of doing thigs, I was recommending users not to use them unless they are sure all their environment is updated to latest versions (which usually is not the case). You are confusing the "use" vs "implementation" here. There needs to be "widespread deployment and successful operational experience.", and that at least for me would mean that actually would need to use that feature, not just that it might be complied in to the implementation. > That may all be true, but it is also irrelevant to whether the RFC > itself should advance. The IANA values are not in question: only the > bits on the wire are covered in the RFCs. The bits on the wire in > RFC 5930 are highly interoperable, as shown by many different > implementations (possibly even yours). And how does that point there is "successful operational experience" for those groups? When I went through the list of IPsec related standards I used following criteria for it: 1) It is widely implemented 2) It is widely used 3) If document does not have errata, it is easy to upgrade. The RFC6410 lists following ones: (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. (3) There are no unused features in the specification that greatly increase implementation complexity. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. The first one covers my case 1 and 2. My case for 3 is more strict, as (2) only requires there is no errata that would cause implementation to fail. The errata in RFC4753 was definately such, the errata to RFC5903 is not. (3) and (4) should not be problem for it. This for example one reason I do not think we can put some of the other ones forward either. I.e. following ones are standard track, but even if some of them do have enough implementations, I do not think they are used widely enough yet: MOBIKE (4555), ECDSA (4754=>5903), OCSP extensions (4806), AEAD for IKEv2 (5282), redirect (5685), session resumption (5723), EAP only athentication (5998), Quick Crash Detection (6290), High Availibility (6311). > > > Do others in the WG feel that the issues Tero brought up are > significant enough to prevent RFC 5930 from advancing on the > standards track? -- kivinen@iki.fi From paul.hoffman@vpnc.org Sun Nov 10 11:58:39 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D621A21E8141 for ; Sun, 10 Nov 2013 11:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXwdQZ3EGZ3r for ; Sun, 10 Nov 2013 11:58: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 7C6E421E808A for ; Sun, 10 Nov 2013 11:58:38 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAAJwRkA047708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Nov 2013 12:58:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <21119.52368.275498.727447@fireball.kivinen.iki.fi> Date: Sun, 10 Nov 2013 11:58:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <720FB937-2A17-4940-B9F2-DCB2CF1C73AE@vpnc.org> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <5E1F107E-76DE-495F-9A3F-484576EEFDA3@vpnc.org> <21119.52368.275498.727447@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1822) Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 19:58:40 -0000 On Nov 10, 2013, at 10:12 AM, Tero Kivinen wrote: > Paul Hoffman writes: >>> No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the = same >>> IANA values for two different non-interoperable uses of the groups, = I >>> cannot say there is enough interoperable use for that RFC. >>=20 >> Nor can you say that there is *not* enough interoperable use. As >> others have pointed out, there are lots implementations, and as far >> as I have heard, all current implementations are using RFC 5930. >=20 > I agree there is enough interoperable implementations, I do not know > if they are "widely used". As far as I know people are still using > MODP DH groups when they are actually using IKEv2 in the field.=20 Given that you told your customers not to the ECDSA curves, it seems = sensible that you would not hear them saying that they were disagreeing = with you. :-) >>> I have recommended everybody not to use them, as you never know if >>> they work, as you do not know if the other end is upgraded to Errata >>> version of 4753 (i.e. RFC5903). >>=20 >> That's fine if you want to recommend it; many implementors are >> ignoring you and interoperating just fine.=20 >=20 > Again I did not recommend implementors not to implement it or fix > their code to use RFC5930 way of doing thigs, I was recommending users > not to use them unless they are sure all their environment is updated > to latest versions (which usually is not the case). >=20 > You are confusing the "use" vs "implementation" here. No, I'm not. > There needs to > be "widespread deployment and successful operational experience.", and > that at least for me would mean that actually would need to use that > feature, not just that it might be complied in to the implementation. Correct. And some US government installations are seeing both, most = likely because they are requiring it. >> That may all be true, but it is also irrelevant to whether the RFC >> itself should advance. The IANA values are not in question: only the >> bits on the wire are covered in the RFCs. The bits on the wire in >> RFC 5930 are highly interoperable, as shown by many different >> implementations (possibly even yours).=20 >=20 > And how does that point there is "successful operational experience" > for those groups? I didn't say that it did; so, see above. There has been both conformance = and interoperability testing for those curves, and day-to-day = deployment. (Which is more than you can probably show for some of the = two largest MODP groups in RFC 3526, but I think it is fine to leave = them in because there was limited interop testing for them a decade ago = and that's good enough.) --Paul Hoffman= From alejandro@vixur.com Mon Nov 11 04:40:21 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF24911E8168 for ; Mon, 11 Nov 2013 04:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf20RR04VhsX for ; Mon, 11 Nov 2013 04:40:14 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 973A811E80FA for ; Mon, 11 Nov 2013 04:40:13 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id ie18so3152772vcb.23 for ; Mon, 11 Nov 2013 04:40:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=DXtQlx+DWOXMjglwal8jzA9ApvZMkD/7qB8wUDIyzfY=; b=YVom5saYttot03KVNif06U3YZU5xT3bUKFHR+HzjQ/359YFnddgc2qu2f370J7zTFS XzMqID0deSR1FoHobIwuEnuhBhSgW5APZ8h085lzKe9QkZoUi5QIT2IbmpUGV2nMgCyz rS8wBNc4E8eye7j1ok/8eLSJfDFwfpJQ2X39vDokXT+sWM9kMs4o2xnHFaDJMDUf3Gfo 67UaOh5CGLu4Sj2uPU/GU/bAB+5sMcAO7fwaldIxDQvvtHvArukZgQhHzFrSI/uJse/x eA7g5+V7EwT65jWij1uF04zB64/9P1/KGkvmSbFxKjQaR6kdLtwuo5pTNsCGv0eFiir9 2dVQ== X-Gm-Message-State: ALoCoQkHYz0mwptnQirb1bgFD5fc5P6uYvPT2lsJi/TvA9E2362k85cx/YsjurQmp+gWjYslIr2Y X-Received: by 10.58.11.73 with SMTP id o9mr23710736veb.8.1384173612829; Mon, 11 Nov 2013 04:40:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.221.48.5 with HTTP; Mon, 11 Nov 2013 04:39:52 -0800 (PST) X-Originating-IP: [186.55.186.162] From: Alejandro Bovino Date: Mon, 11 Nov 2013 10:39:52 -0200 Message-ID: To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=047d7b2ed3418025e904eae608a6 Subject: [IPsec] connect to VPNC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 12:40:21 -0000 --047d7b2ed3418025e904eae608a6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I=B4m trying to connect to a VPN. The connection should be made this way: the guest located in one server and the host in another. The guest server has VPNC ( vpnc-0.5.3-4.el6.x86_64 ) installed. With this configuration settings: IPSec gateway #.#.#.# IPSec ID ### IPSec secret ### Xauth username ### Xauth password ### IKE Authmode psk local port 0 The server crashes when I run the command 'vpnc'. The debug output ends abruptly with this last two lines: S7 setup_link (phase 2 + main_loop) S7.0 run interface setup script I call the server suuport and they told me there is no log error for VPNC. > "I would recommend running VPNC and directing the error output to a file; > when the server crashes, you can restart it and then view that file to se= e > if there is an error shown there." But can not find a way to direct the output to a file. if anyone could help would be appreciated. --047d7b2ed3418025e904eae608a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, I=B4m trying to connec= t to a VPN.

The connection should = be made this way: the guest located in one server and the host in another.<= /span>
The guest server has VPNC ( vpnc= -0.5.3-4.el6.x86_64 ) installed.
With this configuration settings:

IPSec gateway #.#.#.#
IPSec ID ###
IPSec secret ###
Xaut= h username ###
Xauth password ###
IKE Authmode psk
local port 0
The server crashes when I = run the command 'vpnc'.=A0Th= e debug output ends abruptly=A0with this last two lines:

S7 setup_link (phase 2 + main_loop)
S7.0 run interface setup script

I call the server suuport and they told me there is no log error for VPNC.<= /div>
"I would recommend running VPNC and directing the error output to a fi= le; when the server crashes, you can restart it and then view that file to = see if there is an error shown there."

But can not find a way to direct the output to a file.
=A0
if anyone could help would be appreci= ated.
--047d7b2ed3418025e904eae608a6-- From paul.hoffman@vpnc.org Mon Nov 11 05:58:01 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A069F21F9FA3 for ; Mon, 11 Nov 2013 05:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YTRkCMGiJHC for ; Mon, 11 Nov 2013 05:58:01 -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 DB67621F9E44 for ; Mon, 11 Nov 2013 05:57:40 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rABDvc8H081786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Nov 2013 06:57:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Mon, 11 Nov 2013 05:57:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alejandro Bovino X-Mailer: Apple Mail (2.1822) Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] connect to VPNC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 13:58:01 -0000 Greetings. This mailing list is for the development of the IPsec suite = of protocols, not for tech support for a particular implementation. Your = question is better answered by your vendor or maybe one of the many = general question-and-answer web sites on the Internet. --Paul Hoffman= From andreas.steffen@strongswan.org Tue Nov 12 03:01:38 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D3711E8125 for ; Tue, 12 Nov 2013 03:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CgNA-h+86RF for ; Tue, 12 Nov 2013 03:01:34 -0800 (PST) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by ietfa.amsl.com (Postfix) with ESMTP id D537D11E80F1 for ; Tue, 12 Nov 2013 03:01:33 -0800 (PST) Received: from cl-242.zrh-02.ch.sixxs.net ([2001:1620:f00:f1::2]) by strongswan.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1VgBhI-0007zw-Om; Tue, 12 Nov 2013 11:59:52 +0100 Message-ID: <528209CE.5020607@strongswan.org> Date: Tue, 12 Nov 2013 11:58:22 +0100 From: Andreas Steffen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> In-Reply-To: <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030601010905090909000406" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 11:01:38 -0000 This is a cryptographically signed message in MIME format. --------------ms030601010905090909000406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, speaking for the strongSwan Project I report that we support and frequently use the following algorithms: - RFC 5903: ECP Groups for IKE and IKEv2 - RFC 4754: IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) - RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec ESP ECP, ECDSA and AES-GCM interoperability has been successfully tested multiple times with Microsoft's Vista/Windows 7 IKEv1 Advanced Firewall implementation. Additionally starting with strongSwan 5.1.1, we support - RFC 6932: Brainpool Elliptic Curves for the IKE Group Description Registry as an alternative for the NIST curves. Best regards Andreas On 11/07/2013 04:29 PM, Yoav Nir wrote: >=20 > On Nov 7, 2013, at 6:46 AM, wrote: >=20 >>=20 >> On Nov 7, 2013, at 2:11 AM, Yaron Sheffer >> wrote: >>=20 >>> ... IIRC we published RFC 5903 using the old code points because >>> there was no objection, i.e. no indication that people had >>> deployed pre-errata 4753. Whether this was the right thing to do >>> or not is not very interesting now. >>>=20 >>> So, seeing that people are slowly moving to ECC, I would like >>> some input from the group on whether to progress RFC 5903. We >>> will need to demonstrate implementation experience to do that. >>=20 >> "Slowly moving"? I'm not sure they are moving at all. It may be >> there are implementations of IPSec/IKE with ECC, but I've never >> encountered one in the wild. >=20 > Huh? >=20 > The VPN products from Cisco, Juniper and Check Point support them, as > well as both StrongSwan and OpenSwan. I'm sure there are others as > well. >=20 > Yoav =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D[ITA-HSR]=3D=3D --------------ms030601010905090909000406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMhDCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGSDCCBTCgAwIBAgIDB7KBMA0GCSqGSIb3DQEB CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwOTI4MTIzNDU4 WhcNMTQwOTMwMDMxMjI2WjBYMScwJQYDVQQDDB5hbmRyZWFzLnN0ZWZmZW5Ac3Ryb25nc3dh bi5vcmcxLTArBgkqhkiG9w0BCQEWHmFuZHJlYXMuc3RlZmZlbkBzdHJvbmdzd2FuLm9yZzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJtxLfnUeESAyEiRlISv6pmUjP1uEd/4 18V5rGVcJbAtzuJfHAlJeHyVaqI8aGjwLN2jHxmPVPJfFi0Z3t/bRAK4u7vnfysSJHTqyrYn 9af2sg59CHvVo9fPEbvX7S+8mi1B2hbWUAVhIO0cmqChBku17gmHdWx+t86gp2v4Ku9ztxC7 D/iNodhHRAofm3RWZSy7VI8W8kifDo2aH2PFG3fw5jFHPxzYNL1DR/ENA2VA1io0x5NA78Mx ZpR6Rgz1jsXp3EgSh+xkcNhY2ugDu1/lIxtvey6JD/BgWIHHh2DI/2gb+HFsDrgVo+A4yf3S u/qv6JHapij26OUCLEYkwdsCAwEAAaOCAuQwggLgMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUp4bQ66T4CmiuI9i9 RewQZ8gFWdgwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKQYDVR0RBCIwIIEe YW5kcmVhcy5zdGVmZmVuQHN0cm9uZ3N3YW4ub3JnMIIBTAYDVR0gBIIBQzCCAT8wggE7Bgsr BgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRv IHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBD QSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNv bXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0w K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh c3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQsFAAOCAQEAwrFtQfZk5tTb8e//+hSdJGU7Pfq8k6Ip gpzGWIHwy5h/OKJ9mX/4oXWXxIg5L1iyNX44AbnUBRIr7LxfWsKy1O+SxjlraxmeClKD83fJ bbqFg9f14TpF3KvjQULFvNlJf8mdfjO3JCYeswDw3GBjtWYl49zyqiYYG4ovZ+FcPz38cOUT 6VtAjzVe862tsq1mE86WuxMeEt5rDHSf2BorxN+VbG3R9+5ewcl4P6pxbWYjCooHfg4gcplI qMHaggRZvS9c1p85CT5BTIlcLwf1RZz6/TDgCarGqkQnGKovFSotb/6fafq49C5nAtXkyB9X FDQ7lYoldvA387ATO1FTgjGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0ECAweygTAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMzExMTIxMDU4MjJaMCMGCSqGSIb3DQEJBDEWBBQ5mMcj gZpXdyPaYvxXo2wgKLCmpjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDB7KBMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMHsoEwDQYJKoZIhvcNAQEBBQAEggEAmqME YVRn/ExJL8CKl6L2NvMKx5adr7RzOB0jyre5pP5aKb9RcyQSSwkFVaFRcyh5l3taMVexHiBj jUtmzH/a9ZDjYlGW6uBr6B7g9pdSWRsIYGHjBAPBu4F8DKwJCXEczyr15i0qwuq3TRdZcgQ+ 2e804wPo/N2q9wLnWkCR+EYO6+hGy7Mq+MvMq0UvZeYkoHm8df5QOOoO9eiZlahxFKfZBgqV QuT5L0k6KWSQQCBFiNjaIq1+HxAH34ytA5If1bPbAjMo+B++wEEEbuRH/qJ4xXpkAhKt9Jm9 YkV8QhA1K1t/msTDw9f87j+6kkiZla/gTxOlUYmiaPfJEiWjFQAAAAAAAA== --------------ms030601010905090909000406-- From kivinen@iki.fi Tue Nov 12 07:13:29 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9C911E8178 for ; Tue, 12 Nov 2013 07:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1flZyqkTWYE for ; Tue, 12 Nov 2013 07:13:28 -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 3DC4F11E8121 for ; Tue, 12 Nov 2013 07:13:28 -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 rACFDNV0010423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 17:13:24 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACFDNbO015087; Tue, 12 Nov 2013 17:13:23 +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: <21122.17811.829263.373978@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 17:13:23 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <526141A0.5030206@gmail.com> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <526141A0.5030206@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Cc: ipsec@ietf.org, Valery Smyslov Subject: [IPsec] RFC5996bis editorial change in section 1. Introduction (Was Re: Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:13:29 -0000 [I am now doing these editorial changes, and I will be sending separate emails for each of them, just so I can keep track of what is changed and where, and you can complain if I miss or misinterpret something (but do not complain about missing changes before I send email that I have processed all of the changes).] Yaron Sheffer writes: > By the way, your correction #2 still does not do it IMHO. The sentence > refers to RFC 5996. So: > > "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was > not backward compatible. RFC 5996 revised RFC 4306 to provide a > clarification of IKEv2, making minimum changes to the IKEv2 protocol. > The current document slightly revises RFC 5996 to make it suitable for > progression to Internet Standard." Changed IKEv2 was a change to the IKE protocol that was not backward compatible. In contrast, the current document not only provides a clarification of IKEv2, but makes minimum changes to the IKE protocol. A list of the significant differences between RFC 4306 and RFC 5996 is given in and differences between RFC 5996 and this document is given in . to: IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was not backward compatible. RFC 5996 revised RFC 4306 to provide a clarification of IKEv2, making minimum changes to the IKEv2 protocol. The current document slightly revises RFC 5996 to make it suitable for progression to Internet Standard. A list of the significant differences between RFC 4306 and RFC 5996 is given in and differences between RFC 5996 and this document is given in . -- kivinen@iki.fi From yaronf.ietf@gmail.com Tue Nov 12 07:18:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0952721F9D0A for ; Tue, 12 Nov 2013 07:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuK2pylGMvid for ; Tue, 12 Nov 2013 07:18:11 -0800 (PST) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0756E11E8169 for ; Tue, 12 Nov 2013 07:18:04 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id my12so2298685bkb.38 for ; Tue, 12 Nov 2013 07:18:03 -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=2sQRTsTMJ04ddyYEuPySA9fj3gwF/E/IFCJJQBiRIZU=; b=xw8cO9oodSDE+roo8KtsJyjkycU3IWQI+GOFmpepnhRuhHPHxsQiDAVqL5BzAf0Is/ QhTnfFbxpUDoaBW3eNORASylgfz2qRYPez19rGofd4OqLxLpOvypFUSNeN3XUGloGZk5 Su7GPLuMmyppFFri2jcRn2klRGUyPX9OM4GpbhQqMfHxYq6lKiQ96/O98JnQQvt+NLAJ CLKiPP/u5GaaR+QAd97I2GYKiQfPiXsOG69j+q0MWJ2KiElm7btiJIapv06Ig3oTl9yz aQpayHmvZAcfPUsDwt0DQTLojrwxejmZ0FglWYbe6mv1i84vqnKt0Yk2E3YWkMuPq/Q6 03Nw== X-Received: by 10.204.103.5 with SMTP id i5mr47694bko.176.1384269483175; Tue, 12 Nov 2013 07:18:03 -0800 (PST) Received: from [192.168.201.198] (diup-241-234.inter.net.il. [213.8.241.234]) by mx.google.com with ESMTPSA id l9sm18639824bkg.0.2013.11.12.07.18.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 07:18:02 -0800 (PST) Message-ID: <528246A8.8020009@gmail.com> Date: Tue, 12 Nov 2013 17:18:00 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tero Kivinen References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <526141A0.5030206@gmail.com> <21122.17811.829263.373978@fireball.kivinen.iki.fi> In-Reply-To: <21122.17811.829263.373978@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Valery Smyslov Subject: Re: [IPsec] RFC5996bis editorial change in section 1. Introduction (Was Re: Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:18:12 -0000 Looks good to me. Yaron On 11/12/2013 05:13 PM, Tero Kivinen wrote: > [I am now doing these editorial changes, and I will be sending > separate emails for each of them, just so I can keep track of what is > changed and where, and you can complain if I miss or misinterpret > something (but do not complain about missing changes before I send > email that I have processed all of the changes).] > From kivinen@iki.fi Tue Nov 12 07:57:49 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E685721E827E for ; Tue, 12 Nov 2013 07:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjAmZDX6F10Y for ; Tue, 12 Nov 2013 07:57:49 -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 BECA521E8283 for ; Tue, 12 Nov 2013 07:57:47 -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 rACFviaD004794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 17:57:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACFvilX027994; Tue, 12 Nov 2013 17:57:44 +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: <21122.20472.654531.780862@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 17:57:44 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 43 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 1.6 Requirements Terminology (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:57:50 -0000 Valery Smyslov writes: > 1. Section 1.6 Requirements Terminology is placed far from the begining > of the document and all the requirements words, along with terms > from RFC4301 etc. are used before they are formally introduced. > I don't think it is appropriate for standards track document. > I suggest to move this section before Introduction. We had this discussion twice when we were making RFC5996 ( http://www.ietf.org/mail-archive/web/ipsec/current/msg03051.html and http://www.ietf.org/mail-archive/web/ipsec/current/msg04526.html ). The fist of this emails (Yaron's notes) caused ticket #51 to be opened: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/51 And the resolution for that ticket #51 was closed as "wontfix" and with comments: > There is no other good place to do this without messing up the section > numbering. > > This is too difficult to do well, and it really isn't that important. And I think that same thing holds still. The problem is that there are lots of people who refer to the IKEv2 specification by section numbers, and if we change those that will cause all those references to be invalid, which might cause confusion. For the second email there was much bigger reordering of the sections suggested, and looking at the email exchange people were in favor of it, but then nothing was changed. There is nothing on the list about this, so it might be it was discussed in the IETF meeting. Anyways we decided against this last time, so I will not be doing this change unless I get more support for this from the WG, and I agree with #51 resoluton, that there is no other good place to do this without messing up the section numbers. -- kivinen@iki.fi From svanru@gmail.com Tue Nov 12 07:59:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A3C21E812A for ; Tue, 12 Nov 2013 07:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8VAvz4BVXhk for ; Tue, 12 Nov 2013 07:59:11 -0800 (PST) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8F21E8143 for ; Tue, 12 Nov 2013 07:58:55 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id k4so2951240qaq.14 for ; Tue, 12 Nov 2013 07:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=FQj8MRifutPVBrnfMTwl5lc4zB9E/NqQAKV7nYmyJqQ=; b=TT6eaZ7wTEBkwK3Bt12pJfiTpC4k23Y/iVQ0mF2apdd+eyobcJJ35wuSaZcLV1rksm G2GNDZt2HEiXr81XuOz/R/diTihOdbSkt5zjffrdv6asLoqzEg7ev01DaGBvrIb+/Yfn UqacHMrr/HMSY9GmiQ+lax4ftoUNtXsJ3uHinHIjCbn61fWYfN0cnrhmLjy9UrfHePVV yLS9/5SHvEOqIe/LkJou9R9LU6FF11Lz2NpVoJWChVkfaMtXpKd/eOLhC1I6oZxhWrmY BMTj32/rq6E2H+Hdn0NlnzoHWERb8E79cfjSxIcTdncP91Sf9M1hj08QDwZfrIBqQ1kc hDwA== X-Received: by 10.49.98.100 with SMTP id eh4mr57860636qeb.42.1384271934565; Tue, 12 Nov 2013 07:58:54 -0800 (PST) Received: from notebook (pool-71-125-201-224.nycmny.east.verizon.net. [71.125.201.224]) by mx.google.com with ESMTPSA id r5sm63174575qeh.1.2013.11.12.07.58.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Nov 2013 07:58:54 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Yaron Sheffer" , "Tero Kivinen" References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <526141A0.5030206@gmail.com> <21122.17811.829263.373978@fireball.kivinen.iki.fi> <528246A8.8020009@gmail.com> In-Reply-To: <528246A8.8020009@gmail.com> Date: Tue, 12 Nov 2013 10:58:48 -0500 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3508.205 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3508.205 Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC5996bis editorial change in section 1. Introduction (Was Re: Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:59:12 -0000 Agreed. Valery. -----Original Message----- From: Yaron Sheffer Sent: Tuesday, November 12, 2013 10:18 AM To: Tero Kivinen Cc: Valery Smyslov ; ipsec@ietf.org Subject: Re: RFC5996bis editorial change in section 1. Introduction (Was Re: [IPsec] Editorial changes to RFC5996) Looks good to me. Yaron On 11/12/2013 05:13 PM, Tero Kivinen wrote: > [I am now doing these editorial changes, and I will be sending > separate emails for each of them, just so I can keep track of what is > changed and where, and you can complain if I miss or misinterpret > something (but do not complain about missing changes before I send > email that I have processed all of the changes).] > From yaronf.ietf@gmail.com Tue Nov 12 08:04:21 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A780721E81A6 for ; Tue, 12 Nov 2013 08:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvGMy7uYTitR for ; Tue, 12 Nov 2013 08:04:21 -0800 (PST) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id C151D21E8294 for ; Tue, 12 Nov 2013 08:04:20 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c50so3280592eek.13 for ; Tue, 12 Nov 2013 08:04:20 -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=xQAd7yrRyOgijwNel6eAwxVyvYsBru49Hgm7MDK0Xx8=; b=x3DD41TS9Klc3yKAbW+N9RtfNaekc41RD3un4JIVN672CUNFTAmP2Z7KJpk0hQfljt Z5pvFZfHf/lWy/HAO/fK5PrS4bQuhJ/PbYotFDVPuVXRfp5Ju3F8B8AnWP0kA8UsNtck ySsRR9WVl/h2jELT0oUiwAAlBvOhQUir7yw6g5wNNMxweEzIz57gozKQI4B2SEFEe3Xi QpX/ZgDmG32Biis7tgvpfe8WQkMmpu21uV0qFRuqHvN+tDMRa+jVHxnUkeClpJ/OF/kh oSytET/HRCN6QSOV2m37ImM262Wfr+EDUDUh/lkM4iIX4QZY0X2HMe65GVP7wjPJ1DdH 5X+A== X-Received: by 10.14.108.9 with SMTP id p9mr43140753eeg.8.1384272259834; Tue, 12 Nov 2013 08:04:19 -0800 (PST) Received: from [192.168.198.180] (diup-241-234.inter.net.il. [213.8.241.234]) by mx.google.com with ESMTPSA id s3sm77423593eeo.3.2013.11.12.08.04.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 08:04:19 -0800 (PST) Message-ID: <52825181.7060803@gmail.com> Date: Tue, 12 Nov 2013 18:04:17 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tero Kivinen , Valery Smyslov References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <21122.20472.654531.780862@fireball.kivinen.iki.fi> In-Reply-To: <21122.20472.654531.780862@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC5996bis editorial change in section 1.6 Requirements Terminology (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:04:21 -0000 I agree with Tero's reasoning, even though I raised this issue in the past (and I still think the text is kind of weird). Let's keep changes in this "bis" to the minimum possible. Thanks, Yaron On 2013-11-12 17:57, Tero Kivinen wrote: > Valery Smyslov writes: >> 1. Section 1.6 Requirements Terminology is placed far from the begining >> of the document and all the requirements words, along with terms >> from RFC4301 etc. are used before they are formally introduced. >> I don't think it is appropriate for standards track document. >> I suggest to move this section before Introduction. > > We had this discussion twice when we were making RFC5996 ( > http://www.ietf.org/mail-archive/web/ipsec/current/msg03051.html and > http://www.ietf.org/mail-archive/web/ipsec/current/msg04526.html ). > > The fist of this emails (Yaron's notes) caused ticket #51 to be > opened: > > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/51 > > And the resolution for that ticket #51 was closed as "wontfix" and > with comments: > >> There is no other good place to do this without messing up the section >> numbering. >> From kivinen@iki.fi Tue Nov 12 08:08:15 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F6E11E8203 for ; Tue, 12 Nov 2013 08:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ8YE7bJrWvx for ; Tue, 12 Nov 2013 08:08:15 -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 A57A521E829B for ; Tue, 12 Nov 2013 08:08:06 -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 rACG7wBH009839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 18:07:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACG7wNA007274; Tue, 12 Nov 2013 18:07:58 +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: <21122.21086.696680.556721@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 18:07:58 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 10 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 1.2. The Initial Exchanges (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:08:15 -0000 Valery Smyslov writes: > 3. Page 10. > "HDR contains the Security Parameter Indexes (SPIs), version numbers, > and flags of various sorts." > > Not mentioned Message ID, Exchange Type (and Next Payload and length, > but they are not very important here). I suggest to change: > > "HDR contains the Security Parameter Indexes (SPIs), version numbers, > Type of Exchange, Message ID and flags of various sorts." I was first thinking that Message ID and Exchange Type are not very important here either, but as I noticed that the same section do explain Message ID earlier, and talks about Exchanges even when it does not yet specify how different exchanges are indicated, so I think this addition might clarify things. Changed: HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts. The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE SA. The KE payload sends the initiator's Diffie-Hellman value. Ni is the initiator's nonce. to: HDR contains the Security Parameter Indexes (SPIs), version numbers, Exchange Type, Message ID, and flags of various sorts. The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE SA. The KE payload sends the initiator's Diffie-Hellman value. Ni is the initiator's nonce. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 08:39:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5444511E811B for ; Tue, 12 Nov 2013 08:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hq84Q8HxgHJ for ; Tue, 12 Nov 2013 08:39:17 -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 B62A111E81DB for ; Tue, 12 Nov 2013 08:38:48 -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 rACGcNu8023412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 18:38:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACGcNLm022229; Tue, 12 Nov 2013 18:38:23 +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: <21122.22910.975951.361576@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 18:38:22 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 30 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 1.2. The Initial Exchanges (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:39:20 -0000 Valery Smyslov writes: > 4. Page 11. > "At this point in the negotiation, each party can generate SKEYSEED, > from which all keys are derived for that IKE SA." > > Term SKEYSEED pops up from nowhere. No reference is gived and > even no word is explained what is it all about. First-time readers will > definitely be puzzled. I suggest to change: > > "At this point in the negotiation, each party can generate a quantity > called SKEYSEED (see section 2.14), from which all keys are derived > for that IKE SA." Changed: At this point in the negotiation, each party can generate SKEYSEED, from which all keys are derived for that IKE SA. To: At this point in the negotiation, each party can generate a quantity called SKEYSEED (see ), from which all keys are derived for that IKE SA. -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Nov 12 09:59:38 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0081811E80FA for ; Tue, 12 Nov 2013 09:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHZvUQCSalft for ; Tue, 12 Nov 2013 09:59:37 -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 0038311E80EA for ; Tue, 12 Nov 2013 09:59:36 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rACHxOPZ030048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Nov 2013 10:59:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <8F5BE7F0-2D4F-49EA-88FE-2A18C60C3061@checkpoint.com> Date: Tue, 12 Nov 2013 09:59:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4F0B8002-2D07-4F5E-8D73-48A4B69A785C@vpnc.org> References: <21113.35851.639220.396901@fireball.kivinen.iki.fi> <5279DA9B.70209@gmail.com> <21114.36175.642611.890719@fireball.kivinen.iki.fi> <527B3D23.8060609@gmail.com> <21B30D73-F92B-4C9E-902F-D1A6F0A243F3@checkpoint.com> <21115.53576.367047.460636@fireball.kivinen.iki.fi> <8F5BE7F0-2D4F-49EA-88FE-2A18C60C3061@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1822) Cc: "" Subject: Re: [IPsec] Other documents to upgrade to internet standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:59:38 -0000 On Nov 7, 2013, at 9:52 AM, Yoav Nir wrote: > On Nov 7, 2013, at 9:43 AM, Tero Kivinen > wrote: >=20 >> So have you actually seen anyone actually using those groups between >> different vendors? >=20 > Perhaps we should have an interop event. How about the Sunday of the = London meeting? Tero was probably talking about using them in the wild, not at an = interop event. We have messages saying that vendors have shown interop = among themselves, so an interop event just for this point is overkill, = given the amount of work it takes to organize everyone. --Paul Hoffman= From kivinen@iki.fi Tue Nov 12 10:55:47 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DF811E8140 for ; Tue, 12 Nov 2013 10:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFlipNZWOqDM for ; Tue, 12 Nov 2013 10:55:46 -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 3750B11E8122 for ; Tue, 12 Nov 2013 10:55:44 -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 rACItcFX023073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 20:55:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACItckD028604; Tue, 12 Nov 2013 20:55:38 +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: <21122.31146.72395.590469@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 20:55:38 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 35 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 1.2. The Initial Exchanges (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:55:47 -0000 Valery Smyslov writes: > 5. Page 14, 15 and 16 > "The responder replies (using the same Message ID to respond) with the > accepted offer in an SA payload, and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group." > > "The responder replies (using the same Message ID to respond) with the > accepted offer in an SA payload, and a Diffie-Hellman value in the > KEr payload if the selected cryptographic suite includes that group." > > "The responder replies (using the same Message ID to respond) with the > accepted offer in an SA payload, and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group." > > All three sentencies look like they were copy-pasted and all three > lacks mention Nonce Payload. I think it should be explicitely > mentioned here, as it was mentioned in descriptions of Initiator's message, > above each of this sentencies. I agree on adding the comment about nonce in those copied sections. The reason for copying is because the original section 1.3 in RFC4306 was split 3 ways in RFC5996. > And I also think that words in parentheses here are superfluous, as > this requirement is comon for all exchanges, not only for > CREATE_CHILD_SA, and stated several times in the document. So, I > suggest to change: This was propsed for the RFC5996 already (by me :-) and there was ticket #34 opened for it and the change was not done as it was considered important to keep it there: My original email opening the issue: http://www6.ietf.org/mail-archive/web/ipsec/current/msg02953.html ticket opened by it http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/34 and more of my comments to the issue: http://www6.ietf.org/mail-archive/web/ipsec/current/msg03155.html and I think this caused we to add definition of Message ID in the beginning of section 1.2. > "The responder replies with the accepted offer in an SA payload, > nonce in the Nr payload and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group." > > "The responder replies with the accepted offer in an SA payload, > nonce in the Nr payload and a Diffie-Hellman value in the > KEr payload if the selected cryptographic suite includes that group." > > "The responder replies with the accepted offer in an SA payload, > nonce in the Nr payload and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group." Changed: The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group. ... The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if the selected cryptographic suite includes that group. A new responder SPI is supplied in the SPI field of the SA payload. ... The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group. To: The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, nonce in the Nr payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group. ... The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, nonce in the Nr payload, and a Diffie-Hellman value in the KEr payload if the selected cryptographic suite includes that group. A new responder SPI is supplied in the SPI field of the SA payload. ... The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, nonce in the Nr, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 11:01:48 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4238521E80AC for ; Tue, 12 Nov 2013 11:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvj6YHG84lrG for ; Tue, 12 Nov 2013 11:01:47 -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 62FA921E8093 for ; Tue, 12 Nov 2013 11:01:46 -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 rACJ1iU8002213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 21:01:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACJ1iWA008924; Tue, 12 Nov 2013 21:01:44 +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: <21122.31512.200431.405925@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 21:01:44 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 6 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 1.5 Informational Messages outside of an IKE SA (Was Editorial changes to RFC5996). X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:01:48 -0000 Valery Smyslov writes: > 6. Page 19. > "The recipient of this notification cannot tell > whether the SPI is for AH or ESP, but this is not important because > the SPIs are supposed to be different for the two." > > Why "is supposed to be different"? RFC4301 clearly states: > "For a unicast SA, the SPI can be used by itself to specify an SA, or it > may be > used in conjunction with the IPsec protocol type." > > So I suggest to change as follows: > > "The recipient of this notification cannot tell > whether the SPI is for AH or ESP, but this is not important because > in many cases the SPIs will be different for the two." > > And some words should be added for the case when SPIs are not > different for AH and ESP. I have no good suggestion here. Changed: The recipient of this notification cannot tell whether the SPI is for AH or ESP, but this is not important because the SPIs are supposed to be different for the two. To: The recipient of this notification cannot tell whether the SPI is for AH or ESP, but this is not important because in many cases the SPIs will be different for the two. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 11:09:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C21C21F9F8E for ; Tue, 12 Nov 2013 11:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgE7T3CLW3qX for ; Tue, 12 Nov 2013 11:09:14 -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 D40CE11E814D for ; Tue, 12 Nov 2013 11:08:58 -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 rACJ8up4000944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 21:08:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACJ8udf020538; Tue, 12 Nov 2013 21:08:56 +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: <21122.31944.517406.172616@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 21:08:56 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 7 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 2.6 IKE SA SPIs and Cookies (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:09:14 -0000 Valery Smyslov writes: > 7. Page 31. > Phrase "(see Section 2.6)" actually references the same section. It should > either > be removed or corrected. Changed: In the first message of an initial IKE exchange, the initiator will not know the responder's SPI value and will therefore set that field to zero. When the IKE_SA_INIT exchange does not result in the creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE (see ), the responder's SPI will be zero also in the response message. However, if the responder sends a non-zero responder SPI, the initiator should not reject the response for only that reason. To: In the first message of an initial IKE exchange, the initiator will not know the responder's SPI value and will therefore set that field to zero. When the IKE_SA_INIT exchange does not result in the creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE, the responder's SPI will be zero also in the response message. However, if the responder sends a non-zero responder SPI, the initiator should not reject the response for only that reason. Not sure where it could point, so I removed it. And there you can also see why it is not so easy to see it points to section itself :-) -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 11:13:26 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A9D21F9D46 for ; Tue, 12 Nov 2013 11:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cdsYUH0fMX6 for ; Tue, 12 Nov 2013 11:13:25 -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 37BD421F9BDB for ; Tue, 12 Nov 2013 11:13:25 -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 rACJDLbd018493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 21:13:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACJDLi7005523; Tue, 12 Nov 2013 21:13:21 +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: <21122.32209.736437.529150@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 21:13:21 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 4 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 2.6 IKE SA SPIs and Cookies (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:13:26 -0000 Valery Smyslov writes: > 8. Page 31. > "However, if the responder sends a non-zero > responder SPI, the initiator should not reject the response for only > that reason." > > Should here "should not" be "SHOULD NOT"? If I correctly parsed exchanges in the mailing list concensus was to skip this change? Was my interpretation correct? So currently this change was skipped. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 11:40:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E1E21E812A for ; Tue, 12 Nov 2013 11:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH2JCJWUpMuD for ; Tue, 12 Nov 2013 11:40:50 -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 5777821E8091 for ; Tue, 12 Nov 2013 11:40:41 -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 rACJecRK022082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 21:40:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACJecut027359; Tue, 12 Nov 2013 21:40:38 +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: <21122.33846.638013.396271@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 21:40:38 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 27 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 2.15 Authentication of the IKE SA (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:40:52 -0000 Valery Smyslov writes: > 9. Page 49. > "There are two types of EAP authentication (described in > Section 2.16), and each type uses different values in the AUTH > computations shown above. If the EAP method is key-generating, > substitute master session key (MSK) for the shared secret in the > computation. For non-key-generating methods, substitute SK_pi and > SK_pr, respectively, for the shared secret in the two AUTH > computations." > > Isn't this para superfluous here? Its content belongs to EAP > authentication and in fact it is described in more details two pages > below. That text was added in the draft-ietf-ipsecme-ikev2bis-08 because of the ticket #151: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/151 Because of that I would like to get more feedback from WG before I revert that change. I.e no changes done. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 11:44:05 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E2511E8153 for ; Tue, 12 Nov 2013 11:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrccavwf9YcT for ; Tue, 12 Nov 2013 11:44:04 -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 433B611E814D for ; Tue, 12 Nov 2013 11:44:04 -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 rACJi1VM003632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 21:44:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACJi1SN013495; Tue, 12 Nov 2013 21:44:01 +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: <21122.34049.954552.379947@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 21:44:01 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 2.16 Extensible Authentication Protocol Methods (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:44:05 -0000 Valery Smyslov writes: > 10. Page 51. > "As described in Section 2.2, when EAP is used, each pair of IKE SA > initial setup messages will have their message numbers incremented; > the first pair of AUTH messages will have an ID of 1, the second will > be 2, and so on." > > Should be: > > "As described in Section 2.2, when EAP is used, each pair of IKE SA > initial setup messages will have their message numbers incremented; > the first pair of IKE_AUTH messages will have an ID of 1, the second will > be 2, and so on." Changed: As described in , when EAP is used, each pair of IKE SA initial setup messages will have their message numbers incremented; the first pair of AUTH messages will have an ID of 1, the second will be 2, and so on. To: As described in , when EAP is used, each pair of IKE SA initial setup messages will have their message numbers incremented; the first pair of IKE_AUTH messages will have an ID of 1, the second will be 2, and so on. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 11:49:59 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81C821F9FBA for ; Tue, 12 Nov 2013 11:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFjkWnvzEYEi for ; Tue, 12 Nov 2013 11:49:59 -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 E7D5421F9FB7 for ; Tue, 12 Nov 2013 11:49:58 -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 rACJnuUk015246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 21:49:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACJnuuP014790; Tue, 12 Nov 2013 21:49:56 +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: <21122.34404.323314.332709@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 21:49:56 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 4 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 2.17 Generating Keying Material for Child SAs (Was Editorial changes to RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:49:59 -0000 Valery Smyslov writes: > 11. Page 52: > "A single CHILD_SA negotiation may result in multiple Security > Associations." > > Should be: > > "A single CREATE_CHILD_SA negotiation may result in multiple Security > Associations." Changed: A single CHILD_SA negotiation may result in multiple Security Associations. To: A single CREATE_CHILD_SA negotiation may result in multiple Security Associations. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 11:53:49 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9016911E811B for ; Tue, 12 Nov 2013 11:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9fu5iMYjQm0 for ; Tue, 12 Nov 2013 11:53:49 -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 BF52E21F9EED for ; Tue, 12 Nov 2013 11:53:36 -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 rACJrY5Z024021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 21:53:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACJrYug008640; Tue, 12 Nov 2013 21:53:34 +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: <21122.34622.118634.864403@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 21:53:34 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <2FA74E8177C2445E82D929E4857FA377@buildpc> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <2FA74E8177C2445E82D929E4857FA377@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Cc: ipsec@ietf.org Subject: [IPsec] RFC5996bis editorial change in section 3.2 Generic Payload Header (Was One more editorial issue in RFC5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:53:49 -0000 Valery Smyslov writes: > Just came across one more small editorial issue in RFC5996. > Page 73, description of "Next Payload" field, sentence > > In the header of an Encrypted payload, the Next Payload field is set > to the payload type of the first contained payload (instead of 0); > conversely, the Next Payload field of the last contained payload > is set to zero). > > has extra round bracket at the end. Removed. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 12:19:07 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFBE21E80DC for ; Tue, 12 Nov 2013 12:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJK1u3j9uYFn for ; Tue, 12 Nov 2013 12:19:05 -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 A8DB521E80C4 for ; Tue, 12 Nov 2013 12:19:04 -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 rACKIxQa007118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 22:18:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACKIvTr016014; Tue, 12 Nov 2013 22:18:57 +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: <21122.36145.673093.986774@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 22:18:57 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21103.50109.281784.791771@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] 5996bis 3.3.1 proposal structure X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:19:07 -0000 Paul Wouters writes: > Implementors still need to name that struct. Instead of everyone > coming up with their own name it would be good to have a standard > name for it. I do not think it is that important to have names, I am good at inventing better names than what they use in standards :-) > So just naming it in the RFC like we do for the other IKEv2 proposal > fields would be useful. I would suggest "last payload". As it is not payload, I used "Last Substruc" instead. The data inside those are Proposal or Transform Substructures. Changed: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 2 | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the last Proposal Substructure in the SA. This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA. The value (2) corresponds to a payload type of Proposal in IKEv1, and the first four octets of the Proposal structure are designed to look somewhat like the header of a payload. To: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Substruc | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... o Last Substruc (1 octet) - Specifies whether this is the last Proposal Substructure in the SA. This field has value 0 if this was last Proposal Substructure, and value 2 there are more Proposal Substructures. This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA. The value (2) corresponds to a payload type of Proposal in IKEv1, and the first four octets of the Proposal structure are designed to look somewhat like the header of a payload. And: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 3 | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transform Type | RESERVED | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last Transform Substructure in the Proposal. This syntax is inherited from ISAKMP, but is unnecessary because the last transform could be identified from the length of the proposal. The value (3) corresponds to a payload type of Transform in IKEv1, and the first four octets of the Transform structure are designed to look somewhat like the header of a payload. To: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Substruc | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transform Type | RESERVED | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... o Last Substruc (1 octet) - Specifies whether this is the last Transform Substructure in the Proposal. This field has value 0 if this was last Transform Substructure, and value 3 there are more Transform Substructures. This syntax is inherited from ISAKMP, but is unnecessary because the last transform could be identified from the length of the proposal. The value (3) corresponds to a payload type of Transform in IKEv1, and the first four octets of the Transform structure are designed to look somewhat like the header of a payload. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 12:41:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD0B21F9E94 for ; Tue, 12 Nov 2013 12:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dblMhJ7nvubq for ; Tue, 12 Nov 2013 12:41:12 -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 6AA3C21F9FB7 for ; Tue, 12 Nov 2013 12:41:09 -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 rACKf5hh021002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2013 22:41:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACKf5A4020948; Tue, 12 Nov 2013 22:41:05 +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: <21122.37473.667025.840884@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 22:41:05 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <527217DD.6040305@gmail.com> References: <52680567.2080204@gmail.com> <527217DD.6040305@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 18 min Cc: IPsecme WG Subject: Re: [IPsec] Working Group Last Call: draft-kivinen-ipsecme-ikev2-rfc5996bis-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:41:14 -0000 Yaron Sheffer writes: > I think RFC 6989 (additional tests when reusing DH values) should be a > normative reference, There is not a single group defined, or even mentioned in the RFC5996bis that requires those checks, so I think it can be informational. For documents specifying groups that require those checks they should have the normative references to that document. > and the text at the bottom of 2.12 should be strengthened to > something like: > > In such cases, additional tests defined in [RFC6989] MUST be performed > by the IKE peers. See this document, as well as [REUSE] for a security > analysis of this practice. Why would the tests in RFC6989 need to be only if implementation reuses exponents, and remembers exponentals other end used? The previous sentence before that part is: An implementation that reuses exponentials MAY choose to remember the exponential used by the other endpoint on past exchanges and if one is reused to avoid the second half of the calculation. And that "In such cases" would refer to completely wrong thing. Also I do not want to add new MUSTs at this point, especially as there is no need for that for groups defined in this document. > Rationale: even if EC groups (and the "DSA groups") are not defined in > RFC 5996, they are a mainstream use case and the RFC 6989 tests are > security critical for them. Also, process-wise, RFC 6989 is a Standards > Track document so the normative reference is legit. And those documents specifying those groups should have normative references to that document, and we should most likely make new versions of those RFCs to include the reference. On the other hand IANA registry already has that pointer, so I think that should be enough for the implementors. > Small typo: in Sec. 3.3.2, "do not need" -> "does not need", and "needs > to have" -> "need to have". The first change I had already done, did the another fix now, i.e. changed: Note, that MODP Diffie-Hellman groups listed above does not need any special validity tests to be performed, but other types of groups (ECP and MODP groups with small subgroups) needs to have some additional tests to be performed on them to use them securely. See "Additional Diffie-Hellman Tests for IKEv2" () for more information. To: Note, that MODP Diffie-Hellman groups listed above does not need any special validity tests to be performed, but other types of groups (ECP and MODP groups with small subgroups) need to have some additional tests to be performed on them to use them securely. See "Additional Diffie-Hellman Tests for IKEv2" () for more information. -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Nov 12 13:24:41 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC63621E8064 for ; Tue, 12 Nov 2013 13:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG6ttXTyRmgZ for ; Tue, 12 Nov 2013 13:24:41 -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 43DBE11E80E6 for ; Tue, 12 Nov 2013 13:24:41 -0800 (PST) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rACLObOa037138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Nov 2013 14:24:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <21122.36145.673093.986774@fireball.kivinen.iki.fi> Date: Tue, 12 Nov 2013 13:24:37 -0800 Content-Transfer-Encoding: 7bit Message-Id: <347F5A23-86DB-42E6-93E2-0FA2316C6A6E@vpnc.org> References: <21103.50109.281784.791771@fireball.kivinen.iki.fi> <21122.36145.673093.986774@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1822) Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] 5996bis 3.3.1 proposal structure X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:24:42 -0000 On Nov 12, 2013, at 12:18 PM, Tero Kivinen wrote: > Paul Wouters writes: >> Implementors still need to name that struct. Instead of everyone >> coming up with their own name it would be good to have a standard >> name for it. > > I do not think it is that important to have names, I am good at > inventing better names than what they use in standards :-) > >> So just naming it in the RFC like we do for the other IKEv2 proposal >> fields would be useful. I would suggest "last payload". > > As it is not payload, I used "Last Substruc" instead. The data inside > those are Proposal or Transform Substructures. > > Changed: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 (last) or 2 | RESERVED | Proposal Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Proposal Num | Protocol ID | SPI Size |Num Transforms| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > > o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the > last Proposal Substructure in the SA. This syntax is inherited > from ISAKMP, but is unnecessary because the last Proposal could be > identified from the length of the SA. The value (2) corresponds > to a payload type of Proposal in IKEv1, and the first four octets > of the Proposal structure are designed to look somewhat like the > header of a payload. > > > To: > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Last Substruc | RESERVED | Proposal Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Proposal Num | Protocol ID | SPI Size |Num Transforms| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > > o Last Substruc (1 octet) - Specifies whether this is the last > Proposal Substructure in the SA. This field has value 0 if this > was last Proposal Substructure, and value 2 there are more > Proposal Substructures. This syntax is inherited from ISAKMP, but > is unnecessary because the last Proposal could be identified from > the length of the SA. The value (2) corresponds to a payload type > of Proposal in IKEv1, and the first four octets of the Proposal > structure are designed to look somewhat like the header of a > payload. Slight editorial clean-up on the new wording: o Last Substruc (1 octet) - Specifies whether or not this is the last Proposal Substructure in the SA. This field has a value of 0 if this was last Proposal Substructure, and a value of 2 if there are more Proposal Substructures. . . . > And: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 (last) or 3 | RESERVED | Transform Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Transform Type | RESERVED | Transform ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the > last Transform Substructure in the Proposal. This syntax is > inherited from ISAKMP, but is unnecessary because the last > transform could be identified from the length of the proposal. > The value (3) corresponds to a payload type of Transform in IKEv1, > and the first four octets of the Transform structure are designed > to look somewhat like the header of a payload. > > > To: > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Last Substruc | RESERVED | Transform Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Transform Type | RESERVED | Transform ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > o Last Substruc (1 octet) - Specifies whether this is the last > Transform Substructure in the Proposal. This field has value 0 if > this was last Transform Substructure, and value 3 there are more > Transform Substructures. This syntax is inherited from ISAKMP, > but is unnecessary because the last transform could be identified > from the length of the proposal. The value (3) corresponds to a > payload type of Transform in IKEv1, and the first four octets of > the Transform structure are designed to look somewhat like the > header of a payload. Editorial: o Last Substruc (1 octet) - Specifies whether or not this is the last Transform Substructure in the Proposal. This field has a value of 0 if this was last Transform Substructure, and a value of 3 if there are more Transform Substructures. . . . --Paul Hoffman From kivinen@iki.fi Tue Nov 12 14:47:45 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB4A11E8122 for ; Tue, 12 Nov 2013 14:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSahUmdHdW8N for ; Tue, 12 Nov 2013 14:47:41 -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 1170911E810B for ; Tue, 12 Nov 2013 14:47:36 -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 rACMlW2x014980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Nov 2013 00:47:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACMlWhh004831; Wed, 13 Nov 2013 00:47:32 +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: <21122.45059.960364.725643@fireball.kivinen.iki.fi> Date: Wed, 13 Nov 2013 00:47:31 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <347F5A23-86DB-42E6-93E2-0FA2316C6A6E@vpnc.org> References: <21103.50109.281784.791771@fireball.kivinen.iki.fi> <21122.36145.673093.986774@fireball.kivinen.iki.fi> <347F5A23-86DB-42E6-93E2-0FA2316C6A6E@vpnc.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 11 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] 5996bis 3.3.1 proposal structure X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 22:47:46 -0000 Paul Hoffman writes: > Slight editorial clean-up on the new wording: > > o Last Substruc (1 octet) - Specifies whether or not this is the last > Proposal Substructure in the SA. This field has a value of 0 if this > was last Proposal Substructure, and a value of 2 if there are more > Proposal Substructures. . . . Added "or not", "a", "of", "a" "of", and "if". > Editorial: > > o Last Substruc (1 octet) - Specifies whether or not this is the last > Transform Substructure in the Proposal. This field has a value of 0 if > this was last Transform Substructure, and a value of 3 if there are more > Transform Substructures. . . . Same. Final result: o Last Substruc (1 octet) - Specifies whether or not this is the last Proposal Substructure in the SA. This field has a value of 0 if this was last Proposal Substructure, and a value of 2 if there are more Proposal Substructures. and o Last Substruc (1 octet) - Specifies whether or not this is the last Transform Substructure in the Proposal. This field has a value of 0 if this was last Transform Substructure, and a value of 3 if there are more Transform Substructures. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 12 14:52:42 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5058211E8131 for ; Tue, 12 Nov 2013 14:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlJoYnFyQ-cw for ; Tue, 12 Nov 2013 14:52:41 -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 8510E11E812B for ; Tue, 12 Nov 2013 14:52:41 -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 rACMqeB2015553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 13 Nov 2013 00:52:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rACMqerG029590; Wed, 13 Nov 2013 00:52:40 +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: <21122.45368.280673.855613@fireball.kivinen.iki.fi> Date: Wed, 13 Nov 2013 00:52:40 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [IPsec] RFC5996bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 22:52:42 -0000 I am now done through my queue of RFC5996bis changes. If someone has still something, that wants to argue about those I didn't include, do it now. I will be submitting new draft version soon (tomorrow). -- kivinen@iki.fi From paul@cypherpunks.ca Tue Nov 12 18:20:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2B621E8096 for ; Tue, 12 Nov 2013 18:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxqMZLAwDpar for ; Tue, 12 Nov 2013 18:20:45 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1B821E809C for ; Tue, 12 Nov 2013 18:20:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3dK8gV5Tb8z7Zc; Tue, 12 Nov 2013 21:20:38 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GWpAzuFpTgmO; Tue, 12 Nov 2013 21:20:37 -0500 (EST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 12 Nov 2013 21:20:36 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 6EE488086E; Tue, 12 Nov 2013 21:20:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5AE24800A9; Tue, 12 Nov 2013 21:20:37 -0500 (EST) Date: Tue, 12 Nov 2013 21:20:37 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <21122.36145.673093.986774@fireball.kivinen.iki.fi> Message-ID: References: <21103.50109.281784.791771@fireball.kivinen.iki.fi> <21122.36145.673093.986774@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] 5996bis 3.3.1 proposal structure X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 02:20:51 -0000 On Tue, 12 Nov 2013, Tero Kivinen wrote: > Paul Wouters writes: >> Implementors still need to name that struct. Instead of everyone >> coming up with their own name it would be good to have a standard >> name for it. > > I do not think it is that important to have names, I am good at > inventing better names than what they use in standards :-) Unlike you, we hope that our customers send us patches :) > As it is not payload, I used "Last Substruc" instead. The data inside > those are Proposal or Transform Substructures. Thanks for the changes :) Paul From sean@blunkmicro.com Tue Nov 12 22:33:19 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74F821E8082 for ; Tue, 12 Nov 2013 22:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnNDLXruBtR4 for ; Tue, 12 Nov 2013 22:33:12 -0800 (PST) Received: from blnkms23.securesites.net (blnkms23.securesites.net [161.58.211.245]) by ietfa.amsl.com (Postfix) with ESMTP id B3DF211E8108 for ; Tue, 12 Nov 2013 22:33:12 -0800 (PST) Received: from [192.168.1.77] (50-0-67-197.dsl.static.fusionbroadband.com [50.0.67.197]) (authenticated bits=0) by blnkms23.securesites.net (8.14.5/8.13.6) with ESMTP id rAD6X3lq053488; Wed, 13 Nov 2013 06:33:06 GMT Message-ID: <52831D23.5090709@blunkmicro.com> Date: Tue, 12 Nov 2013 22:33:07 -0800 From: Sean Lawless Organization: Blunk Microsystems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "ipsec@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] RFC5996 section 2.13 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 06:33:19 -0000 Hello, I am implementing RFC 5996 and am confused with section 2.13. The text defines prf+ (K,S), but does not define K or S. Specifically I am trying to generate SKEYSEED using PRF_HMAC_SHA1. The HMAC function takes a variable length data and a secret. For prf+ (K,S), are the nonce's (K) the data portion of the HMAC algorithm or the secret? 2.13 mentions SK_d, SK_pi, etc. but these are not used until 2.14 where the same description is duplicated from 2.13. I would be grateful if K and S can be well defined in section 2.13 instead of SK_d, SK_pi, etc. Best Regards, Sean Lawless Sr. SW Engineer Blunk Microsystems LLC sean@blunkmicro.com From paul@cypherpunks.ca Wed Nov 13 12:45:11 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFCE21E80C3 for ; Wed, 13 Nov 2013 12:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li5bXLGtFqLo for ; Wed, 13 Nov 2013 12:45:05 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id A131411E8136 for ; Wed, 13 Nov 2013 12:44:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3dKd9V5qY7z71n; Wed, 13 Nov 2013 15:44:46 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id U6AaWfZVbBAa; Wed, 13 Nov 2013 15:44:45 -0500 (EST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 13 Nov 2013 15:44:45 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 423E08086E; Wed, 13 Nov 2013 15:44:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2F501800A9; Wed, 13 Nov 2013 15:44:44 -0500 (EST) Date: Wed, 13 Nov 2013 15:44:44 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <21087.60447.758422.672867@fireball.kivinen.iki.fi> Message-ID: References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org WG" Subject: [IPsec] RFC5996bis section 3.1 comment X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:45:11 -0000 On Thu, 17 Oct 2013, Tero Kivinen wrote: [forgive me if already reported] Section 3.1 states: o Major Version (4 bits) - Indicates the major version of the IKE protocol in use. Implementations based on this version of IKE MUST set the major version to 2. Implementations based on previous versions of IKE and ISAKMP MUST set the major version to --> 1. Implementations based on this version of IKE MUST reject or ignore messages containing a version number greater than 2 with an INVALID_MAJOR_VERSION notification message as described in Section 2.5. The reading of "this version" on the line marked "-->" is a little unclear. Does it refer to the previous sentence's version (version 1) or this version as in "this document's" version (version 2). I suggest replacing "this version" with "this document's version" o Minor Version (4 bits) - Indicates the minor version of the IKE protocol in use. Implementations based on this version of IKE MUST set the minor version to 0. They MUST ignore the minor version number of received messages. For the Major we tell what IKEv1 implementations should do. Why don't we do that for the Minor as well? Suggested addition: Implementations based on the previous major version of IKE and ISAKMP MUST set the minor version to 0 and reject or ignore messages containing a minor version number greater than 0 with an INVALID_MINOR_VERSION notification message. Paul From internet-drafts@ietf.org Wed Nov 13 16:19:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB29521E80ED; Wed, 13 Nov 2013 16:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmBGjCluqOZJ; Wed, 13 Nov 2013 16:19:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6163521E8094; Wed, 13 Nov 2013 16:19:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131114001920.30578.72559.idtracker@ietfa.amsl.com> Date: Wed, 13 Nov 2013 16:19:20 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-kivinen-ipsecme-ikev2-rfc5996bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 00:19:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Internet Key Exchange Protocol Version 2 (IKEv2) Author(s) : Charlie Kaufman Paul Hoffman Yoav Nir Pasi Eronen Tero Kivinen Filename : draft-kivinen-ipsecme-ikev2-rfc5996bis-02.txt Pages : 139 Date : 2013-11-13 Abstract: This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document replaces and updates RFC 5996, and includes all of the errata for it, and it is intended to update IKEv2 to be Internet Standard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-rfc5996bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-kivinen-ipsecme-ikev2-rfc5996bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Nov 13 16:19:46 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E510B21E8173; Wed, 13 Nov 2013 16:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDiNlH1aXKNF; Wed, 13 Nov 2013 16:19:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7080A21E8168; Wed, 13 Nov 2013 16:19:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131114001946.30542.15700.idtracker@ietfa.amsl.com> Date: Wed, 13 Nov 2013 16:19:46 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-kivinen-ipsecme-signature-auth-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 00:19:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Signature Authentication in IKEv2 Author(s) : Tero Kivinen Filename : draft-kivinen-ipsecme-signature-auth-03.txt Pages : 16 Date : 2013-11-13 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is fixed hash algorithm tied to each curve. This document generalizes the IKEv2 signature support so it can support any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This is generic mechanism, and is not limited to ECDSA, but can also be used with other signature algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-kivinen-ipsecme-signature-auth-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kivinen@iki.fi Wed Nov 13 16:25:44 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B288921E80AB for ; Wed, 13 Nov 2013 16:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUvdHK9qxJKc for ; Wed, 13 Nov 2013 16:25:44 -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 E82A821E8090 for ; Wed, 13 Nov 2013 16:25:42 -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 rAE0Pel5014074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 14 Nov 2013 02:25:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rAE0PewW012019; Thu, 14 Nov 2013 02:25:40 +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: <21124.6276.800771.457943@fireball.kivinen.iki.fi> Date: Thu, 14 Nov 2013 02:25:40 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min Subject: [IPsec] New drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 00:25:44 -0000 I updated the RFC5996bis draft to include the editorial changes sent to the list (all changes sent up To tuesday). I also updated the signature authentication draft by adding the section about the public key selection methods, and I also added the binary objects for the commonly used signature ASN.1 objects. If someone has any way to verify those (especially the RSASSA-PSS method with parameters), that would be really good. I did create perl script to generate those, but then I needed cut & paste suitable ASN.1 modules to generate correct results and especially the RSASSA-PSS ASN.1 is quite complex so I may have made mistakes there. What is still missing from the signature draft is the actual payload examples, I will generate in the next version, but would like to know if it is enough to just generate two examples, not for every single algorithm (was thinking of sha1WithRSAEncryption and dsa-with-sha256). The actual algorithms does not really matter, and even one example might be enough as we have the asn1 blobs above, and the signature is mostly as placeholder as veryfing it will be difficult... -- kivinen@iki.fi From kent@bbn.com Tue Nov 19 13:06:26 2013 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 31E0C1AE1A0 for ; Tue, 19 Nov 2013 13:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 ixCow473MmcR for ; Tue, 19 Nov 2013 13:06:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id F282A1AE193 for ; Tue, 19 Nov 2013 13:06:23 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:49949 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VisUz-000EqF-10 for ipsec@ietf.org; Tue, 19 Nov 2013 16:06:17 -0500 Message-ID: <528BD2C6.7060701@bbn.com> Date: Tue, 19 Nov 2013 16:06:14 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ipsec References: <20131119163930.7275.53854.idtracker@ietfa.amsl.com> In-Reply-To: <20131119163930.7275.53854.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131119163930.7275.53854.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070500090601070209090202" Subject: [IPsec] Fwd: I-D ACTION:draft-kent-ipsecme-ah-rfc4302bis-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, 19 Nov 2013 21:06:26 -0000 This is a multi-part message in MIME format. --------------070500090601070209090202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit updated versions of RFC 4301, 4302, and 4303 have been posted: Title : IP Authentication Header (AH) Author(s) : S. Kent Filename : draft-kent-ipsecme-ah-rfc4302bis Pages : 35 Date : Nov. 19, 2013 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 4302. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kent-ipsecme-ah-rfc4302bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Title : Security Architecture for the Internet Protocol Author(s) : S. Kent Filename : draft-kent-ipsecme-saforip-rfc4301bis Pages : 104 Date : Nov. 19, 2013 This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 4301 and 6040. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kent-ipsecme-saforip-rfc4301bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-kent-ipsecme-esp-rfc4303bis Pages : 46 Date : Nov. 19, 2013 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. 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 obsoletes RFC 4303. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kent-ipsecme-esp-rfc4303bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --------------070500090601070209090202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit updated versions of RFC 4301, 4302, and 4303 have been posted:



    Title         : IP Authentication Header (AH)
    Author(s)     : S. Kent
    Filename      : draft-kent-ipsecme-ah-rfc4302bis
    Pages         : 35 
    Date          : Nov. 19, 2013 
    
 This document describes an updated version of the IP Authentication
   Header (AH), which is designed to provide authentication services in
   IPv4 and IPv6.  This document obsoletes RFC 4302.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kent-ipsecme-ah-rfc4302bis-00.txt

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



    Title         : Security Architecture for the Internet Protocol
    Author(s)     : S. Kent
    Filename      : draft-kent-ipsecme-saforip-rfc4301bis
    Pages         : 104 
    Date          : Nov. 19, 2013 
    
  This document describes an updated version of the &quot;Security
   Architecture for IP&quot;, which is designed to provide security services
   for traffic at the IP layer.  This document obsoletes RFC 4301 and
   6040.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kent-ipsecme-saforip-rfc4301bis-00.txt

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


    Title         : IP Encapsulating Security Payload (ESP)
    Author(s)     : S. Kent
    Filename      : draft-kent-ipsecme-esp-rfc4303bis
    Pages         : 46 
    Date          : Nov. 19, 2013 
    
   This document describes an updated version of the Encapsulating
   Security Payload (ESP) protocol, which is designed to provide a mix
   of security services in IPv4 and IPv6.  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
   obsoletes RFC 4303.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kent-ipsecme-esp-rfc4303bis-00.txt

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

--------------070500090601070209090202-- From yaronf.ietf@gmail.com Tue Nov 19 14:08:25 2013 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 0874B1AE173 for ; Tue, 19 Nov 2013 14:08:25 -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 arPDjLrZSZ5Y for ; Tue, 19 Nov 2013 14:08:23 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 39ABB1AE163 for ; Tue, 19 Nov 2013 14:08:23 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so8375396wgh.20 for ; Tue, 19 Nov 2013 14:08:16 -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=d5zVfzaWtXtJ7980uQEUkMOtC0N5VH2mqPGvFPUsKB4=; b=NANVwptghA01lP/LKixiKNgc/O0wjCAnxmGkXl72Vcka5xeSmI9gJ7T/QfNk4rLEHD 3xIXFfT1U3gHROxAeZaLCSdLen84kas5lmvNwGxw7JQvjoPadDu/m+WvYMuMPphFV6Ab A8m3NyXoYiznpVgx0nZWZsgY0XUUxyzzMgdGzsrcKXfaNs0D7S8sn2nv09CC0hXTWKYX owTgLLF1ZyaQZC9wDVfMZ/F22eWYh5cLeXPQ9gwARJvFSjkxPCK9i6Gfrdl1uezCYhN1 APQ0MVock/ZpQUpw/Jz0TXkrERa3UfDfXP95qgv62+1oFEQY4AUaAWEgqy0b8x5HbE09 ZZjg== X-Received: by 10.194.241.228 with SMTP id wl4mr23269570wjc.2.1384898896735; Tue, 19 Nov 2013 14:08:16 -0800 (PST) Received: from [10.0.0.9] (bzq-79-182-173-156.red.bezeqint.net. [79.182.173.156]) by mx.google.com with ESMTPSA id ll10sm9794831wic.9.2013.11.19.14.08.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 14:08:16 -0800 (PST) Message-ID: <528BE14E.1050503@gmail.com> Date: Wed, 20 Nov 2013 00:08:14 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stephen Kent , ipsec References: <20131119163930.7275.53854.idtracker@ietfa.amsl.com> <528BD2C6.7060701@bbn.com> In-Reply-To: <528BD2C6.7060701@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Fwd: I-D ACTION:draft-kent-ipsecme-ah-rfc4302bis-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, 19 Nov 2013 22:08:25 -0000 On 11/19/2013 11:06 PM, Stephen Kent wrote: > updated versions of RFC 4301, 4302, and 4303 have been posted: > > Thank you Steve for working on these drafts. These drafts are targeted at republication as Internet Standards. As promised in Vancouver, I would like to open the question of whether we should be republishing RFC 4302 - AH. My personal opinion is that we should not. We have downgraded AH and consistently discouraged its use, replacing it by ESP-null. People are obviously free to implement it even if it remains Proposed Standard, but why give the wrong message by promoting it to IS? Thanks, Yaron From kent@bbn.com Tue Nov 19 14:17:45 2013 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 580981AE179 for ; Tue, 19 Nov 2013 14:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 vEYnfNTlTWWm for ; Tue, 19 Nov 2013 14:17:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 247F51AE163 for ; Tue, 19 Nov 2013 14:17:43 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:54110 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vitc0-000G6Q-Gx; Tue, 19 Nov 2013 17:17:36 -0500 Message-ID: <528BE37F.60402@bbn.com> Date: Tue, 19 Nov 2013 17:17:35 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Yaron Sheffer , ipsec References: <20131119163930.7275.53854.idtracker@ietfa.amsl.com> <528BD2C6.7060701@bbn.com> <528BE14E.1050503@gmail.com> In-Reply-To: <528BE14E.1050503@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Fwd: I-D ACTION:draft-kent-ipsecme-ah-rfc4302bis-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, 19 Nov 2013 22:17:45 -0000 Yaron, I think we should progress it to FS only if there are other protocols that make use of it, and which are really in use in a non-trivial fashion. I think Sean said that he identified some such protocols when he was exploring this topic, so we should ask Sean for details. Steve > On 11/19/2013 11:06 PM, Stephen Kent wrote: >> updated versions of RFC 4301, 4302, and 4303 have been posted: >> >> > Thank you Steve for working on these drafts. These drafts are targeted > at republication as Internet Standards. As promised in Vancouver, I > would like to open the question of whether we should be republishing > RFC 4302 - AH. > > My personal opinion is that we should not. We have downgraded AH and > consistently discouraged its use, replacing it by ESP-null. People are > obviously free to implement it even if it remains Proposed Standard, > but why give the wrong message by promoting it to IS? > > Thanks, > Yaron > From yaronf.ietf@gmail.com Tue Nov 19 14:24:07 2013 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 C91DB1AE0B6 for ; Tue, 19 Nov 2013 14:24:07 -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 fl8kCbKrpvTz for ; Tue, 19 Nov 2013 14:24:06 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id E5D671AE065 for ; Tue, 19 Nov 2013 14:24:05 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id t61so1685021wes.7 for ; Tue, 19 Nov 2013 14:23:59 -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=OY+mhIhRS0hCnTKaD8rc39v5cGxcbPHbtCD1Se0ZpFc=; b=L+ooSTtRrp31jUqV0K8OyjYPcqua09SIbB8KeIk5y1RlaMdavT8xxKvY/VYvYtT5vK ZWtszd7bLWnoaCP/JUbW93VpvOwNz9hB1X/kG5/t7+0i75czvb0Zdlqya2qyJOkFdEGb uIiNYW0m+kSpH9wRzMfrF9YONHgGGPIm1neNRxh+vhnaUpCICPHUEGpaQwW6QE33361L pib+j+eb7l19pOe3W4O21RPt4cp4BV0n0DA1q+4HUCnIB/SAaLWpQzO5L2Kdf2/wKYEj QQLM2KjmxJpZJpbJ2YpP9mBoTVb8rncM2aqILC7fPz8Zb1mhhiGVtduLiW6taQnYVZK/ IfvQ== X-Received: by 10.180.74.174 with SMTP id u14mr9014354wiv.53.1384899839273; Tue, 19 Nov 2013 14:23:59 -0800 (PST) Received: from [10.0.0.9] (bzq-79-182-173-156.red.bezeqint.net. [79.182.173.156]) by mx.google.com with ESMTPSA id ll10sm9890529wic.9.2013.11.19.14.23.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 14:23:58 -0800 (PST) Message-ID: <528BE4FD.90408@gmail.com> Date: Wed, 20 Nov 2013 00:23:57 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Stephen Kent , ipsec References: <20131119163930.7275.53854.idtracker@ietfa.amsl.com> <528BD2C6.7060701@bbn.com> <528BE14E.1050503@gmail.com> <528BE37F.60402@bbn.com> In-Reply-To: <528BE37F.60402@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Fwd: I-D ACTION:draft-kent-ipsecme-ah-rfc4302bis-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, 19 Nov 2013 22:24:08 -0000 Hi Steve, I'm fine with what you say. Just a quick comment on process: we don't have FS (Full Standard) any more. Since RFC 6410, we have "Proposed Standard" and "Internet Standard". Thanks, Yaron On 11/20/2013 12:17 AM, Stephen Kent wrote: > Yaron, > > I think we should progress it to FS only if there are other protocols > that make use > of it, and which are really in use in a non-trivial fashion. I think > Sean said that he identified some such protocols when he was exploring > this topic, so we should ask Sean > for details. > > Steve >> On 11/19/2013 11:06 PM, Stephen Kent wrote: >>> updated versions of RFC 4301, 4302, and 4303 have been posted: >>> >>> >> Thank you Steve for working on these drafts. These drafts are targeted >> at republication as Internet Standards. As promised in Vancouver, I >> would like to open the question of whether we should be republishing >> RFC 4302 - AH. >> >> My personal opinion is that we should not. We have downgraded AH and >> consistently discouraged its use, replacing it by ESP-null. People are >> obviously free to implement it even if it remains Proposed Standard, >> but why give the wrong message by promoting it to IS? >> >> Thanks, >> Yaron >> > From Paul_Koning@Dell.com Wed Nov 20 07:36:24 2013 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 4E3EC1ADF8E for ; Wed, 20 Nov 2013 07:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, 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 zSlHPHr2YRlr for ; Wed, 20 Nov 2013 07:36:22 -0800 (PST) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by ietfa.amsl.com (Postfix) with ESMTP id BB98B1ADF67 for ; Wed, 20 Nov 2013 07:36:22 -0800 (PST) X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="4.93,737,1378875600"; d="scan'208";a="336265844" From: To: Thread-Topic: [IPsec] Fwd: I-D ACTION:draft-kent-ipsecme-ah-rfc4302bis-00.txt Thread-Index: AQHO5XPXQbMjgNQVMkCs+VQbzWRvCJoupiWA Date: Wed, 20 Nov 2013 15:36:08 +0000 Message-ID: References: <20131119163930.7275.53854.idtracker@ietfa.amsl.com> <528BD2C6.7060701@bbn.com> <528BE14E.1050503@gmail.com> In-Reply-To: <528BE14E.1050503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.216.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <9AF52EB1FCDB0F4CACB34B9D6E31CD38@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ipsec@ietf.org, kent@bbn.com Subject: Re: [IPsec] Fwd: I-D ACTION:draft-kent-ipsecme-ah-rfc4302bis-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: Wed, 20 Nov 2013 15:36:24 -0000 On Nov 19, 2013, at 5:08 PM, Yaron Sheffer wrote: > On 11/19/2013 11:06 PM, Stephen Kent wrote: >> updated versions of RFC 4301, 4302, and 4303 have been posted: >>=20 >>=20 > Thank you Steve for working on these drafts. These drafts are targeted at= republication as Internet Standards. As promised in Vancouver, I would lik= e to open the question of whether we should be republishing RFC 4302 - AH. >=20 > My personal opinion is that we should not. We have downgraded AH and cons= istently discouraged its use, replacing it by ESP-null. People are obviousl= y free to implement it even if it remains Proposed Standard, but why give t= he wrong message by promoting it to IS? I agree with that. paul From gandhar.ietf@gmail.com Fri Nov 22 06:05:02 2013 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 3F6231AE133 for ; Fri, 22 Nov 2013 06:05:02 -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 WFrKiRk-Gfry for ; Fri, 22 Nov 2013 06:05:00 -0800 (PST) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 94F071AE12D for ; Fri, 22 Nov 2013 06:05:00 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id f13so890680vbg.11 for ; Fri, 22 Nov 2013 06:04:53 -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=qSlSgyPQdzp/udXlG9aVKEkYeeI7W1EXEpWNe9Oe+2k=; b=k7Zh+w1PTS3O55D5AuqSAhT50H6FfQpd9rLd7vpl2NHPREHbRv4Qg3Sr7yAYVWLV7b 3hMejr+UJvdqlzjsrs0nQa4VNF2qDJExKss+VU8ffMJBgTtTh67pcCZTjgan+t+4uLHj Nn/UGnRGOvKjywSPlYFfu7ozUtdcGu60D6d9R79HC553UZt04nZdlcEaUZ5OmS7KkmCT tofmzxzawmCDKtaa9e5AEiczzm3IQF87Y++HchB3aSmajHekvxnuJkK8O7f0JHAaBm/c 8Q5TjMP5dBHgTADJhlgiHYg0+RwQgiZsKYa6yI/xMhB1pO7VQyHXRXtyfJnYg2KgrsUQ Vkrg== MIME-Version: 1.0 X-Received: by 10.58.11.73 with SMTP id o9mr11506294veb.8.1385129093385; Fri, 22 Nov 2013 06:04:53 -0800 (PST) Received: by 10.58.164.195 with HTTP; Fri, 22 Nov 2013 06:04:53 -0800 (PST) Date: Fri, 22 Nov 2013 19:34:53 +0530 Message-ID: From: Gandhar Gokhale To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=047d7b2ed3419454b004ebc47f02 Subject: [IPsec] NAT-T and IPv6 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, 22 Nov 2013 14:05:02 -0000 --047d7b2ed3419454b004ebc47f02 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, RFC3948 states in the Introduction section: =93As defined in this document, UDP encapsulation of ESP packets is writte= n in terms of IPv4 headers. There is no technical reason why an IPv6 header could not be used as the outer header and/or as the inner header. And in section 2.1 it states "o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o receivers MUST NOT depend on the UDP checksum being a zero value" As per RFC 2460 UDP header with 0 checksum must be discarded. If all these statements are seen together it would mean NAT-T for IPv6 as described in RFC 3498 won't work. Am I missing something? Is NAT-T a valid deployment case for IPv6 network i.e. when the outer header of IPsec tunnel is IPv6? --=20 Gandhar Gokhale Networking Components Group LSI --047d7b2ed3419454b004ebc47f02 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hello,


RFC3948 states in the Introduction section:<= /p>

=A0=A0= =A0=A0=A0

=93As defined in this document, UD= P encapsulation of ESP packets is=A0 written in terms of IPv4 headers.=A0 There is no technical reason why an IPv6 header could not be used as the outer header and/or as the inner header.


And in section 2.1 i= t states=A0


"o  =
the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and=A0<=
/pre>
 o  receivers MUST NOT depend=
 on the UDP checksum being a zero value"


As per RFC 24=
60 UDP header with 0 checksum must be discarded. =A0

If all these statements are seen together it would mean NAT-T for IPv6= as described in RFC 3498 won't work.=A0

Am I missing something?=A0

Is NAT-T a valid deployment case for IPv6 network i.e. when the outer heade= r of IPsec tunnel is IPv6?


--
Gandha= r Gokhale
Networking Components Group
LSI
--047d7b2ed3419454b004ebc47f02-- From timo.teras@gmail.com Fri Nov 22 12:05:38 2013 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 710491AE3F1 for ; Fri, 22 Nov 2013 12:05:38 -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 Nzw6keo5JKzk for ; Fri, 22 Nov 2013 12:05:36 -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 5DAF31AE3CF for ; Fri, 22 Nov 2013 12:05:35 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id w7so1351526lbi.22 for ; Fri, 22 Nov 2013 12:05:27 -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=2YhIjw1XFzFEDO5Az3RllZvq4Ji6J4WtRYK0/sJNNz0=; b=hVVUnV9fNsLtJBMo0l+VeUFcu4JtbaS6St3lRK9hDLvec138JfKoEBYwwY/oAjVKQp 6q5wv8kytwQRxeDJ5+Oi2xHfy6I6sYD1BHJmkmK3DOnBnmEaCdajVbmnU7cnPUGi8NWH Bom9JiHmr+ep+jx4WhmwJPxUukYY4ruRv2g3mKa7x6Gvvm9mhTXni2IFO25BMbpczSlV r7VhOHTzh0yRSIoxSCnm19q8n/uX+FOnO306rtG9hOrZ3WnebPQvemmFXeuD4fwNJg9d BhSbsAcL+XY4YaQnoSEKIJCDw9xo8lkRZU7LGysQ6y9lN8y8gHlkN0VtvV2CmTPp8jR7 PbHA== X-Received: by 10.112.128.226 with SMTP id nr2mr10397249lbb.17.1385150727493; Fri, 22 Nov 2013 12:05:27 -0800 (PST) Received: from vostro ([83.145.235.194]) by mx.google.com with ESMTPSA id r10sm25904005lag.7.2013.11.22.12.05.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Nov 2013 12:05:27 -0800 (PST) Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= Date: Fri, 22 Nov 2013 22:05:29 +0200 From: Timo Teras To: ipsec@ietf.org Message-ID: <20131122220529.0c5dba7d@vostro> X-Mailer: Claws Mail 3.9.2 (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] DMVPN thoughts 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, 22 Nov 2013 20:06:38 -0000 Hi everyone, Yaron Sheffer recently invited my to share my thoughts on DMVPN as it seems to be one of the option being considered to be the AD VPN standard. As brief background, I am the author of opennhrp [1] which can be used to implement Cisco DMVPN style networks on Linux [2]. I have also written multiple improvements to Linux kernel to support this kind of networks. Additionally, I have enhanced ipsec-tools (racoon) [3] to be suitable for this use, and am currently looking into integrating opennhrp with strongswan [4]. The opennhrp project started back in 2007. It was implemented based on the NHRP specification (RFC 2332) and with some insight take from draft-ietf-ion-r2r-nhrp-03. The remaining Cisco NHRP extensions I implemented based on protocol analysis. While it is not perfect match with Cisco DMVPN, I have good success interoperating with Cisco devices. The feature set of opennhrp is not as complete as Cisco - e.g. IPv6 is not (yet) supported. It would have been very helpful to have draft-detienne-dmvpn-00 at the time I was writing most of the code. I did considerable testing against Cisco devices in 2007-2008 but since have been concentrating more on fully opennhrp based DMVPN networks - so I have not paid close attention on the latest Cisco updates. However, after brief read of the draft, it seems to be missing at least: - Authentication extension (code 7; from RFC 2332) payload format which seems to be Cisco specific - at least RFC 2332 does not specify it - NAT address extension (code 9; Cisco specified, and apparently even conflicts with some RFC drafts), and it's CIE based payload content specification - The specifics how Request ID field should be used. My experience shows that Request ID is stored along with the registrations, and needs to match in Purge requests for the Purge operation to succeed (IMHO, such Request ID matching should not be done). The one defect for me with DMVPN was that hubs are not automatically discovered (or maybe there's something for this nowadays?). Thus opennhrp has one extension: "dynamic-map" configuration stanza. It binds the NHSes to a DNS entry. The A records of that DNS name are used as NBMA addresses of the NHSes. During initial NHRP registration the NHRP Registration Requests are sent to the network broadcast address with hop count 1, and the NHS network address is picked up from the NHRP Registration Reply. The list of NHS servers is of course synchronized regularly. So as minimum, this or some similar hub autodetection mechanism should be added to dmvpn spec. Additionally, running multiple DMVPN instances on single router would require a standards compliant way to negotiate GRE key in IKE traffic selectors. There seems to have been discussions about that back in 2008 on this list, but it seems nothing came out of it. So I think this issue should be brought to discussion again too. I personally do like how the DMVPN stack works and would like to see it standardized. However, I do understand that it might not be perfect fit or even preference for all. Cheers, Timo [1] http://sourceforge.net/projects/opennhrp/ [2] http://wiki.alpinelinux.org/wiki/Dynamic_Multipoint_VPN_%28DMVPN%29 [3] http://ipsec-tools.sourceforge.net/ [4] https://lists.strongswan.org/pipermail/dev/2013-November/000945.html From kivinen@iki.fi Mon Nov 25 07:20:30 2013 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 6C0DD1ADF4D for ; Mon, 25 Nov 2013 07:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 0NRHvX6L4TiV for ; Mon, 25 Nov 2013 07:20:27 -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 5A2AF1ADF4C for ; Mon, 25 Nov 2013 07:20:27 -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 rAPFKMLM022111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Nov 2013 17:20:22 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rAPFKMrm014123; Mon, 25 Nov 2013 17:20:22 +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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21139.27318.60621.427765@fireball.kivinen.iki.fi> Date: Mon, 25 Nov 2013 17:20:22 +0200 From: Tero Kivinen To: Gandhar Gokhale In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 13 min Cc: ipsec@ietf.org Subject: [IPsec] NAT-T and IPv6 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, 25 Nov 2013 15:20:30 -0000 Gandhar Gokhale writes: > As defined in this document, UDP encapsulation of ESP packets is=A0 > written in terms of IPv4 headers.=A0 There is no technical reason why= > an IPv6 header could not be used as the outer header and/or as the > inner header. Of course we hope nobody every makes NATs for IPv6, but having IPv4 NAT and then having IPv6 packets inside is of course possibility.=20 > And in section 2.1 it states=A0 >=20 > "o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and=A0= >=20 > o receivers MUST NOT depend on the UDP checksum being a zero value"= Note that it only talks about IPv4 UDP Checksum field, it does not specify such recommendation for IPv6 UDP checksum. > As per RFC 2460 UDP header with 0 checksum must be discarded. =A0 Which is why the with the IPv6 you must calculate UDP checksum when sending the packet. Using the IPv4 UDP checksum of 0 is an optimization, which removes useless checksum calculations of the UDP packet, and that optimization cannot be used for IPv6.=20 > If all these statements are seen together it would mean NAT-T for IPv= 6 as > described in RFC 3498 won't work.=A0 > > Am I missing something=3F=A0 I think you are missing the "IPv4" word in the quoted context. It does not claim you can use that optimization for IPv6. For IPv6 you must calculate checksum properly when sending UDP encapsulated ESP packets over IPv6. For more information check the RFC3715 which have bit more text about IPv6 and NATs, and if I remember right there might have also been some discussion about this in the IPsec mailing list during the development of this rfc. > Is NAT-T a valid deployment case for IPv6 network i.e. when the > outer header of IPsec tunnel is IPv6=3F Yes, but hopefully people will not do NATs on IPv6 :-) There are use cases for static stateless NATs in the IPv6, i.e. prefix changes and you do not want to renumber your whole network, but IPv4 style dynamic NATs should not be needed in IPv6. --=20 kivinen@iki.fi From mls@cisco.com Mon Nov 25 17:41:41 2013 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 3615B1AE108 for ; Mon, 25 Nov 2013 17:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 LhvN_lKqxzRj for ; Mon, 25 Nov 2013 17:41:39 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id E1A331AE107 for ; Mon, 25 Nov 2013 17:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5861; q=dns/txt; s=iport; t=1385430099; x=1386639699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aEK1CmLcKpMvPU+tyIFIOb8URmOMK5swGh15zWg5cVQ=; b=iCDG2tk36bsDy7/qXYS1j0+MwJIREzb9PjnDNaDFPeN2ZVAd/t4OESI8 j5WnqeYyhnV2XsMZHcLB/1Jd/XF+zP7ZQ7fBlw7q8kHrQEo1KS1JhNk7S gx0lwSSRQmbd7K40OVBfgY6R2wAspM+6l+YVbhEnK1jn28fKc+NkUeoyl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAPj7k1KtJV2a/2dsb2JhbABZgwc4U7wpgSkWdIIlAQEBAwEBAQFrCwUHBAIBCBEEAQELHQcnAQoUCQgCBA4FCIdzBQENvlMXjlYxBwaDGoETA4kKjDuDf5BigyiCKg X-IronPort-AV: E=Sophos;i="4.93,771,1378857600"; d="scan'208";a="2204141" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 26 Nov 2013 01:41:37 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAQ1fbtk029902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 01:41:37 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.132]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 19:41:37 -0600 From: "Mike Sullenberger (mls)" To: Timo Teras Thread-Topic: [IPsec] DMVPN thoughts Thread-Index: AQHO575a5ix3rggJ0kqw7LvAWvejAZo2tMNQ Date: Tue, 26 Nov 2013 01:41:36 +0000 Message-ID: <9D83DE546CB6DC47A3AE04086FDE35F523FD7185@xmb-aln-x06.cisco.com> References: <20131122220529.0c5dba7d@vostro> In-Reply-To: <20131122220529.0c5dba7d@vostro> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.69.88.254] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Mike Sullenberger \(mls\)" Subject: Re: [IPsec] DMVPN thoughts 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, 26 Nov 2013 01:41:41 -0000 Timo, Thank you very much for your comments. I had not realized that anyone had tried to implement our additions to NHRP, it is nice to hear that it wasn't "too hard" to do. =20 I have a couple of comments, inline. Mike. Mike Sullenberger, DSE mls@cisco.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 .:|:.:|:. Customer Advocacy=A0=A0=A0=A0=A0=A0=A0=A0=A0 CISCO > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Timo Teras > Sent: Friday, November 22, 2013 12:05 PM > To: ipsec@ietf.org > Subject: [IPsec] DMVPN thoughts >=20 > Hi everyone, >=20 > Yaron Sheffer recently invited my to share my thoughts on DMVPN as it > seems to be one of the option being considered to be the AD VPN > standard. >=20 > As brief background, I am the author of opennhrp [1] which can be used > to implement Cisco DMVPN style networks on Linux [2]. I have also > written multiple improvements to Linux kernel to support this kind of > networks. Additionally, I have enhanced ipsec-tools (racoon) [3] to be > suitable for this use, and am currently looking into integrating opennhrp > with strongswan [4]. >=20 > The opennhrp project started back in 2007. It was implemented based > on the NHRP specification (RFC 2332) and with some insight take from > draft-ietf-ion-r2r-nhrp-03. The remaining Cisco NHRP extensions I > implemented based on protocol analysis. While it is not perfect match > with Cisco DMVPN, I have good success interoperating with Cisco > devices. The feature set of opennhrp is not as complete as Cisco - e.g. > IPv6 is not (yet) supported. >=20 > It would have been very helpful to have draft-detienne-dmvpn-00 at > the time I was writing most of the code. I did considerable testing > against Cisco devices in 2007-2008 but since have been concentrating > more on fully opennhrp based DMVPN networks - so I have not paid > close attention on the latest Cisco updates. >=20 > However, after brief read of the draft, it seems to be missing at least: > - Authentication extension (code 7; from RFC 2332) payload format which > seems to be Cisco specific - at least RFC 2332 does not specify it [Mike Sullenberger]=20 Yes you are correct, back in 1995 when the initial NHRP implementation was done, only a simple clear-text authentication was done using a SPI value of 1 and not including the src-addr field, just the Authentication Da= ta field. Since then we have thought about fixing this, but since DMVPN is encrypted with IPsec and we use the strong authentication in ISAKMP/IKEv2, there hasn't been a big impetus to get this fixed. > - NAT address extension (code 9; Cisco specified, and apparently even > conflicts with some RFC drafts), and it's CIE based payload content > specification [Mike Sullenberger]=20 This is true. In hind-sight we probably should have made this a vendor private extension. > - The specifics how Request ID field should be used. My experience > shows that Request ID is stored along with the registrations, and > needs to match in Purge requests for the Purge operation to succeed > (IMHO, such Request ID matching should not be done). [Mike Sullenberger]=20 I would have to check this, but I don't think that we bother to match up the request-id from a purge message with the original resolution request/reply that created the mapping entry. We do match the request-id between the resolution request and reply. > The one defect for me with DMVPN was that hubs are not automatically > discovered (or maybe there's something for this nowadays?). Thus > opennhrp has one extension: "dynamic-map" configuration stanza. It > binds the NHSes to a DNS entry. The A records of that DNS name are > used as NBMA addresses of the NHSes. During initial NHRP registration > the NHRP Registration Requests are sent to the network broadcast > address with hop count 1, and the NHS network address is picked up > from the NHRP Registration Reply. The list of NHS servers is of course > synchronized regularly. So as minimum, this or some similar hub > autodetection mechanism should be added to dmvpn spec. [Mike Sullenberger]=20 We do have this mechanism now. You can specify the NHS as a FQDN and at tunnel initialization time we will use DNS to translate the name to an address. From then on the address is used, though if access to the NHS goe= s down then we initial retry with the address, but if that still fails we wil= l do another DNS lookup on the name in case the address has changed. We also use the mechanism as described in RFC2332 to get the NHS network address from the NHRP registration reply. > Additionally, running multiple DMVPN instances on single router would > require a standards compliant way to negotiate GRE key in IKE traffic > selectors. There seems to have been discussions about that back in 2008 > on this list, but it seems nothing came out of it. So I think this issue > should be brought to discussion again too. [Mike Sullenberger]=20 I am not really that "keen" on adding GRE tunnel key negotiation to IKE. I prefer keeping these two layers a little more separated. Though I possibly could be convinced otherwise. > I personally do like how the DMVPN stack works and would like to see it > standardized. However, I do understand that it might not be perfect fit > or even preference for all. >=20 > Cheers, > Timo >=20 > [1] http://sourceforge.net/projects/opennhrp/ > [2] > http://wiki.alpinelinux.org/wiki/Dynamic_Multipoint_VPN_%28DMVPN > %29 > [3] http://ipsec-tools.sourceforge.net/ > [4] https://lists.strongswan.org/pipermail/dev/2013- > November/000945.html > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From svuggral@cisco.com Mon Nov 25 20:07:06 2013 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 B53BB1AE0C8 for ; Mon, 25 Nov 2013 20:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 0xH3ag7EV2r3 for ; Mon, 25 Nov 2013 20:07:05 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CCFF01AE0A7 for ; Mon, 25 Nov 2013 20:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6844; q=dns/txt; s=iport; t=1385438825; x=1386648425; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=V6qgtWoGmy+Mvj1iIiAq/GC4N2/ibVElxJ80ZS5/PYU=; b=AVlibAakyhmi4oq7eQ4o7n6TYStl0FPZWuzi/mpzr9FiQWC73aquY1KR tJ5WGjtrxS4ugKSFMMaPqY6FULPQC20SiGrzBLjbZ8n5SN7NOc5ISdx4Z DobYZVoQchHaCxhobLlkLrKgYQEJWlOyglKxirReaEyRf13FPqSyKE/zd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADYelFKtJXHA/2dsb2JhbABZgkNEgQu8IYEkFnSCJQEBAQSBCQIBCBEDAQIoByERFAkIAgQBEodvAw+2aw2IBxeMZ4F+GIQzA5YpgWuMWYU4gyiCKg X-IronPort-AV: E=Sophos;i="4.93,771,1378857600"; d="scan'208,217";a="284503227" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 26 Nov 2013 04:07:04 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAQ474mJ024663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 04:07:04 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.153]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 22:07:04 -0600 From: "Shravan Vuggrala (svuggral)" To: Gandhar Gokhale , "ipsec@ietf.org" Thread-Topic: [IPsec] NAT-T and IPv6 Thread-Index: AQHO54vsKnL1mnenUk20+RKmj9oe/Zo3rM8A Date: Tue, 26 Nov 2013 04:07:03 +0000 Message-ID: References: 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: [72.163.206.102] Content-Type: multipart/alternative; boundary="_000_CEBA1CB7DC6Fsvuggralciscocom_" MIME-Version: 1.0 Subject: Re: [IPsec] NAT-T and IPv6 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, 26 Nov 2013 04:07:06 -0000 --_000_CEBA1CB7DC6Fsvuggralciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Its already mentioned in the first section that there is no technical reaso= n why it should not work with IPv6. << As defined in this document, UDP encapsulation of ESP packets is written in terms of IPv4 headers. There is no technical reason why an IPv6 header could not be used as the outer header and/or as the inner header. >> =97 Regards Shravan From: Gandhar Gokhale > Date: Friday, November 22, 2013 at 7:34 PM To: "ipsec@ietf.org" > Subject: [IPsec] NAT-T and IPv6 Hello, RFC3948 states in the Introduction section: =93As defined in this document, UDP encapsulation of ESP packets is writte= n in terms of IPv4 headers. There is no technical reason why an IPv6 heade= r could not be used as the outer header and/or as the inner header. And in section 2.1 it states "o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o receivers MUST NOT depend on the UDP checksum being a zero value" As per RFC 2460 UDP header with 0 checksum must be discarded. If all these statements are seen together it would mean NAT-T for IPv6 as d= escribed in RFC 3498 won't work. Am I missing something? Is NAT-T a valid deployment case for IPv6 network i.e. when the outer heade= r of IPsec tunnel is IPv6? -- Gandhar Gokhale Networking Components Group LSI --_000_CEBA1CB7DC6Fsvuggralciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <436EA21EC65D1D4BAC03B79D3B340897@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Its already mentioned in the first section that there is no technical = reason why it should not work with IPv6. 

<<

 As d= efined in this document, UDP encapsulation of ESP packets is

written in= terms of IPv4 headers. There is no technical reason why

an IPv6 he= ader could not be used as the outer header and/or as the

inner head= er.

>>



=97 
Regards
Shravan 

From: Gandhar Gokhale <gandhar.ietf@gmail.com>
Date: Friday, November 22, 2013 at = 7:34 PM
To: "ipsec@ietf.org" <ips= ec@ietf.org>
Subject: [IPsec] NAT-T and IPv6

Hello,


RFC3948 states in t= he Introduction section:

      

= =93As defined in this document, UDP encapsulation of ESP packets is  w= ritten in terms of IPv4 headers.  There is no technical reason why an = IPv6 header could not be used as the outer header and/or as the inner header.

An= d in section 2.1 it states 


"o  the IPv4 UDP Checksum SHOULD be =
transmitted as a zero value, and 
 o  receivers MUST NOT de=
pend on the UDP checksum being a zero value"

As = per RFC 2460 UDP header with 0 checksum must be discarded.  


If all= these statements are seen together it would mean NAT-T for IPv6 as describ= ed in RFC 3498 won't work. 

Am I m= issing something? 

Is NAT= -T a valid deployment case for IPv6 network i.e. when the outer header of I= Psec tunnel is IPv6?


--
Gandhar Gokhale
Networking Components Group
LSI
 --_000_CEBA1CB7DC6Fsvuggralciscocom_-- From svuggral@cisco.com Mon Nov 25 20:18:14 2013 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 D21191AE113 for ; Mon, 25 Nov 2013 20:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 sFcfaC5ObQ1D for ; Mon, 25 Nov 2013 20:18:13 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id EBC861ADFC6 for ; Mon, 25 Nov 2013 20:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8788; q=dns/txt; s=iport; t=1385439493; x=1386649093; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7IxMthZv2Z8mDJY+TQOAefWIzlqLYMd210YEoeCTp/s=; b=a+fkOEMZ4fchTdFy18K9DNNQcSK2RHwhZiEEgT4byp0tcMCfR5UzeYGx Ck00qvCP2Pr96iumRKtiiXys/Kt9gwPdSch9V0a1kPiE+FRwmgbAxhjUA +EaofNW9h/rMj/j9VvghS26QWJnQSqsjp7DU3FbriBZn8ZyTGIo3cD/+e w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAFMglFKtJXG//2dsb2JhbABZgkNEgQALvCGBJBZ0giUBAQEEgQkCAQgRAwECKAchERQJCAIEARKHbwMPtmsNiAcXjGeBLREBPxiEMwOWKYFrjFmFOIMogXE5 X-IronPort-AV: E=Sophos;i="4.93,771,1378857600"; d="scan'208,217";a="2229882" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-8.cisco.com with ESMTP; 26 Nov 2013 04:18:12 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAQ4ICfv013669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 04:18:12 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.153]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 22:18:12 -0600 From: "Shravan Vuggrala (svuggral)" To: "Shravan Vuggrala (svuggral)" , Gandhar Gokhale , "ipsec@ietf.org" Thread-Topic: [IPsec] NAT-T and IPv6 Thread-Index: AQHO54vsKnL1mnenUk20+RKmj9oe/Zo3rM8AgAADHQA= Date: Tue, 26 Nov 2013 04:18:12 +0000 Message-ID: References: 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: [72.163.206.102] Content-Type: multipart/alternative; boundary="_000_CEBA1F2DDC78svuggralciscocom_" MIME-Version: 1.0 Subject: Re: [IPsec] NAT-T and IPv6 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, 26 Nov 2013 04:18:15 -0000 --_000_CEBA1F2DDC78svuggralciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Missed part of the email=85 In IPv6 the checksum is replaced as 0xFFFF if the checksum yields ZERO and = the responder ignores that. -- Thanks From: Shravan Vuggrala > Date: Tuesday, November 26, 2013 at 9:37 AM To: Gandhar Gokhale >= , "ipsec@ietf.org" > Subject: Re: [IPsec] NAT-T and IPv6 Its already mentioned in the first section that there is no technical reaso= n why it should not work with IPv6. << As defined in this document, UDP encapsulation of ESP packets is written in terms of IPv4 headers. There is no technical reason why an IPv6 header could not be used as the outer header and/or as the inner header. >> =97 Regards Shravan From: Gandhar Gokhale > Date: Friday, November 22, 2013 at 7:34 PM To: "ipsec@ietf.org" > Subject: [IPsec] NAT-T and IPv6 Hello, RFC3948 states in the Introduction section: =93As defined in this document, UDP encapsulation of ESP packets is writte= n in terms of IPv4 headers. There is no technical reason why an IPv6 heade= r could not be used as the outer header and/or as the inner header. And in section 2.1 it states "o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o receivers MUST NOT depend on the UDP checksum being a zero value" As per RFC 2460 UDP header with 0 checksum must be discarded. If all these statements are seen together it would mean NAT-T for IPv6 as d= escribed in RFC 3498 won't work. Am I missing something? Is NAT-T a valid deployment case for IPv6 network i.e. when the outer heade= r of IPsec tunnel is IPv6? -- Gandhar Gokhale Networking Components Group LSI --_000_CEBA1F2DDC78svuggralciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7DF799301E76344B96C1A097F564F168@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Missed part of the email=85 

In IPv6 the checksum is replaced as 0xFFFF if the checksum yields ZERO= and the responder ignores that. 

-- 
Thanks


From: Shravan Vuggrala <svuggral@cisco.com>
Date: Tuesday, November 26, 2013 at= 9:37 AM
To: Gandhar Gokhale <gandhar.ietf@gmail.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] NAT-T and IPv6=

Its already mentioned in the first section that there is no technical = reason why it should not work with IPv6. 

<<

 As d= efined in this document, UDP encapsulation of ESP packets is

written in= terms of IPv4 headers. There is no technical reason why

an IPv6 he= ader could not be used as the outer header and/or as the

inner head= er.

>>



=97 
Regards
Shravan 

From: Gandhar Gokhale <gandhar.ietf@gmail.com>
Date: Friday, November 22, 2013 at = 7:34 PM
To: "ipsec@ietf.org" <ips= ec@ietf.org>
Subject: [IPsec] NAT-T and IPv6

Hello,


RFC3948 states in t= he Introduction section:

      

= =93As defined in this document, UDP encapsulation of ESP packets is  w= ritten in terms of IPv4 headers.  There is no technical reason why an = IPv6 header could not be used as the outer header and/or as the inner header.

An= d in section 2.1 it states 


"o  the IPv4 UDP Checksum SHOULD be =
transmitted as a zero value, and 
 o  receivers MUST NOT de=
pend on the UDP checksum being a zero value"

As = per RFC 2460 UDP header with 0 checksum must be discarded.  


If all= these statements are seen together it would mean NAT-T for IPv6 as describ= ed in RFC 3498 won't work. 

Am I m= issing something? 

Is NAT= -T a valid deployment case for IPv6 network i.e. when the outer header of I= Psec tunnel is IPv6?


--
Gandhar Gokhale
Networking Components Group
LSI
 --_000_CEBA1F2DDC78svuggralciscocom_-- From timo.teras@gmail.com Mon Nov 25 22:30:08 2013 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 5894B1AC3FA for ; Mon, 25 Nov 2013 22:30:08 -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 6H1at6MA815f for ; Mon, 25 Nov 2013 22:30:06 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id CB47B1AE175 for ; Mon, 25 Nov 2013 22:30:05 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so3786398lam.7 for ; Mon, 25 Nov 2013 22:30:03 -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=qitvxSWExMhUIDwWL8cSPiRiO7aQUyod/qp2b7WeyFg=; b=B5yKg31Ni+c/nZ58QFmy8Vmwx10+gjF8DU/KKzSq+kJh3vYB7Zm3WeHwqWQzr2aDQm yu9DLNknggDOb1iddlJwtn+iyH7od59QhddtuyytzhlVl0VoPAkMwdtZBGaGIkxuv+26 Z5AJGGWHRFFQN7JlKEG9Sanxt6l4PzzJKXqDEJtVd30joExdQBTdinJUZM69ZKdDRRzA tr3mWQjx/pThCGBUE/+g5tu0BWojbauqG/BKk4nLWdIvgFY81+vWd02ihc6vcuMB67WD AhFJJ6kxE0KCmkyZygNQVUPtHQoYZxDO4z7g6ztie2VqR3OzoML6WSEZt86jPfhhP2+k pFBw== X-Received: by 10.112.130.37 with SMTP id ob5mr3743338lbb.35.1385447402887; Mon, 25 Nov 2013 22:30:02 -0800 (PST) Received: from vostro ([83.145.235.199]) by mx.google.com with ESMTPSA id go4sm40662384lbc.3.2013.11.25.22.30.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2013 22:30:02 -0800 (PST) Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= Date: Tue, 26 Nov 2013 08:29:59 +0200 From: Timo Teras To: "Mike Sullenberger (mls)" Message-ID: <20131126082959.679c96d4@vostro> In-Reply-To: <9D83DE546CB6DC47A3AE04086FDE35F523FD7185@xmb-aln-x06.cisco.com> References: <20131122220529.0c5dba7d@vostro> <9D83DE546CB6DC47A3AE04086FDE35F523FD7185@xmb-aln-x06.cisco.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; i486-alpine-linux-uclibc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] DMVPN thoughts 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, 26 Nov 2013 06:30:08 -0000 On Tue, 26 Nov 2013 01:41:36 +0000 "Mike Sullenberger (mls)" wrote: > Thank you very much for your comments. I had not realized that > anyone had tried to implement our additions to NHRP, it is nice > to hear that it wasn't "too hard" to do. :) > I have a couple of comments, inline. Likewise. > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Timo Teras > > Sent: Friday, November 22, 2013 12:05 PM > > To: ipsec@ietf.org > > Subject: [IPsec] DMVPN thoughts > > > >[snip] > > However, after brief read of the draft, it seems to be missing at > > least: > > - Authentication extension (code 7; from RFC 2332) payload format > > which seems to be Cisco specific - at least RFC 2332 does not > > specify it > > [Mike Sullenberger] > Yes you are correct, back in 1995 when the initial NHRP > implementation was done, only a simple clear-text authentication was > done using a SPI value of 1 and not including the src-addr field, > just the Authentication Data field. Since then we have thought about > fixing this, but since DMVPN is encrypted with IPsec and we use the > strong authentication in ISAKMP/IKEv2, there hasn't been a big > impetus to get this fixed. Yes, I figured this. IMHO, the whole NHRP authentication is kinda redundant since IPsec is used - but I just implemented it for completeness. Not sure if it makes sense to use it in new installs. Or does it add something on some scenarios? Or would it make sense to specify that it is not recommended to be used. > > - NAT address extension (code 9; Cisco specified, and apparently > > even conflicts with some RFC drafts), and it's CIE based payload > > content specification > > [Mike Sullenberger] > This is true. In hind-sight we probably should have made this a > vendor private extension. Agreed. I believe this is more or less needed for proper interop in scenarios where spoke is behind NAT. So this should be documented. > > - The specifics how Request ID field should be used. My experience > > shows that Request ID is stored along with the registrations, and > > needs to match in Purge requests for the Purge operation to > > succeed (IMHO, such Request ID matching should not be done). > > [Mike Sullenberger] > I would have to check this, but I don't think that we bother to match > up the request-id from a purge message with the original resolution > request/reply that created the mapping entry. We do match the > request-id between the resolution request and reply. I observed this in 2008 - could have changed since then. But at least back then I was unable to purge a binding unless the Request ID matched to the one in the original Registration Request. > > The one defect for me with DMVPN was that hubs are not automatically > > discovered (or maybe there's something for this nowadays?). Thus > > opennhrp has one extension: "dynamic-map" configuration stanza. It > > binds the NHSes to a DNS entry. The A records of that DNS name are > > used as NBMA addresses of the NHSes. During initial NHRP > > registration the NHRP Registration Requests are sent to the network > > broadcast address with hop count 1, and the NHS network address is > > picked up from the NHRP Registration Reply. The list of NHS servers > > is of course synchronized regularly. So as minimum, this or some > > similar hub autodetection mechanism should be added to dmvpn spec. > > [Mike Sullenberger] > We do have this mechanism now. You can specify the NHS as a FQDN and > at tunnel initialization time we will use DNS to translate the name > to an address. From then on the address is used, though if access to > the NHS goes down then we initial retry with the address, but if that > still fails we will do another DNS lookup on the name in case the > address has changed. We also use the mechanism as described in > RFC2332 to get the NHS network address from the NHRP registration > reply. Oh - I somehow missed the RFC2332 on that. I need to fix that in my code. How you handle if the FQDN has multiple A-records? Do you just pick one to be hub from it, or consider all as hubs? opennhrp will use them all as separate hubs - so each client needs exactly one FQDN to pull all hubs; and if records are added/removed it synchronizes to new set of hubs properly. > > Additionally, running multiple DMVPN instances on single router > > would require a standards compliant way to negotiate GRE key in IKE > > traffic selectors. There seems to have been discussions about that > > back in 2008 on this list, but it seems nothing came out of it. So > > I think this issue should be brought to discussion again too. > > [Mike Sullenberger] > I am not really that "keen" on adding GRE tunnel key negotiation to > IKE. I prefer keeping these two layers a little more separated. > Though I possibly could be convinced otherwise. How else would you handle per-dmvpn authentication then? If you have two dmvpn instances that require different certs, it's not possible to properly authenticate the GRE traffic unless per-key selector is used. Otherwise I could give network A's cert and start sending stuff on network B's GRE tunnel. As somewhat related, but additional feature, opennhrp also allows hooks on peer-up and peer-register events. And I also ship a rudimentary example hook that pulls the IKE certificate, and checks it's subjectAltName to have the GRE address requested in NHRP Registration Request. > > I personally do like how the DMVPN stack works and would like to > > see it standardized. However, I do understand that it might not be > > perfect fit or even preference for all. As additional note - after reading the other drafts. I think I like the dmvpn approach most. The IKE extension thingy is certainly interesting too. Granted the intial implementation draft-sathyanarayan-ipsecme-advpn-00 looks simpler than dmvpn. But but I fear that more and more IKE extensions need to be specified to handle things that DMVPN leaves to be care of routing protocols. E.g. in DMVPN it is simple to setup two gateway nodes for one site - and do multipath, or primary-backup setups using BGP / OSPF. I believe those setups would need additional IKE extensions to work properly in the suggested draft-sathyanarayan-ipsecme-advpn-00 setup. So IMHO, the big advantage in DMVPN is that network layers are done properly, instead of trying to stuff all functionality to one place. - Timo From gandhar.ietf@gmail.com Tue Nov 26 01:57:58 2013 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 AC8FA1AE133 for ; Tue, 26 Nov 2013 01:57:58 -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 MGb6jTCD-jBa for ; Tue, 26 Nov 2013 01:57:57 -0800 (PST) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id BB56C1AD68D for ; Tue, 26 Nov 2013 01:57:56 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id lf12so3584162vcb.21 for ; Tue, 26 Nov 2013 01:57:56 -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=FSOuWKUS9qNCnPGOQilXqDzzzUv/HHQ2XNhSmg0yWto=; b=uN83sMpCtmj44w5rY6MYbgxs3nJTuCFWlBKDKNofsz8mT6LBz+rgdCS9XKan/8PiTb nB0RUXkveft71fx5k8aJ7LIS0kKWpvqwDcirtbAxx0BmOdQxn0uFHA0CoCUdr5+Md4LM JN7tj/4zIz71WDYqvcoDmrlCe938Pgrfma1JzPGgtULMpJy24j3EJPwC9zr087K9QOkp mZ8vFMc5SiBBCB+Ue2rrJxCV4Hv5MZNQgreS8YpFfamtoVFeuaA0Sf/pqncl93m3Vvs0 t1YCd14EIVM86FFLzh8ignX8+RavsAyZ9/UbBSE5R8eM0tuLVaD5sDvqVpEgdQKfzoAQ Rt5w== MIME-Version: 1.0 X-Received: by 10.220.11.7 with SMTP id r7mr29879210vcr.12.1385459876503; Tue, 26 Nov 2013 01:57:56 -0800 (PST) Received: by 10.58.164.195 with HTTP; Tue, 26 Nov 2013 01:57:56 -0800 (PST) In-Reply-To: <21139.27318.60621.427765@fireball.kivinen.iki.fi> References: <21139.27318.60621.427765@fireball.kivinen.iki.fi> Date: Tue, 26 Nov 2013 15:27:56 +0530 Message-ID: From: Gandhar Gokhale To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Cc: ipsec@ietf.org Subject: Re: [IPsec] NAT-T and IPv6 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, 26 Nov 2013 09:57:58 -0000 Thank you Tero. It clarifies my doubt. However, with a SHOULD clause it's not quite apparent in the RFC that this is just an 'optimization' for IPv4. And since the RFC claims that there is no technical reason for this not to work with IPv6 it becomes incompatible set of statements. Now, seen in the light of optimization it makes sense to me. SHOULD clause can be defied if there's a strong reason for it and incompatibility of IPv6 is sufficiently strong reason to defy this SHOULD, I suppose. On Mon, Nov 25, 2013 at 8:50 PM, Tero Kivinen wrote: > Gandhar Gokhale writes: >> As defined in this document, UDP encapsulation of ESP packets is >> written in terms of IPv4 headers. There is no technical reason why >> an IPv6 header could not be used as the outer header and/or as the >> inner header. > > Of course we hope nobody every makes NATs for IPv6, but having IPv4 > NAT and then having IPv6 packets inside is of course possibility. > >> And in section 2.1 it states >> >> "o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and >> >> o receivers MUST NOT depend on the UDP checksum being a zero value" > > Note that it only talks about IPv4 UDP Checksum field, it does not > specify such recommendation for IPv6 UDP checksum. > >> As per RFC 2460 UDP header with 0 checksum must be discarded. > > Which is why the with the IPv6 you must calculate UDP checksum when > sending the packet. Using the IPv4 UDP checksum of 0 is an > optimization, which removes useless checksum calculations of the UDP > packet, and that optimization cannot be used for IPv6. > >> If all these statements are seen together it would mean NAT-T for IPv6 as >> described in RFC 3498 won't work. >> >> Am I missing something? > > I think you are missing the "IPv4" word in the quoted context. It does > not claim you can use that optimization for IPv6. For IPv6 you must > calculate checksum properly when sending UDP encapsulated ESP packets > over IPv6. > > For more information check the RFC3715 which have bit more text about > IPv6 and NATs, and if I remember right there might have also been some > discussion about this in the IPsec mailing list during the development > of this rfc. > >> Is NAT-T a valid deployment case for IPv6 network i.e. when the >> outer header of IPsec tunnel is IPv6? > > Yes, but hopefully people will not do NATs on IPv6 :-) > > There are use cases for static stateless NATs in the IPv6, i.e. prefix > changes and you do not want to renumber your whole network, but IPv4 > style dynamic NATs should not be needed in IPv6. > -- > kivinen@iki.fi -- Gandhar Gokhale Networking Components Group LSI From kivinen@iki.fi Tue Nov 26 06:44:53 2013 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 8774F1AD9AE for ; Tue, 26 Nov 2013 06:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 9SE9uT3IRph6 for ; Tue, 26 Nov 2013 06:44:51 -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 DE7F31AD8F5 for ; Tue, 26 Nov 2013 06:44:49 -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 rAQEijM3027946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Nov 2013 16:44:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rAQEiiOl028718; Tue, 26 Nov 2013 16:44:44 +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: <21140.46044.770517.637673@fireball.kivinen.iki.fi> Date: Tue, 26 Nov 2013 16:44:44 +0200 From: Tero Kivinen To: Gandhar Gokhale In-Reply-To: References: <21139.27318.60621.427765@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 9 min Cc: ipsec@ietf.org Subject: Re: [IPsec] NAT-T and IPv6 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, 26 Nov 2013 14:44:53 -0000 Gandhar Gokhale writes: > Thank you Tero. It clarifies my doubt. > However, with a SHOULD clause it's not quite apparent in the RFC that > this is just an 'optimization' for IPv4. And since the RFC claims that > there is no technical reason for this not to work with IPv6 it becomes > incompatible set of statements. I think the SHOULD clause is VERY clear that it only covers IPv4. The "IPv4" text was added there in the -08 version of the draft-ietf-ipsec-udp-encaps draft just because there was comment that checksum cannot be zero on IPv6... And NAT-T does work with IPv6, but some things are different with IPv4 and IPv6... > Now, seen in the light of optimization it makes sense to me. SHOULD > clause can be defied if there's a strong reason for it and > incompatibility of IPv6 is sufficiently strong reason to defy this > SHOULD, I suppose. There is nothing in the document saying how you should set checksum field if you are using IPv6. There is SHOULD saying that "IPv4 UDP Checksum" SHOULD be transmitted as zero. That SHOULD does not apply at all, unless you are using IPv4. Even if you are using this with IPv6, you can set the "IPv4 UDP checksum" to zero, but of course "IPv6 UDP checksum" is completely different thing, and that must be set, as defined in the IPv6 specifications. -- kivinen@iki.fi From mls@cisco.com Tue Nov 26 14:45:34 2013 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 2E0B41AE026 for ; Tue, 26 Nov 2013 14:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 oVb_uhuZfQo8 for ; Tue, 26 Nov 2013 14:44:56 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCCB1ADFA6 for ; Tue, 26 Nov 2013 14:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10153; q=dns/txt; s=iport; t=1385505893; x=1386715493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aVdSrmkUNTvgfhK0P+Jq2br6+iYEVaKvKirEXUOTSEQ=; b=aw4xkmtRdy1QDJC39sIo2DryZD+KRIhtmVw7a7gCiOfvhHnwxuiSW7Y5 Run/DiqHEmHBYgBTjGYCdTRP1riG+Z1Cia9/cCJ4c469XGejxkunfa2E9 vZz/jjmYzh3IgSeDMxGE0ZT1TiJqtZV6Tf6xCyLF6/5e9aXtcIF0aQfk4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIsjlVKtJV2c/2dsb2JhbABRCIMHgQu7A4EqFnSCJQEBAQMBeQUHBAIBCBEEAQEBCg4PByERFAkIAgQOBQiHZwMJBQG3Pw2IDBeMbIElFSUxBwYSgwiBEwOJCo0fjkWFOYMogio X-IronPort-AV: E=Sophos;i="4.93,778,1378857600"; d="scan'208";a="284742124" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 26 Nov 2013 22:44:53 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAQMiqkg011993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 22:44:52 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.67]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 16:44:52 -0600 From: "Mike Sullenberger (mls)" To: Timo Teras Thread-Topic: [IPsec] DMVPN thoughts Thread-Index: AQHO575a5ix3rggJ0kqw7LvAWvejAZo2tMNQgADCMYCAAKBcQA== Date: Tue, 26 Nov 2013 22:44:51 +0000 Message-ID: <9D83DE546CB6DC47A3AE04086FDE35F523FD78CE@xmb-aln-x06.cisco.com> References: <20131122220529.0c5dba7d@vostro> <9D83DE546CB6DC47A3AE04086FDE35F523FD7185@xmb-aln-x06.cisco.com> <20131126082959.679c96d4@vostro> In-Reply-To: <20131126082959.679c96d4@vostro> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.69.88.254] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Mike Sullenberger \(mls\)" Subject: Re: [IPsec] DMVPN thoughts 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, 26 Nov 2013 22:45:34 -0000 Timo, Comments Inline. Mike. Mike Sullenberger, DSE mls@cisco.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 .:|:.:|:. Customer Advocacy=A0=A0=A0=A0=A0=A0=A0=A0=A0 CISCO > -----Original Message----- > From: Timo Ter=E4s [mailto:timo.teras@gmail.com] On Behalf Of Timo > Teras > Sent: Monday, November 25, 2013 10:30 PM > To: Mike Sullenberger (mls) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] DMVPN thoughts >=20 > On Tue, 26 Nov 2013 01:41:36 +0000 > "Mike Sullenberger (mls)" wrote: >=20 > > Thank you very much for your comments. I had not realized that > > anyone had tried to implement our additions to NHRP, it is nice > > to hear that it wasn't "too hard" to do. >=20 > :) >=20 > > I have a couple of comments, inline. >=20 > Likewise. >=20 > > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Timo > Teras > > > Sent: Friday, November 22, 2013 12:05 PM > > > To: ipsec@ietf.org > > > Subject: [IPsec] DMVPN thoughts > > > > > >[snip] > > > However, after brief read of the draft, it seems to be missing at > > > least: > > > - Authentication extension (code 7; from RFC 2332) payload format > > >which seems to be Cisco specific - at least RFC 2332 does not > > >specify it > > > > [Mike Sullenberger] > > Yes you are correct, back in 1995 when the initial NHRP > > implementation was done, only a simple clear-text authentication > > was done using a SPI value of 1 and not including the src-addr field, > > just the Authentication Data field. Since then we have thought > > about fixing this, but since DMVPN is encrypted with IPsec and=20 > > we use the strong authentication in ISAKMP/IKEv2, there hasn't=20 > > been a big impetus to get this fixed. >=20 > Yes, I figured this. IMHO, the whole NHRP authentication is kinda > redundant since IPsec is used - but I just implemented it for > completeness. Not sure if it makes sense to use it in new installs. Or > does it add something on some scenarios? Or would it make sense to > specify that it is not recommended to be used. > [Mike Sullenberger]=20 There is one use case where we run DMVPN without crypto, because the customer has their own inline hardware encryptors. They like to use DMVPN in this case, because it presents a few tunnel flows to the encryptor instead of thousands of user data flows. Making the encryptors job easier. So we will likely keep it, though it wouldn't hurt to go ahead and implement a SHA(2) authentication to go with the clear-text password. =20 > > > - NAT address extension (code 9; Cisco specified, and apparently > > > even conflicts with some RFC drafts), and it's CIE based payload > > > content specification > > > > [Mike Sullenberger] > > This is true. In hind-sight we probably should have made this a > > vendor private extension. >=20 > Agreed. I believe this is more or less needed for proper interop in > scenarios where spoke is behind NAT. So this should be documented. [Mike Sullenberger]=20 Yes, we will go ahead and document this in an update to the draft. >=20 > > > - The specifics how Request ID field should be used. My experience > > > shows that Request ID is stored along with the registrations, and > > > needs to match in Purge requests for the Purge operation to > > > succeed (IMHO, such Request ID matching should not be done). > > > > [Mike Sullenberger] > > I would have to check this, but I don't think that we bother to match > > up the request-id from a purge message with the original resolution > > request/reply that created the mapping entry. We do match the > > request-id between the resolution request and reply. >=20 > I observed this in 2008 - could have changed since then. But at least bac= k > then I was unable to purge a binding unless the Request ID matched to > the one in the original Registration Request. [Mike Sullenberger]=20 I know that over the last few years we have put some more work into making NHRP purges work better. So perhaps we fixed this.=20 > > > The one defect for me with DMVPN was that hubs are not=20 > > > automatically discovered (or maybe there's something for this=20 > > > nowadays?). Thus opennhrp has one extension: "dynamic-map"=20 > > > configuration stanza. It binds the NHSes to a DNS entry. The A=20 > > > records of that DNS name are used as NBMA addresses of the=20 > > > NHSes. During initial NHRP registration the NHRP Registration=20 > > > Requests are sent to the network broadcast address with hop=20 > > > count 1, and the NHS network address is picked up from the NHRP=20 > > > Registration Reply. The list of NHS servers is of course synchronized= =20 > > > regularly. So as minimum, this or some similar hub autodetection=20 > > > mechanism should be added to dmvpn spec. > > > > [Mike Sullenberger] > > We do have this mechanism now. You can specify the NHS as a FQDN > > and at tunnel initialization time we will use DNS to translate the=20 > > name to an address. From then on the address is used, though if > > access to the NHS goes down then we initial retry with the address,=20 > > but if that still fails we will do another DNS lookup on the name in > > case the address has changed. We also use the mechanism as > > described in RFC2332 to get the NHS network address from the NHRP > > registration reply. >=20 > Oh - I somehow missed the RFC2332 on that. I need to fix that in my > code. >=20 [Mike Sullenberger]=20 Yes it is a cute trick of setting the destination protocol address to be th= e same as the source protocol address. Then when the NHS responds it replaces the destination protocol address with its own address and the NHC picks it up from there. Note, we did simplify the NHRP registration processing, in that we only allow the NHRP registration to go one hop. We didn't see any real usefulness in allowing NHRP registrations to be routed. > How you handle if the FQDN has multiple A-records? Do you just pick > one to be hub from it, or consider all as hubs? opennhrp will use them > all as separate hubs - so each client needs exactly one FQDN to pull all > hubs; and if records are added/removed it synchronizes to new set of > hubs properly. >=20 [Mike Sullenberger]=20 That is an interesting idea. We just pick the first one from the list and use that, another NHC may pick a different one from the list, due to=20 DNS A record randomization, or any other criteria that the DNS chooses to use to sort the list. > > > Additionally, running multiple DMVPN instances on single router > > > would require a standards compliant way to negotiate GRE key in IKE > > > traffic selectors. There seems to have been discussions about that > > > back in 2008 on this list, but it seems nothing came out of it. So I > > > think this issue should be brought to discussion again too. > > > > [Mike Sullenberger] > > I am not really that "keen" on adding GRE tunnel key negotiation to > > IKE. I prefer keeping these two layers a little more separated. > > Though I possibly could be convinced otherwise. >=20 > How else would you handle per-dmvpn authentication then? If you > have two dmvpn instances that require different certs, it's not possible > to properly authenticate the GRE traffic unless per-key selector is used. >=20 > Otherwise I could give network A's cert and start sending stuff on > network B's GRE tunnel. >=20 [Mike Sullenberger]=20 I have to check exactly how it is done, but we can tie a GRE tunnel interface to an ISAKMP/IKEv2 instance and then ISAKMP/IKEv2 instance to a CERT chain. So when an NHC authenticates via a specific CERT chain then it is mapped/locked into a specific GRE tunnel interface instance. The NHC would then NHRP register, and if that isn't successful then the ISAKMP/IKEv2/IPsec SAs are cleared. So far this hasn't been something we have worried too much about, but with opening this up to hosts we May have to revisit this to make sure there isn't a security hole. > As somewhat related, but additional feature, opennhrp also allows > hooks on peer-up and peer-register events. And I also ship a > rudimentary example hook that pulls the IKE certificate, and checks it's > subjectAltName to have the GRE address requested in NHRP > Registration Request. > [Mike Sullenberger]=20 We added something like this, called Smart-spoke, for NHRP resolution Requests, which allows the receiver of an NHRP resolution request to execute a script, to take some action, one of which would be to accept or reject the NHRP resolution request, but it can be used to do just about anything. We need to look into expanding this to NHRP registration request/reply and NHRP resolution reply. We also have syslog and SNMP notifications for all sorts of NHRP events. > > > I personally do like how the DMVPN stack works and would like to > > > see it standardized. However, I do understand that it might not be > > > perfect fit or even preference for all. >=20 > As additional note - after reading the other drafts. I think I like the > dmvpn approach most. The IKE extension thingy is certainly interesting > too. >=20 > Granted the intial implementation draft-sathyanarayan-ipsecme-advpn- > 00 > looks simpler than dmvpn. But but I fear that more and more IKE > extensions need to be specified to handle things that DMVPN leaves to > be care of routing protocols. >=20 > E.g. in DMVPN it is simple to setup two gateway nodes for one site - and > do multipath, or primary-backup setups using BGP / OSPF. I believe > those setups would need additional IKE extensions to work properly in > the suggested draft-sathyanarayan-ipsecme-advpn-00 setup. >=20 > So IMHO, the big advantage in DMVPN is that network layers are done > properly, instead of trying to stuff all functionality to one place. [Mike Sullenberger]=20 This was one of the main tenets of DMVPN, I.e. making sure to use a layered model (routing, mapping (NHRP), tunneling (GRE), and encrypt/auth(IPsec) and keeping each layer separated. Thanks, Mike. =20 > - Timo From TurnerS@ieca.com Sat Nov 30 08:38:57 2013 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 42F391AE454 for ; Sat, 30 Nov 2013 08:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 iXfoHc_O_QH3 for ; Sat, 30 Nov 2013 08:38:55 -0800 (PST) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.88.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7B75B1AE44B for ; Sat, 30 Nov 2013 08:38:55 -0800 (PST) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id F125E162AA2DE; Sat, 30 Nov 2013 10:38:53 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id D1A9F162AA2BA for ; Sat, 30 Nov 2013 10:38:53 -0600 (CST) Received: from [173.73.126.4] (port=59516 helo=[192.168.1.100]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VmnZE-0004YI-53 for ipsec@ietf.org; Sat, 30 Nov 2013 10:38:52 -0600 From: Sean Turner Content-Type: multipart/signed; boundary="Apple-Mail=_158F5803-3DF0-4A54-A814-CB251E5F15A1"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Date: Sat, 30 Nov 2013 11:38:49 -0500 References: <20131119163930.7275.53854.idtracker@ietfa.amsl.com> <528BD2C6.7060701@bbn.com> <528BE14E.1050503@gmail.com> To: IPsecme WG In-Reply-To: X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.126.4 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.100]) [173.73.126.4]:59516 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: Re: [IPsec] I-D ACTION:draft-kent-ipsecme-ah-rfc4302bis-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: Sat, 30 Nov 2013 16:38:57 -0000 --Apple-Mail=_158F5803-3DF0-4A54-A814-CB251E5F15A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 20, 2013, at 10:36, Paul_Koning@Dell.com wrote: >=20 > On Nov 19, 2013, at 5:08 PM, Yaron Sheffer = wrote: >=20 >> On 11/19/2013 11:06 PM, Stephen Kent wrote: >>> updated versions of RFC 4301, 4302, and 4303 have been posted: >>>=20 >>>=20 >> Thank you Steve for working on these drafts. These drafts are = targeted at republication as Internet Standards. As promised in = Vancouver, I would like to open the question of whether we should be = republishing RFC 4302 - AH. >>=20 >> My personal opinion is that we should not. We have downgraded AH and = consistently discouraged its use, replacing it by ESP-null. People are = obviously free to implement it even if it remains Proposed Standard, but = why give the wrong message by promoting it to IS? >=20 > I agree with that. >=20 > paul My thinking around also uplifting AH to IS was based on conversations = with authors of the following draft when it came to the IESG: = https://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601-update-survey-repo= rt/ I=92m double checking that they did in fact implement AH based on RFC = 4601 or whether they implemented ESP based on RFC 5796. I like to = propose that we postpone the discussion of progressing AH until I report = back, but I would like to proceed with moving 4301 and 4303 to IS. The = only real difference is that downrefs to RFC 4302 will need to be called = out in the IETF LCs to other drafts. spt= --Apple-Mail=_158F5803-3DF0-4A54-A814-CB251E5F15A1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMTEzMDE2Mzg1MFowIwYJKoZIhvcNAQkEMRYEFCTwJuhP9Wv5Mw3uAur9vs1Y YgrhMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQDdhXU3Wt02T0puvtvBsgU5zrQ0 Mt9uQxld1tTajDUfZG8K5tFKMQwWWGkxoLtVuPAve9J1ZUZoz6ew8Ad4ej5PTJg+bj6hBsd6Almz SI/bhj1kgBvk3NOQ0eQSZMbapa2tF65mxOME5uR4xOM1GMvXAfZuSubn761cdGvmo/0KLBknbMPl /1vlxGjFS1g1Ipcuoz5FZnf5tNPWq+aMW0xgw8WRgSDHVHJhvu9Hf30Lk3CcbNzfyrAZB5hrYc2C gDpl86H7z36yXClP13mdzHe2Z/NoIC/mWrPDi/jguoAwUfshgN8j/k2QXlQcJqLNxMgosu/VJX6Y AKjiVp4QKeGHAAAAAAAA --Apple-Mail=_158F5803-3DF0-4A54-A814-CB251E5F15A1--