From mailman-bounces@ietf.org Sat Jan 1 05:54:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08493 for ; Sat, 1 Jan 2005 05:54:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgDp-0006Ut-0u for ipsec-archive@lists.ietf.org; Sat, 01 Jan 2005 05:10:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipsec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:02:59 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipsec-archive@lists.ietf.org: List Password // URL ---- -------- ipsec@ietf.org ogcewi https://www1.ietf.org/mailman/options/ipsec/ipsec-archive%40lists.ietf.org From ipsec-bounces@ietf.org Sun Jan 2 04:53:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20163 for ; Sun, 2 Jan 2005 04:53:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cl2IU-0004lY-23; Sun, 02 Jan 2005 04:45:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cl2Fh-0003q5-99 for ipsec@megatron.ietf.org; Sun, 02 Jan 2005 04:42:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19736 for ; Sun, 2 Jan 2005 04:42:19 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cl2Rb-0007I1-Ov for ipsec@ietf.org; Sun, 02 Jan 2005 04:54:40 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j029fmug217114 for ; Sun, 2 Jan 2005 09:41:48 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j029gbes151016 for ; Sun, 2 Jan 2005 10:42:37 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j029fl7S001806 for ; Sun, 2 Jan 2005 10:41:48 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j029flqN001798; Sun, 2 Jan 2005 10:41:47 +0100 Received: from zurich.ibm.com (sig-9-145-248-133.de.ibm.com [9.145.248.133]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA80118; Sun, 2 Jan 2005 10:41:35 +0100 Message-ID: <41D7C1CE.5020104@zurich.ibm.com> Date: Sun, 02 Jan 2005 10:41:34 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Stephen Kent Subject: Re: [Ipsec] Re: [Fwd: Review of draft-ietf-ipsec-rfc2401bis-05.txt [Re: New batch of Last Call Documents]] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Stephen Kent wrote: > At 8:02 PM -0800 12/28/04, Vishwas Manral wrote: > >> Hi Steve, >> >> As you said "such behavior by intermediate routers would tend to cause >> havoc with the traffic anyway, so I would hope that this would not be a >> common occurrence". >> >> Would we however want to put a comment regarding the same? The text to >> add could be "Changing DSCP values en-route can result in different >> class of packets on the same SA and SHOULD be avoided." >> >> Sorry for the confusion caused. >> >> Thanks, >> Vishwas > > > We could add an advisory statement that warns folks, e.g., > > "If significant reordering 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." > > Steve This is certainly reasonable. Let's try to construct an example where it might conceivably happen: a video stream with two types of packet, i.e. coarse and fine resolution. A possible reason for varying the DSCP is to favor the coarse packets under congestion, so that they get through promptly even if the fine detail is lost. But for that to happen en route requires deep packet inspection (of non-encrypted packets) by a device that magically knows that the data packets are a video stream. This seems pretty unlikely. The normal scenario is that it's the video source itself that marks the coarse and fine packets appropriately - and that would lead to two SAs, not to an SA with a varying DSCP value. Brian _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 3 04:44:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10167 for ; Mon, 3 Jan 2005 04:44:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClOiO-0004In-Et; Mon, 03 Jan 2005 04:41:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClOZy-000268-St for ipsec@megatron.ietf.org; Mon, 03 Jan 2005 04:32:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09363 for ; Mon, 3 Jan 2005 04:32:43 -0500 (EST) Received: from smtp.wineasy.se ([195.42.198.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClOm3-0007fC-CQ for ipsec@ietf.org; Mon, 03 Jan 2005 04:45:18 -0500 Received: from easymail.wineasy.se (easymail.wineasy.se [195.42.198.3] (may be forged)) by smtp.wineasy.se with ESMTP id j039WPbS008643; Mon, 3 Jan 2005 10:32:25 +0100 Received: by easymail.wineasy.se (Postfix, from userid 33) id A47DC23DB9; Mon, 3 Jan 2005 10:32:24 +0100 (CET) Content-Type: multipart/mixed; boundary="----------=_1104744744-10561-0" MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: Magnus Alstr=?iso-8859-1?Q?=F6?=m To: Tero Kivinen Message-Id: <20050103093224.A47DC23DB9@easymail.wineasy.se> Date: Mon, 3 Jan 2005 10:32:24 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ipsec@ietf.org Subject: [Ipsec] RE: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format... ------------=_1104744744-10561-0 Content-Type: text/plain Content-Disposition: inline X-MIME-Autoconverted: from 8bit to base64 by smtp.wineasy.se id j039WPbS008643 Content-Transfer-Encoding: base64 SGkgVGVybywNDQoNDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gSSBndWVzc2VkIHRoYXQg dGhlIHNpZ24gb3BlcmF0aW9uIHNob3VsZCBiZSBhIGhhc2grc2lnbiBvcGVyYXRpb24sIGJ1 dCB0aGUgcXVlc3Rpb24gaXMgc3RpbGwgaG93IHRoZSBoYXNoaW5nIHNob3VsZCBiZSBwZXJm b3JtZWQuIFRoZXJlIGlzIGEgcHJmIGZ1bmN0aW9uIG5lZ290aWF0ZWQsIGJ1dCBubyBoYXNo IGFsZ29yaXRobS4gU2hvdWxkIEkgdGFrZSB0aGUgZGF0YSBhbmQgY3JlYXRlIGEgaG1hYz8g T3Igc2hvdWxkIEkgdGFrZSB3aGF0ZXZlciBhbGdvcml0aG0gSSBwcmVmZXIgYW5kIGVuY29k ZSB0aGUgZGlnZXN0IHRvIGEgZGVyLWVuY29kZWQgZGlnZXN0LWluZm8gYmVmb3JlIEkgc2ln bj8gIA0NCg0NCnJlZ2FyZHMgTWFnbnVzDQ0KDQ0KDQ0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0NCkRhdHVtOiBUaHUsIDMwIERlYyAyMDA0IDExOjQ3OjQzICswMjAwDQ0KRnLl bjogVGVybyBLaXZpbmVuIDxraXZpbmVuQGlraS5maT4NDQpUaWxsOiAgTWFnbnVzIEFsc3Ry 9m0gPG1hZ251cy5hbHN0cm9tQGludGVycGVhay5zZT4NDQpDYzogIGlwc2VjQGlldGYub3Jn DQ0KxG1uZTogW0lwc2VjXSBJS0V2Mg0NCg0NCk1hZ251cyBBbHN0cvZtIHdyaXRlczoNDQo+ IDEuMyBUaGUgQ1JFQVRFX0NISUxEX1NBIEV4Y2hhbmdlDQ0KPiANDQo+IEluIHRoZSBDSElM RF9TQSBjcmVhdGVkIGFzIHBhcnQgb2YgdGhlIGluaXRpYWwgZXhjaGFuZ2UsIGEgc2Vjb25k IEtFDQ0KPiBwYXlsb2FkIGFuZCBub25jZSBNVVNUIE5PVCBiZSBzZW50LiBUaGUgcmVzdWx0 IGlzIHRoYXQgdGhlIENISUxEX1NBDQ0KPiB3aWxsIGFsd2F5cyB1c2UgdGhlIHNhbWUgREgg Z3JvdXAgKG9yIG5vbmUpLiBTaG91bGQgeW91IG5vdCBiZQ0NCj4gYWxsb3dlZCB0byB1c2Ug ZGlmZmVyZW50IGdyb3Vwcz8gDQ0KDQ0KTm8uIFRoZXJlIGlzIG5vIHBvaW50IG9mIHVzaW5n IGRpZmZlcmVudCBncm91cCB0aGVyZS4gSW4gcXVpdGUgbWFueQ0NCmNhc2VzIHRoaXMgQ0hJ TERfU0Egd2lsbCBhbHNvIGJlIHRoZSBvbmx5IFNBIGNyZWF0ZWQuIEhhdmluZyBvbmx5IG9u ZQ0NCmdyb3VwIHRoZXJlIGFuZCBvbmx5IG9uZSBESCBjYWxjdWxhdGlvbiBzaW1wbGlmaWVz IHRoZSBwcm90b2NvbCBhbmQNDQpyZWR1Y2VzIGNhbGN1bGF0aW9uIG92ZXJoZWFkLg0NCg0N Cj4gMi4xNS4gQXV0aGVudGljYXRpb24gb2YgdGhlIElLRV9TQSAoMi4xNSkNDQo+IA0NCj4g QWNjb3JkaW5nIHRvIHRoZSBkcmFmdCBzaG91bGQgdGhlIGF1dGhlbnRpY2F0aW9uIGRhdGEg YmUgY3JlYXRlZCBieQ0NCj4gYXBwZW5kaW5nOiA8bWVzc2FnZT4sIDxub25jZV94PiBhbmQg PHByZihTS19weCxpZF94KT4uIEFzIGEgcmVzdWx0DQ0KPiB3aWxsIHRoZSBjb21wbGV0ZSBk YXRhIHRvIGJlIHNpZ25lZCBiZSBxdWl0ZSBsYXJnZSwgb2YgY291cnNlDQ0KPiBkZXBlbmRp bmcgb24gdGhlIG9yaWdpbmFsIG1lc3NhZ2UuIEhvdyBhcmUgdGhhdCBzaWduYXR1cmUgc3Vw cG9zZWQNDQo+IHRvIGJlIGNyZWF0ZWQ/DQ0KDQ0KU2lnbmluZyBpbmNsdWRlcyB0aGUgbm9y bWFsIHBoYXNlIG9mIHRoZSBjYWxjdWxhdGluZyBoYXNoIG92ZXIgdGhlDQ0KZGF0YSBiZWZv cmUgYWN0dWFsbHkgc2lnbmluZyBpdC4gVGhlIG9sZCBJS0V2MSBtZXRob2Qgb2Ygc2lnbmlu ZyB0aGUNDQphbHJlYWR5IGNhbGN1bGF0ZWQgZGlnZXN0IGNhdXNlZCBzb21lIHByb2JsZW1z LCBhcyB0aGVyZSBpcyBoYXJkd2FyZQ0NCmltcGxlbWVudGF0aW9uIGFuZCBBUElzIHdoaWNo IG9ubHkgYWxsb3cgaGFzaCtzaWduLCBhbmQgZG8gbm90IG9mZmVyDQ0KYW55IHJhdyBzaWdu aW5nIG9wZXJhdGlvbnMuIFNvIElLRXYyIHVzZXMgbm9ybWFsIGhhc2grc2lnbiBvcGVyYXRp b24uIA0NCg0NCj4gMi4yMyBOQVQgVHJhdmVyc2FsIA0NCj4gDQ0KPiBZb3UgYXJlIHN1cHBv c2VkIHRvIHNlbmQgdGhlIE5BVF9ERVRFQ1RJT04gcGF5bG9hZHMgaW4gdGhlIGZpcnN0DQ0K PiBJS0VfU0FfSU5JVCBleGNoYW5nZSBhbmQgYXJlIGFsc28gc3VwcG9zZWQgdG8gYWRkIHRo ZSBwYXlsb2Fkcw0NCj4gYmVmb3JlIENFUlRfUkVRIHBheWxvYWQuIFRoZSBDRVJUX1JFUSBw YXlsb2FkIGlzIHBhcnQgb2YgdGhlDQ0KPiBJS0VfU0FfSU5JVCBleGNoYW5nZSBmb3IgcmVz cG9uZGVyIGFuZCB0aGUgZm9sbG93aW5nIElLRV9BVVRIDQ0KPiBleGNoYW5nZSBmb3IgaW5p dGlhdG9yLg0NCg0NClRoZSBsb2NhdGlvbiBvZiB0aGUgTkFUX0RFVEVDVElPTiBwYXlsb2Fk IGlzIGFmdGVyIHRoZSBOaSBhbmQgTnINDQpwYXlsb2FkcyAoYW5kIGlmIHRoZXJlIGlzIENF UlRSRVEgaW4gdGhlIHJlc3BvbmRlciBJS0VfU0FfSU5JVCB0aGVuIGl0DQ0KaXMgYmV0d2Vl biBOciBhbmQgQ0VSVFJFUSkuIFRoZXJlIGlzIG5vIENFUlRSRVEgaW4gdGhlIGluaXRpYXRv cg0NCklLRV9TQV9JTklUIHBhY2tldCwgc28gdGhlIGxvY2F0aW9uIGlzIGFmdGVyIE5pLg0N Cg0NCkkuZToNDQoNDQoNDQoNDQogICAgICAgSW5pdGlhdG9yICAgICAgICAgICAgICAgICAg ICAgICAgICBSZXNwb25kZXINDQogICAgICAtLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAg ICAgICAgIC0tLS0tLS0tLS0tDQ0KICAgICAgIEhEUiwgU0FpMSwgS0VpLCBOaSwNDQoJICAg IE4oTkFUX0RFVEVDVElPTl9ERVNUSU5BVElPTl9JUCksDQ0KCSAgICBOKE5BVF9ERVRFQ1RJ T05fU09VUkNFX0lQKSwgDQ0KCSAgICBbTihOQVRfREVURUNUSU9OX1NPVVJDRV9JUCkgLi4u XSAtLT4NDQoNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tICAgIEhEUiwgU0Fy MSwgS0VyLCBOciwNDQoJCQkJCU4oTkFUX0RFVEVDVElPTl9ERVNUSU5BVElPTl9JUCksDQ0K CQkJCQlOKE5BVF9ERVRFQ1RJT05fU09VUkNFX0lQKSwgDQ0KCQkJCQlbTihOQVRfREVURUNU SU9OX1NPVVJDRV9JUCkgLi4uXSwNDQoJCQkJCVtDRVJUUkVRXQ0NCg0NCkkuZS4gdGhlcmUg aXMgZXhhY3RseSBvbmUgTkFUX0RFVEVDVElPTl9ERVNUSU5BVElPTl9JUCBwYXlsb2FkLCBh bmQNDQp0aGVuIG9uZSBvciBtb3JlIE5BVF9ERVRFQ1RJT05fU09VUkNFX0lQIG5vdGlmaWNh dGlvbnMuIFRoZSBkcmFmdCBkb2VzDQ0Kbm90IHNwZWNpZnkgdGhlIG9yZGVyIG9mIHRoZSBk ZXN0aW5hdGlvbiBhbmQgc291cmNlIElQIHBheWxvYWRzLCBidXQgSQ0NCnVzZWQgdGhlIHNh bWUgb3JkZXIgdGhhdCBpcyB1c2VkIGluIHRoZSByZmMzOTQ3IChJS0V2MSBOQVQtVCkuIA0N Cg0NCj4gVGhlIE5BVF9ERVRFQ1RJT04gcGF5bG9hZHMgc2hvdWxkIGluY2x1ZGUgdGhlIFNQ SXMsIGJ1dCB0aGUNDQo+IGluaXRpYXRvciB3aWxsIG5vdCBrbm93IHRoZSByZXNwb25kZXIg c3BpIHVudGlsIHRoZSBmaXJzdCBtZXNzYWdlIGlzDQ0KPiByZWNlaXZlZC4gV2hlbiBhcmUg dGhlIE5BVF9ERVRFQ1RJT04gcGF5bG9hZHMgc3VwcG9zZWQgdG8gYmUNDQo+IHRyYW5zbWl0 dGVkPw0NCg0NClRoZSBpbml0aWF0b3Igd2lsbCB1c2UgcmVzcG9uZGVyIFNQSXIgb2YgMCB3 aGVuIHNlbmRpbmcgaXRzIG93bg0NCm5vdGlmaWNhdGlvbnMgKGkuZSB0aGUgZXhhY3RseSBz YW1lIFNQSSBpdCBwdXRzIGluIHRoZSBJS0VfU0FfSU5JVA0NCnBhY2tldCB3aGVyZSBpdCBp cyBzZW5kaW5nIHRoaXMgbm90aWZpY2F0aW9uLiBUaGUgcmVzcG9uZGVyIHdpbGwgdXNlDQ0K dGhlIHNhbWUgd2hlbiBjaGVja2luZyB0aGUgdmFsdWVzIHNlbnQgYnkgdGhlIGluaXRpYXRv ciwgYnV0IGl0IHdpbGwNDQp0aGVuIHVzZSBib3RoIFNQSXMgd2hlbiBzZW5kaW5nIGl0cyBv d24gcmVwbHkgcGFja2V0LiBJIGFncmVlIHRoaXMgaXMNDQpub3QgcGVyaGFwcyB2ZXJ5IGNs ZWFyIGZyb20gdGhlIGRyYWZ0LCBhbmQgcmVhc29uIGZvciB0aGlzIGlzIHRoYXQNDQp0aGVy ZSBpcyBmZXdlciByb3VuZCB0cmlwcyBpbiB0aGUgSUtFdjEgdGhhbiB3aGF0IHdhcyBpbiB0 aGUgbWFpbiBtb2RlDQ0Kb2YgdGhlIElLRXYxICh3aGVyZSB0aGUgcGF5bG9hZHMgYXBwZWFy ZWQgaW4gdGhlIDNyZCBhbmQgNHRoIHBhY2tldA0NCigybmQgcm91bmQgdHJpcCkpLg0NCg0N Ck9uIHRoZSBvdGhlciBoYW5kIHdlIGRvIG5vdCB3YW50IHRvIGNvbXBsaWNhdGUgdGhlIHBy b3RvY29sDQ0KZGVzY3JpcHRpb24gYnkgZGVmaW5pbmcgdGhlIE5BVF9ERVRFQ1RJT05fKiBw YXlsb2FkcyBkaWZmZXJlbnRseQ0NCmRlcGVuZGluZyB3aGV0aGVyIHRoZXkgYXJlIHNlbnQg YnkgdGhlIGluaXRpYXRvciBvciByZXNwb25kZXIgKGkuZS4NDQpzYXkgdGhhdCBza2lwIFNQ SXIgaW4gdGhlIGluaXRpYXRvcnMgTkFUX0RFVEVDVElPTl8qIHBheWxvYWRzLCBub3cgd2UN DQppbmNsdWRlIFNQSXIsIGJ1dCB1c2UgdmFsdWUgb2YgMCkuIA0NCg0NCj4gMy42IENlcnRp ZmljYXRlIHBheWxvYWQNDQo+IA0NCj4gV2h5IGlzIGl0IGEgTVVTVCByZXF1aXJlbWVudCB0 byBzZW5kIGFuZCByZWNlaXZlIGZpcnN0IHR3byBIYXNoIGFuZA0NCj4gVVJMIGZvcm1hdHMu IFRvIGFkZCBodHRwIGxvb2t1cCBpbiBhIG1pbmltYWwgaW1wbGVtZW50YXRpb24gc2VlbXMg dG8NDQo+IGJlIHF1aXRlIHVubmVjY2Vzc2FyeS4gDQ0KDQ0KVGhpcyBpcyB0cnlpbmcgdG8g ZW5mb3JjZSB0aGF0IGV2ZW4gbWluaW1hbCBpbXBsZW1lbnRhdGlvbnMgY2FuIHdvcmsNDQpl dmVuIHdoZW4geW91IGNhbm5vdCBzZW5kIGxhcmdlIGVub3VnaCBVRFAgcGFja2V0cyB3aGlj aCBjb3VsZCBob2xkDQ0KY2VydGlmaWNhdGVzLiANDQotLSANDQpraXZpbmVuQHNhZmVuZXQt aW5jLmNvbQ0NCg0NCg== ------------=_1104744744-10561-0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------------=_1104744744-10561-0-- From ipsec-bounces@ietf.org Mon Jan 3 09:47:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02855 for ; Mon, 3 Jan 2005 09:47:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClTSr-0005zZ-I9; Mon, 03 Jan 2005 09:45:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChirN-00057s-Ik for ipsec@megatron.ietf.org; Fri, 24 Dec 2004 01:23:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06214 for ; Fri, 24 Dec 2004 01:23:32 -0500 (EST) Received: from smtp.knology.net ([24.214.63.101]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Chj1P-0003Xg-Cv for ipsec@ietf.org; Fri, 24 Dec 2004 01:33:55 -0500 Received: (qmail 28874 invoked by uid 0); 24 Dec 2004 06:23:51 -0000 Received: from user-69-1-45-93.knology.net (HELO ori.thedillows.org) (69.1.45.93) by smtp2.knology.net with SMTP; 24 Dec 2004 06:23:51 -0000 Received: from ori.thedillows.org (localhost [127.0.0.1]) by ori.thedillows.org (8.13.1/8.13.1) with ESMTP id iBO6NSLJ003239; Fri, 24 Dec 2004 01:23:28 -0500 Received: (from il1@localhost) by ori.thedillows.org (8.13.1/8.13.1/Submit) id iBO6NSSG003238; Fri, 24 Dec 2004 01:23:28 -0500 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: [Ipsec] Issue on input process of Linux native IPsec From: David Dillow To: Park Lee In-Reply-To: <20041223062905.20979.qmail@web51503.mail.yahoo.com> References: <20041223062905.20979.qmail@web51503.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 24 Dec 2004 01:23:27 -0500 Message-Id: <1103869407.3016.7.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 03 Jan 2005 09:44:51 -0500 Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2004-12-22 at 22:29 -0800, Park Lee wrote: > Thanks. > But, After a packet was received, It has already been > processed by xfrm4_rcv(), xfrm4_rcv_encap(), > ah_input(), esp_input(),etc. so, I think that there is > no need to search(or created) a bundle everytime a > packet is recieved, since it has already been > processed. Am I right? Are you sure you're not seeing the creation of a reply packet? Unless you're testing with UDP and a listening socket on the receiver, you're going to get a response packet if the incoming packet makes it through the iptables rules. You were testing with ICMP echo requests (ping), if I recall. I think either you're basing your idea of the packet flow on printk()'s, or I'm just too tired and missing where xfrm_lookup() gets called on the rx path... (yes, sk can be NULL there, but I was wrong about it being called for Rx'd packets, I think). However, if your NIC driver does NAPI, you can see an xfrm_lookup() on the reply packet when the driver calls netif_receive_skb() -- this bit me recently... -- David Dillow _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 3 11:23:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10939 for ; Mon, 3 Jan 2005 11:23:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClUvk-0001MN-Nu; Mon, 03 Jan 2005 11:19:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClUrX-0004AK-EM for ipsec@megatron.ietf.org; Mon, 03 Jan 2005 11:15:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10369 for ; Mon, 3 Jan 2005 11:15:17 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClV3f-0007kS-Um for ipsec@ietf.org; Mon, 03 Jan 2005 11:27:55 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j03GEfjf022391; Mon, 3 Jan 2005 11:14:42 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20041231061636.2254.qmail@web90007.mail.scd.yahoo.com> References: <20041231061636.2254.qmail@web90007.mail.scd.yahoo.com> Date: Mon, 3 Jan 2005 11:11:26 -0500 To: Surya Batchu From: Stephen Kent Subject: Re: [Ipsec] 'Name' as Selector Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:16 PM -0800 12/30/04, Surya Batchu wrote: >Section 4.4.1.1 of rfc2401-bis describes 'Name' in >selectors and its usage of it. > >Based on my understanding after reading this section, >this is mainly intended to be used in remote access >scenarios. >What is the advantage of using this over IRAC/IRAS >method >specified by IKEv2 draft? Aren't both addressing and >solving the same problem? If so, why is the support >for >'Names' is made MUST? If not, can somebody describe >the usage scenaris of 'Name' field in SPD policy? > >Thanks >Surya IRAC/IRAS deals with the ability of a remote client to be assigned a (local) address when it established a tunnel to a security gateway. It does not address the question of how to authenticate the remote client and make an IPsec access control decision prior to this address assignment phase of IKE. Thus I believe that the Name form of identity is still appropriate and in text I prepared for the pki4ipsec WG, I explained in ore detail how/when to use this form of ID in the initial IKE peer authentication and authorization phase. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 3 13:28:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23008 for ; Mon, 3 Jan 2005 13:28:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClWuK-0000Qm-Sl; Mon, 03 Jan 2005 13:26:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClWmL-0005WG-8w for ipsec@megatron.ietf.org; Mon, 03 Jan 2005 13:18:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22153 for ; Mon, 3 Jan 2005 13:18:02 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWyU-0002Qh-T6 for ipsec@ietf.org; Mon, 03 Jan 2005 13:30:42 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j03IHpj2078221 for ; Mon, 3 Jan 2005 10:17:52 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 3 Jan 2005 10:17:48 -0800 To: ipsec@ietf.org From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ipsec] Protocol Action: 'Algorithms for Internet Key Exchange version 1 (IKEv1)' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has approved the following document: - 'Algorithms for Internet Key Exchange version 1 (IKEv1) ' as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. Technical Summary The required and suggested algorithms in the original IKEv1 specification do not reflect the current reality of IPsec market. It requires allowing weak security and suggests algorithms that are rarely implemented. This document updates the original specification and is intended for all IKEv1 implementations. Working Group Summary This document is not affiliated with any WG, although the IPsec WG did have the opportunity to review it. In fact, it was modified based on some comments posted to the IPsec WG mail list. Protocol Quality This document was reviewed by Russ Housley for the IESG. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 4 08:23:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10112 for ; Tue, 4 Jan 2005 08:23:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clob5-0006wu-Ox; Tue, 04 Jan 2005 08:19:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CloYg-0005pH-5F for ipsec@megatron.ietf.org; Tue, 04 Jan 2005 08:17:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09631 for ; Tue, 4 Jan 2005 08:17:08 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clokz-0004yC-VR for ipsec@ietf.org; Tue, 04 Jan 2005 08:29:57 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j04DH2H24434; Tue, 4 Jan 2005 15:17:03 +0200 (EET) X-Scanned: Tue, 4 Jan 2005 15:16:45 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j04DGjn3021225; Tue, 4 Jan 2005 15:16:45 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00aPabit; Tue, 04 Jan 2005 15:16:31 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j04DGVx29553; Tue, 4 Jan 2005 15:16:31 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 Jan 2005 15:16:27 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 Jan 2005 15:16:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] RE: Date: Tue, 4 Jan 2005 15:16:26 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD1783F4@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] RE: Thread-Index: AcTxeSs2PO07t+K1TUGEn4dbuQzOEgA4PoZw To: , X-OriginalArrivalTime: 04 Jan 2005 13:16:26.0582 (UTC) FILETIME=[98657F60:01C4F25F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, Hmm, this was discussed off-list about a year ago (with Russ, Charlie, and Hannes), but it seems that it was forgotten since... You're quite right in that IKEv2 does not negotiate the hash function (or the encoding method) used for RSA signatures.=20 For the hash function, the intent was that supporting SHA-1 is mandatory (but draft-ietf-ipsec-ikev2-algorithms does not=20 actually say that).=20 For the encoding method, the draft talks about "PKCS#1 padded=20 hash"; since the reference points to PKCS#1 v2.0 (and not v2.1),=20 and that version has only one encoding method for signatures=20 (EMSA-PKCS1-v1_5), that's the mandatory-to-support one (BTW,=20 note that this is different from the encoding method used=20 in IKEv1). (Tero/Charlie/Russ/anyone: please correct me if I didn't get this right.) Best regards, Pasi > -----Original Message----- > From: Magnus Alstr=F6m > Sent: Monday, January 03, 2005 11:32 AM > To: Tero Kivinen > Cc: ipsec@ietf.org > Subject: [Ipsec] RE: >=20 >=20 > Hi Tero, >=20 >=20 >=20 > Thanks for the comments. I guessed that the sign operation=20 > should be a hash+sign operation, but the question is still=20 > how the hashing should be performed. There is a prf function=20 > negotiated, but no hash algorithm. Should I take the data and=20 > create a hmac? Or should I take whatever algorithm I prefer=20 > and encode the digest to a der-encoded digest-info before I sign? =20 >=20 >=20 >=20 > regards Magnus _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 4 11:27:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24129 for ; Tue, 4 Jan 2005 11:27:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClrUK-0004Ua-AD; Tue, 04 Jan 2005 11:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClrLt-0000j8-KF for ipsec@megatron.ietf.org; Tue, 04 Jan 2005 11:16:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23066 for ; Tue, 4 Jan 2005 11:16:07 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClrYH-00006b-Gw for ipsec@ietf.org; Tue, 04 Jan 2005 11:28:58 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j04GFwxo004469 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 4 Jan 2005 18:15:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j04GFuiX004466; Tue, 4 Jan 2005 18:15: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: <16858.49468.184575.1177@fireball.kivinen.iki.fi> Date: Tue, 4 Jan 2005 18:15:56 +0200 From: Tero Kivinen To: Subject: RE: [Ipsec] RE: In-Reply-To: <125EA890549C8641A72F3809CB80DCCD1783F4@esebe056.ntc.nokia.com> References: <125EA890549C8641A72F3809CB80DCCD1783F4@esebe056.ntc.nokia.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > You're quite right in that IKEv2 does not negotiate the hash > function (or the encoding method) used for RSA signatures. > For the hash function, the intent was that supporting SHA-1 > is mandatory (but draft-ietf-ipsec-ikev2-algorithms does not > actually say that). Probably pest is to use same hash algorithm that was used to sign the certificate itself. If the other end does not support that algorith, then he cannot verify the certificate, thus the signature will be invalid anyways. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 5 21:07:55 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14306 for ; Wed, 5 Jan 2005 21:07:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmMzB-0007H7-5J; Wed, 05 Jan 2005 21:02:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmMs3-0005QW-4s for ipsec@megatron.ietf.org; Wed, 05 Jan 2005 20:55:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13852 for ; Wed, 5 Jan 2005 20:55:24 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmN4j-0000d8-HV for ipsec@ietf.org; Wed, 05 Jan 2005 21:08:33 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j061tIWF033231 for ; Wed, 5 Jan 2005 17:55:19 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 5 Jan 2005 17:55:20 -0800 To: IPsec WG From: rfc-editor@rfc-editor.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Ipsec] RFC 3948 on UDP Encapsulation of IPsec ESP Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 3948 Title: UDP Encapsulation of IPsec ESP Packets Author(s): A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg Status: Standards Track Date: January 2005 Mailbox: Ari.Huttunen@F-Secure.com, briansw@microsoft.com, vvolpe@cisco.com, ldiburro@nortelnetworks.com, markus.stenberg@iki.fi Pages: 15 Characters: 30366 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsec-udp-encaps-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3948.txt This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). This document is a product of the IP Security Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 5 21:10:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14476 for ; Wed, 5 Jan 2005 21:10:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmMzC-0007Hr-7D; Wed, 05 Jan 2005 21:02:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmMs3-0005QZ-Q0 for ipsec@megatron.ietf.org; Wed, 05 Jan 2005 20:55:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13855 for ; Wed, 5 Jan 2005 20:55:25 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmN4j-0000d6-BW for ipsec@ietf.org; Wed, 05 Jan 2005 21:08:34 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j061tIWD033231 for ; Wed, 5 Jan 2005 17:55:18 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 5 Jan 2005 17:54:53 -0800 To: IPsec WG From: rfc-editor@rfc-editor.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Ipsec] RFC 3947 on Negotiation of NAT-Traversal in the IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 3947 Title: Negotiation of NAT-Traversal in the IKE Author(s): T. Kivinen, B. Swander, A. Huttunen, V. Volpe Status: Standards Track Date: January 2005 Mailbox: kivinen@safenet-inc.com, Ari.Huttunen@F-Secure.com, briansw@microsoft.com, vvolpe@cisco.com Pages: 16 Characters: 34759 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsec-nat-t-ike-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3947.txt This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). This document is a product of IP Security Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 6 09:02:15 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08191 for ; Thu, 6 Jan 2005 09:02:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmY8I-00034v-0B; Thu, 06 Jan 2005 08:56:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmXrc-0008Ay-2Q for ipsec@megatron.ietf.org; Thu, 06 Jan 2005 08:39:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07052 for ; Thu, 6 Jan 2005 08:39:42 -0500 (EST) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmY4L-0006Jh-Ei for ipsec@ietf.org; Thu, 06 Jan 2005 08:52:56 -0500 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by smtp2.int-evry.fr (Postfix) with ESMTP id 93C0B2FDF8 for ; Thu, 6 Jan 2005 14:22:51 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1CmXZ2-000OBT-9j for ; Thu, 06 Jan 2005 14:20:32 +0100 Date: Thu, 6 Jan 2005 14:20:32 +0100 From: Julien Bournelle To: ipsec@ietf.org Message-ID: <20050106132032.GQ90089@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@ipv6-5.int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ipsec] IKEv2 and EAP key X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, In draft-ietf-ipsec-ike2-17.txt section 2.16 concerning use of EAP, it is mentionned that both Initiator and Responder must use the MSK key (derived from the EAP method in use) to generate AUTH payloads. With regard to draft-ietf-eap-keying-04.txt, I think that it should be the AAA-Key (which may be the MSK) or the TSK because it is the AAA-Key which can be exported from the EAP server to the EAP authenticator (here the Responder). (Maybe this has been already mentionned and in this case, I'm sorry for the noise.) -- julien.bournelle@int-evry.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 7 01:10:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02205 for ; Fri, 7 Jan 2005 01:10:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmnE4-0004Yq-Lw; Fri, 07 Jan 2005 01:03:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmnDU-0004Bd-Pz for ipsec@megatron.ietf.org; Fri, 07 Jan 2005 01:03:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02041 for ; Fri, 7 Jan 2005 01:03:20 -0500 (EST) Received: from [207.145.48.18] (helo=ip-207-145-48-18.sjc.megapath.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmnQL-0000ig-9Y for ipsec@ietf.org; Fri, 07 Jan 2005 01:16:42 -0500 Received: from brahma.intotoind.com ([66.80.10.146]) by ip-207-145-48-18.sjc.megapath.net (SMSSMTP 4.0.0.59) with SMTP id M2005010622021306398 for ; Thu, 06 Jan 2005 22:02:14 -0800 Received: from [172.16.3.124] (3mc124.intotoind.com [172.16.3.124]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id j0762V52010371 for ; Fri, 7 Jan 2005 11:32:31 +0530 From: Someshwar Parate To: ipsec@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 07 Jan 2005 11:45:34 +0530 Message-Id: <1105078534.1740.7.camel@rh.intotoind.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Ipsec] proposal addition in aggresive mode. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi all, Can we add more than one proposal (attribute) in IKE policy to have same DH group? ============ Actually I am trying to configure IKE policies in out IGATEWAY box and I am getting following error while adding second proposal iGateway:/config/ike>add ike B M I -ma 172.16.12.15 -pa 172.16.3.1 -rid I172.16.3.1 -lid 172.16.12.15 -pfs Y -key 1234567890123456 Policy added successfully iGateway:/config/ike>addattrib ike 1 M P -k 400 -s 600 -g M768 -e 3DES -eklen 16 Attribute added successfully iGateway:/config/ike>addattrib ike 2 M P -k 400 -s 600 -g M768 -e DES -eklen 16 Error in adding the attribute ERROR: Atmost One Attribute allowed for an Aggressive Mode Policy. =============== Does anybody throw any light on this? thanks and regards... -- Somesh _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 7 01:46:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03730 for ; Fri, 7 Jan 2005 01:46:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmnno-0002SL-Af; Fri, 07 Jan 2005 01:40:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmnjG-0001D3-BB for ipsec@megatron.ietf.org; Fri, 07 Jan 2005 01:36:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03281 for ; Fri, 7 Jan 2005 01:36:09 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmnwB-00027w-5B for ipsec@ietf.org; Fri, 07 Jan 2005 01:49:32 -0500 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j076a7Vu028564 for ; Thu, 6 Jan 2005 23:36:07 -0700 (MST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I9X00701OHT0V@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for ipsec@ietf.org; Fri, 07 Jan 2005 01:36:07 -0500 (EST) Received: from [192.168.2.58] (vpn-129-147-152-127.Central.Sun.COM [129.147.152.127]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I9X007R7P06EO@bur-mail2.east.sun.com>; Fri, 07 Jan 2005 01:36:07 -0500 (EST) Date: Thu, 06 Jan 2005 22:36:05 -0800 From: Radia Perlman Subject: Re: [Ipsec] proposal addition in aggresive mode. In-reply-to: <1105078534.1740.7.camel@rh.intotoind.com> To: Someshwar Parate Message-id: <41DE2DD5.8040804@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 References: <1105078534.1740.7.camel@rh.intotoind.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7BIT Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT In aggressive mode's first message, Alice sends a Diffie-Hellman value, so therefore has to have already decided on which Diffie-Hellman group she is using. She can't propose others. But she should be able to propose multiple alternatives for the other cryptographic algorithms (prf, encryption, hash) Radia Someshwar Parate wrote: >Hi all, > >Can we add more than one proposal (attribute) in IKE policy to have same >DH group? > >============ >Actually I am trying to configure IKE policies in out IGATEWAY box and I >am getting following error while adding second proposal > >iGateway:/config/ike>add ike B M I -ma 172.16.12.15 -pa 172.16.3.1 -rid >I172.16.3.1 -lid 172.16.12.15 -pfs Y -key 1234567890123456 >Policy added successfully > >iGateway:/config/ike>addattrib ike 1 M P -k 400 -s 600 -g M768 -e 3DES >-eklen 16 >Attribute added successfully > >iGateway:/config/ike>addattrib ike 2 M P -k 400 -s 600 -g M768 -e DES >-eklen 16 >Error in adding the attribute >ERROR: Atmost One Attribute allowed for an Aggressive Mode Policy. >=============== > >Does anybody throw any light on this? > >thanks and regards... > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 7 01:48:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03975 for ; Fri, 7 Jan 2005 01:48:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmnnp-0002SR-6I; Fri, 07 Jan 2005 01:40:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmnkD-0001ao-O1 for ipsec@megatron.ietf.org; Fri, 07 Jan 2005 01:37:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03305 for ; Fri, 7 Jan 2005 01:37:08 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmnx7-0002LB-NS for ipsec@ietf.org; Fri, 07 Jan 2005 01:50:32 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j076Rsja022567 for ; Fri, 7 Jan 2005 01:27:54 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j076Rrja022540 for ; Fri, 7 Jan 2005 01:27:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] proposal addition in aggresive mode. Date: Thu, 6 Jan 2005 23:37:04 -0700 Message-ID: Thread-Topic: [Ipsec] proposal addition in aggresive mode. Thread-Index: AcT0gCvPj8zm2sr9TvuKhfox12N7gwAAuFAQ From: "Rai, Anupam \(Anupam\)" To: "Someshwar Parate" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Yes you can . -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]On Behalf Of Someshwar Parate Sent: Thursday, January 06, 2005 10:16 PM To: ipsec@ietf.org Subject: [Ipsec] proposal addition in aggresive mode. Hi all, Can we add more than one proposal (attribute) in IKE policy to have same DH group? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Actually I am trying to configure IKE policies in out IGATEWAY box and I am getting following error while adding second proposal iGateway:/config/ike>add ike B M I -ma 172.16.12.15 -pa 172.16.3.1 -rid I172.16.3.1 -lid 172.16.12.15 -pfs Y -key 1234567890123456 Policy added successfully iGateway:/config/ike>addattrib ike 1 M P -k 400 -s 600 -g M768 -e 3DES -eklen 16 Attribute added successfully iGateway:/config/ike>addattrib ike 2 M P -k 400 -s 600 -g M768 -e DES -eklen 16 Error in adding the attribute ERROR: Atmost One Attribute allowed for an Aggressive Mode Policy. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Does anybody throw any light on this? thanks and regards... --=20 Somesh _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 7 02:04:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09357 for ; Fri, 7 Jan 2005 02:04:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmo8S-0004Bl-3y; Fri, 07 Jan 2005 02:02:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmo4k-0001lx-NN for ipsec@megatron.ietf.org; Fri, 07 Jan 2005 01:58:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04482 for ; Fri, 7 Jan 2005 01:58:21 -0500 (EST) Received: from web90009.mail.scd.yahoo.com ([66.218.94.67]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmoHY-0003m4-Sl for ipsec@ietf.org; Fri, 07 Jan 2005 02:11:45 -0500 Received: (qmail 6749 invoked by uid 60001); 7 Jan 2005 06:57:42 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=rXgBz5Ns11t0/xpjj3pO02Wkhi7tGOzpTenPHumiCyg65z7BI0PGZYkGRXZ4rtjhCV5dkxHq6Xysik+Lx0NvtzrT5zGg78UH2WUjI3hzWKfEczC7FssK9Oj2/KO6dDo8bDdqU41oawgStbaaIVa2jPKXzsd8ZFoESpCVwXlObC4= ; Message-ID: <20050107065742.6747.qmail@web90009.mail.scd.yahoo.com> Received: from [67.169.115.217] by web90009.mail.scd.yahoo.com via HTTP; Thu, 06 Jan 2005 22:57:42 PST Date: Thu, 6 Jan 2005 22:57:42 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] proposal addition in aggresive mode. To: Someshwar Parate , ipsec@ietf.org In-Reply-To: <1105078534.1740.7.camel@rh.intotoind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.6 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Check this extract from IKE RFC: " Security Association negotiation is limited with Aggressive Mode. Due to message construction requirements the group in which the Diffie- Hellman exchange is performed cannot be negotiated. " Since, KE payload is also sent along with SA proposals, DH group can't be negotiated. In case of IKEv2, this restriction is not present, even though both SA and KE happen in the same message. It has been taken care by different method in IKEv2. --- Someshwar Parate wrote: > Hi all, > > Can we add more than one proposal (attribute) in IKE > policy to have same > DH group? > > ============ > Actually I am trying to configure IKE policies in > out IGATEWAY box and I > am getting following error while adding second > proposal > > iGateway:/config/ike>add ike B M I -ma 172.16.12.15 > -pa 172.16.3.1 -rid > I172.16.3.1 -lid 172.16.12.15 -pfs Y -key > 1234567890123456 > Policy added successfully > > iGateway:/config/ike>addattrib ike 1 M P -k 400 -s > 600 -g M768 -e 3DES > -eklen 16 > Attribute added successfully > > iGateway:/config/ike>addattrib ike 2 M P -k 400 -s > 600 -g M768 -e DES > -eklen 16 > Error in adding the attribute > ERROR: Atmost One Attribute allowed for an > Aggressive Mode Policy. > =============== > > Does anybody throw any light on this? > > thanks and regards... > -- > Somesh > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 7 02:27:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20820 for ; Fri, 7 Jan 2005 02:27:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmoTw-0001yz-P0; Fri, 07 Jan 2005 02:24:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmoSo-0001Iz-PC for ipsec@megatron.ietf.org; Fri, 07 Jan 2005 02:23:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20421 for ; Fri, 7 Jan 2005 02:23:13 -0500 (EST) Received: from web90009.mail.scd.yahoo.com ([66.218.94.67]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cmofi-0005Ye-1n for ipsec@ietf.org; Fri, 07 Jan 2005 02:36:37 -0500 Received: (qmail 15412 invoked by uid 60001); 7 Jan 2005 07:22:40 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=HTlbRw3ahxQ8HNBKAE+sxJOHvXWhccmoOTI4Nw051n+/vEJZhMP6unVNOcAy21/ZEZy3Tk3G+zGCJMXg6Bqkz3mu9zsTjyz2XvDEdy03SA7mVeQDQ5tOHNES3Qowuh11Zj8ktkokRBJLm3WBAfYLl/JQS0hRRKMGCclgo6w2FSE= ; Message-ID: <20050107072240.15410.qmail@web90009.mail.scd.yahoo.com> Received: from [67.169.115.217] by web90009.mail.scd.yahoo.com via HTTP; Thu, 06 Jan 2005 23:22:40 PST Date: Thu, 6 Jan 2005 23:22:40 -0800 (PST) From: Surya Batchu To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.6 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ipsec] rfc2401 & rfc2401bis compatability with IKEv1 and IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, After going through the drafts, it seems that security policies configured based on rfc2401-bis can only work with IKEv2 key management. I guess, rfc2401 specific policies can work either IKEv1 and IKEv2. Due to this, I feel that the user configuring the rfc2401-bis SPD policy, should be aware that the security gateway that is protecting the remote network supports IKEv2. Accordingly, these kind of SPD policies would need to be configured (through management interface) to use only IKEv2 management. Is that correct assesment? Surya __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 7 02:35:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21555 for ; Fri, 7 Jan 2005 02:35:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmobo-0006eP-50; Fri, 07 Jan 2005 02:32:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmoVX-0003MA-2m for ipsec@megatron.ietf.org; Fri, 07 Jan 2005 02:26:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20742 for ; Fri, 7 Jan 2005 02:26:01 -0500 (EST) Received: from [207.145.48.18] (helo=ip-207-145-48-18.sjc.megapath.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmoiQ-0005ee-DN for ipsec@ietf.org; Fri, 07 Jan 2005 02:39:25 -0500 Received: from brahma.intotoind.com ([66.80.10.146]) by ip-207-145-48-18.sjc.megapath.net (SMSSMTP 4.0.0.59) with SMTP id M2005010623245706488 for ; Thu, 06 Jan 2005 23:24:58 -0800 Received: from [172.16.3.124] (3mc124.intotoind.com [172.16.3.124]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id j077PCFM026306 for ; Fri, 7 Jan 2005 12:55:12 +0530 From: Someshwar Parate To: ipsec@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 07 Jan 2005 13:08:16 +0530 Message-Id: <1105083497.1990.23.camel@rh.intotoind.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Ipsec] proposal addition in aggresive mode. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, I apologize for my previous mail with the same subject as above. Please read the same as below; Can we add more than one proposal (attribute) in IKE policy to have same DH group? I appreciate if somebody can provide info in this regard. -- regards... - Somesh ========================================================= -------------------------------------------------------- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 7 02:59:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23436 for ; Fri, 7 Jan 2005 02:59:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmow1-0006Lv-SW; Fri, 07 Jan 2005 02:53:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmopo-0004Ag-PK for ipsec@megatron.ietf.org; Fri, 07 Jan 2005 02:47:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22780 for ; Fri, 7 Jan 2005 02:46:59 -0500 (EST) Received: from web90007.mail.scd.yahoo.com ([66.218.94.65]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cmp2k-0006YR-AP for ipsec@ietf.org; Fri, 07 Jan 2005 03:00:23 -0500 Received: (qmail 53968 invoked by uid 60001); 7 Jan 2005 07:46:27 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=QRhc2RQZ00JzrnQoLvyJg540iqm2QE0EcaDr26ptSeUB+ZbrduOXovf3XrXxGhFLyc7UGY3NTmQGrkTU2URHaRtekBuHjuXyonD022ffNtzH8HF5e8eIg584HYtjEu1nAyK24+zoXeJX97Phg/U7+tTecRjyfrQRkzkgxtFDoAk= ; Message-ID: <20050107074627.53966.qmail@web90007.mail.scd.yahoo.com> Received: from [67.169.115.217] by web90007.mail.scd.yahoo.com via HTTP; Thu, 06 Jan 2005 23:46:27 PST Date: Thu, 6 Jan 2005 23:46:27 -0800 (PST) From: Surya Batchu To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.6 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ipsec] IPsec/IKEv2 client software X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I am looking for IKEv2/IPsec client package on windows XP, that support EAP based authentication. I appreaciate any information on this. Does anybody know Microsoft plans for supporting IKEv2? Thanks Surya __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 7 03:19:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24551 for ; Fri, 7 Jan 2005 03:19:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmpJL-00019R-4L; Fri, 07 Jan 2005 03:17:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmpGc-00089p-D2 for ipsec@megatron.ietf.org; Fri, 07 Jan 2005 03:14:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24325 for ; Fri, 7 Jan 2005 03:14:40 -0500 (EST) Received: from mxout5.netvision.net.il ([194.90.9.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmpTX-000812-Ro for ipsec@ietf.org; Fri, 07 Jan 2005 03:28:05 -0500 Received: from [192.168.0.70] ([217.132.251.86]) by mxout5.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I9X003J8TJ043@mxout5.netvision.net.il> for ipsec@ietf.org; Fri, 07 Jan 2005 10:13:48 +0200 (IST) Date: Fri, 07 Jan 2005 10:13:45 +0200 From: Yoav Nir Subject: Re: [Ipsec] IPsec/IKEv2 client software In-reply-to: <20050107074627.53966.qmail@web90007.mail.scd.yahoo.com> To: Surya Batchu Message-id: <0D02BD58-6084-11D9-84AF-000393AD410A@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20050107074627.53966.qmail@web90007.mail.scd.yahoo.com> X-Spam-Score: 2.4 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7BIT Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT I'm also interested. AFAIK only Cisco and Juniper announced anything. Microsoft has not announced anything regarding IKEv2, but Charlie Kaufman who edited the draft works for Microsoft, so obviously there's some interest there in IKEv2. Still, a company the size of Microsoft in interested in everything, which doesn't mean they have a specific feature or product under development. If they don't, then the vendors and open source people will do it for them. On Jan 7, 2005, at 9:46 AM, Surya Batchu wrote: > Hi, > > I am looking for IKEv2/IPsec client package on windows > XP, that support EAP based authentication. I > appreaciate any information on this. > > Does anybody know Microsoft plans for supporting > IKEv2? > > Thanks > Surya _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 7 14:40:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07915 for ; Fri, 7 Jan 2005 14:40:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmzvt-0003cE-WA; Fri, 07 Jan 2005 14:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmzvG-0003MZ-Hv for ipsec@megatron.ietf.org; Fri, 07 Jan 2005 14:37:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07648 for ; Fri, 7 Jan 2005 14:37:21 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn08J-0001NI-BK for ipsec@ietf.org; Fri, 07 Jan 2005 14:50:51 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j07Jajjl005264; Fri, 7 Jan 2005 14:36:48 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050107072240.15410.qmail@web90009.mail.scd.yahoo.com> References: <20050107072240.15410.qmail@web90009.mail.scd.yahoo.com> Date: Fri, 7 Jan 2005 10:13:10 -0500 To: Surya Batchu From: Stephen Kent Subject: Re: [Ipsec] rfc2401 & rfc2401bis compatability with IKEv1 and IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.7 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:22 PM -0800 1/6/05, Surya Batchu wrote: >Hi, > >After going through the drafts, it seems that security >policies configured based on rfc2401-bis can only work >with IKEv2 key management. I guess, rfc2401 specific >policies can work either IKEv1 and IKEv2. > >Due to this, I feel that the user configuring the >rfc2401-bis SPD policy, should be aware that the >security gateway that is protecting the remote network >supports IKEv2. Accordingly, these kind of SPD >policies would need to be configured (through >management interface) to use only IKEv2 management. > > >Is that correct assesment? > >Surya yes, some of the SPD features in 2401bis require use of IKEv2 to negotiate them. Thus it is desirable that one know whether a peer is IKEv2 capable when creating SPD entries that take advantage of these feaures. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jan 8 11:44:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17392 for ; Sat, 8 Jan 2005 11:44:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnJd5-0007vv-HW; Sat, 08 Jan 2005 11:39:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnJcW-0007nN-QZ for ipsec@megatron.ietf.org; Sat, 08 Jan 2005 11:39:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17033 for ; Sat, 8 Jan 2005 11:39:18 -0500 (EST) Received: from web90001.mail.scd.yahoo.com ([66.218.94.59]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CnJph-0005qP-Rq for ipsec@ietf.org; Sat, 08 Jan 2005 11:53:01 -0500 Received: (qmail 93014 invoked by uid 60001); 8 Jan 2005 16:38:38 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=uUl+8llTE9z4hNKn2c7lDLe2Fgeuftf8msbnLzNUMxZ+cnQ84paGMTSPOr2ZH63pCrMcI+9FhFF3o0bQS8rG/tHAZjn6n0JNi81TCO2CkkNzI34oNSfAZ0bKSM9O+xY7L7Yu6FMHasD7Olnb1R4WiF4cVF1SjFaeSW9nk3+/WOA= ; Message-ID: <20050108163836.93011.qmail@web90001.mail.scd.yahoo.com> Received: from [67.169.115.217] by web90001.mail.scd.yahoo.com via HTTP; Sat, 08 Jan 2005 08:38:36 PST Date: Sat, 8 Jan 2005 08:38:36 -0800 (PST) From: Surya Batchu To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ipsec] Stateful fragment check X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1918731978==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1918731978== Content-Type: multipart/alternative; boundary="0-643684446-1105202316=:90876" --0-643684446-1105202316=:90876 Content-Type: text/plain; charset=us-ascii Hi, If 'Stateful fragmen check' is required, then the security policies on the both communicating security gateways should be configured with the 'fragCheck' set to TRUE. It means that, the users configuring the policies on these security gateways should know a priori that these gateway support this feature. Is that correct? If so, what are the advantages of negotiating IKE_NOTIFY_NON_FIRST_FRAGMENT_ALSO using IKEv2? If there is any mis-configuration of 'fragCheck' flag on IPsec peers, then this negotiation helps in notifying the user with auditable event and correcting the configuration. This is one advantage I see. Are there any other uses of this? Surya --------------------------------- Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. --0-643684446-1105202316=:90876 Content-Type: text/html; charset=us-ascii
Hi,
 
If 'Stateful fragmen check' is required, then the security policies on the both communicating security gateways should be configured with the 'fragCheck' set to TRUE.  It means that, the users configuring the policies on these security gateways should know a priori that these gateway support this feature.  Is that correct?
 
If so, what are the advantages of negotiating IKE_NOTIFY_NON_FIRST_FRAGMENT_ALSO using IKEv2?
 
If there is any mis-configuration of 'fragCheck' flag on IPsec peers, then this negotiation helps in notifying the user with auditable event and correcting the configuration. This is one advantage I see.  Are there any other uses of this?
 
Surya

Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard. --0-643684446-1105202316=:90876-- --===============1918731978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1918731978==-- From ipsec-bounces@ietf.org Sun Jan 9 12:43:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26222 for ; Sun, 9 Jan 2005 12:43:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cnh3T-0006FC-OU; Sun, 09 Jan 2005 12:40:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CngzL-0005rz-1K for ipsec@megatron.ietf.org; Sun, 09 Jan 2005 12:36:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25887 for ; Sun, 9 Jan 2005 12:36:24 -0500 (EST) Received: from web90001.mail.scd.yahoo.com ([66.218.94.59]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CnhCj-0000QS-9o for ipsec@ietf.org; Sun, 09 Jan 2005 12:50:20 -0500 Received: (qmail 77389 invoked by uid 60001); 9 Jan 2005 17:35:50 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=hUhyTA3TJ5T94IBHmLU3mlKSgV4JT9nLZ82xD14FYA9cL3sXEqV/k5AzTJJQfhiG6b6KTh6fqxUbQyDTc2EPHJow16WyN9/Ux30YtzAdOkkELIJd/EhtI73W2OscPtxmTPFkX6JQSarO/Vms768W38pwxfzcSia7UK8iarDCSSU= ; Message-ID: <20050109173550.77387.qmail@web90001.mail.scd.yahoo.com> Received: from [67.169.115.217] by web90001.mail.scd.yahoo.com via HTTP; Sun, 09 Jan 2005 09:35:49 PST Date: Sun, 9 Jan 2005 09:35:49 -0800 (PST) From: Surya Batchu To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Ipsec] Fragment handling in IPv6 based IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0709656242==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0709656242== Content-Type: multipart/alternative; boundary="0-1568803776-1105292149=:76990" --0-1568803776-1105292149=:76990 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA25887 Content-Transfer-Encoding: quoted-printable Please validate my understanding. =20 Assumption: Security policy is configured with transport selectors. =20 IPv6: =20 Case1: IPsec device is deployed in an environment, where all IP packets = (all fragments) will go through the device. =20 All fragments of a packet can be gathered together (Some sort of Pseudo r= eassembly) , SPD policy is checked.=20 =20 Case A: 'fragCheck' is TRUE in the policy. If the peer does not support = 'stateful fragment check', SAs will not be established and thereby no t= raffic would pass through. User of the device can be informed through aud= itable event indicating that peer does not support 'stateful fragment che= cking'. If the peer supports it, SA establishment goes through and traff= ic will pass through the tunnel. =20 Case B: fragCheck is FALSE in the policy. In this case, if there is no p= olicy with transport selector values set to OPAQUE, then there is a possi= bility that, the non-initial fragments would not be secured and most prob= ably would be discarded (if there is no BYPASS policy).=20 Also, based on rfc2401-bis, this case is not preferable for IPv6. =20 =20 Case 2: IPsec device is deployed in an environment where all outbound fra= gments may not come to same IPsec device. =20 In case of pseudo reassembly fragments is not possible.=20 =20 In this case, even 'fragCheck' is set to TRUE in the policy, device shoul= d not negotiate 'stateful fragment related IKV2 notify message'. It sho= uld fallback onto 'separate tunnel SA for non-initial fragments'. If thi= s is not desirable (as per RFC2401-bis, this is not desirable for IPv6), = then the only option is to disallow user to configure any security polici= es with transport selectors ie all policies should have IPv6 address sele= ctors only. =20 =20 In summary: In case1, all security policies with transport selectors must have 'fragC= heck' set to TRUE. In case2, security policies must not be configured with transport selecto= rs. =20 =20 Surya =20 =20 =20 =20 =20 =20 =09 --------------------------------- Do you Yahoo!? All your favorites on one personal page =96 Try My Yahoo! --0-1568803776-1105292149=:76990 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA25887 Content-Transfer-Encoding: quoted-printable
Please validate my understanding.
 
Assumption: Security policy is configured with transport selectors.<= /DIV>
 
IPv6:
 
Case1:  IPsec device is deployed in an environment, where all I= P packets (all fragments) will go through the device.
 
All fragments of a packet can be gathered together (Some sort of Pse= udo reassembly) , SPD policy is checked. 
 
Case A: 'fragCheck' is TRUE in the policy.  If the peer do= es not support 'stateful fragment check',   SAs will not be est= ablished and thereby no traffic would pass through. User of the device ca= n be informed through auditable event indicating that peer does not suppo= rt 'stateful fragment checking'.  If the peer supports it, SA establ= ishment goes through and traffic will pass through the tunnel.
 
Case B:  fragCheck is FALSE in the policy. In this case, i= f there is no policy with transport selector values set to OPAQUE, then t= here is a possibility that, the non-initial fragments would not be secure= d and most probably would be discarded (if there is no BYPASS policy).
Also, based on rfc2401-bis, this case is not preferable for IPv6.
 
 
Case 2: IPsec device is deployed in an environment where all outboun= d fragments may not come to same IPsec device.
 
In case of pseudo reassembly fragments is not possible.
 
In this case, even 'fragCheck' is set to TRUE in the policy, device = should not negotiate 'stateful fragment related IKV2 notify message'.&nbs= p;  It should fallback onto 'separate tunnel SA for non-initial frag= ments'.  If this is not desirable (as per RFC2401-bis, this is not d= esirable for IPv6), then the only option is to disallow user to configure= any security policies with transport selectors ie all policies should ha= ve IPv6 address selectors only.
 
 
In summary:
In case1, all security policies with transport selectors must have '= fragCheck' set to TRUE.
In case2, security policies must not be configured with transport se= lectors.
 
 
Surya
 
 
 
 
 
 

Do you Yahoo!?
=20 All your favorites on one personal page =96 Try My Yahoo! --0-1568803776-1105292149=:76990-- --===============0709656242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0709656242==-- From ipsec-bounces@ietf.org Sun Jan 9 15:07:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02854 for ; Sun, 9 Jan 2005 15:07:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnjCK-0005Qj-7K; Sun, 09 Jan 2005 14:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cnj8k-0004wb-7N for ipsec@megatron.ietf.org; Sun, 09 Jan 2005 14:54:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02000 for ; Sun, 9 Jan 2005 14:54:16 -0500 (EST) Received: from web52610.mail.yahoo.com ([206.190.39.148]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CnjMB-0005Bl-UW for ipsec@ietf.org; Sun, 09 Jan 2005 15:08:13 -0500 Received: (qmail 97946 invoked by uid 60001); 9 Jan 2005 19:53:46 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=LcfwBjzgqDtLT+pupk0CX4qB8PzcPxzWNe7zLlq4yDCYE4mJBNx/pJvx48d88Hcs0QSsLs7Nn51j8RGo2PXLrWbRZEqaNP79G+w5fCyXcRO0gB5UMoM6Ei/PrqpC16oD1m7MJMbv736Uqgm2t3VYfRcW9d9pYQZ7r7zE+CWjm9A= ; Message-ID: <20050109195346.97944.qmail@web52610.mail.yahoo.com> Received: from [69.109.118.20] by web52610.mail.yahoo.com via HTTP; Sun, 09 Jan 2005 11:53:46 PST Date: Sun, 9 Jan 2005 11:53:46 -0800 (PST) From: Subha Venkataramanan To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ipsec] Question: IPv6 fragment handling by VPN Security Gateway X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi List-members, I have a question on how an intermediate IPv6 router doing IPsec should handle fragments (whose size is 1280) at the protected side and that upon encryption could become > 1280 bytes. Since Intermediate IPv6 routers are not supposed to fragment, I suppose the security gateway device should send a ICMP PMTU message to the node from which the packet originated. Since the minimum MTU size that is to be supported for IPv6 is 1280, will the end node honour this ICMP PMTU message ? Also should an IPv6 VPN Security Gateway support NAT Traversal ? Thanks, Subha __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 9 21:46:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26864 for ; Sun, 9 Jan 2005 21:46:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnpXN-0006N5-Bj; Sun, 09 Jan 2005 21:44:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnpTV-00065J-7l for ipsec@megatron.ietf.org; Sun, 09 Jan 2005 21:40:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26406 for ; Sun, 9 Jan 2005 21:40:07 -0500 (EST) Received: from [207.145.48.18] (helo=ip-207-145-48-18.sjc.megapath.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cnph1-0002eu-AU for ipsec@ietf.org; Sun, 09 Jan 2005 21:54:07 -0500 Received: from intotoinc.com ([66.80.10.146]) by ip-207-145-48-18.sjc.megapath.net (SMSSMTP 4.0.0.59) with SMTP id M2005010918390908417 ; Sun, 09 Jan 2005 18:39:09 -0800 Received: from IntotoMail (trinity.intoto.com [10.1.5.19]) by intotoinc.com (8.12.5/8.12.5) with SMTP id j0A2gfEM018322; Sun, 9 Jan 2005 18:42:41 -0800 Message-Id: <200501100242.j0A2gfEM018322@intotoinc.com> Received: from client for UebiMiau2.7 (webmail client); Sun, 9 Jan 2005 18:57:36 -0800 Date: Sun, 9 Jan 2005 18:57:36 -0800 From: "Srinivasa Rao Addepalli" To: "Subha Venkataramanan" , "ipsec@ietf.org" Subject: Re: [Ipsec] Question: IPv6 fragment handling by VPN Security Gateway X-Priority: 3 X-Mailer: Intoto Mail 1.2 X-MSMail-Priority: Medium Importance: Medium MIME-Version: 1.0 X-Spam-Score: 4.3 (++++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Srinivasa Rao Addepalli List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0730754113==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0730754113== Content-Type: text/html; charset="iso-8859-1"; Content-Transfer-Encoding: 8bit

--------- Original Message --------
From: "Subha Venkataramanan" <subhaav@yahoo.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: [Ipsec] Question: IPv6 fragment handling by VPN Security Gateway
Date: Sun 01/09/05 04:11 AM


Hi List-members,

I have a question on how an intermediate IPv6 router
doing IPsec should handle fragments (whose size is
1280) at the protected side and that upon encryption
could become > 1280 bytes.

Since Intermediate IPv6 routers are not supposed
to fragment, I suppose the security gateway device
should send a ICMP PMTU message to the node from
which the packet originated.

SRINI>IPsec gateway is not fragmenting the original packet. It might fragment the tunnel packet, which is anyway new packet and originating from this device.

SRINI> Sending ICMP too big message is still good as long as PMTU is equal or more than 1280. Note that, the sender need not honor ICMP too big a message, if it has PMTU value less than 1280.


Since the minimum MTU size that is to be supported for
IPv6 is 1280, will the end node honour this ICMP PMTU
message ?

Also should an IPv6 VPN Security Gateway support NAT
Traversal ?

Thanks,
Subha



__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec




--===============0730754113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0730754113==-- From ipsec-bounces@ietf.org Mon Jan 10 12:16:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06440 for ; Mon, 10 Jan 2005 12:16:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2zV-0003jI-1T; Mon, 10 Jan 2005 12:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2sE-00021K-4Y for ipsec@megatron.ietf.org; Mon, 10 Jan 2005 11:58:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04929 for ; Mon, 10 Jan 2005 11:58:31 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co35p-0000XF-7F for ipsec@ietf.org; Mon, 10 Jan 2005 12:12:40 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0AGvqjh002653; Mon, 10 Jan 2005 11:57:55 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050108163836.93011.qmail@web90001.mail.scd.yahoo.com> References: <20050108163836.93011.qmail@web90001.mail.scd.yahoo.com> Date: Mon, 10 Jan 2005 11:57:37 -0500 To: Surya Batchu From: Stephen Kent Subject: Re: [Ipsec] Stateful fragment check Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:38 AM -0800 1/8/05, Surya Batchu wrote: >Hi, > >If 'Stateful fragmen check' is required, then the security policies >on the both communicating security gateways should be configured >with the 'fragCheck' set to TRUE. It means that, the users >configuring the policies on these security gateways should know a >priori that these gateway support this feature. Is that correct? > >If so, what are the advantages of negotiating >IKE_NOTIFY_NON_FIRST_FRAGMENT_ALSO using IKEv2? An IPsec implementation uses this feature to determine if a peer is willing to accommodate non-initial fragments on the SA being negotiated, when the traffic selectors for the SA require inspection of port fields. > If there is any mis-configuration of 'fragCheck' flag on IPsec >peers, then this negotiation helps in notifying the user with >auditable event and correcting the configuration. This is one >advantage I see. Are there any other uses of this? It is not necessarily a mis-configuration, just a different local policy, just like traffic selectors are local policy info. We need a way to detect that there would be problems if non-initial fragments were sent via the SA, just as we want a way to detect if traffic consistent with specified selectors will be acceptable to a peer. IKE negotiation accomplishes this. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 10 15:32:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21419 for ; Mon, 10 Jan 2005 15:32:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co644-0007IZ-9b; Mon, 10 Jan 2005 15:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co62p-0006tQ-F8; Mon, 10 Jan 2005 15:21:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20460; Mon, 10 Jan 2005 15:21:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co6GU-0006c2-EG; Mon, 10 Jan 2005 15:35:51 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Co61e-0006OG-2K; Mon, 10 Jan 2005 15:20:30 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 10 Jan 2005 15:20:30 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec mailing list , ipsec chair , Internet Architecture Board , ipsec chair , RFC Editor Subject: [Ipsec] Protocol Action: 'Extended Sequence Number Addendum to IPsec DOI for ISAKMP' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has approved the following document: - 'Extended Sequence Number Addendum to IPsec DOI for ISAKMP ' as a Proposed Standard This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Russ Housley and Sam Hartman. Technical Summary The IPsec Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the IPsec DOI for ISAKMP. These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended 64-bit sequence numbers for a particular AH or ESP security association. Working Group Summary The IPsec Working Group came to consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 10 15:38:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22294 for ; Mon, 10 Jan 2005 15:38:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co6Bh-0002cl-RN; Mon, 10 Jan 2005 15:30:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co643-0007I9-J7; Mon, 10 Jan 2005 15:22:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20605; Mon, 10 Jan 2005 15:22:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co6Hj-0006eV-J6; Mon, 10 Jan 2005 15:37:07 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Co62p-0006u9-Tw; Mon, 10 Jan 2005 15:21:43 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 10 Jan 2005 15:21:43 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipsec mailing list , ipsec chair , Internet Architecture Board , ipsec chair , RFC Editor Subject: [Ipsec] Protocol Action: 'IP Authentication Header' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has approved the following document: - 'IP Authentication Header ' as a Proposed Standard This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Russ Housley and Sam Hartman. Technical Summary This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This obsoletes RFC 2402, which was published in November 1998. Working Group Summary The IPsec Working Group came to consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 10 16:38:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04380 for ; Mon, 10 Jan 2005 16:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co6YN-0006oq-AK; Mon, 10 Jan 2005 15:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co6WU-0005mR-Ld for ipsec@megatron.ietf.org; Mon, 10 Jan 2005 15:52:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23878 for ; Mon, 10 Jan 2005 15:52:20 -0500 (EST) Received: from [207.145.48.18] (helo=ip-207-145-48-18.sjc.megapath.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Co6k9-0007uG-P6 for ipsec@ietf.org; Mon, 10 Jan 2005 16:06:31 -0500 Received: from intotoinc.com ([66.80.10.146]) by ip-207-145-48-18.sjc.megapath.net (SMSSMTP 4.0.0.59) with SMTP id M2005011012512309269 for ; Mon, 10 Jan 2005 12:51:23 -0800 Received: from subha (dhcp-66.intoto.com [10.1.5.66]) by intotoinc.com (8.12.5/8.12.5) with SMTP id j0AKt1EN023038 for ; Mon, 10 Jan 2005 12:55:01 -0800 Message-ID: <12be01c4f755$e6f42fa0$4205010a@subha> From: "subha" To: References: <20050108163836.93011.qmail@web90001.mail.scd.yahoo.com> Date: Mon, 10 Jan 2005 12:49:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Multiple Seperate IPSec Contexts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi List-members, Is there a draft or RFC that indicates how to send Context Identifiers and receive Context Identifiers in IKE payload ? Basically, when acting as a responder, how do we get this context identifier from the peer, to internally determine, which IPsec context to use ? Thanks, Subha _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 11 14:22:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18097 for ; Tue, 11 Jan 2005 14:22:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoRY3-0001lI-DX; Tue, 11 Jan 2005 14:19:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoRSb-0001Gs-IZ for ipsec@megatron.ietf.org; Tue, 11 Jan 2005 14:13:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17556 for ; Tue, 11 Jan 2005 14:13:44 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoRgQ-0004Ip-Bz for ipsec@ietf.org; Tue, 11 Jan 2005 14:28:05 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0BJD6jf002224; Tue, 11 Jan 2005 14:13:06 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050109173550.77387.qmail@web90001.mail.scd.yahoo.com> References: <20050109173550.77387.qmail@web90001.mail.scd.yahoo.com> Date: Tue, 11 Jan 2005 14:12:57 -0500 To: Surya Batchu From: Stephen Kent Subject: Re: [Ipsec] Fragment handling in IPv6 based IPsec X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0756427121==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0756427121== Content-Type: multipart/alternative; boundary="============_-1106651715==_ma============" --============_-1106651715==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:35 AM -0800 1/9/05, Surya Batchu wrote: >Content-Type: text/html; charset=us-ascii >X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA25887 > >Please validate my understanding. > >Assumption: Security policy is configured with transport selectors. I assume you mean non-trivial port selectors (the phrase defined in 240abis), and the reference is to an SPD policy entry, which is the subject of the discussion below, right? >IPv6: > >Case1: IPsec device is deployed in an environment, where all IP >packets (all fragments) will go through the device. > >All fragments of a packet can be gathered together (Some sort of >Pseudo reassembly) , SPD policy is checked. it looks like you talking about an IPsec device as a sender, but it would be nice to say so explicitly. also, you have not clearly stated the context the discussion, e.g., arrival of an outbound packet at a sender with no extant, matching SA in place to carry the packet, and a resulting search of the SPD to locate a policy and establish an SA with a peer. is the packet that triggers the SA creation a non-initial fragment? > Case A: 'fragCheck' is TRUE in the policy. If the peer does not >support 'stateful fragment check', SAs will not be established and >thereby no traffic would pass through. User of the device can be >informed through auditable event indicating that peer does not >support 'stateful fragment checking'. If the peer supports it, SA >establishment goes through and traffic will pass through the tunnel. right, assuming all of the context info I added above. > Case B: fragCheck is FALSE in the policy. In this case, if there >is no policy with transport selector values set to OPAQUE, then >there is a possibility that, the non-initial fragments would not be >secured and most probably would be discarded (if there is no BYPASS >policy). >Also, based on rfc2401-bis, this case is not preferable for IPv6. This is basically true, if I interpret you comments to refer to non-initial fragments being compared to the SPD and the SAD based on address and protocol matching, so that the ambiguity is just in terms of the port fields. Having a BYPASS entry that would allow non-initial fragments to be bypassed, when initial ones would be protected, would be a bad idea. 2401bis does not say this case is bad, per se, for IPv6. It is a problem for v4 as well, since the conditions you cite rule out all three of the options described in section 7 for accommodating fragments. >Case 2: IPsec device is deployed in an environment where all >outbound fragments may not come to same IPsec device. you mean inbound fragments, not outbound fragments. > In case of pseudo reassembly fragments is not possible. 2401bis says stateful fragment checking may fail in such contexts. > In this case, even 'fragCheck' is set to TRUE in the policy, device >should not negotiate 'stateful fragment related IKV2 notify >message'. It should fallback onto 'separate tunnel SA for >non-initial fragments'. If this is not desirable (as per >RFC2401-bis, this is not desirable for IPv6), then the only option >is to disallow user to configure any security policies with >transport selectors ie all policies should have IPv6 address >selectors only. A local admin may choose to try stateful fragment checking even under these circumstances, since it may work most of the time anyway, depending on a variety of factors. For example, how often fragments arise, whether the multiple paths permitted by the multiple SGs are invoked for load sharing in a way that makes it likely that fragments of a single packet are sent to different destination SGs, etc. >In summary: >In case1, all security policies with transport selectors must have >'fragCheck' set to TRUE. >In case2, security policies must not be configured with transport selectors. This summary seems a bit oversimplified, perhaps because I had to try to fill in a lot of missing context for your questions/statements. It is fair to say that IF one chooses to accommodate fragments over tunnels (many enterprise environments do not) and IF your security policy makes use of port-field selectors (not all enterprises do), THEN use of stateful fragment checking is a good idea for IPv6, since the separate tunnel option defined in section 7.2 is not advisable for IPv6. In contexts where there are multiple security gateways serving an enclave, it may or may not be OK to use port selectors. In practice, the existence of multiple security gateways does not always mean that fragments of a single packet will often arrive at different gateways, although this is possible. In many contexts the fragments for a given packet will likely traverse the same gateway, making stateful checking feasible. Steve --============_-1106651715==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] Fragment handling in IPv6 based IPsec
At 9:35 AM -0800 1/9/05, Surya Batchu wrote:
Content-Type: text/html; charset=us-ascii
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA25887
Please validate my understanding.
 
Assumption: Security policy is configured with transport selectors.

I assume you mean non-trivial port selectors (the phrase defined in 240abis), and the reference is to an SPD policy entry, which is the subject of the discussion below, right?

IPv6:
 
Case1:  IPsec device is deployed in an environment, where all IP packets (all fragments) will go through the device.
 
All fragments of a packet can be gathered together (Some sort of Pseudo reassembly) , SPD policy is checked.

it looks like you talking about an IPsec device as a sender, but it would be nice to say so explicitly. also, you have not clearly stated the context the discussion, e.g., arrival of an outbound packet at a sender with no extant, matching SA in place to carry the packet, and a resulting search of the SPD to locate a policy and establish an SA with a peer. is the packet that triggers the SA creation a non-initial fragment?

 Case A: 'fragCheck' is TRUE in the policy.  If the peer does not support 'stateful fragment check',   SAs will not be established and thereby no traffic would pass through. User of the device can be informed through auditable event indicating that peer does not support 'stateful fragment checking'.  If the peer supports it, SA establishment goes through and traffic will pass through the tunnel.

right, assuming all of the context info I added above.

 Case B:  fragCheck is FALSE in the policy. In this case, if there is no policy with transport selector values set to OPAQUE, then there is a possibility that, the non-initial fragments would not be secured and most probably would be discarded (if there is no BYPASS policy).
Also, based on rfc2401-bis, this case is not preferable for IPv6.

This is basically true, if I interpret you comments to refer to non-initial fragments being compared to the SPD and the SAD based on address and protocol matching, so that the ambiguity is just in terms of the port fields. Having a BYPASS entry that would allow non-initial fragments to be bypassed, when initial ones would be protected, would be a bad idea. 2401bis does not say this case is bad, per se, for IPv6. It is a problem for v4 as well, since the conditions you cite rule out all three of the options described in section 7 for accommodating fragments.

Case 2: IPsec device is deployed in an environment where all outbound fragments may not come to same IPsec device.

you mean inbound fragments, not outbound fragments.

 In case of pseudo reassembly fragments is not possible.

2401bis says stateful fragment checking may fail in such contexts.

 In this case, even 'fragCheck' is set to TRUE in the policy, device should not negotiate 'stateful fragment related IKV2 notify message'.   It should fallback onto 'separate tunnel SA for non-initial fragments'.  If this is not desirable (as per RFC2401-bis, this is not desirable for IPv6), then the only option is to disallow user to configure any security policies with transport selectors ie all policies should have IPv6 address selectors only.

A local admin may choose to try stateful fragment checking even under these circumstances, since it may work most of the time anyway, depending on a variety of factors. For example, how often fragments arise, whether the multiple paths permitted by the multiple SGs are invoked for load sharing in a way that makes it likely that fragments of a single packet are sent to different destination SGs, etc.

In summary:
In case1, all security policies with transport selectors must have 'fragCheck' set to TRUE.
In case2, security policies must not be configured with transport selectors.

This summary seems a bit oversimplified, perhaps because I had to try to fill in a lot of missing context for your questions/statements.

It is fair to say that IF one chooses to accommodate fragments over tunnels (many enterprise environments do not) and IF your security policy makes use of port-field selectors (not all enterprises do), THEN use of stateful fragment checking is a good idea for IPv6, since the separate tunnel option defined in section 7.2 is not advisable for IPv6.  In contexts where there are multiple security gateways serving an enclave, it may or may not be OK to use port selectors. In practice, the existence of multiple security gateways does not always mean that fragments of a single packet will often arrive at different gateways, although this is possible.  In many contexts the fragments for a given packet will likely traverse the same gateway, making stateful checking feasible.

Steve
--============_-1106651715==_ma============-- --===============0756427121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0756427121==-- From ipsec-bounces@ietf.org Tue Jan 11 15:09:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21882 for ; Tue, 11 Jan 2005 15:09:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSD1-0001BS-Jo; Tue, 11 Jan 2005 15:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoS7V-0007l8-QI for ipsec@megatron.ietf.org; Tue, 11 Jan 2005 14:56:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20754 for ; Tue, 11 Jan 2005 14:56:00 -0500 (EST) Received: from web52604.mail.yahoo.com ([206.190.39.142]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CoSLL-0005Fc-74 for ipsec@ietf.org; Tue, 11 Jan 2005 15:10:22 -0500 Received: (qmail 91838 invoked by uid 60001); 11 Jan 2005 19:55:26 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=O/Iq8OsdN7tSHXXPYY4RI+KZniihXa38A1LVphbnhjVXmDkGEOcDDZEhZis8wplU13RvYERtCrMtULdW3iGVdw45GH62Cv5O/S754Z9BrQW4o8XXNrp+jM/A6FYdLGwZv/Jpgf2o7iyKPPFYw83ZKjLmXB2jsudvbRo3DYkU2TI= ; Message-ID: <20050111195526.91836.qmail@web52604.mail.yahoo.com> Received: from [69.109.118.20] by web52604.mail.yahoo.com via HTTP; Tue, 11 Jan 2005 11:55:26 PST Date: Tue, 11 Jan 2005 11:55:26 -0800 (PST) From: Subha Venkataramanan Subject: Re: [Ipsec] Multiple Seperate IPSec Contexts To: subha , ipsec@ietf.org In-Reply-To: <12be01c4f755$e6f42fa0$4205010a@subha> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Maybe my initial mail was not clear. I am re-sending it with more information. Draft 2401-bis, talks about the following in Section 4.4. It states 'To this end, if supported by the key management protocolin use, context identifiers MAY be conveyed from Initiator to Responder in the signalling messages, with the result that the IPsec SAs are created with a binding to a particular context' This does not address the scenario, where when we are acting as a Responder,how do we make the peer send some IPsec context info, so that internally we know which context to use. Is there any draft that talks about this ? Thanks, Subha --- subha wrote: > Hi List-members, > > Is there a draft or RFC that indicates how to send > Context Identifiers > and receive Context Identifiers in IKE payload ? > > Basically, when acting as a responder, how do we get > this context identifier > from the peer, to internally determine, which IPsec > context to use ? > > Thanks, > Subha > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 11 15:51:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26427 for ; Tue, 11 Jan 2005 15:51:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSjd-0007CV-BZ; Tue, 11 Jan 2005 15:35:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSiO-0006Nn-Ac for ipsec@megatron.ietf.org; Tue, 11 Jan 2005 15:34:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24220 for ; Tue, 11 Jan 2005 15:34:06 -0500 (EST) Received: from [207.145.48.18] (helo=ip-207-145-48-18.sjc.megapath.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CoSwE-0005xS-LF for ipsec@ietf.org; Tue, 11 Jan 2005 15:48:29 -0500 Received: from intotoinc.com ([66.80.10.146]) by ip-207-145-48-18.sjc.megapath.net (SMSSMTP 4.0.0.59) with SMTP id M2005011112330510260 for ; Tue, 11 Jan 2005 12:33:05 -0800 Received: from SriniSony (SriniSony.intoto.com [10.1.5.118]) by intotoinc.com (8.12.5/8.12.5) with ESMTP id j0BKakEN010567 for ; Tue, 11 Jan 2005 12:36:49 -0800 Message-Id: <200501112036.j0BKakEN010567@intotoinc.com> From: "Srinivasa Rao Addepalli" To: Subject: Re: [Ipsec] Multiple Seperate IPSec Contexts Date: Tue, 11 Jan 2005 12:33:23 -0800 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT4GfmtfXQYibK9RTaRGNCE7kheTAAAdHjwAAA8tSA= X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Subha Venkataramanan Sent: Tuesday, January 11, 2005 11:55 AM To: subha; ipsec@ietf.org Subject: Re: [Ipsec] Multiple Seperate IPSec Contexts Hi, Maybe my initial mail was not clear. I am re-sending it with more information. Draft 2401-bis, talks about the following in Section 4.4. It states 'To this end, if supported by the key management protocolin use, context identifiers MAY be conveyed from Initiator to Responder in the signalling messages, with the result that the IPsec SAs are created with a binding to a particular context' This does not address the scenario, where when we are acting as a Responder,how do we make the peer send some IPsec context info, so that internally we know which context to use. Is there any draft that talks about this ? SRINI> I am not aware of any defined mechanism in IKEv2 to identify the IPsec context. One way to do this is to define public IP address for each IPsec context i.e as many public IP addresses as number of IPsec contexts. Based on the 'destination IP' address of incoming IKE message, appropriate IPsec context can be determined. Thanks, Subha --- subha wrote: > Hi List-members, > > Is there a draft or RFC that indicates how to send > Context Identifiers > and receive Context Identifiers in IKE payload ? > > Basically, when acting as a responder, how do we get > this context identifier > from the peer, to internally determine, which IPsec > context to use ? > > Thanks, > Subha > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 11 17:06:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09093 for ; Tue, 11 Jan 2005 17:06:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTsr-0001kQ-My; Tue, 11 Jan 2005 16:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTh4-00029I-Ow for ipsec@megatron.ietf.org; Tue, 11 Jan 2005 16:36:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05963 for ; Tue, 11 Jan 2005 16:36:48 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoTuv-0001T0-4e for ipsec@ietf.org; Tue, 11 Jan 2005 16:51:12 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.177]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Z5KGLWY7; Tue, 11 Jan 2005 16:35:55 -0500 Message-Id: <6.2.0.14.2.20050111161829.03464a18@email> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 11 Jan 2005 16:29:00 -0500 To: Subha Venkataramanan , subha , ipsec@ietf.org From: Mark Duffy Subject: Re: [Ipsec] Multiple Seperate IPSec Contexts In-Reply-To: <20050111195526.91836.qmail@web52604.mail.yahoo.com> References: <12be01c4f755$e6f42fa0$4205010a@subha> <20050111195526.91836.qmail@web52604.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Subha, There was a discussion of this relative to IKEv2 in March 2003. (Look in the mail list archives for the thread "Another field for traffic selector?"). At that time the wg decided not to put anything into the base IKEv2 for signalling of context, but that it could possibly be done later as an extension. Then in 2401bis the text you quote below was added to explicitly permit this sort of thing. But AFAIK there has been no effort to actually define this capability for IKEv2. --Mark At 02:55 PM 1/11/2005, Subha Venkataramanan wrote: >Hi, > >Maybe my initial mail was not clear. I am re-sending >it with more information. > >Draft 2401-bis, talks about the following in Section >4.4. > >It states 'To this end, if supported by the key >management protocolin use, context identifiers MAY be >conveyed from Initiator to Responder in the signalling >messages, with the result that the IPsec SAs are >created with a binding to a particular context' > >This does not address the scenario, where when we are >acting as a Responder,how do we make the peer send >some IPsec context info, so that internally we >know which context to use. > >Is there any draft that talks about this ? > >Thanks, >Subha > >--- subha wrote: > > > Hi List-members, > > > > Is there a draft or RFC that indicates how to send > > Context Identifiers > > and receive Context Identifiers in IKE payload ? > > > > Basically, when acting as a responder, how do we get > > this context identifier > > from the peer, to internally determine, which IPsec > > context to use ? > > > > Thanks, > > Subha _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 11 17:47:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11980 for ; Tue, 11 Jan 2005 17:47:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUaG-0005eG-Tn; Tue, 11 Jan 2005 17:33:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUT0-0003pE-DZ for ipsec@megatron.ietf.org; Tue, 11 Jan 2005 17:26:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10478 for ; Tue, 11 Jan 2005 17:26:20 -0500 (EST) Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUgr-0002uJ-4y for ipsec@ietf.org; Tue, 11 Jan 2005 17:40:44 -0500 Received: from [10.31.100.177] ([10.31.100.177]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA08252 for ; Tue, 11 Jan 2005 14:25:29 -0800 (PST) Message-ID: <41E45259.9030209@windriver.com> Date: Tue, 11 Jan 2005 15:25:29 -0700 From: Russ Magee User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Ipsec] AES for Quick Mode in IKE? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, According to RFC3602, Section 7.: 7. IANA Considerations IANA has assigned Encryption Algorithm ID 7 to AES-CBC. IANA has assigned ESP Transform Identifier 12 to ESP_AES. Am I correct in interpreting this to mean that AES-CBC, if used for encryption in IKE, uses Encryption Algorithm ID 7 [RFC2409, Appendix A]? There appears to be no RFC detailing specifically how AES-CBC should be used in IKE, so can anyone please shed details on 1) How keying material is generated and used to yield keys during Phase 1 for use in Quick Mode for AES-CBC. The RFCs would imply that it should be done identically to 3DES, feeding a PRF repeatedly and concatenating the results as described in [RFC2409, 5.3]. 2) What other vendors (if any) have already implemented AES in IKE and details on their implementation that would affect interoperability. Thanks very much, -Russ Magee Wind River Systems _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 11 19:19:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19518 for ; Tue, 11 Jan 2005 19:19:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoW3H-0007IB-JK; Tue, 11 Jan 2005 19:07:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVvC-0005Vn-Et for ipsec@megatron.ietf.org; Tue, 11 Jan 2005 18:59:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17885 for ; Tue, 11 Jan 2005 18:59:31 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoW95-0004u3-RW for ipsec@ietf.org; Tue, 11 Jan 2005 19:13:57 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j0BNxVpv023426 for ; Tue, 11 Jan 2005 15:59:31 -0800 (PST) Received: from punchin-danmcd.east.sun.com (punchin-danmcd.East.Sun.COM [129.148.19.2]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j0BNxU8p020605 for ; Tue, 11 Jan 2005 18:59:30 -0500 (EST) Received: from punchin-danmcd.east.sun.com (localhost [127.0.0.1]) by punchin-danmcd.east.sun.com (8.13.2+Sun/8.13.2) with ESMTP id j0C02fAB005137; Tue, 11 Jan 2005 19:02:41 -0500 (EST) Received: (from danmcd@localhost) by punchin-danmcd.east.sun.com (8.13.2+Sun/8.13.2/Submit) id j0C02fdV005136; Tue, 11 Jan 2005 19:02:41 -0500 (EST) Date: Tue, 11 Jan 2005 19:02:40 -0500 From: Dan McDonald To: Russ Magee Subject: Re: [Ipsec] AES for Quick Mode in IKE? Message-ID: <20050112000240.GA5104@everywhere.east.sun.com> References: <41E45259.9030209@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E45259.9030209@windriver.com> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Networking & Security X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, Jan 11, 2005 at 03:25:29PM -0700, Russ Magee wrote: > IANA has assigned Encryption Algorithm ID 7 to AES-CBC. > IANA has assigned ESP Transform Identifier 12 to ESP_AES. > > Am I correct in interpreting this to mean that AES-CBC, if used for > encryption in IKE, uses Encryption Algorithm ID 7 [RFC2409, Appendix A]? Yes. > There appears to be no RFC detailing specifically how AES-CBC should be > used in IKE, so can anyone please shed details on > > 1) How keying material is generated and used to yield keys during Phase > 1 for use in Quick Mode for AES-CBC. The RFCs would imply that it > should be done identically to 3DES, feeding a PRF repeatedly and > concatenating the results as described in [RFC2409, 5.3]. I believe that is correct. (Historical note - people should've specified this with Blowfish, instead of fixing interoperable Blowfish at 128 bits.) > 2) What other vendors (if any) have already implemented AES in IKE > and details on their implementation that would affect > interoperability. We haven't enabled AES in IKE yet, but it should be straightforward - (esp. given our IKE code's lineage). The biggest obstacle I see to interop is properly handling the Key Length attribute in both Phase 1 and 2. Also, to get your biggest security bang for your buck, you should probably be using one of the newer and larger Diffie-Hellman groups, as well as one of the SHA2 hashes. I'm sure the testing event coming up in February will cover AES in IKEv1. Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 12 06:02:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01338 for ; Wed, 12 Jan 2005 06:02:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cog9p-0006bb-VO; Wed, 12 Jan 2005 05:55:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cog1r-000542-HE for ipsec@megatron.ietf.org; Wed, 12 Jan 2005 05:47:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00474 for ; Wed, 12 Jan 2005 05:47:05 -0500 (EST) Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CogFq-0001ZB-H9 for ipsec@ietf.org; Wed, 12 Jan 2005 06:01:35 -0500 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 773BE5BBAB for ; Wed, 12 Jan 2005 12:46:33 +0200 (EET) Received: from unknown[10.128.128.81]:39212 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.150 Release) with SMTP; Wed, 12 Jan 2005 10:46:31 -0000 Received: (qmail 18503 invoked from network); 12 Jan 2005 10:46:31 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 12 Jan 2005 10:46:31 -0000 Message-Id: <5.2.1.1.0.20050112114522.02d5f168@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 12 Jan 2005 11:49:01 +0100 To: Russ Magee , ipsec@ietf.org From: Joern Sierwald Subject: Re: [Ipsec] AES for Quick Mode in IKE? In-Reply-To: <41E45259.9030209@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 15:25 11.01.2005 -0700, Russ Magee wrote: >Hello, > >According to RFC3602, Section 7.: > >7. IANA Considerations > > IANA has assigned Encryption Algorithm ID 7 to AES-CBC. > IANA has assigned ESP Transform Identifier 12 to ESP_AES. > >Am I correct in interpreting this to mean that AES-CBC, if used for=20 >encryption in IKE, uses Encryption Algorithm ID 7 [RFC2409, Appendix A]? > >There appears to be no RFC detailing specifically how AES-CBC should be=20 >used in IKE, so can anyone please shed details on > >1) How keying material is generated and used to yield keys during Phase > 1 for use in Quick Mode for AES-CBC. The RFCs would imply that it > should be done identically to 3DES, feeding a PRF repeatedly and > concatenating the results as described in [RFC2409, 5.3]. > >2) What other vendors (if any) have already implemented AES in IKE > and details on their implementation that would affect > interoperability. > >Thanks very much, >-Russ Magee > Wind River Systems F-Secure (myself actually) has implemented AES for IKE and ESP, and I have found it to be quite trivial. I have just added AES to the list of algorithms. It doesn't need any special treatment, compared to blowfish for instance. Maybe that's why nobody bothered to write a document about it. J=F6rn _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 12 10:21:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21202 for ; Wed, 12 Jan 2005 10:21:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CokB5-0001sy-0y; Wed, 12 Jan 2005 10:12:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cok2T-0006ck-0N for ipsec@megatron.ietf.org; Wed, 12 Jan 2005 10:04:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18694 for ; Wed, 12 Jan 2005 10:03:58 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CokGR-0007re-VV for ipsec@ietf.org; Wed, 12 Jan 2005 10:18:31 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0CF3n3I091480 for ; Wed, 12 Jan 2005 07:03:50 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050112000240.GA5104@everywhere.east.sun.com> References: <41E45259.9030209@windriver.com> <20050112000240.GA5104@everywhere.east.sun.com> Date: Wed, 12 Jan 2005 07:03:52 -0800 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] AES for Quick Mode in IKE? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 7:02 PM -0500 1/11/05, Dan McDonald wrote: >We haven't enabled AES in IKE yet, but it should be straightforward Many vendors find it so. VPNC has 19 products fully interoperating with AES, and are about to add more; see . --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 12 11:08:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24697 for ; Wed, 12 Jan 2005 11:08:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CokyE-00037Y-Qd; Wed, 12 Jan 2005 11:03:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coksj-00020B-RV for ipsec@megatron.ietf.org; Wed, 12 Jan 2005 10:58:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24093 for ; Wed, 12 Jan 2005 10:58:00 -0500 (EST) Received: from web90002.mail.scd.yahoo.com ([66.218.94.60]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Col6j-0000ej-Jy for ipsec@ietf.org; Wed, 12 Jan 2005 11:12:33 -0500 Received: (qmail 32860 invoked by uid 60001); 12 Jan 2005 15:57:26 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=MNQVRsUdXkf99gh48hJZQqoQ8RT532XfZXWjxx7pKJkMmLz1yvf0wHqRb8QhK0xjeMrbvIYB9ipN73RTZu76SKirrh0tEcTyLXUal31Pmnfhehguvq35wGJ0Mfga1AszPMRE5eqFxPVjNK5IG3OdX0vbhL47GPapc3ZJAq5ynHg= ; Message-ID: <20050112155726.32858.qmail@web90002.mail.scd.yahoo.com> Received: from [67.169.115.217] by web90002.mail.scd.yahoo.com via HTTP; Wed, 12 Jan 2005 07:57:26 PST Date: Wed, 12 Jan 2005 07:57:26 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] Fragment handling in IPv6 based IPsec To: Stephen Kent In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.6 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Steve, Yes. Context of original email is in re: outbound packets, ie packets going from protected and unprotected. Your concluding comments indeed clear up lot of things for me. Thanks Surya --- Stephen Kent wrote: > At 9:35 AM -0800 1/9/05, Surya Batchu wrote: > >Content-Type: text/html; charset=us-ascii > >X-MIME-Autoconverted: from 8bit to quoted-printable > by ietf.org id MAA25887 > > > >Please validate my understanding. > > > >Assumption: Security policy is configured with > transport selectors. > > I assume you mean non-trivial port selectors (the > phrase defined in > 240abis), and the reference is to an SPD policy > entry, which is the > subject of the discussion below, right? > > >IPv6: > > > >Case1: IPsec device is deployed in an environment, > where all IP > >packets (all fragments) will go through the device. > > > >All fragments of a packet can be gathered together > (Some sort of > >Pseudo reassembly) , SPD policy is checked. > > it looks like you talking about an IPsec device as a > sender, but it > would be nice to say so explicitly. also, you have > not clearly stated > the context the discussion, e.g., arrival of an > outbound packet at a > sender with no extant, matching SA in place to carry > the packet, and > a resulting search of the SPD to locate a policy and > establish an SA > with a peer. is the packet that triggers the SA > creation a > non-initial fragment? > > > Case A: 'fragCheck' is TRUE in the policy. If > the peer does not > >support 'stateful fragment check', SAs will not > be established and > >thereby no traffic would pass through. User of the > device can be > >informed through auditable event indicating that > peer does not > >support 'stateful fragment checking'. If the peer > supports it, SA > >establishment goes through and traffic will pass > through the tunnel. > > right, assuming all of the context info I added > above. > > > Case B: fragCheck is FALSE in the policy. In > this case, if there > >is no policy with transport selector values set to > OPAQUE, then > >there is a possibility that, the non-initial > fragments would not be > >secured and most probably would be discarded (if > there is no BYPASS > >policy). > >Also, based on rfc2401-bis, this case is not > preferable for IPv6. > > This is basically true, if I interpret you comments > to refer to > non-initial fragments being compared to the SPD and > the SAD based on > address and protocol matching, so that the ambiguity > is just in terms > of the port fields. Having a BYPASS entry that would > allow > non-initial fragments to be bypassed, when initial > ones would be > protected, would be a bad idea. 2401bis does not say > this case is > bad, per se, for IPv6. It is a problem for v4 as > well, since the > conditions you cite rule out all three of the > options described in > section 7 for accommodating fragments. > > >Case 2: IPsec device is deployed in an environment > where all > >outbound fragments may not come to same IPsec > device. > > you mean inbound fragments, not outbound fragments. > > > In case of pseudo reassembly fragments is not > possible. > > 2401bis says stateful fragment checking may fail in > such contexts. > > > In this case, even 'fragCheck' is set to TRUE in > the policy, device > >should not negotiate 'stateful fragment related > IKV2 notify > >message'. It should fallback onto 'separate > tunnel SA for > >non-initial fragments'. If this is not desirable > (as per > >RFC2401-bis, this is not desirable for IPv6), then > the only option > >is to disallow user to configure any security > policies with > >transport selectors ie all policies should have > IPv6 address > >selectors only. > > A local admin may choose to try stateful fragment > checking even under > these circumstances, since it may work most of the > time anyway, > depending on a variety of factors. For example, how > often fragments > arise, whether the multiple paths permitted by the > multiple SGs are > invoked for load sharing in a way that makes it > likely that fragments > of a single packet are sent to different destination > SGs, etc. > > >In summary: > >In case1, all security policies with transport > selectors must have > >'fragCheck' set to TRUE. > >In case2, security policies must not be configured > with transport selectors. > > This summary seems a bit oversimplified, perhaps > because I had to try > to fill in a lot of missing context for your > questions/statements. > > It is fair to say that IF one chooses to accommodate > fragments over > tunnels (many enterprise environments do not) and IF > your security > policy makes use of port-field selectors (not all > enterprises do), > THEN use of stateful fragment checking is a good > idea for IPv6, since > the separate tunnel option defined in section 7.2 is > not advisable > for IPv6. In contexts where there are multiple > security gateways > serving an enclave, it may or may not be OK to use > port selectors. In > practice, the existence of multiple security > gateways does not always > mean that fragments of a single packet will often > arrive at different > gateways, although this is possible. In many > contexts the fragments > for a given packet will likely traverse the same > gateway, making > stateful checking feasible. > > Steve __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 12 14:14:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06247 for ; Wed, 12 Jan 2005 14:14:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ConrV-0007qR-B7; Wed, 12 Jan 2005 14:08:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ConpC-0007Dt-Gq for ipsec@megatron.ietf.org; Wed, 12 Jan 2005 14:06:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05872 for ; Wed, 12 Jan 2005 14:06:33 -0500 (EST) From: rob.parkhill@windriver.com Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coo3G-0004kU-3x for ipsec@ietf.org; Wed, 12 Jan 2005 14:21:07 -0500 Received: from ala-mta03.windriver.com (ala-mta03 [147.11.57.132]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA17413 for ; Wed, 12 Jan 2005 11:05:55 -0800 (PST) Received: by ala-mta03.wrs.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jan 2005 11:05:56 -0800 Message-ID: To: ipsec@ietf.org Subject: RE: [Ipsec] AES for Quick Mode in IKE? Date: Wed, 12 Jan 2005 11:05:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Paul Hoffman writes: > Many vendors find it so. VPNC has 19 products fully > interoperating with AES, and are about to add more; see > . Is the use (sending and receiving) of the key length attribute in Phase 1 a requirement for AES interop? The AES interop test only uses 128-bit keys, but I see no mention of requiring the key length attribute. thanks... Rob _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 12 20:50:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08431 for ; Wed, 12 Jan 2005 20:50:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cotup-0007t2-6n; Wed, 12 Jan 2005 20:36:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CottH-0007Wd-Ho for ipsec@megatron.ietf.org; Wed, 12 Jan 2005 20:35:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07543 for ; Wed, 12 Jan 2005 20:35:10 -0500 (EST) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cou7M-0005rA-Dp for ipsec@ietf.org; Wed, 12 Jan 2005 20:49:48 -0500 Received: from root (helo=thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1Cotsx-0002gP-00; Wed, 12 Jan 2005 20:34:51 -0500 Received: from tytso by thunk.org with local (Exim 4.43) id 1Cotsw-00032I-C9; Wed, 12 Jan 2005 20:34:50 -0500 To: kent@bbn.com, kseo@bbn.com From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 12 Jan 2005 20:34:50 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: ipsec@ietf.org, housley@vigilsec.com Subject: [Ipsec] Issues remaining for draft-ietf-ipsec-rfc2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Based on the results of the IETF-wide last call of 2401-bis and the comments from the IESG, these are the issues which Barbara and I believe still need to be addressed in draft-ietf-ipsec-rfc2401bis-05. If anyone believes there are any issues that we missed, please let us know as soon as possible. Steve, Karen --- I understand that you have been communicating with some of the AD's directly with respect to their concerns. How far away are we from reaching closure on these issues, and are there any that you feel require specific attention from the working group? Many thanks!! - Ted Last Call Issues ================ Mark Duffy's 2401-bis fragment checking for Bypass/Discard (see ipsec mailing list thread starting on October 5th through November 6th: Date: Sat, 06 Nov 2004 23:36:25 -0500 From: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD Ted, Thank you for taking the time to re-read the thread and think about this issue. What I would seek is a minor change that allows discarding non-initial fragments processed for BYPASS as an alternative to stateful fragment checking of them. I think this can be as simple as replacing this sentence in 7.4: An implementation MUST support stateful fragment checking to accommodate BYPASS traffic for which a non-trivial port range is specified. with this one: An implementation MUST NOT forward fragmented BYPASS traffic without performing stateful fragment checking. ------------------------------------- IESG Issues =========== Harald Alvestrand: Comment: Reviewed by Brian Carpenter, Gen-ART There are nits and small comments (review in document log), but no show-stoppers. [ i.e., Brian Carpenter's comments, see ipsec mailing list. ] -------------------------------------------------- Ted Hardie: Comment: This seems to have a mix of RFC 2026 and RFC 3668 boilerplates. -------------------------------------------------- Ted Hardie: In Section 4.1, the draft says: In many secure multicast (or anycast) architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the Group Security Association's (GSA's) SPI. 3740 does not seem to mention anycast. Is there a similar reference for anycast? -------------------------------------------------- Ted Hardie: Section 4.4.1 uses 192.168 addresses, rather than the example prefix 192.0.2.x/24 -------------------------------------------------- Ted Hardie: I found the use of "road warrior" in section 4.5.2 distracting. -------------------------------------------------- Sam Hartman: [issue 1, based on my iSCSI example] I am beginning to believe that I have a somewhat general problem with the balances and tradeoffs that the IPsec working group has chosen and how those interact with the rest of the IETF. The IPsec working group is focusing on IPsec as its own application; system administrators and users who configure IPsec because they want specific traffic protected. That's clearly an important use of IPsec. However the rest of the IETF continues to view IPsec as an appropriate tool for providing security for other applications, protocols, etc. In these situations, IPsec (especially in native implementations) may need to provide appropriate interfaces to these uses. I'm concerned that the 2401bis model favors the first use too much. Revisiting that issue this late in the process would be inappropriate. However I'd like to focus on two cases where 2401bis seems to be problematic for the use of IPsec as a security tool by higher layers. The first issue is one I noticed late yesterday. Section 7.4 mandates stateful fragment handling for bypass and discard traffic if any of the SPD selectors specify a specific port. This means that when I start protecting traffic for one application, I end up having to significantly complicate the packet processing for all my traffic. Especially for native implementations, this seems unnecessary. It seems like the real requirement is that I should not be able to manipulate fragments to generate or receive unprotected traffic when I'm expecting protected traffic. It seems like keeping track of whether a particular socket requires protected traffic would be sufficient. I'm not sure you can do better than 7.4 for other types of implementations. The second case is the case I described eearlier where a host is using IPsec both to provide security services for a higher layer and to enforce specific policy as a security gateway etc. Again, it seems like you can do better than the current document for native implementations. Virtual interfaces based on MAC address seem like the wrong solution; it only works if the protected traffic doesn't share a router with unprotected traffic. I understand not all implementations need to support this sort of functionality. I'm concerned that it is not clear from the current draft that you might want to do this. Also, I'm concerned that you might end up choosing an implementation of this feature with hidden implications. I suspect I need to be more concrete in what I want here. I think that all I'm asking for is clarifying text, but I haven't yet figured out how I'd do what I want in the model so I'm having a hard time determining if it is clear. There are probably one or two rounds of discussion that need to happen on this; I will try to be responsive so this does not bog down. -------------------------------------------------- Sam Hartman: [issue 2; Steve proposed two solutions both of which are acceptable to me.] In 4.4.4.1, the two uses of the name pseudo-selector do not seem to be comparable and so I don't understand why they are overloaded. In the first use, the name is an IKE identity used to contact a responder. In the second use, the name is a local OS user for whom protection services will be used or bypassed (or data discarded). The local OS is unlikely to use IKE identities; local naming is more likely to be unix UIDs, Windows security IDs or something similar. Why are these two different things both called name; why should they be in the same place in the SPD? -------------------------------------------------- Sam Hartman: [issue 3; I think we have rough agreement] The example for X.500 distinguished names seems in the wrong order. Shouldn't the country come last, not first? In any event, a reference to the string encoding of DNs that is being used should probably be given; I'm assuming the example is relative to RFC 2253 or at this point its successor. If you are using a different string encoding--particularly one with different ordering--it is even more critical to cite. -------------------------------------------------- Sam Hartman: [issue 4; one outstanding question; probably the answer will be sufficient for me to drop the issue.] There doesn't in general seem to be a way to create an SPD policy that uses IPsec if a SA is available but is not used otherwise. If the peer is using an IKE identity other than an IP address the name selector is adequate for this task. However I don't understand how to create an SPD entry of this type if the peer will assert an IP address for its identity. -------------------------------------------------- Sam Hartman: [issue 5; open question/clarification] In section 5, the document claims that both outbound and inbound packets must be checked against the SPD (or a cache). This doesn't actually appear to be what's described for inbound packets that use IPsec protection. The procedure for handling packets only checks them against the SAD, not against the SPD. The text claims that the SAD is a cache of the SPD for inbound packets. If this were true, everything would be consistent. However, earlier in section 4.4.1, the document says that a system administrator should be given the opportunity to decide what happens when the SPD is changed. One of the options is to allow extant SAs to continue. If this option is taken, the SAD can contain SAs that correspond to no SPD entry. I believe the simplest fix is to revise section 5 to claim that the SPD is consulted for outbound packets and the SPD-I and SAD are consulted for inbound packets. -------------------------------------------------- Sam Hartman: [issue 6; Steve proposed acceptable solution] The text after rule 4 of 5.2 is confusing; Steve proposes making a rule 5. -------------------------------------------------- Sam Hartman: [issue 7; agreed solution] Section 7.4 should gain the same text about stateful fragment checking not working in case of multiple paths as found in section 7.3. -------------------------------------------------- Sam Hartman: [issue 8; need to post Steve's text to tracker] Steve Kent has new PAD text (4.4.3) which clarifies and extends the PAD. Russ has asked me to hold a discuss on this text. I'm discussing some comments about that text with Steve and Russ and expect to amend my discuss once those discussions complete. -------------------------------------------------- Sam Hartman: [issue 9] Appendix C: There's text at the top of the appendix claiming that the module does not compile because of a duplicate tag. Could you please explain this in more detail. -------------------------------------------------- Sam Hartman: Comment: Section 6.1.2 creates requirements for incoming ICMP packets on the protected side of the IPsec boundary. As best I can tell the attacks described in that section are potential problems for any Internet gateway and have nothing to do with IPsec. If so, why should the IPsec architecture add requirements for additional administrative controls to mitigate these attacks? (I think the administrative controls are a good idea; I'm just unsure why this specification is the right place for them.) -------------------------------------------------- Russ Housley: Discuss: When will the module identifier be assigned for Appendix C? If you want IANA to do it, then it needs to be called out in the IANA Considerations section. -------------------------------------------------- Russ Housley: Comment: Section 4.1: s/Memory (TCAM0 features/Memory (TCAM) features/ Section 4.4.1: s/SPD-SPD-S, SPD-SPD-I, SPD-SPD-O/SPD-S, SPD-I, SPD-O/ s/The SPD-SPD-S/The SPD-S/ Section 4.4.2: s/Database(SAD),/Database (SAD),/ Section 8.2.1: s/SAD entry When/SAD entry. When/ -------------------------------------------------- Alex Zinin: Discuss: How does the in/out-bound processing model defined in section 5 work in the case of a VPN gateway? In particular, how does presence of multiple routing realms and a two-stage forwarding process affect it (imagine a gw that uses dynamic routing over the VPN tunnels protected by IPsec transport mode as encapsulated packets leave the box)? What about locally-originated messages, such as routing messages in this case. I know how to make it work, the question is how the described model addresses these scenarios. -------------------------------------------------- Alex Zinin: Section 4.4 Major IPsec Databases: > Forwarding vs Security Decisions > > The IPsec model described here embodies a clear separation between > forwarding (routing) and security decisions, to accommodate a wide > range of contexts where IPsec may be employed. Forwarding may be > trivial, in the case where there are only two interfaces, or it > may be complex, e.g., if there are multiple protected or > unprotected interfaces or if the context in which IPsec is > implemented employs a sophisticated forwarding function. minor note: complexity of forwarding doesn't depend directly on the number of local interfaces. > IPsec > assumes only that outbound and inbound traffic that has passed > through IPsec processing is forwarded in a fashion consistent with > the context in which IPsec is implemented. What does the above statement really mean? -------------------------------------------------- Alex Zinin: Though Appendix E is not normative, I should note that it is rather confusing. Specifically, though the document states that no changes to the forwarding function are introduced, the appendix mentions two different forwarding tables--one for protected, and one for unprotected side. Also, the representation of the forwarding tables themselves creates an impression that routes usually include both source and destination prefixes, which clearly isn't true (unless we're talking about a special case of policy-based routing). Again, I know how to make it work, but I don't think the doc is very good at explaining this. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 13 19:06:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08201 for ; Thu, 13 Jan 2005 19:06:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpEwh-0002rN-VA; Thu, 13 Jan 2005 19:04:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpEkh-00071H-5k for ipsec@megatron.ietf.org; Thu, 13 Jan 2005 18:51:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06952 for ; Thu, 13 Jan 2005 18:51:39 -0500 (EST) Received: from web52604.mail.yahoo.com ([206.190.39.142]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CpEyy-0004Gt-7H for ipsec@ietf.org; Thu, 13 Jan 2005 19:06:31 -0500 Received: (qmail 36733 invoked by uid 60001); 13 Jan 2005 23:51:08 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=bHwDIChiIRz33I7JsOXu9HD55tw8ZMyS+TkLxh5dFW4yZcgNHB0KBosKjUvIj9yfj9j0yAah/h4ZY4fFRl1fPKW5L5tXIhSeEo7NjnuxgQGm8yWUPPc1+KdG8XOuhppcfN4mrQcbSfApDmZoeH/ylj+PNRgsTTZcSMJFXt2bWNg= ; Message-ID: <20050113235108.36731.qmail@web52604.mail.yahoo.com> Received: from [69.109.173.90] by web52604.mail.yahoo.com via HTTP; Thu, 13 Jan 2005 15:51:08 PST Date: Thu, 13 Jan 2005 15:51:08 -0800 (PST) From: Subha Venkataramanan To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ipsec] Next Layer Protocol (Ref: 2401-bis draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi List-members, In Section 4.4.4.1 (Selectors) under Next- Layer Protocols, it is mentioned that "to simplify locating the next header protocol, there SHOULD be a mechanism for configuring which IPv6 extension headers to SKIP" Could someone indicate to me what was the intent behind this kind of configuration ? Thanks, Subha __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 13 23:47:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25583 for ; Thu, 13 Jan 2005 23:47:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpJG6-0001YU-4u; Thu, 13 Jan 2005 23:40:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpJDj-0000y3-QX for ipsec@megatron.ietf.org; Thu, 13 Jan 2005 23:37:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24872 for ; Thu, 13 Jan 2005 23:37:56 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpJS3-0001IP-3l for ipsec@ietf.org; Thu, 13 Jan 2005 23:52:50 -0500 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0E4bLjf012058; Thu, 13 Jan 2005 23:37:22 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 13 Jan 2005 23:40:54 -0500 To: "Theodore Ts'o" From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Cc: ipsec@ietf.org, housley@vigilsec.com Subject: [Ipsec] Re: Issues remaining for draft-ietf-ipsec-rfc2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Ted, Based on IESG feedback, we are in the process of resolving the Mark Duffy issue as part of a discussion of the same topic (with a somewhat different slant) with Sam Hartman. Working with the IESG/AD's, we have put together a set of changes that we believe address the IESG comments in your email. I am working on incorporating them into the 2401bis draft for Steve's review when he returns from travel on Monday. So I estimate we'll have the revised draft ready to submit to the IESG some time next week. At the moment, I'm not aware of any issues for the working group except for the one you list below from Mark, but that could change as I go through the various IESG issues. Thank you for your help, Karen >Based on the results of the IETF-wide last call of 2401-bis and the >comments from the IESG, these are the issues which Barbara and I believe >still need to be addressed in draft-ietf-ipsec-rfc2401bis-05. If anyone >believes there are any issues that we missed, please let us know as soon >as possible. > >Steve, Karen --- I understand that you have been communicating with some >of the AD's directly with respect to their concerns. How far away are >we from reaching closure on these issues, and are there any that you >feel require specific attention from the working group? > >Many thanks!! > > - Ted > > >Last Call Issues >================ > >Mark Duffy's 2401-bis fragment checking for Bypass/Discard (see ipsec >mailing list thread starting on October 5th through November 6th: > > >Date: Sat, 06 Nov 2004 23:36:25 -0500 >From: Mark Duffy >Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD > >Ted, > >Thank you for taking the time to re-read the thread and think about this >issue. What I would seek is a minor change that allows discarding >non-initial fragments processed for BYPASS as an alternative to stateful >fragment checking of them. > >I think this can be as simple as replacing this sentence in 7.4: > An implementation MUST support stateful fragment checking to accommodate > BYPASS traffic for which a non-trivial port range is specified. >with this one: > An implementation MUST NOT forward fragmented BYPASS traffic > without performing stateful fragment checking. > >------------------------------------- > >IESG Issues >=========== > >Harald Alvestrand: > >Comment: >Reviewed by Brian Carpenter, Gen-ART > >There are nits and small comments (review in document log), but no >show-stoppers. > >[ i.e., Brian Carpenter's comments, see ipsec mailing list. ] > >-------------------------------------------------- > >Ted Hardie: > >Comment: >This seems to have a mix of RFC 2026 and RFC 3668 boilerplates. > >-------------------------------------------------- > >Ted Hardie: > >In Section 4.1, the draft says: > >In many secure multicast (or anycast) architectures, e.g., [RFC3740], >a central Group Controller/Key Server unilaterally assigns the Group >Security Association's (GSA's) SPI. > >3740 does not seem to mention anycast. Is there a similar reference >for anycast? > >-------------------------------------------------- > >Ted Hardie: > >Section 4.4.1 uses 192.168 addresses, rather than the example prefix >192.0.2.x/24 > >-------------------------------------------------- > >Ted Hardie: > >I found the use of "road warrior" in section 4.5.2 distracting. > >-------------------------------------------------- > >Sam Hartman: > >[issue 1, based on my iSCSI example] > >I am beginning to believe that I have a somewhat general problem with >the balances and tradeoffs that the IPsec working group has chosen and >how those interact with the rest of the IETF. The IPsec working group >is focusing on IPsec as its own application; system administrators and >users who configure IPsec because they want specific traffic >protected. That's clearly an important use of IPsec. However the >rest of the IETF continues to view IPsec as an appropriate tool for >providing security for other applications, protocols, etc. In these >situations, IPsec (especially in native implementations) may need to >provide appropriate interfaces to these uses. I'm concerned that the >2401bis model favors the first use too much. Revisiting that issue >this late in the process would be inappropriate. However I'd like to >focus on two cases where 2401bis seems to be problematic for the use >of IPsec as a security tool by higher layers. > >The first issue is one I noticed late yesterday. Section 7.4 mandates >stateful fragment handling for bypass and discard traffic if any of >the SPD selectors specify a specific port. This means that when I >start protecting traffic for one application, I end up having to >significantly complicate the packet processing for all my traffic. >Especially for native implementations, this seems unnecessary. It >seems like the real requirement is that I should not be able to >manipulate fragments to generate or receive unprotected traffic when >I'm expecting protected traffic. It seems like keeping track of >whether a particular socket requires protected traffic would be >sufficient. I'm not sure you can do better than 7.4 for other types >of implementations. > >The second case is the case I described eearlier where a host is >using IPsec both to provide security services for a higher layer and >to enforce specific policy as a security gateway etc. Again, it >seems like you can do better than the current document for native >implementations. Virtual interfaces based on MAC address seem like >the wrong solution; it only works if the protected traffic doesn't >share a router with unprotected traffic. > >I understand not all implementations need to support this sort of >functionality. I'm concerned that it is not clear from the current >draft that you might want to do this. Also, I'm concerned that you >might end up choosing an implementation of this feature with hidden >implications. > >I suspect I need to be more concrete in what I want here. I think >that all I'm asking for is clarifying text, but I haven't yet figured >out how I'd do what I want in the model so I'm having a hard time >determining if it is clear. > >There are probably one or two rounds of discussion that need to happen >on this; I will try to be responsive so this does not bog down. > >-------------------------------------------------- > >Sam Hartman: > >[issue 2; Steve proposed two solutions both of which are acceptable >to me.] > > >In 4.4.4.1, the two uses of the name pseudo-selector do not seem to be >comparable and so I don't understand why they are overloaded. In the >first use, the name is an IKE identity used to contact a responder. >In the second use, the name is a local OS user for whom protection >services will be used or bypassed (or data discarded). The local OS >is unlikely to use IKE identities; local naming is more likely to be >unix UIDs, Windows security IDs or something similar. Why are these >two different things both called name; why should they be in the same >place in the SPD? > >-------------------------------------------------- > >Sam Hartman: > >[issue 3; I think we have rough agreement] > >The example for X.500 distinguished names seems in the wrong order. >Shouldn't the country come last, not first? In any event, a reference >to the string encoding of DNs that is being used should probably be >given; I'm assuming the example is relative to RFC 2253 or at this >point its successor. If you are using a different string >encoding--particularly one with different ordering--it is even more >critical to cite. > >-------------------------------------------------- > >Sam Hartman: > >[issue 4; one outstanding question; probably the answer will be >sufficient for me to drop the issue.] > > >There doesn't in general seem to be a way to create an SPD policy that >uses IPsec if a SA is available but is not used otherwise. If the >peer is using an IKE identity other than an IP address the name >selector is adequate for this task. However I don't understand how to >create an SPD entry of this type if the peer will assert an IP address >for its identity. > >-------------------------------------------------- > >Sam Hartman: > >[issue 5; open question/clarification] > >In section 5, the document claims that both outbound and inbound >packets must be checked against the SPD (or a cache). This doesn't >actually appear to be what's described for inbound packets that use >IPsec protection. The procedure for handling packets only checks them >against the SAD, not against the SPD. The text claims that the SAD is >a cache of the SPD for inbound packets. If this were true, everything >would be consistent. However, earlier in section 4.4.1, the document >says that a system administrator should be given the opportunity to >decide what happens when the SPD is changed. One of the options is to >allow extant SAs to continue. If this option is taken, the SAD can >contain SAs that correspond to no SPD entry. I believe the simplest >fix is to revise section 5 to claim that the SPD is consulted for >outbound packets and the SPD-I and SAD are consulted for inbound >packets. > >-------------------------------------------------- > >Sam Hartman: > >[issue 6; Steve proposed acceptable solution] > >The text after rule 4 of 5.2 is confusing; Steve proposes making a >rule 5. > >-------------------------------------------------- > >Sam Hartman: > >[issue 7; agreed solution] > >Section 7.4 should gain the same text about stateful fragment checking >not working in case of multiple paths as found in section 7.3. > >-------------------------------------------------- > >Sam Hartman: > >[issue 8; need to post Steve's text to tracker] > >Steve Kent has new PAD text (4.4.3) which clarifies and extends the >PAD. Russ has asked me to hold a discuss on this text. I'm >discussing some comments about that text with Steve and Russ and >expect to amend my discuss once those discussions complete. > >-------------------------------------------------- > >Sam Hartman: > >[issue 9] >Appendix C: > >There's text at the top of the appendix claiming that the module does >not compile because of a duplicate tag. Could you please explain this >in more detail. > >-------------------------------------------------- > >Sam Hartman: > >Comment: >Section 6.1.2 creates requirements for incoming ICMP packets on the >protected side of the IPsec boundary. As best I can tell the attacks >described in that section are potential problems for any Internet >gateway and have nothing to do with IPsec. If so, why should the >IPsec architecture add requirements for additional administrative >controls to mitigate these attacks? (I think the administrative >controls are a good idea; I'm just unsure why this specification is >the right place for them.) > >-------------------------------------------------- > >Russ Housley: > >Discuss: > > When will the module identifier be assigned for Appendix C? > If you want IANA to do it, then it needs to be called out in > the IANA Considerations section. > > >-------------------------------------------------- > >Russ Housley: > >Comment: > > Section 4.1: > s/Memory (TCAM0 features/Memory (TCAM) features/ > > Section 4.4.1: > s/SPD-SPD-S, SPD-SPD-I, SPD-SPD-O/SPD-S, SPD-I, SPD-O/ > s/The SPD-SPD-S/The SPD-S/ > > Section 4.4.2: > s/Database(SAD),/Database (SAD),/ > > Section 8.2.1: > s/SAD entry When/SAD entry. When/ > >-------------------------------------------------- > >Alex Zinin: > >Discuss: > >How does the in/out-bound processing model defined in section 5 work >in the case of a VPN gateway? In particular, how does presence of >multiple routing realms and a two-stage forwarding process affect it >(imagine a gw that uses dynamic routing over the VPN tunnels protected >by IPsec transport mode as encapsulated packets leave the box)? What >about locally-originated messages, such as routing messages in this >case. I know how to make it work, the question is how the described >model addresses these scenarios. > >-------------------------------------------------- > >Alex Zinin: > >Section 4.4 Major IPsec Databases: > >> Forwarding vs Security Decisions >> >> The IPsec model described here embodies a clear separation between >> forwarding (routing) and security decisions, to accommodate a wide >> range of contexts where IPsec may be employed. Forwarding may be > > trivial, in the case where there are only two interfaces, or it >> may be complex, e.g., if there are multiple protected or >> unprotected interfaces or if the context in which IPsec is >> implemented employs a sophisticated forwarding function. > >minor note: complexity of forwarding doesn't depend directly on the number of >local interfaces. > >> IPsec >> assumes only that outbound and inbound traffic that has passed >> through IPsec processing is forwarded in a fashion consistent with > > the context in which IPsec is implemented. > >What does the above statement really mean? > >-------------------------------------------------- > >Alex Zinin: > >Though Appendix E is not normative, I should note that it is rather >confusing. Specifically, though the document states that no changes >to the forwarding function are introduced, the appendix mentions two >different forwarding tables--one for protected, and one for >unprotected side. Also, the representation of the forwarding tables >themselves creates an impression that routes usually include both >source and destination prefixes, which clearly isn't true (unless >we're talking about a special case of policy-based routing). Again, I >know how to make it work, but I don't think the doc is very good at >explaining this. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 14 00:29:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28233 for ; Fri, 14 Jan 2005 00:29:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpJzI-0001eA-KK; Fri, 14 Jan 2005 00:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpJww-00011P-8R for ipsec@megatron.ietf.org; Fri, 14 Jan 2005 00:24:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27887 for ; Fri, 14 Jan 2005 00:24:38 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpKB7-0002FH-ON for ipsec@ietf.org; Fri, 14 Jan 2005 00:39:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Re: Issues remaining for draft-ietf-ipsec-rfc2401bis Date: Thu, 13 Jan 2005 21:31:56 -0800 Message-ID: Thread-Topic: [Ipsec] Re: Issues remaining for draft-ietf-ipsec-rfc2401bis thread-index: AcT59aVa4cUvk5JkQ9KQQFhQTl4dYQAAawjQ From: "Vishwas Manral" To: "Karen Seo" , "Theodore Ts'o" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22e211536bda974b2dcf811522dc525d Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, housley@vigilsec.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Karen, Though it is not a critical problem but as part of resolving the IESG comments I had raised an issue, the following are the resolving comments:- Stephen Kent wrote: > At 8:02 PM -0800 12/28/04, Vishwas Manral wrote: >=20 >> Hi Steve, >> >> As you said "such behavior by intermediate routers would tend to=20 >> cause havoc with the traffic anyway, so I would hope that this would=20 >> not be a common occurrence". >> >> Would we however want to put a comment regarding the same? The text=20 >> to add could be "Changing DSCP values en-route can result in=20 >> different class of packets on the same SA and SHOULD be avoided." >> >> Sorry for the confusion caused. >> >> Thanks, >> Vishwas >=20 >=20 > We could add an advisory statement that warns folks, e.g., >=20 > "If significant reordering of packets occurs in an SA, e.g, as a=20 > result of changes to DSCP values en route, this may trigger packet=20 > discarding by a receiver due to application of the anti-replay mechanism." >=20 > Steve This is certainly reasonable. Let's try to construct an example where it might conceivably happen: a video stream with two types of packet, i.e. coarse and fine resolution. A possible reason for varying the DSCP is to favor the coarse packets under congestion, so that they get through promptly even if the fine detail is lost. But for that to happen en route requires deep packet inspection (of non-encrypted packets) by a device that magically knows that the data packets are a video stream. This seems pretty unlikely. The normal scenario is that it's the video source itself that marks the coarse and fine packets appropriately - and that would lead to two SAs, not to an SA with a varying DSCP value. Brian Thanks, Vishwas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Karen Seo Sent: Friday, January 14, 2005 10:11 AM To: Theodore Ts'o Cc: ipsec@ietf.org; housley@vigilsec.com Subject: [Ipsec] Re: Issues remaining for draft-ietf-ipsec-rfc2401bis Ted, Based on IESG feedback, we are in the process of resolving the Mark=20 Duffy issue as part of a discussion of the same topic (with a=20 somewhat different slant) with Sam Hartman. Working with the IESG/AD's, we have put together a set of changes=20 that we believe address the IESG comments in your email. I am working=20 on incorporating them into the 2401bis draft for Steve's review when=20 he returns from travel on Monday. So I estimate we'll have the=20 revised draft ready to submit to the IESG some time next week. At the moment, I'm not aware of any issues for the working group=20 except for the one you list below from Mark, but that could change as=20 I go through the various IESG issues. Thank you for your help, Karen >Based on the results of the IETF-wide last call of 2401-bis and the >comments from the IESG, these are the issues which Barbara and I believe >still need to be addressed in draft-ietf-ipsec-rfc2401bis-05. If anyone >believes there are any issues that we missed, please let us know as soon >as possible. > >Steve, Karen --- I understand that you have been communicating with some >of the AD's directly with respect to their concerns. How far away are >we from reaching closure on these issues, and are there any that you >feel require specific attention from the working group? > >Many thanks!! > > - Ted > > >Last Call Issues >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Mark Duffy's 2401-bis fragment checking for Bypass/Discard (see ipsec >mailing list thread starting on October 5th through November 6th: > > >Date: Sat, 06 Nov 2004 23:36:25 -0500 >From: Mark Duffy >Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD > >Ted, > >Thank you for taking the time to re-read the thread and think about this >issue. What I would seek is a minor change that allows discarding >non-initial fragments processed for BYPASS as an alternative to stateful >fragment checking of them. > >I think this can be as simple as replacing this sentence in 7.4: > An implementation MUST support stateful fragment checking to accommodate > BYPASS traffic for which a non-trivial port range is specified. >with this one: > An implementation MUST NOT forward fragmented BYPASS traffic > without performing stateful fragment checking. > >------------------------------------- > >IESG Issues >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Harald Alvestrand: > >Comment: >Reviewed by Brian Carpenter, Gen-ART > >There are nits and small comments (review in document log), but no >show-stoppers. > >[ i.e., Brian Carpenter's comments, see ipsec mailing list. ] > >-------------------------------------------------- > >Ted Hardie: > >Comment: >This seems to have a mix of RFC 2026 and RFC 3668 boilerplates. > >-------------------------------------------------- > >Ted Hardie: > >In Section 4.1, the draft says: > >In many secure multicast (or anycast) architectures, e.g., [RFC3740], >a central Group Controller/Key Server unilaterally assigns the Group >Security Association's (GSA's) SPI.=20 > >3740 does not seem to mention anycast. Is there a similar reference >for anycast? > >-------------------------------------------------- > >Ted Hardie: > >Section 4.4.1 uses 192.168 addresses, rather than the example prefix >192.0.2.x/24 > >-------------------------------------------------- > >Ted Hardie: > >I found the use of "road warrior" in section 4.5.2 distracting. > >-------------------------------------------------- > >Sam Hartman: > >[issue 1, based on my iSCSI example] > >I am beginning to believe that I have a somewhat general problem with >the balances and tradeoffs that the IPsec working group has chosen and >how those interact with the rest of the IETF. The IPsec working group >is focusing on IPsec as its own application; system administrators and >users who configure IPsec because they want specific traffic >protected. That's clearly an important use of IPsec. However the >rest of the IETF continues to view IPsec as an appropriate tool for >providing security for other applications, protocols, etc. In these >situations, IPsec (especially in native implementations) may need to >provide appropriate interfaces to these uses. I'm concerned that the >2401bis model favors the first use too much. Revisiting that issue >this late in the process would be inappropriate. However I'd like to >focus on two cases where 2401bis seems to be problematic for the use >of IPsec as a security tool by higher layers. > >The first issue is one I noticed late yesterday. Section 7.4 mandates >stateful fragment handling for bypass and discard traffic if any of >the SPD selectors specify a specific port. This means that when I >start protecting traffic for one application, I end up having to >significantly complicate the packet processing for all my traffic. >Especially for native implementations, this seems unnecessary. It >seems like the real requirement is that I should not be able to >manipulate fragments to generate or receive unprotected traffic when >I'm expecting protected traffic. It seems like keeping track of >whether a particular socket requires protected traffic would be >sufficient. I'm not sure you can do better than 7.4 for other types >of implementations. > >The second case is the case I described eearlier where a host is >using IPsec both to provide security services for a higher layer and >to enforce specific policy as a security gateway etc. Again, it >seems like you can do better than the current document for native >implementations. Virtual interfaces based on MAC address seem like >the wrong solution; it only works if the protected traffic doesn't >share a router with unprotected traffic.=20 > >I understand not all implementations need to support this sort of >functionality. I'm concerned that it is not clear from the current >draft that you might want to do this. Also, I'm concerned that you >might end up choosing an implementation of this feature with hidden >implications. =20 > >I suspect I need to be more concrete in what I want here. I think >that all I'm asking for is clarifying text, but I haven't yet figured >out how I'd do what I want in the model so I'm having a hard time >determining if it is clear. > >There are probably one or two rounds of discussion that need to happen >on this; I will try to be responsive so this does not bog down. > >-------------------------------------------------- > >Sam Hartman: > >[issue 2; Steve proposed two solutions both of which are acceptable >to me.] > > >In 4.4.4.1, the two uses of the name pseudo-selector do not seem to be >comparable and so I don't understand why they are overloaded. In the >first use, the name is an IKE identity used to contact a responder. >In the second use, the name is a local OS user for whom protection >services will be used or bypassed (or data discarded). The local OS >is unlikely to use IKE identities; local naming is more likely to be >unix UIDs, Windows security IDs or something similar. Why are these >two different things both called name; why should they be in the same >place in the SPD? > >-------------------------------------------------- > >Sam Hartman: > >[issue 3; I think we have rough agreement] > >The example for X.500 distinguished names seems in the wrong order. >Shouldn't the country come last, not first? In any event, a reference >to the string encoding of DNs that is being used should probably be >given; I'm assuming the example is relative to RFC 2253 or at this >point its successor. If you are using a different string >encoding--particularly one with different ordering--it is even more >critical to cite. > >-------------------------------------------------- > >Sam Hartman: > >[issue 4; one outstanding question; probably the answer will be >sufficient for me to drop the issue.] > > >There doesn't in general seem to be a way to create an SPD policy that >uses IPsec if a SA is available but is not used otherwise. If the >peer is using an IKE identity other than an IP address the name >selector is adequate for this task. However I don't understand how to >create an SPD entry of this type if the peer will assert an IP address >for its identity.=20 > >-------------------------------------------------- > >Sam Hartman: > >[issue 5; open question/clarification] > >In section 5, the document claims that both outbound and inbound >packets must be checked against the SPD (or a cache). This doesn't >actually appear to be what's described for inbound packets that use >IPsec protection. The procedure for handling packets only checks them >against the SAD, not against the SPD. The text claims that the SAD is >a cache of the SPD for inbound packets. If this were true, everything >would be consistent. However, earlier in section 4.4.1, the document >says that a system administrator should be given the opportunity to >decide what happens when the SPD is changed. One of the options is to >allow extant SAs to continue. If this option is taken, the SAD can >contain SAs that correspond to no SPD entry. I believe the simplest >fix is to revise section 5 to claim that the SPD is consulted for >outbound packets and the SPD-I and SAD are consulted for inbound >packets. > >-------------------------------------------------- > >Sam Hartman: > >[issue 6; Steve proposed acceptable solution] > >The text after rule 4 of 5.2 is confusing; Steve proposes making a >rule 5. > >-------------------------------------------------- > >Sam Hartman: > >[issue 7; agreed solution] > >Section 7.4 should gain the same text about stateful fragment checking >not working in case of multiple paths as found in section 7.3. > >-------------------------------------------------- > >Sam Hartman: > >[issue 8; need to post Steve's text to tracker] > >Steve Kent has new PAD text (4.4.3) which clarifies and extends the >PAD. Russ has asked me to hold a discuss on this text. I'm >discussing some comments about that text with Steve and Russ and >expect to amend my discuss once those discussions complete. > >-------------------------------------------------- > >Sam Hartman: > >[issue 9] >Appendix C: > >There's text at the top of the appendix claiming that the module does >not compile because of a duplicate tag. Could you please explain this >in more detail. > >-------------------------------------------------- > >Sam Hartman: > >Comment: >Section 6.1.2 creates requirements for incoming ICMP packets on the >protected side of the IPsec boundary. As best I can tell the attacks >described in that section are potential problems for any Internet >gateway and have nothing to do with IPsec. If so, why should the >IPsec architecture add requirements for additional administrative >controls to mitigate these attacks? (I think the administrative >controls are a good idea; I'm just unsure why this specification is >the right place for them.) > >-------------------------------------------------- > >Russ Housley: > >Discuss: > > When will the module identifier be assigned for Appendix C? > If you want IANA to do it, then it needs to be called out in > the IANA Considerations section. > > >-------------------------------------------------- > >Russ Housley: > >Comment: > > Section 4.1: > s/Memory (TCAM0 features/Memory (TCAM) features/ > > Section 4.4.1: > s/SPD-SPD-S, SPD-SPD-I, SPD-SPD-O/SPD-S, SPD-I, SPD-O/ > s/The SPD-SPD-S/The SPD-S/ > > Section 4.4.2: > s/Database(SAD),/Database (SAD),/ > > Section 8.2.1: > s/SAD entry When/SAD entry. When/ > >-------------------------------------------------- > >Alex Zinin: > >Discuss: > >How does the in/out-bound processing model defined in section 5 work >in the case of a VPN gateway? In particular, how does presence of >multiple routing realms and a two-stage forwarding process affect it >(imagine a gw that uses dynamic routing over the VPN tunnels protected >by IPsec transport mode as encapsulated packets leave the box)? What >about locally-originated messages, such as routing messages in this >case. I know how to make it work, the question is how the described >model addresses these scenarios. > >-------------------------------------------------- > >Alex Zinin: > >Section 4.4 Major IPsec Databases: > >> Forwarding vs Security Decisions >> >> The IPsec model described here embodies a clear separation between >> forwarding (routing) and security decisions, to accommodate a wide >> range of contexts where IPsec may be employed. Forwarding may be > > trivial, in the case where there are only two interfaces, or it >> may be complex, e.g., if there are multiple protected or >> unprotected interfaces or if the context in which IPsec is >> implemented employs a sophisticated forwarding function. > >minor note: complexity of forwarding doesn't depend directly on the number of >local interfaces. > >> IPsec >> assumes only that outbound and inbound traffic that has passed >> through IPsec processing is forwarded in a fashion consistent with > > the context in which IPsec is implemented. > >What does the above statement really mean? > >-------------------------------------------------- > >Alex Zinin: > >Though Appendix E is not normative, I should note that it is rather >confusing. Specifically, though the document states that no changes >to the forwarding function are introduced, the appendix mentions two >different forwarding tables--one for protected, and one for >unprotected side. Also, the representation of the forwarding tables >themselves creates an impression that routes usually include both >source and destination prefixes, which clearly isn't true (unless >we're talking about a special case of policy-based routing). Again, I >know how to make it work, but I don't think the doc is very good at >explaining this. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 17 23:02:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23461 for ; Mon, 17 Jan 2005 23:02:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqkTF-0002xy-0J; Mon, 17 Jan 2005 22:55:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqkQT-0002VI-RU for ipsec@megatron.ietf.org; Mon, 17 Jan 2005 22:53:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22649 for ; Mon, 17 Jan 2005 22:53:03 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqkfe-0002jf-B9 for ipsec@ietf.org; Mon, 17 Jan 2005 23:08:47 -0500 Received: by rproxy.gmail.com with SMTP id r35so47899rna for ; Mon, 17 Jan 2005 19:53:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=N14I/f6+ptVgsboN/l3TZLZ2SSO3ww2Ln2WutIwZmjoHJ3bc2pLXsTM8/YmF7tcJzNxqjDwwlI6138SasgfHBCVQXX/ucS8d32UjtxQr4HMoZoklqS5gt1mDBowdw6M+AwIrvBrX84GtPsUwAUw9nnqnyPzMCu+MzqcnYkzH0xw= Received: by 10.38.67.52 with SMTP id p52mr274212rna; Mon, 17 Jan 2005 19:53:00 -0800 (PST) Received: by 10.38.12.3 with HTTP; Mon, 17 Jan 2005 19:53:00 -0800 (PST) Message-ID: Date: Tue, 18 Jan 2005 11:53:00 +0800 From: Gazali To: ipsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] the same subnet in ipsec tunnul? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gazali List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable why not setup the same subnet in ipsec tunnul? If I setup the IPsec gateway on route mode=EF=BC=8Cit's sure that I can't s= et up the same subnet,but whne the Gateway on bridge mode,what happen? for example: the two gateway ip : 192.168.1.1 and 192.168.1.2. src subnet: 192.168.1.0/24 dst subnet:192.168.1.0/24 when a host 192.168.1.30 want to access another host 192.168.1.40 in the dst subnet,I doubt it. please help me. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 18 14:51:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24332 for ; Tue, 18 Jan 2005 14:51:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqzKg-0001Pd-UV; Tue, 18 Jan 2005 14:48:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqzJe-0001DY-6T for ipsec@megatron.ietf.org; Tue, 18 Jan 2005 14:47:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24014 for ; Tue, 18 Jan 2005 14:46:56 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqzYt-0001Fi-D7 for ipsec@ietf.org; Tue, 18 Jan 2005 15:02:48 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0IJkNjf009694; Tue, 18 Jan 2005 14:46:23 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050113235108.36731.qmail@web52604.mail.yahoo.com> References: <20050113235108.36731.qmail@web52604.mail.yahoo.com> Date: Tue, 18 Jan 2005 14:41:51 -0500 To: Subha Venkataramanan From: Stephen Kent Subject: Re: [Ipsec] Next Layer Protocol (Ref: 2401-bis draft) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:51 PM -0800 1/13/05, Subha Venkataramanan wrote: >Hi List-members, > >In Section 4.4.4.1 (Selectors) under Next- Layer >Protocols, it is mentioned that "to simplify locating >the next header protocol, there SHOULD be a mechanism >for configuring which IPv6 extension headers to SKIP" > >Could someone indicate to me what was the intent >behind this kind of configuration ? > >Thanks, >Subha In IPv6, the use of hop-by-hop and destination extension headers can make it harder than in Ipv4 to locate the next layer protocol. This text suggests that it would be useful to be able to configure an IPsec implementation with a list of which of these extension headers can safely be ignored when parsing the IPv6 header to locate the next protocol. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 20 05:38:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14181 for ; Thu, 20 Jan 2005 05:38:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrZWw-0003Qv-5m; Thu, 20 Jan 2005 05:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrZS2-0002nR-DR for ipsec@megatron.ietf.org; Thu, 20 Jan 2005 05:22:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13576 for ; Thu, 20 Jan 2005 05:22:01 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrZhd-0001tQ-P3 for ipsec@ietf.org; Thu, 20 Jan 2005 05:38:15 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j0KAM0jZ002855 for ; Thu, 20 Jan 2005 12:22:00 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j0KALxFg002852; Thu, 20 Jan 2005 12:21:59 +0200 Date: Thu, 20 Jan 2005 12:21:59 +0200 Message-Id: <200501201021.j0KALxFg002852@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ipsec] PFKEY and IKEv2? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org [those who do not use PFKEY, *IGNORE* this message] There used to be a PFKEY mailing list, but I have lost the reference. Is it still alive? Does everyone invent their own extensions to the PFKEY v2 to support IKEv2? I would prefer that there would be some PFKEYv3. At least it would be nice to agree on the new extension formats for passing the traffic selectors. So, is this list the place to plan on these or will someone provide me a reference to a working PFKEY mailing list? -- Markku Savela _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 20 07:03:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19573 for ; Thu, 20 Jan 2005 07:03:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crayv-0002fi-Ov; Thu, 20 Jan 2005 07:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crau1-000212-P8 for ipsec@megatron.ietf.org; Thu, 20 Jan 2005 06:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19072 for ; Thu, 20 Jan 2005 06:55:02 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crb9f-0003wS-Mf for ipsec@ietf.org; Thu, 20 Jan 2005 07:11:17 -0500 Received: from kolumbus.fi (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E8BCB898A5; Thu, 20 Jan 2005 13:54:31 +0200 (EET) Message-ID: <41EF9BC2.2020902@kolumbus.fi> Date: Thu, 20 Jan 2005 13:53:38 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markku Savela Subject: Re: [Ipsec] PFKEY and IKEv2? References: <200501201021.j0KALxFg002852@burp.tkv.asdf.org> In-Reply-To: <200501201021.j0KALxFg002852@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Markku, > There used to be a PFKEY mailing list, but I have lost the > reference. Is it still alive? > > Does everyone invent their own extensions to the PFKEY v2 to support > IKEv2? > > I would prefer that there would be some PFKEYv3. At least it would be > nice to agree on the new extension formats for passing the traffic > selectors. > > So, is this list the place to plan on these or will someone provide me > a reference to a working PFKEY mailing list? I don't think a working one exists although the list may still exist somewhere. Anyway, the history in this matter is that the original PF_KEY idea was great but that the specifications didn't quite go all the way towards providing everything that a real implementation would need. So people ended up adding their own extensions. At some point I, for instance, tried to propose a common extension, but didn't receive a lot of interest from others. Probably there were a few other attempts and proposals as well. Going forward the critical question is whether everyone who uses PF_KEY and has their own extensions is going to want to upgrade to a PF_KEYv3, if someone were to make that happen? If yes, then maybe its worth talking about it. If not... --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 20 10:05:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03562 for ; Thu, 20 Jan 2005 10:05:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crdjh-0003dg-VW; Thu, 20 Jan 2005 09:56:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crdfy-0003Dx-8e for ipsec@megatron.ietf.org; Thu, 20 Jan 2005 09:52:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02602 for ; Thu, 20 Jan 2005 09:52:43 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crdve-0000DG-Pk for ipsec@ietf.org; Thu, 20 Jan 2005 10:08:59 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j0KEqYpv011804; Thu, 20 Jan 2005 06:52:34 -0800 (PST) Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0KEqX8p025297; Thu, 20 Jan 2005 09:52:33 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.13.2+Sun/8.12.11) with ESMTP id j0KEq71W027974; Thu, 20 Jan 2005 09:52:07 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.13.2+Sun/8.13.1/Submit) id j0KEq7TI027973; Thu, 20 Jan 2005 09:52:07 -0500 (EST) Date: Thu, 20 Jan 2005 09:52:07 -0500 From: Dan McDonald To: Jari Arkko Subject: Re: [Ipsec] PFKEY and IKEv2? Message-ID: <20050120145207.GC27948@kebe.East.Sun.COM> References: <200501201021.j0KALxFg002852@burp.tkv.asdf.org> <41EF9BC2.2020902@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41EF9BC2.2020902@kolumbus.fi> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Networking & Security X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thu, Jan 20, 2005 at 01:53:38PM +0200, Jari Arkko wrote: > Anyway, the history in this matter is that the original PF_KEY idea > was great Thank you (as does Craig and Bao, I'm sure). :) > but that the specifications didn't quite go all the way towards providing > everything that a real implementation would need. In Solaris, our IKEv1 support required two big changes: - Extended ACQUIRE. This would allow AH+ESP to be specified in a single acquire message. If I understand 2401bis and IKEv2 correctly, that can no longer happen. (Unless IP compression is still negotiated, in which case the extended ACQUIRE is still useful.) - Inverse ACQUIRE. If I'm a responder, I'd like to know what to use. This is really the exception to the rule that PF_KEY should not be a policy interface. ACQUIRE and inverse-ACQUIRE is where Key Management meets IPsec configuration policy. > So people ended up adding their own extensions. At some point I, for > instance, tried to propose a common extension, but didn't receive a lot of > interest from others. Probably there were a few other attempts and > proposals as well. Yeah. I suspect most of us were busy working on our own code bases. > Going forward the critical question is whether everyone who > uses PF_KEY and has their own extensions is going to want to > upgrade to a PF_KEYv3, if someone were to make that happen? > If yes, then maybe its worth talking about it. If not... This will be my last post on this thread on the IPsec mailing list. pf_key@inner.net is still open for business, AFAIK, and people should go there. Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 20 11:36:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13181 for ; Thu, 20 Jan 2005 11:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrfBe-0003IZ-VH; Thu, 20 Jan 2005 11:29:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crf2w-0000ic-08 for ipsec@megatron.ietf.org; Thu, 20 Jan 2005 11:20:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10626 for ; Thu, 20 Jan 2005 11:20:31 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrfIc-0002al-Jg for ipsec@ietf.org; Thu, 20 Jan 2005 11:36:48 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j0KGJtl21692; Thu, 20 Jan 2005 17:19:56 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j0KGJtSj024161; Thu, 20 Jan 2005 17:19:56 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200501201619.j0KGJtSj024161@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela Subject: Re: [Ipsec] PFKEY and IKEv2? In-reply-to: Your message of Thu, 20 Jan 2005 12:21:59 +0200. <200501201021.j0KALxFg002852@burp.tkv.asdf.org> Date: Thu, 20 Jan 2005 17:19:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: Does everyone invent their own extensions to the PFKEY v2 to support IKEv2? => we are working on extensions to support Mobile IPv6 and one of them is needed by IKEv2 too. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 20 13:36:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22993 for ; Thu, 20 Jan 2005 13:36:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crh1Z-0005ti-04; Thu, 20 Jan 2005 13:27:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crgx9-0004EX-GZ for ipsec@megatron.ietf.org; Thu, 20 Jan 2005 13:22:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21903 for ; Thu, 20 Jan 2005 13:22:40 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrhCr-00061x-D1 for ipsec@ietf.org; Thu, 20 Jan 2005 13:38:58 -0500 Received: by machshav.com (Postfix, from userid 512) id 75F1AFB277; Thu, 20 Jan 2005 18:22:40 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0AE1FFB23C; Thu, 20 Jan 2005 18:22:40 +0000 (UTC) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id ACC063BFEF9; Thu, 20 Jan 2005 13:22:36 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Jari Arkko Subject: Re: [Ipsec] PFKEY and IKEv2? In-Reply-To: Your message of "Thu, 20 Jan 2005 13:53:38 +0200." <41EF9BC2.2020902@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Jan 2005 13:22:36 -0500 Message-Id: <20050120182236.ACC063BFEF9@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In message <41EF9BC2.2020902@kolumbus.fi>, Jari Arkko writes: > >Going forward the critical question is whether everyone who >uses PF_KEY and has their own extensions is going to want to >upgrade to a PF_KEYv3, if someone were to make that happen? >If yes, then maybe its worth talking about it. If not... > I think a new, standardized PF_KEY version would be an excellent idea. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 20 16:10:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06044 for ; Thu, 20 Jan 2005 16:10:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjGA-0003pW-E3; Thu, 20 Jan 2005 15:50:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjCq-00023a-OR for ipsec@megatron.ietf.org; Thu, 20 Jan 2005 15:47:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04264 for ; Thu, 20 Jan 2005 15:47:02 -0500 (EST) Received: from pike.sandelman.ca ([205.150.200.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrjSZ-0001ZP-LI for ipsec@ietf.org; Thu, 20 Jan 2005 16:03:21 -0500 Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by pike.sandelman.ca (Postfix) with ESMTP id 4F44063B53; Thu, 20 Jan 2005 15:46:57 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D6ABABCEA; Thu, 20 Jan 2005 15:46:56 -0500 (EST) To: Jari Arkko Subject: Re: [Ipsec] PFKEY and IKEv2? In-Reply-To: Message from Jari Arkko of "Thu, 20 Jan 2005 13:53:38 +0200." <41EF9BC2.2020902@kolumbus.fi> References: <200501201021.j0KALxFg002852@burp.tkv.asdf.org> <41EF9BC2.2020902@kolumbus.fi> X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 16) Date: Thu, 20 Jan 2005 15:46:56 -0500 Message-ID: <7445.1106254016@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jari" == Jari Arkko writes: Jari> the way towards providing everything that a real Jari> implementation would need. So people ended up adding their Jari> own extensions. At some point I, for instance, tried to Jari> propose a common extension, but didn't receive a lot of Jari> interest from others. Probably there were a few other attempts Jari> and proposals as well. Jari> Going forward the critical question is whether everyone who Jari> uses PF_KEY and has their own extensions is going to want to Jari> upgrade to a PF_KEYv3, if someone were to make that happen? Jari> If yes, then maybe its worth talking about it. If not... It is high time to get a group together to do this. The problem has always been getting some critical mass to do this. I would move to PF_KEYv3. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQfAYvYqHRg3pndX9AQHIDgP/bJLAHTatjIrRFyk/r8Po5mzzO76PwNt1 C7lPMFnJXuvCJ8K31y6rCubONvCQVNjdP8XnGMFPGlPXJ/aeZ6Pm+NyhRKYhM3yJ iiMbCPbP/JadLZyltCqZvtph+ZIcWvLbkWfa4m9TbYbg5fpgK5SxseCK0la6xrc7 cdnCUaXJf1w= =WU0+ -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 21 00:55:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20833 for ; Fri, 21 Jan 2005 00:55:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crrgi-0008Gn-IO; Fri, 21 Jan 2005 00:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrrZX-0006nt-19 for ipsec@megatron.ietf.org; Fri, 21 Jan 2005 00:43:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19235 for ; Fri, 21 Jan 2005 00:42:59 -0500 (EST) Received: from kame195.kame.net ([203.178.141.195] helo=papa.tanu.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrrpK-000891-7w for ipsec@ietf.org; Fri, 21 Jan 2005 00:59:23 -0500 Received: from localhost (cp.64translator.com [202.214.123.2]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id j0L5gQhB035108; Fri, 21 Jan 2005 14:42:29 +0900 (JST) (envelope-from sakane@kame.net) To: kent@bbn.com Subject: Re: [Ipsec] rfc2401 & rfc2401bis compatability with IKEv1 and IKEv2 In-Reply-To: Your message of "Fri, 7 Jan 2005 10:13:10 -0500" References: X-Mailer: Cue version 0.8 (041108-2350/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050121144244E.sakane@kame.net> Date: Fri, 21 Jan 2005 14:42:44 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20030322(IM144) Lines: 42 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on papa.tanu.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, We have to separate a key management protocol from rfc2401-bis. I am not sure that the rfc2401-bis is written so, but make sure that the description of parameters or functions required to use IKEv2 should not be "MUST implement it". Otherwise, an implementer will inject any of them, then IKEv1 will not work on such implementation. regards, > At 11:22 PM -0800 1/6/05, Surya Batchu wrote: > >Hi, > > > >After going through the drafts, it seems that security > >policies configured based on rfc2401-bis can only work > >with IKEv2 key management. I guess, rfc2401 specific > >policies can work either IKEv1 and IKEv2. > > > >Due to this, I feel that the user configuring the > >rfc2401-bis SPD policy, should be aware that the > >security gateway that is protecting the remote network > >supports IKEv2. Accordingly, these kind of SPD > >policies would need to be configured (through > >management interface) to use only IKEv2 management. > > > > > >Is that correct assesment? > > > >Surya > > yes, some of the SPD features in 2401bis require use of IKEv2 to > negotiate them. Thus it is desirable that one know whether a peer is > IKEv2 capable when creating SPD entries that take advantage of these > feaures. > > Steve > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 21 10:49:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21146 for ; Fri, 21 Jan 2005 10:49:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0yu-0005VY-9f; Fri, 21 Jan 2005 10:45:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0sV-0004II-BR for ipsec@megatron.ietf.org; Fri, 21 Jan 2005 10:39:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20534 for ; Fri, 21 Jan 2005 10:39:13 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs18N-00074D-EX for ipsec@ietf.org; Fri, 21 Jan 2005 10:55:41 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0LFcYjj006437; Fri, 21 Jan 2005 10:38:39 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050121144244E.sakane@kame.net> References: <20050121144244E.sakane@kame.net> Date: Fri, 21 Jan 2005 09:57:36 -0500 To: Shoichi Sakane From: Stephen Kent Subject: Re: [Ipsec] rfc2401 & rfc2401bis compatability with IKEv1 and IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:42 PM +0900 1/21/05, Shoichi Sakane wrote: >Hi, > >We have to separate a key management protocol from rfc2401-bis. >I am not sure that the rfc2401-bis is written so, but make sure that >the description of parameters or functions required to use IKEv2 >should not be "MUST implement it". Otherwise, an implementer will >inject any of them, then IKEv1 will not work on such implementation. > >regards, 2401bis implicitly establishes requirements for certain features for a key/SA management protocol to enable systems to make full use of the IPsec features defined in 2401bis. IKEv2 satisfies these requirements; IKE v1 does not. It's way too late to suggest that we degrade requirements in 2401bis to be backwards compatible with IKE v1. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 23 17:20:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14011 for ; Sun, 23 Jan 2005 17:20:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csq29-00082B-GR; Sun, 23 Jan 2005 17:16:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csq1B-0007tk-9E for ipsec@megatron.ietf.org; Sun, 23 Jan 2005 17:15:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13818 for ; Sun, 23 Jan 2005 17:15:34 -0500 (EST) Received: from web90001.mail.scd.yahoo.com ([66.218.94.59]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CsqHY-00048G-M1 for ipsec@ietf.org; Sun, 23 Jan 2005 17:32:33 -0500 Received: (qmail 99676 invoked by uid 60001); 23 Jan 2005 22:15:05 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=F0RaiSvuWX75/nD26ByiIfUfb/Kmz23xWMO4Z/AKNWrgAtrmg4klJlbcnBxLI9G/qPbluoMBq9+RkK+rYU6bfHNi7dUC7hnQEbNE1dG9gBmMt6Trm4+piDIh+ZSvBiHiocfKxVVlV1CTnK3yb+8SlC/A7fWnCjcHvnueNkkUe+M= ; Message-ID: <20050123221505.99674.qmail@web90001.mail.scd.yahoo.com> Received: from [67.170.231.141] by web90001.mail.scd.yahoo.com via HTTP; Sun, 23 Jan 2005 14:15:05 PST Date: Sun, 23 Jan 2005 14:15:05 -0800 (PST) From: Surya Batchu To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ipsec] Replicated identities across multiple remote access users X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0537113744==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0537113744== Content-Type: multipart/alternative; boundary="0-819464915-1106518505=:99196" --0-819464915-1106518505=:99196 Content-Type: text/plain; charset=us-ascii In IPsec drafts and standards, there is no explicit prohition of reusing the identity by remote access clients. It seems to me that, there was an implicit understanding that each peer uses its own and unique identity. Now, we have a need to support multiple remote access sessions using the same identitiy. Some of the issues I can see are with INITIAL-CONTACT and assignment of internal IP address (virtual IP address) to the clients. What are the other technical&deployment issues in allowing duplicate identities from IKE based remote access clients? Surya --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' --0-819464915-1106518505=:99196 Content-Type: text/html; charset=us-ascii
In IPsec drafts and standards, there is no explicit prohition of reusing the identity by remote access clients. It seems to me that, there was an implicit understanding that each peer uses its own and unique identity. Now, we have a need to support multiple remote access sessions using the same identitiy. Some of the issues I can see are with INITIAL-CONTACT and assignment of internal IP address (virtual IP address) to the clients.
 
What are the other technical&deployment issues in allowing duplicate identities from IKE based remote access clients?
 
Surya

Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term' --0-819464915-1106518505=:99196-- --===============0537113744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0537113744==-- From ipsec-bounces@ietf.org Sun Jan 23 19:53:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26092 for ; Sun, 23 Jan 2005 19:53:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CssR9-0007Qv-RV; Sun, 23 Jan 2005 19:50:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CssPy-0007Cl-6a for ipsec@megatron.ietf.org; Sun, 23 Jan 2005 19:49:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25797 for ; Sun, 23 Jan 2005 19:49:18 -0500 (EST) Received: from mail2.panix.com ([166.84.1.73]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CssgM-0007uI-2p for ipsec@ietf.org; Sun, 23 Jan 2005 20:06:19 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id C4BF8A6F7B; Sun, 23 Jan 2005 19:48:58 -0500 (EST) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j0O0mww14641; Sun, 23 Jan 2005 19:48:58 -0500 (EST) Date: Sun, 23 Jan 2005 19:48:58 -0500 From: Thor Lancelot Simon To: Surya Batchu Subject: Re: [Ipsec] Replicated identities across multiple remote access users Message-ID: <20050124004858.GA19983@panix.com> References: <20050123221505.99674.qmail@web90001.mail.scd.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050123221505.99674.qmail@web90001.mail.scd.yahoo.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tls@rek.tjls.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sun, Jan 23, 2005 at 02:15:05PM -0800, Surya Batchu wrote: > > In IPsec drafts and standards, there is no explicit prohition of > reusing the identity by remote access clients. It seems to me that, > there was an implicit understanding that each peer uses its own and > unique identity. Now, we have a need to support multiple remote access > sessions using the same identitiy. That's a spectacularly bad idea. It makes possible an array of man in the middle and credential-stealing attacks that are remarkably easy to execute. You almost might as well not use IPsec at all. -- Thor Lancelot Simon tls@rek.tjls.com "The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem." - Noam Chomsky _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 24 03:44:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18399 for ; Mon, 24 Jan 2005 03:44:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cszmc-00038t-OK; Mon, 24 Jan 2005 03:41:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CszkX-0002wV-BW for ipsec@megatron.ietf.org; Mon, 24 Jan 2005 03:39:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17981 for ; Mon, 24 Jan 2005 03:39:00 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct00v-0003Yd-Ih for ipsec@ietf.org; Mon, 24 Jan 2005 03:56:04 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j0O8cvVH021004 for ; Mon, 24 Jan 2005 10:38:57 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j0O8cvKF021001; Mon, 24 Jan 2005 10:38:57 +0200 Date: Mon, 24 Jan 2005 10:38:57 +0200 Message-Id: <200501240838.j0O8cvKF021001@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org In-reply-to: <7445.1106254016@marajade.sandelman.ottawa.on.ca> (message from Michael Richardson on Thu, 20 Jan 2005 15:46:56 -0500) Subject: Re: [Ipsec] PFKEY and IKEv2? References: <200501201021.j0KALxFg002852@burp.tkv.asdf.org> <41EF9BC2.2020902@kolumbus.fi> <7445.1106254016@marajade.sandelman.ottawa.on.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Ok, there seems to be interest on this. How to proceed? "pf_key at inner.net" does not seem to be working for me. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 24 10:32:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21837 for ; Mon, 24 Jan 2005 10:32:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct64X-00046F-ST; Mon, 24 Jan 2005 10:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct5y8-0002ql-Kn for ipsec@megatron.ietf.org; Mon, 24 Jan 2005 10:17:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20082 for ; Mon, 24 Jan 2005 10:17:29 -0500 (EST) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct6Ed-0007cn-Nv for ipsec@ietf.org; Mon, 24 Jan 2005 10:34:36 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j0OFGvCD025337 for ; Mon, 24 Jan 2005 10:16:57 -0500 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j0OFGtCX025332; Mon, 24 Jan 2005 10:16:55 -0500 Received: from pkoning.equallogic.com ([172.16.1.108]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Jan 2005 10:16:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16885.4454.350467.958685@gargle.gargle.HOWL> Date: Mon, 24 Jan 2005 10:16:54 -0500 From: Paul Koning To: tls@rek.tjls.com Subject: Re: [Ipsec] Replicated identities across multiple remote access users References: <20050123221505.99674.qmail@web90001.mail.scd.yahoo.com> <20050124004858.GA19983@panix.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 24 Jan 2005 15:16:55.0459 (UTC) FILETIME=[BD679730:01C50227] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Thor" == Thor Lancelot Simon writes: Thor> On Sun, Jan 23, 2005 at 02:15:05PM -0800, Surya Batchu wrote: >> In IPsec drafts and standards, there is no explicit prohition of >> reusing the identity by remote access clients. It seems to me >> that, there was an implicit understanding that each peer uses its >> own and unique identity. Now, we have a need to support multiple >> remote access sessions using the same identitiy. Thor> That's a spectacularly bad idea. It makes possible an array of Thor> man in the middle and credential-stealing attacks that are Thor> remarkably easy to execute. You almost might as well not use Thor> IPsec at all. I'd say that's a bit of an exaggeration. It seems to me that a remote access server has to support multiple sessions with the same identity, because the same user may want to establish multiple sessions. That's a perfectly good application without serious security issues. On the other hand, I would agree that it makes sense to warn that identities should not be shared among multiple users, because then each can impersonate the other. But that's an administrative guideline, not a rule that translates into server algorithms. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 24 11:14:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26122 for ; Mon, 24 Jan 2005 11:14:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6l8-0005Li-K4; Mon, 24 Jan 2005 11:08:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6dZ-0004HN-IS for ipsec@megatron.ietf.org; Mon, 24 Jan 2005 11:00:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24517 for ; Mon, 24 Jan 2005 11:00:18 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ct6u5-0000rf-8K for ipsec@ietf.org; Mon, 24 Jan 2005 11:17:26 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id EEF38103D8 for ; Mon, 24 Jan 2005 10:59:46 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20565-22 for ; Mon, 24 Jan 2005 10:59:34 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id D8EF4102D1 for ; Mon, 24 Jan 2005 10:59:33 -0500 (EST) To: ipsec@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Mon, 24 Jan 2005 10:50:54 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 01/24/2005 10:50:56 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Subject: [Ipsec] test X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 24 11:49:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28814 for ; Mon, 24 Jan 2005 11:49:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7KX-0006R4-MP; Mon, 24 Jan 2005 11:44:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7Cv-0004qU-3L for ipsec@megatron.ietf.org; Mon, 24 Jan 2005 11:36:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28016 for ; Mon, 24 Jan 2005 11:36:50 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ct7TR-0002L4-DC for ipsec@ietf.org; Mon, 24 Jan 2005 11:53:58 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 1A4E41066F for ; Mon, 24 Jan 2005 11:36:20 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18387-70 for ; Mon, 24 Jan 2005 11:36:09 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id E927710655 for ; Mon, 24 Jan 2005 11:36:08 -0500 (EST) To: ipsec@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Mon, 24 Jan 2005 11:27:29 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 01/24/2005 11:27:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ipsec] Rekey IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Can somebody please clarify the following: Section 2.18 of IKEv2 draft 17 states that when an IKE SA is being re-keyed the new initiator and responder SPI's are supplied in the SPI fields. But it seems to me that the SPI's of the existing IKE SA are required in these fields to be able to decrypt the packets (you need the SPI's to be able to identity which IKE SA the packet belongs to). Therefore this statement does not make sense to me. Is this a mistake or am I missing something? Thanks, Tom _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 24 12:30:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03905 for ; Mon, 24 Jan 2005 12:30:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7uO-0000En-00; Mon, 24 Jan 2005 12:21:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7i1-00035b-Bq for ipsec@megatron.ietf.org; Mon, 24 Jan 2005 12:09:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02269 for ; Mon, 24 Jan 2005 12:08:58 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7yK-0003hO-Mr for ipsec@ietf.org; Mon, 24 Jan 2005 12:25:55 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 24 Jan 2005 09:08:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0OH7sM8015472; Mon, 24 Jan 2005 09:07:54 -0800 (PST) Received: from ghuangw2k01 (sjc-vpn1-677.cisco.com [10.21.98.165]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAX73384; Mon, 24 Jan 2005 09:08:08 -0800 (PST) Message-Id: <200501241708.BAX73384@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Surya Batchu'" , Subject: RE: [Ipsec] Replicated identities across multiple remote access users Date: Mon, 24 Jan 2005 09:08:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcUBmc/tgpFMSZTsSNyAS4JjDBOnkAAnUvFg In-Reply-To: <20050123221505.99674.qmail@web90001.mail.scd.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Michael Richardson did a particularly good job summarizing a discussion the ICSA had about this very subject: http://www1.ietf.org/mail-archive/web/ipsec/current/msg01032.html -g ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Surya Batchu Sent: Sunday, January 23, 2005 2:15 PM To: ipsec@ietf.org Subject: [Ipsec] Replicated identities across multiple remote access users In IPsec drafts and standards, there is no explicit prohition of reusing the identity by remote access clients. It seems to me that, there was an implicit understanding that each peer uses its own and unique identity. Now, we have a need to support multiple remote access sessions using the same identitiy. Some of the issues I can see are with INITIAL-CONTACT and assignment of internal IP address (virtual IP address) to the clients. What are the other technical&deployment issues in allowing duplicate identities from IKE based remote access clients? Surya ________________________________ Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 24 12:36:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04508 for ; Mon, 24 Jan 2005 12:36:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7uw-0000jO-9D; Mon, 24 Jan 2005 12:22:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7p6-0006EO-E4 for ipsec@megatron.ietf.org; Mon, 24 Jan 2005 12:16:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02760 for ; Mon, 24 Jan 2005 12:16:17 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct85c-0003wn-HS for ipsec@ietf.org; Mon, 24 Jan 2005 12:33:26 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 Jan 2005 10:24:22 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0OHFjNt004850; Mon, 24 Jan 2005 09:15:45 -0800 (PST) Received: from ghuangw2k01 (sjc-vpn1-677.cisco.com [10.21.98.165]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BAX73992; Mon, 24 Jan 2005 09:15:39 -0800 (PST) Message-Id: <200501241715.BAX73992@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Tom Stiemerling'" , Subject: RE: [Ipsec] Rekey IKE SA Date: Mon, 24 Jan 2005 09:15:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcUCNLivJB88V7ASRCmnLtRLCoumSgAA1yCw In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I believe it means that while the SPIs in the IKE header are for the parent SA, the SPIs supplied in the SA payload are for the rekey SA. -g > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Tom Stiemerling > Sent: Monday, January 24, 2005 8:27 AM > To: ipsec@ietf.org > Subject: [Ipsec] Rekey IKE SA > > > > > > Can somebody please clarify the following: > > Section 2.18 of IKEv2 draft 17 states that when an IKE SA is > being re-keyed the new initiator and responder SPI's are > supplied in the SPI fields. But it seems to me that the SPI's > of the existing IKE SA are required in these fields to be > able to decrypt the packets (you need the SPI's to be able to > identity which IKE SA the packet belongs to). Therefore this > statement does not make sense to me. Is this a mistake or am > I missing something? > > Thanks, Tom > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 24 13:10:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07560 for ; Mon, 24 Jan 2005 13:10:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8Qu-0007OV-QE; Mon, 24 Jan 2005 12:55:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8HT-0005GV-Rf for ipsec@megatron.ietf.org; Mon, 24 Jan 2005 12:45:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05267 for ; Mon, 24 Jan 2005 12:45:34 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8Xy-0005C9-CP for ipsec@ietf.org; Mon, 24 Jan 2005 13:02:43 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OHjBIH072146; Mon, 24 Jan 2005 09:45:12 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200501240838.j0O8cvKF021001@burp.tkv.asdf.org> References: <200501201021.j0KALxFg002852@burp.tkv.asdf.org> <41EF9BC2.2020902@kolumbus.fi> <7445.1106254016@marajade.sandelman.ottawa.on.ca> <200501240838.j0O8cvKF021001@burp.tkv.asdf.org> Date: Mon, 24 Jan 2005 09:45:07 -0800 To: Markku Savela , ipsec@ietf.org From: Paul Hoffman Subject: Re: [Ipsec] PFKEY and IKEv2? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:38 AM +0200 1/24/05, Markku Savela wrote: >Ok, there seems to be interest on this. How to proceed? "pf_key at >inner.net" does not seem to be working for me. VPNC now set up a new PFKEY mailing list. See for subscription information. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 24 13:52:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11334 for ; Mon, 24 Jan 2005 13:52:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9CY-0001qY-7r; Mon, 24 Jan 2005 13:44:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct95g-00007r-S8 for ipsec@megatron.ietf.org; Mon, 24 Jan 2005 13:37:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09966 for ; Mon, 24 Jan 2005 13:37:30 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9ME-0007HA-D1 for ipsec@ietf.org; Mon, 24 Jan 2005 13:54:39 -0500 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0OIasjf027021; Mon, 24 Jan 2005 13:36:55 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 24 Jan 2005 13:40:23 -0500 To: Russ Housley , "Theodore Ts'o" From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ipsec@ietf.org, Sam Hartman Subject: [Ipsec] Status update re: Issues remaining for draft-ietf-ipsec-rfc2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Russ, Ted, We have revised 2401bis to address the list of issues in the tracker with the exception of one issue that is still under discussion with Sam Hartman (plus possible boilerplate updates). Once that is resolved, the draft will be edited as necessary, nroffed, etc. and submitted to the IESG. Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 24 17:25:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09214 for ; Mon, 24 Jan 2005 17:25:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCVM-0001bt-5F; Mon, 24 Jan 2005 17:16:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCSM-000795-Tf for ipsec@megatron.ietf.org; Mon, 24 Jan 2005 17:13:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08253 for ; Mon, 24 Jan 2005 17:13:07 -0500 (EST) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCix-0001WZ-2B for ipsec@ietf.org; Mon, 24 Jan 2005 17:30:19 -0500 Received: from root (helo=thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1CtCS9-0001Eh-00; Mon, 24 Jan 2005 17:12:57 -0500 Received: from tytso by thunk.org with local (Exim 4.43) id 1CtCSA-0001b8-U9; Mon, 24 Jan 2005 17:12:58 -0500 Date: Mon, 24 Jan 2005 17:12:58 -0500 From: "Theodore Ts'o" To: Karen Seo Message-ID: <20050124221258.GA6005@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipsec@ietf.org, Sam Hartman , Russ Housley Subject: [Ipsec] Re: Status update re: Issues remaining for draft-ietf-ipsec-rfc2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Mon, Jan 24, 2005 at 01:40:23PM -0500, Karen Seo wrote: > Russ, Ted, > > We have revised 2401bis to address the list of issues in the tracker > with the exception of one issue that is still under discussion with > Sam Hartman (plus possible boilerplate updates). Once that is > resolved, the draft will be edited as necessary, nroffed, etc. and > submitted to the IESG. Karen, Steve, This is great to hear! Many thanks to both of you for your hard work in finishing the edits to 2401-bis. Both Barbara and I are looking forward to what will hopefully be the last version of draft-ietf-ipsec-rfc2401bis to be submitted to the I-D editor. Assuming you can clear the last issue with Sam fairly quickly, do you think you would be able to finish the boilerplate/nroff fixups within the week? It would be really great for the IESG to be able to approve this document and be able to close out this working group before the Minneapolis meeting. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 25 11:30:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18297 for ; Tue, 25 Jan 2005 11:30:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtTTL-0000UQ-EM; Tue, 25 Jan 2005 11:23:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtTPK-00082s-Mw for ipsec@megatron.ietf.org; Tue, 25 Jan 2005 11:19:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17148 for ; Tue, 25 Jan 2005 11:19:08 -0500 (EST) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtTg3-0006vO-JJ for Ipsec@ietf.org; Tue, 25 Jan 2005 11:36:28 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0PGIZ3e018307 for ; Tue, 25 Jan 2005 11:18:35 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0PGIZ5X264316 for ; Tue, 25 Jan 2005 11:18:35 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0PGIY2q004913 for ; Tue, 25 Jan 2005 11:18:34 -0500 Received: from d01mll83.pok.ibm.com (d01mll83.pok.ibm.com [9.56.225.194]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0PGIYZP004905 for ; Tue, 25 Jan 2005 11:18:34 -0500 To: Ipsec@ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Wierbowski Date: Tue, 25 Jan 2005 11:18:33 -0500 X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 01/25/2005 11:18:34 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ipsec] RFC 3947 and RFC 3948 interop testing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A few weeks ago the "Negotiation of NAT-Traversal in the IKE" and "UDP Encapsulation of IPsec ESP Packets" drafts became published RFCs. Will there be an interop testing event where we can test our IKEv1 implementation with other vendor's IKEv1 implementations? I know I've seen discussions about IKEv2 interop testing (i.e. ICSA's IPsec/IKEv2 Interoperability Workshop), but did not know where that leaves testing for enhancements to IKEv1 (such as RFCs 3947 and 3948). Dave Wierbowski z/OS Comm Server Developer _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 26 14:01:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00236 for ; Wed, 26 Jan 2005 14:01:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsK9-0007yt-Vd; Wed, 26 Jan 2005 13:55:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsDw-0006KZ-Tw for ipsec@megatron.ietf.org; Wed, 26 Jan 2005 13:49:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28878 for ; Wed, 26 Jan 2005 13:49:01 -0500 (EST) Received: from [207.145.48.18] (helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CtsUu-0007eo-Tj for ipsec@ietf.org; Wed, 26 Jan 2005 14:06:37 -0500 Received: from intoto.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005012610480504778 for ; Wed, 26 Jan 2005 10:48:05 -0800 Received: from SriniSony (SriniSony.intoto.com [10.1.5.109]) by intoto.com (8.12.5/8.12.5) with ESMTP id j0QInEjU017429 for ; Wed, 26 Jan 2005 10:49:16 -0800 Message-Id: <200501261849.j0QInEjU017429@intoto.com> From: "Srinivasa Rao Addepalli" To: Date: Wed, 26 Jan 2005 10:48:24 -0800 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUD151IzSPS19mVQ+S7idkKC8iLZA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Re: Replicated identities X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable In general, it is not good allow reuse of identities by multiple remote = users. But, yet times, it is necessary to allow reuse of identities to = simplify the configuration. It is also necessary that simplification of = configuration should not degrade the security. Typically, it is useful = in cases where there is some other mechanism to identify and = authenticate the user. L2TPoIPsec is one such case. In this case, as = part of PPP, users are authenticated and identified.=20 There is also a need to allow one user to access internal network via = VPN tunnel from different machines simultaneously with or without = L2TPoIPsec. In this case, VPN security gateway would see multiple IKE = sessions with the same identity. Even though this is one valid = deployment scenario, there is no simple way to distinguish between a = single user making multiple IKE sessions Vs different users using the = same identity. This need to be kept in mind in allowing replicated = identities by administrator. Also, note that, if replicated identities = are allowed, administrator may not get accounting related information on = per user basis. To disallow multiple users using same identity, = administrator can employ identity specific preshared keys.=20 As you have indicated, there are some issues allowing multiple IKE = sessions with the same identity and they need to be handled properly. = Some implementations provide configuration facility to allow the reuse = of identities as part of their VPN configuration. Ensure that, the = implementations handle INITIAL_CONTACT message properly. One simple way, = some implementation implemented is to ignore INITIAL_CONTACT = notification message, if administrator configure it to allow replicated = identities. I feel, this will not have any significant effect, if DPD is negotiated = in case of IKEv1. In IKEv2, IKE SA live-check is mandatory and no issue = there. Due to this liveness checks, there will not be any problem of excessive = assignment of IRAS IP addresses to the same IRAC.=20 Srini =E2=9E=A2 In IPsec drafts and standards, there is no explicit = prohibition of reusing the identity by remote access clients.=20 =E2=9E=A2 It seems to me that, there was an implicit understanding that = each peer uses its own and unique identity. =E2=9E=A2 Now, we have a need to support multiple remote access = sessions using the same identitiy.=20 =E2=9E=A2 Some of the issues I can see are with INITIAL-CONTACT and = assignment of internal IP address =E2=9E=A2 (virtual IP address) to the clients. =E2=9E=A2 What are the other technical&deployment issues in allowing = duplicate identities from IKE based=20 =E2=9E=A2 remote access clients? =20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 27 01:40:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07979 for ; Thu, 27 Jan 2005 01:40:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu3HE-0002yt-Hw; Thu, 27 Jan 2005 01:37:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu3G6-0002ZR-PN for ipsec@megatron.ietf.org; Thu, 27 Jan 2005 01:36:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07477 for ; Thu, 27 Jan 2005 01:36:01 -0500 (EST) Received: from web90003.mail.scd.yahoo.com ([66.218.94.61]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cu3XA-0000hf-2x for ipsec@ietf.org; Thu, 27 Jan 2005 01:53:41 -0500 Received: (qmail 5803 invoked by uid 60001); 27 Jan 2005 06:35:29 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ewdAElMVoB806TyU5ayBNHaFUpT1TUcbcdPPBzgAHiDCvP0qxJNnawykjxlOmFnD7/S6jb0rmcGUWZwenZ+EFwU42TMBAqFIGKb+fDh3XN7aRQ7Vc2Ge3nAIQv9LYmd+3g4Q+mjlT5UvOJ+UrbyZvdjS51gn1FFXn9KcBCvPFSI= ; Message-ID: <20050127063529.5801.qmail@web90003.mail.scd.yahoo.com> Received: from [67.170.231.141] by web90003.mail.scd.yahoo.com via HTTP; Wed, 26 Jan 2005 22:35:29 PST Date: Wed, 26 Jan 2005 22:35:29 -0800 (PST) From: Surya Batchu To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ipsec] Identities types IP address, FQDN/user FQDN and DN and its usage in pershared key authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0952088198==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0952088198== Content-Type: multipart/alternative; boundary="0-840604442-1106807729=:5640" --0-840604442-1106807729=:5640 Content-Type: text/plain; charset=us-ascii Hi In pre-shared key authentication mode (no RSA/DSA certificates), what are the advantages of one identity type over another? What are the appropriate deployment scenarios for these different identity types? Surya --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' --0-840604442-1106807729=:5640 Content-Type: text/html; charset=us-ascii
Hi
 
In pre-shared key authentication mode (no RSA/DSA certificates), what are the advantages of one identity type over another? What are the appropriate deployment scenarios for these different identity types?
 
Surya

Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term' --0-840604442-1106807729=:5640-- --===============0952088198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0952088198==-- From ipsec-bounces@ietf.org Thu Jan 27 03:00:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29400 for ; Thu, 27 Jan 2005 03:00:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu4Uj-0004qF-Mk; Thu, 27 Jan 2005 02:55:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu4KF-0002ZF-V3 for ipsec@megatron.ietf.org; Thu, 27 Jan 2005 02:44:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27954 for ; Thu, 27 Jan 2005 02:44:22 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu4bJ-0002K9-Jb for ipsec@ietf.org; Thu, 27 Jan 2005 03:02:03 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0R7iGc23320 for ; Thu, 27 Jan 2005 09:44:18 +0200 (EET) X-Scanned: Thu, 27 Jan 2005 09:44:00 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0R7i0BU007252 for ; Thu, 27 Jan 2005 09:44:00 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 007O2nec; Thu, 27 Jan 2005 09:43:58 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0R7huU28720 for ; Thu, 27 Jan 2005 09:43:56 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 Jan 2005 09:42:51 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 Jan 2005 09:42:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2005 09:42:50 +0200 Message-ID: Thread-Topic: Question about PRFs with fixed size key Thread-Index: AcUEQ82H6sUMpBNnTY+zNzcuOuJ14A== To: X-OriginalArrivalTime: 27 Jan 2005 07:42:51.0175 (UTC) FILETIME=[CDC90370:01C50443] X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Question about PRFs with fixed size key X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, Section 2.15 of draft-ietf-ipsec-ikev2-17 says that "If the negotiated prf takes a fixed size key, the shared secret MUST be of that fixed size". I found some earlier mails about this topic (from May 2003), and got the understanding that this means that if the shared secret is not of that fixed size, it simply can't be used, period; and there's no padding, truncation, or other processing to make it the correct size. Could some of the IKEv2 gurus confirm that this interpretation is indeed correct? (This would imply that PRF_AES128_CBC can't be used with EAP authentication, since RFC 3748 says that MSK is at least 64 octets (512 bytes), while PRF_AES128_CBC requires a 128-bit key.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 27 06:23:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17544 for ; Thu, 27 Jan 2005 06:23:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu7dC-0007LC-5V; Thu, 27 Jan 2005 06:16:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu7cD-0006f7-AK for ipsec@megatron.ietf.org; Thu, 27 Jan 2005 06:15:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16813 for ; Thu, 27 Jan 2005 06:15:05 -0500 (EST) Received: from [217.219.18.2] (helo=cc2.iut.ac.ir) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu7tH-0007Oi-SR for IPsec@ietf.org; Thu, 27 Jan 2005 06:32:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by cc2.iut.ac.ir (Postfix) with ESMTP id 07B92681B8 for ; Thu, 27 Jan 2005 14:58:35 +0330 (IRST) Received: from cc2.iut.ac.ir ([127.0.0.1]) by localhost (cc2.iut.ac.ir [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12293-05 for ; Thu, 27 Jan 2005 14:58:34 +0330 (IRST) Received: from ec.iut.ac.ir (localhost.localdomain [127.0.0.1]) by cc2.iut.ac.ir (Postfix) with ESMTP id C81BF681B6 for ; Thu, 27 Jan 2005 14:58:34 +0330 (IRST) From: "mahdavi" To: IPsec@ietf.org Date: Thu, 27 Jan 2005 14:58:34 +0330 Message-Id: <20050127112834.M78139@ec.iut.ac.ir> X-Mailer: Open WebMail 2.41 20041227 X-OriginatingIP: 217.219.15.236 (mahdavi@ec.iut.ac.ir) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: amavisd-new at cc2.iut.ac.ir X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ipsec] How many SPDs ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi experts. I want to design a high throughput hardware router with IPsec support. I supposed to support 200K SA connections. The question is how many SPD records I have to Support? 200K or less? What is the criterion? <-:-> _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 27 06:54:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21645 for ; Thu, 27 Jan 2005 06:54:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu87Z-0007PD-AZ; Thu, 27 Jan 2005 06:47:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu83p-0006bz-1j for ipsec@megatron.ietf.org; Thu, 27 Jan 2005 06:43:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20380 for ; Thu, 27 Jan 2005 06:43:37 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu8Kv-0008DB-VX for ipsec@ietf.org; Thu, 27 Jan 2005 07:01:22 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j0RBhbJZ027239 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jan 2005 13:43:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j0RBhauF027236; Thu, 27 Jan 2005 13: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: <16888.54248.431136.52059@fireball.kivinen.iki.fi> Date: Thu, 27 Jan 2005 13:43:36 +0200 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: [Ipsec] Question about PRFs with fixed size key In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Section 2.15 of draft-ietf-ipsec-ikev2-17 says that "If the > negotiated prf takes a fixed size key, the shared secret MUST be > of that fixed size". > > I found some earlier mails about this topic (from May 2003), and > got the understanding that this means that if the shared secret > is not of that fixed size, it simply can't be used, period; and > there's no padding, truncation, or other processing to make it > the correct size. That is my interpretation of the above text from the draft. The shared secret MUST be exactly of that given size tobe able to be used in the AUTH = prf(prf(Shared-secret, "Key Pad for IKEv2"), ) if PRF requires fixed key size. > Could some of the IKEv2 gurus confirm that this interpretation > is indeed correct? Yes, I think it is correct. > (This would imply that PRF_AES128_CBC can't be used with EAP > authentication, since RFC 3748 says that MSK is at least 64 > octets (512 bytes), while PRF_AES128_CBC requires a 128-bit > key.) I think the section 2.16 should be modified so that says that if fixed length of the shared secret is required the MSK is truncated or padded with zeros to get the shared secret used in the section 2.15. The text in the 2.15 is mostly meant that if the adminstrator configures the shared secret to be used with PRF_AES128_CBC in the IKEv2, he should also configure the shared secret with proper length. As the 2.16 was added nobody realized that in that case the shared secret is not configured by the adminstrator but coming from the MSK. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 27 09:32:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10057 for ; Thu, 27 Jan 2005 09:32:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuAdM-0000qe-Fj; Thu, 27 Jan 2005 09:28:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuAXj-0006uM-FJ for ipsec@megatron.ietf.org; Thu, 27 Jan 2005 09:22:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09024 for ; Thu, 27 Jan 2005 09:22:39 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuAoo-0004CL-Jq for ipsec@ietf.org; Thu, 27 Jan 2005 09:40:24 -0500 Received: from kolumbus.fi (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 815BD89883; Thu, 27 Jan 2005 16:22:05 +0200 (EET) Message-ID: <41F8F8CE.9000808@kolumbus.fi> Date: Thu, 27 Jan 2005 16:21:02 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Ipsec] Question about PRFs with fixed size key References: <16888.54248.431136.52059@fireball.kivinen.iki.fi> In-Reply-To: <16888.54248.431136.52059@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Tero Kivinen wrote: > Pasi.Eronen@nokia.com writes: > >>Section 2.15 of draft-ietf-ipsec-ikev2-17 says that "If the >>negotiated prf takes a fixed size key, the shared secret MUST be >>of that fixed size". >> >>I found some earlier mails about this topic (from May 2003), and >>got the understanding that this means that if the shared secret >>is not of that fixed size, it simply can't be used, period; and >>there's no padding, truncation, or other processing to make it >>the correct size. > > > That is my interpretation of the above text from the draft. Based on reading the text, that's also my interpretation. >>(This would imply that PRF_AES128_CBC can't be used with EAP >>authentication, since RFC 3748 says that MSK is at least 64 >>octets (512 bytes), while PRF_AES128_CBC requires a 128-bit >>key.) > > > I think the section 2.16 should be modified so that says that if fixed > length of the shared secret is required the MSK is truncated or padded > with zeros to get the shared secret used in the section 2.15. I would support this suggestion. > The text in the 2.15 is mostly meant that if the adminstrator > configures the shared secret to be used with PRF_AES128_CBC in the > IKEv2, he should also configure the shared secret with proper length. > As the 2.16 was added nobody realized that in that case the shared > secret is not configured by the adminstrator but coming from the MSK. Right. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 27 10:17:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15930 for ; Thu, 27 Jan 2005 10:17:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuBLd-0000mp-9A; Thu, 27 Jan 2005 10:14:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuBFR-00062J-TT for ipsec@megatron.ietf.org; Thu, 27 Jan 2005 10:07:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14334 for ; Thu, 27 Jan 2005 10:07:51 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuBWX-0005YF-Q0 for ipsec@ietf.org; Thu, 27 Jan 2005 10:25:36 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0RF7mc11143; Thu, 27 Jan 2005 17:07:48 +0200 (EET) X-Scanned: Thu, 27 Jan 2005 17:07:27 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0RF7R0f006488; Thu, 27 Jan 2005 17:07:27 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00H1POHq; Thu, 27 Jan 2005 17:06:26 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0RF6Px19928; Thu, 27 Jan 2005 17:06:25 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 Jan 2005 17:06:24 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 Jan 2005 17:06:22 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 Jan 2005 17:06:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Question about PRFs with fixed size key Date: Thu, 27 Jan 2005 17:06:21 +0200 Message-ID: Thread-Topic: [Ipsec] Question about PRFs with fixed size key Thread-Index: AcUEZa8DJvdMYDrQRR2agATKT12o0wAGaIkA To: , X-OriginalArrivalTime: 27 Jan 2005 15:06:22.0195 (UTC) FILETIME=[C3306C30:01C50481] X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Tero Kivinen writes: > Pasi.Eronen@nokia.com writes: > > Section 2.15 of draft-ietf-ipsec-ikev2-17 says that "If the > > negotiated prf takes a fixed size key, the shared secret MUST be > > of that fixed size". > >=20 > > I found some earlier mails about this topic (from May 2003), and > > got the understanding that this means that if the shared secret > > is not of that fixed size, it simply can't be used, period; and > > there's no padding, truncation, or other processing to make it > > the correct size. >=20 > That is my interpretation of the above text from the draft. The=20 > shared secret MUST be exactly of that given size tobe able to be=20 > used in the >=20 > AUTH =3D prf(prf(Shared-secret, "Key Pad for IKEv2"), ) >=20 > if PRF requires fixed key size. >=20 > > Could some of the IKEv2 gurus confirm that this interpretation > > is indeed correct? >=20 > Yes, I think it is correct. Ok. What was confusing me a bit is the text in Section 2.13 ("When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula."), but I guess this text applies only to the prf+ construction? Or in other words, prf+ accepts a variable=20 length key even if the underlying prf does not? However, since in IKEv2 prf+ always uses an output of the prf as the key, the padding/truncation happens only if the prf=20 has a fixed key size that is different from the output size. But due to the way AUTH payload is calculated, those prfs can't be used with shared key authentication at all... so perhaps we should require that all future prfs either accept variable length keys or have a key size equal to the output size? (In which case the text in 2.13 becomes unnecessary.) =20 > > (This would imply that PRF_AES128_CBC can't be used with EAP > > authentication, since RFC 3748 says that MSK is at least 64 > > octets (512 bytes), while PRF_AES128_CBC requires a 128-bit > > key.) >=20 > I think the section 2.16 should be modified so that says that > if fixed length of the shared secret is required the MSK is > truncated or padded with zeros to get the shared secret used > in the section 2.15. >=20 > The text in the 2.15 is mostly meant that if the adminstrator > configures the shared secret to be used with PRF_AES128_CBC in > the IKEv2, he should also configure the shared secret with > proper length. As the 2.16 was added nobody realized that in > that case the shared secret is not configured by the > adminstrator but coming from the MSK. Alternatively, we could just say that if you produce a 512-bit MSK, then negotiate a prf that can handle it (i.e., has a fixed key size of 512 bits, or accepts variable length keys). But I'm fine with your proposal as well. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 27 12:51:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06387 for ; Thu, 27 Jan 2005 12:51:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDm3-0000K9-Bp; Thu, 27 Jan 2005 12:49:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDjr-00081C-6Q for ipsec@megatron.ietf.org; Thu, 27 Jan 2005 12:47:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06079 for ; Thu, 27 Jan 2005 12:47:23 -0500 (EST) Received: from web90002.mail.scd.yahoo.com ([66.218.94.60]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CuE11-0001oX-8U for IPsec@ietf.org; Thu, 27 Jan 2005 13:05:11 -0500 Received: (qmail 12356 invoked by uid 60001); 27 Jan 2005 17:46:55 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=6BS62a5o/lobNgv2KfkUrqDdXFUbsbdjETW03upY0ukhUAA613dm/6TeJMyK/t6inzdhmXDvAgU7gIhOmrF8Gz0rGMjoKehy075iwLoNZZ8W1SgObTmZulwbJFY7nSYEisHTuW9Lo7G4x7+igufyfCuL5KSsA+3A2GrUSneONok= ; Message-ID: <20050127174655.12347.qmail@web90002.mail.scd.yahoo.com> Received: from [67.170.231.141] by web90002.mail.scd.yahoo.com via HTTP; Thu, 27 Jan 2005 09:46:55 PST Date: Thu, 27 Jan 2005 09:46:55 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] How many SPDs ? To: mahdavi , IPsec@ietf.org In-Reply-To: <20050127112834.M78139@ec.iut.ac.ir> MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1853633457==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1853633457== Content-Type: multipart/alternative; boundary="0-1280382609-1106848015=:99596" --0-1280382609-1106848015=:99596 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA06079 Content-Transfer-Encoding: quoted-printable =20 If you are targeting 100,000 peers, you need to have 200,000 security pol= icies.=20 If only ESP with AUTH is required, then 200K SAs are established in stea= dy state. Due to rekeying because of softlife time, there is a possibility of more = than one SA pair existing with a peer. So, it is better to leave some SA space for this. =20 Surya mahdavi wrote: Hi experts. I want to design a high throughput hardware router with IPsec support. I supposed to support 200K SA connections.=20 The question is how many SPD records I have to Support? 200K or less? Wha= t is the criterion? <-:-> _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec =09 --------------------------------- Do you Yahoo!? Meet the all-new My Yahoo! =96 Try it today!=20 --0-1280382609-1106848015=:99596 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA06079 Content-Transfer-Encoding: quoted-printable
 
If you are targeting 100,000 peers, you need to have 200,000 securit= y policies.
If only ESP with AUTH is required, then  200K SAs are esta= blished in steady state.
Due to rekeying because of softlife time, there is a possibility of = more than one SA pair
existing with a peer. So, it is better to leave some SA space for th= is.
 
Surya

mahdavi <mahdavi@ec.iut.ac.ir> wrot= e:


Hi experts.

I want to desi= gn a high throughput hardware router with IPsec support. I
supposed to= support 200K SA connections.

The question is how many SPD record= s I have to Support? 200K or less? What is
the criterion?

<-= :->


_______________________________________________
Ipse= c mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinf= o/ipsec

Do you Yahoo!?
=20 Meet the all-new My Yahoo! =96 Try it= today!=20 --0-1280382609-1106848015=:99596-- --===============1853633457== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1853633457==-- From ipsec-bounces@ietf.org Thu Jan 27 13:11:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07826 for ; Thu, 27 Jan 2005 13:11:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDzJ-0004Lz-6M; Thu, 27 Jan 2005 13:03:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDsk-0002gP-Px for ipsec@megatron.ietf.org; Thu, 27 Jan 2005 12:56:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06824 for ; Thu, 27 Jan 2005 12:56:35 -0500 (EST) Received: from web90002.mail.scd.yahoo.com ([66.218.94.60]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CuE9u-00022i-QW for ipsec@ietf.org; Thu, 27 Jan 2005 13:14:23 -0500 Received: (qmail 15210 invoked by uid 60001); 27 Jan 2005 17:56:07 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=rU3Px8gZDcHhnA9b9ml3pP5EII1M9JIcp7GFeDXh0K22A+Kei27iAuEogPU4VqPi4tT0Y9pCLhQ69E/xsMPiqT0qjcI/kfJwe20uWmMp2HiXn5iSI00b8bFr1cpMNYMTsVc0amc817qyTqg0/2pWuvdDmqqMlWxluTdkZXdzBxg= ; Message-ID: <20050127175607.15208.qmail@web90002.mail.scd.yahoo.com> Received: from [67.170.231.141] by web90002.mail.scd.yahoo.com via HTTP; Thu, 27 Jan 2005 09:56:06 PST Date: Thu, 27 Jan 2005 09:56:06 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] Identities types IP address, FQDN/user FQDN and DN and its usage in pershared key authentication To: Surya Batchu , ipsec@ietf.org In-Reply-To: <20050127063529.5801.qmail@web90003.mail.scd.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1334915020==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1334915020== Content-Type: multipart/alternative; boundary="0-679935066-1106848566=:12503" --0-679935066-1106848566=:12503 Content-Type: text/plain; charset=us-ascii If ID type 'ID_IPV4_ADDR' is used, it is necessary for receiving implementation to cross check source IP address of IKE message with the value in received ID payload? If there is a mismatch, some implementations seem to be rejecting the IKE negotiation. Why is this necessary? Does it provide any additional security? In my opinion, it is good enough if ID payload value matches with locally configured 'acceptable remote ID values'. Please give your comments. Surya Surya Batchu wrote: Hi In pre-shared key authentication mode (no RSA/DSA certificates), what are the advantages of one identity type over another? What are the appropriate deployment scenarios for these different identity types? Surya --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term'_______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' --0-679935066-1106848566=:12503 Content-Type: text/html; charset=us-ascii
If ID type 'ID_IPV4_ADDR' is used, it is necessary for receiving implementation to cross check source IP address of IKE message with the value in received ID payload?  If there is a mismatch, some implementations seem to be rejecting the IKE negotiation. Why is this necessary? Does it provide any additional security? In my opinion,  it is good enough if ID payload value matches with locally configured 'acceptable remote ID values'.  Please give your comments.
 
Surya
 


Surya Batchu <suryak_batchu@yahoo.com> wrote:
Hi
 
In pre-shared key authentication mode (no RSA/DSA certificates), what are the advantages of one identity type over another? What are the appropriate deployment scenarios for these different identity types?
 
Surya

Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term'_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term' --0-679935066-1106848566=:12503-- --===============1334915020== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1334915020==-- From ipsec-bounces@ietf.org Fri Jan 28 04:04:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09236 for ; Fri, 28 Jan 2005 04:04:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuRyS-0006A9-J0; Fri, 28 Jan 2005 03:59:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuRxB-0005wy-I0 for ipsec@megatron.ietf.org; Fri, 28 Jan 2005 03:58:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08895 for ; Fri, 28 Jan 2005 03:58:07 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuSET-00070u-Fn for ipsec@ietf.org; Fri, 28 Jan 2005 04:16:02 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j0S8w4jC009435 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Jan 2005 10:58:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j0S8w3C0009432; Fri, 28 Jan 2005 10:58:03 +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: <16889.65179.493511.767099@fireball.kivinen.iki.fi> Date: Fri, 28 Jan 2005 10:58:03 +0200 From: Tero Kivinen To: Subject: RE: [Ipsec] Question about PRFs with fixed size key In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 15 min X-Total-Time: 29 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Ok. What was confusing me a bit is the text in Section 2.13 > ("When the key for the prf function has fixed length, the data > provided as a key is truncated or padded with zeros as necessary > unless exceptional processing is explained following the > formula."), but I guess this text applies only to the prf+ > construction? Or in other words, prf+ accepts a variable > length key even if the underlying prf does not? Yes. > However, since in IKEv2 prf+ always uses an output of the prf > as the key, the padding/truncation happens only if the prf > has a fixed key size that is different from the output size. > But due to the way AUTH payload is calculated, those prfs can't > be used with shared key authentication at all... so perhaps we True. > should require that all future prfs either accept variable > length keys or have a key size equal to the output size? > (In which case the text in 2.13 becomes unnecessary.) There is also other places where it is little bit ambiguous what do if fixed length PRFs are used. The section 2.14 says that if we are using PRF with fixed length key, then 1) If the length(Ni) + length(Nr) == fixed_length_key_length use prf(Ni | Nr, ...) 2) If the length(Ni) + length(Nr) != fixed_length_key_length use Ni and Nr so that half of the bits of key must come from Ni and half from Nr,taking first bits of each. Now if the fixed length key length is 512 bits, and the Ni is 128 bits, annd Nr is 1024 bits, how do we generate the key for the PRF? a) Pad Ni to 256 bits by zeros, and then take 256 bits from it, and concatenate it with first 256 bits of Nr? b) Take 128 bits of Ni, and concatenate it with 384 bits from Nr? What if Nr is also 128 bits long? Do we then concatenate Ni and Nr to form a 256 bit long secret which is then padded with zeros? Currently this cannot yet happen as the nonces must be >= 128 bits long, and the only fixed size PRF is PRF_AES128_CBC and that has key length of 128 bits. Btw the PRF_AES128_CBC should have been named PRF_AES128_XCBC, as it is based on the AES-XCBC-PRF-128. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 28 04:30:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11308 for ; Fri, 28 Jan 2005 04:30:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuSLd-0002aq-SW; Fri, 28 Jan 2005 04:23:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuSHw-000240-UI for ipsec@megatron.ietf.org; Fri, 28 Jan 2005 04:19:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10353 for ; Fri, 28 Jan 2005 04:19:35 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuSZF-0007SJ-DD for Ipsec@ietf.org; Fri, 28 Jan 2005 04:37:29 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j0S9JYSl009656 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Jan 2005 11:19:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j0S9JV8q009653; Fri, 28 Jan 2005 11:19:31 +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: <16890.931.176091.74489@fireball.kivinen.iki.fi> Date: Fri, 28 Jan 2005 11:19:31 +0200 From: Tero Kivinen To: David Wierbowski Subject: [Ipsec] RFC 3947 and RFC 3948 interop testing In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit David Wierbowski writes: > I know I've seen discussions about IKEv2 interop testing (i.e. ICSA's > IPsec/IKEv2 Interoperability Workshop), but did not know where that leaves > testing for enhancements to IKEv1 (such as RFCs 3947 and 3948). We would at least be interested to testing RFC 3947 and 3948, and as we will be in the ICSA interoperability workshop we can do some testing there too if someone else is interested. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 28 06:58:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21566 for ; Fri, 28 Jan 2005 06:58:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuUcr-0007Uo-Lo; Fri, 28 Jan 2005 06:49:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuUXt-0006eX-LP for ipsec@megatron.ietf.org; Fri, 28 Jan 2005 06:44:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20653 for ; Fri, 28 Jan 2005 06:44:10 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuUpB-0002DH-Jb for IPsec@ietf.org; Fri, 28 Jan 2005 07:02:07 -0500 Received: from [10.84.130.119] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0SBhOjh015021; Fri, 28 Jan 2005 06:43:26 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050127174655.12347.qmail@web90002.mail.scd.yahoo.com> References: <20050127174655.12347.qmail@web90002.mail.scd.yahoo.com> Date: Fri, 28 Jan 2005 06:43:20 -0500 To: Surya Batchu From: Stephen Kent Subject: Re: [Ipsec] How many SPDs ? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IPsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:46 AM -0800 1/27/05, Surya Batchu wrote: >Content-Type: text/html; charset=us-ascii >X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA06079 > > >If you are targeting 100,000 peers, you need to have 200,000 >security policies. >If only ESP with AUTH is required, then 200K SAs are established in >steady state. >Due to rekeying because of softlife time, there is a possibility of >more than one SA pair >existing with a peer. So, it is better to leave some SA space for this. > >Surya Th question was about SPD entries, not SAD entries. Depoending on the form of the SPD entries, one may need very few to support creation of 200K SAD entries, or one may need a lot. For example, use of the populate from packet flag enables a single SPD entry to yield many SAD entries. Also, a named SPD entry may yield many SAD entries. So, there is no simple formula for how many SPD entries are needed to support 200K SAs. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 28 08:04:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26376 for ; Fri, 28 Jan 2005 08:04:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuVhm-0002FX-Cw; Fri, 28 Jan 2005 07:58:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuVgB-0001pT-Ml for ipsec@megatron.ietf.org; Fri, 28 Jan 2005 07:56:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25804 for ; Fri, 28 Jan 2005 07:56:50 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuVxW-0003zv-AZ for ipsec@ietf.org; Fri, 28 Jan 2005 08:14:46 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0SCun819046; Fri, 28 Jan 2005 14:56:49 +0200 (EET) X-Scanned: Fri, 28 Jan 2005 14:56:19 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0SCuJAY029288; Fri, 28 Jan 2005 14:56:19 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00WlotOf; Fri, 28 Jan 2005 14:54:28 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0SCsKU04089; Fri, 28 Jan 2005 14:54:20 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jan 2005 14:54:18 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jan 2005 14:54:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Question about PRFs with fixed size key Date: Fri, 28 Jan 2005 14:54:18 +0200 Message-ID: Thread-Topic: [Ipsec] Question about PRFs with fixed size key Thread-Index: AcUFGRy8HWrDJ2wJSiOdcaKpKcg98AAHgAgA To: X-OriginalArrivalTime: 28 Jan 2005 12:54:17.0959 (UTC) FILETIME=[7A63B770:01C50538] X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Tero Kivinen writes: >=20 > There is also other places where it is little bit ambiguous > what do if fixed length PRFs are used. The section 2.14 says > that if we are using PRF with fixed length key, then >=20 > 1) If the length(Ni) + length(Nr) =3D=3D fixed_length_key_length > use prf(Ni | Nr, ...) > 2) If the length(Ni) + length(Nr) !=3D fixed_length_key_length > use Ni and Nr so that half of the bits of key must come=20 > from Ni and half from Nr,taking first bits of each. >=20 > Now if the fixed length key length is 512 bits, and the Ni is > 128 bits, annd Nr is 1024 bits, how do we generate the key for > the PRF? >=20 > a) Pad Ni to 256 bits by zeros, and then take 256 bits from it,=20 > and concatenate it with first 256 bits of Nr? > b) Take 128 bits of Ni, and concatenate it with 384 bits=20 > from Nr? >=20 > What if Nr is also 128 bits long? Do we then concatenate Ni > and Nr to form a 256 bit long secret which is then padded with > zeros? >=20 > Currently this cannot yet happen as the nonces must be >=3D 128 > bits long, and the only fixed size PRF is PRF_AES128_CBC and > that has key length of 128 bits. I would say that if the initiator proposes a PRF that has fixed key length of >256 bits, it can also choose Ni that is long enough (at least key length/2 bits); and likewise for the responder, if it accepts this PRF, it can include sufficiently long Nr. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 28 13:52:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29239 for ; Fri, 28 Jan 2005 13:52:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuaxp-0003vG-O3; Fri, 28 Jan 2005 13:35:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuavy-0002xR-Fx for ipsec@megatron.ietf.org; Fri, 28 Jan 2005 13:33:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27419 for ; Fri, 28 Jan 2005 13:33:27 -0500 (EST) Received: from [207.145.48.18] (helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CubDL-0004Hc-28 for ipsec@ietf.org; Fri, 28 Jan 2005 13:51:28 -0500 Received: from intoto.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005012810321206773 ; Fri, 28 Jan 2005 10:32:12 -0800 Received: from SriniSony ([10.1.5.109]) by intoto.com (8.12.5/8.12.5) with ESMTP id j0SIXYHJ025580; Fri, 28 Jan 2005 10:33:37 -0800 Message-Id: <200501281833.j0SIXYHJ025580@intoto.com> From: "Srinivasa Rao Addepalli" To: "'Surya Batchu'" , Subject: RE: [Ipsec] Identities types IP address, FQDN/user FQDN and DN and its usage in pershared key authentication Date: Fri, 28 Jan 2005 10:32:31 -0800 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUEO1XcNQuuFEEGR1qfA/KIzS4TUQBK4TxQ In-Reply-To: <20050127063529.5801.qmail@web90003.mail.scd.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =A0 In pre-shared key authentication mode (no RSA/DSA certificates), what = are the advantages of one identity type over another? What are the = appropriate deployment scenarios for these different identity types? SRINI> All of them are equal from security perspective. Only requirement = is that the ID should be unique in a VPN. ID field identifies the IPsec = device or client and it should remain same across multiple IPsec sessions. Typically, identity type IP-ADDR is used, if the device/client has = static public IP address. Other identity types can be used in any scenario.=20 Srini _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 28 14:23:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04288 for ; Fri, 28 Jan 2005 14:23:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cubbi-0004p8-PG; Fri, 28 Jan 2005 14:16:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CubYS-0003sR-Id for ipsec@megatron.ietf.org; Fri, 28 Jan 2005 14:13:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02918 for ; Fri, 28 Jan 2005 14:13:15 -0500 (EST) Received: from bayc1-pasmtp01.bayc1.hotmail.com ([65.54.191.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cubpp-0005Ri-Ju for ipsec@ietf.org; Fri, 28 Jan 2005 14:31:14 -0500 Message-ID: X-Originating-IP: [70.48.238.129] X-Originating-Email: [njacottin@sympatico.ca] Received: from belinda ([70.48.238.129]) by bayc1-pasmtp01.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Jan 2005 11:14:43 -0800 From: "Nicolas Jacottin" To: "Srinivasa Rao Addepalli" Subject: RE: [Ipsec] Identities types IP address, FQDN/user FQDN and DN and its usage in pershared key authentication Date: Fri, 28 Jan 2005 14:12:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200501281833.j0SIXYHJ025580@intoto.com> Importance: Normal X-OriginalArrivalTime: 28 Jan 2005 19:14:44.0078 (UTC) FILETIME=[9FD110E0:01C5056D] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA02918 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: njacottin@sympatico.ca List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Dear Srni, The main advantage of using FQDN for pre-shared key auth. against IP addr= ess is scalability. I mean if you have to deploy 10 users-to-site or site-to-site connections it's not a concern as soon as you don't have PAT= in between. Therefore, it's interesting to implement preshared key auth. bas= ed on FQDN when: + you have a large number of IPSec tunnels (machine or user). You can use= a RADIUS server that will take care of the authentication and the storage o= f Users/machine account based on the name and domain. It's offer also the possibility to implement accounting if you use L2TP over IPSec for provid= ing dynamically an IP address to the end tunnel. Note that IKEv2 is , I thin= k, able to provide a standardized way also to implement the dynamic provisioning of an IP address to the tunnel end-point. + when a end-point of a tunnel is hidden by PAT, it's become harder to become aware of the right IP address and even more difficult if the devic= e obtains an IP address via DHCP. Note that when there is NAT in between NA= T-T takes good care of your IPSec connection. So the use of IP address for the authentication is useful if you don't ha= ve a large number of tunnel because it's the simplest way to implement it. I= t's really depends of the topology and what are you willing to achieve. If yo= u need further information let me know. Nicolas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]On Behalf Of Srinivasa Rao Addepalli Sent: vendredi 28 janvier 2005 13:33 To: 'Surya Batchu'; ipsec@ietf.org Subject: RE: [Ipsec] Identities types IP address,FQDN/user FQDN and DN and its usage in pershared key authentication =A0 In pre-shared key authentication mode (no RSA/DSA certificates), what are the advantages of one identity type over another? What are the appropriat= e deployment scenarios for these different identity types? SRINI> All of them are equal from security perspective. Only requirement = is that the ID should be unique in a VPN. ID field identifies the IPsec devi= ce or client and it should remain same across multiple IPsec sessions. Typically, identity type IP-ADDR is used, if the device/client has static public IP address. Other identity types can be used in any scenario. Srini _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 30 07:15:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24882 for ; Sun, 30 Jan 2005 07:15:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvDw5-0003FU-I7; Sun, 30 Jan 2005 07:12:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvDrq-0002JV-Lk for ipsec@megatron.ietf.org; Sun, 30 Jan 2005 07:07:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24452 for ; Sun, 30 Jan 2005 07:07:47 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvE9Z-0007sm-92 for ipsec@ietf.org; Sun, 30 Jan 2005 07:26:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Jan 2005 04:16:58 -0800 Message-ID: <1876F5823FEE8B428E5AD3D56724709D02B70985@sinett-sbs.SiNett.LAN> Thread-Topic: Comments: draft-ietf-ipsec-ikev2-17.txt thread-index: AcUGxWugjWx2cMnqT065fFb2Y1IikA== From: "Vishwas Manral" To: X-Spam-Score: 1.0 (+) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Subject: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1401661619==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1401661619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C506C5.9896F5A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C506C5.9896F5A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I noticed the document in the RFC editor queue, if so I can send the = comments as an RFC errata itself later. Here are some small "nits" I = came across: - 1. Section 2.13 - states "**they** algorithm by which keys are derived = from arbitrary values MUST be specified by the cryptographic transform. = " Typo. 2. Section 3.3.2 - Transform type Values: -=20 Encryption Algorithm (ENCR) 1 (IKE and ESP) Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) I think we can remove the "optional" in ESP part for Integrity = Algorithm. The optional part could be added instead to the Encryption = Algorithm part. 3. Section 3.3.3 Protocol Mandatory Types Optional Types IKE ENCR, PRF, INTEG, D-H ESP ENCR INTEG, D-H, ESN AH INTEG D-H, ESN To be changed to Protocol Mandatory Types Optional Types IKE ENCR, PRF, INTEG, D-H ESP INTEG ENCR, D-H, ESN <<=3D=3D = changed here AH INTEG D-H, ESN 4. Section 1.2 states: - "All but the headers of all the messages that follow are encrypted and = integrity protected." Do we also mean to say that the header is integrity protected but not = encrypted? We may want to clarify the text, and instead state "For all = messages that folllow, the header is encrypted and the message including = the header is integrity protected." 5. "In other words, if the responder stated its window size is N, then = when the initiator needs to make a request X, it MUST wait until it has = received responses to all requests up through request X-N." This = statement may not be true for X < N. 6. In Section 2.13 we talk about (K, S) but never specify what K or S = mean. 7. IKE document talks about ECN, but wont a similar case be there for = DSCP values. I think DSCP values should be copied from the Outer header = back to the inner header too.=20 Also the above could be specified in the = draft-ietf-ipsec-rfc2401bis-05.txt draft too. 8. We may want to state(obvious) that IKE message on port 4500, MUST = have the first 4 bytes as zero on receipt and should always send the = bytes as 0. Thanks, Vishwas =20 ------_=_NextPart_001_01C506C5.9896F5A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=

Hi,

=0A=

I noticed the document in the RFC editor queue, if so I can send the = comments =0A= as an RFC errata itself later. Here are some small  "nits" I came = across: =0A= -

=0A=

1. Section 2.13 –  states "**they** algorithm by which = keys are derived =0A= from arbitrary values MUST be specified by the cryptographic transform. = " =0A= Typo.

=0A=

2. Section 3.3.2 - Transform type Values: -

=0A=

Encryption Algorithm (ENCR)     1  (IKE and =0A= ESP)
Integrity Algorithm (INTEG)     3  = (IKE, AH, =0A= optional in ESP)

=0A=

I think we can remove the "optional" in ESP part for Integrity = Algorithm. The =0A= optional part could be added instead to the Encryption Algorithm = part.

=0A=

3. Section 3.3.3

=0A=

          Protocol  =0A= Mandatory Types        Optional =0A= Types
          &nbs= p; =0A= IKE     ENCR, PRF, INTEG, =0A= D-H
           = =0A= ESP     =0A= ENCR           &nb= sp;       =0A= INTEG, D-H, =0A= ESN
           = =0A= AH      =0A= INTEG           &n= bsp;      =0A= D-H, ESN

=0A=

To be changed to

=0A=

          Protocol  =0A= Mandatory Types        Optional =0A= Types
          &nbs= p; =0A= IKE     ENCR, PRF, INTEG, =0A= D-H
           = =0A= ESP     =0A= INTEG           &n= bsp;      =0A= ENCR, D-H, ESN <<=3D=3D changed =0A= here
           = ; =0A= AH      =0A= INTEG           &n= bsp;      =0A= D-H, ESN

=0A=


4. Section 1.2 states: -

=0A=

"All but the headers of all the messages that follow are encrypted = and =0A= integrity protected."

=0A=

Do we also mean to say that the header is integrity protected but not =0A= encrypted? We may want to clarify the text, and instead state  "For = all =0A= messages that folllow, the header is encrypted and the message including = the =0A= header is integrity protected."

=0A=

5. "In other words, if the responder stated its window size is N, = then when =0A= the initiator needs to make a request X, it MUST wait until it has = received =0A= responses to all requests up through request X-N." This statement may = not be =0A= true for X < N.

=0A=

6.  In Section 2.13 we talk about (K, S) but never specify what = K or S =0A= mean.

=0A=

7. IKE document talks about ECN, but wont a similar case be there for = DSCP =0A= values. I think DSCP values should be copied from the Outer header back = to the =0A= inner header too.

=0A=

Also the above could be specified in the = draft-ietf-ipsec-rfc2401bis-05.txt =0A= draft too.

=0A=

8.  We may want to state(obvious) that IKE message on port 4500, = MUST =0A= have the first 4 bytes as zero on receipt and should always send the = bytes as =0A= 0.

=0A=

Thanks,
Vishwas

=0A=

 

=0A= =0A= =0A= ------_=_NextPart_001_01C506C5.9896F5A2-- --===============1401661619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1401661619==-- From ipsec-bounces@ietf.org Sun Jan 30 23:08:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29586 for ; Sun, 30 Jan 2005 23:08:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvSiU-0003Ji-9K; Sun, 30 Jan 2005 22:59:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvShz-0003E1-H9 for ipsec@megatron.ietf.org; Sun, 30 Jan 2005 22:58:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28802 for ; Sun, 30 Jan 2005 22:58:37 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvSzq-0008JQ-IT for ipsec@ietf.org; Sun, 30 Jan 2005 23:17:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Jan 2005 20:06:42 -0800 Message-ID: Thread-Topic: draft-ietf-ipsec-rfc2401bis-05.txt thread-index: AcUHSkVC/dSOcxQlR+ioPA3e5bSLkw== From: "Vishwas Manral" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1696545106==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1696545106== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5074A.74207C2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5074A.74207C2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steve, =20 I think the security architecture does not specify copying of DSCP and ECN values from the outer header to the inner header in the case of decapsulation for tunnel mode for both IPv4 and IPv6. =20 DSCP values will not be copied directly however, depending on the change of domain. =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5074A.74207C2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Steve,

 

I think the security architecture does not specify = copying of DSCP and ECN values from the outer header to the inner header in the = case of decapsulation for tunnel mode for both IPv4 and = IPv6.

 

DSCP values will not be copied directly however, = depending on the change of domain.

 

Thanks,

Vishwas

 

------_=_NextPart_001_01C5074A.74207C2C-- --===============1696545106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1696545106==-- From ipsec-bounces@ietf.org Mon Jan 31 08:17:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27868 for ; Mon, 31 Jan 2005 08:17:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbLl-0007HD-7e; Mon, 31 Jan 2005 08:12:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbHG-0006Qc-UN for ipsec@megatron.ietf.org; Mon, 31 Jan 2005 08:07:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24877 for ; Mon, 31 Jan 2005 08:07:38 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvbZD-0002ZI-SO for ipsec@ietf.org; Mon, 31 Jan 2005 08:26:12 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j0VD7XQj021455 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 31 Jan 2005 15:07:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j0VD7UrI021452; Mon, 31 Jan 2005 15:07:30 +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: <16894.11666.382510.154389@fireball.kivinen.iki.fi> Date: Mon, 31 Jan 2005 15:07:30 +0200 From: Tero Kivinen To: njacottin@sympatico.ca Subject: RE: [Ipsec] Identities types IP address, FQDN/user FQDN and DN and its usage in pershared key authentication In-Reply-To: References: <200501281833.j0SIXYHJ025580@intoto.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 10 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Nicolas Jacottin writes: > + when a end-point of a tunnel is hidden by PAT, it's become harder to > become aware of the right IP address and even more difficult if the device > obtains an IP address via DHCP. Note that when there is NAT in between NAT-T > takes good care of your IPSec connection. There is no requirement for the ID_IPV4_ADDR or ID_IPV6_ADDR to match any of the addresses of the host (not before, after or inside NAT, host or anything). As long as the IP-addresses are unique among your clients you can use whatever you like. You can even start allocating for the first client ID_IPV4_ADDR of 0.0.0.0, and then next with 0.0.0.1, and so on. When the SGW will see thet ID_IPV4_ADDR it will use it to fetch the policy and authentication data and use those to verify policy and to authenticate the other end. For example it is completely valid from the IKEv2 point of view to create each client a certificate with the IP-address from the INTERNAL network used inside the office (probably from 10.0.0.0/8 net), and assign each client one of those IP-addresses in the DHCP/Radius server. Then when client connects outside making the VPN tunnel from laptop to the SGW, it can use the same ID_IPV4_ADDR identity and the certificate to authenticate itself, and the SGW can after verifying the certificate start doing proxy-arp or similar so that laptop can act just like it would be in the internal office network. For some reason some people consider this bad, but it is completely valid and allowed by the IKEv2. I agree that the first case where using ID_IPV4_ADDR can be much better handled with ID_KEY_ID, and in some cases it is much better to use ID_FQDN or IP_RFC822_ADDR, but there is no requirement in IKEv2 which says any of the ID payloads needs to match any data in the insecure outer IP-header (actually doing any of those checks can break NAT-T). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 31 09:33:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05772 for ; Mon, 31 Jan 2005 09:33:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvcZ8-0001y5-H7; Mon, 31 Jan 2005 09:30:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvcWB-0001W4-Rv for ipsec@megatron.ietf.org; Mon, 31 Jan 2005 09:27:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05267 for ; Mon, 31 Jan 2005 09:27:06 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvco9-0004cq-EP for ipsec@ietf.org; Mon, 31 Jan 2005 09:45:42 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j0VER2QW022653 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 31 Jan 2005 16:27:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j0VER1DS022650; Mon, 31 Jan 2005 16:27: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: <16894.16437.363303.320788@fireball.kivinen.iki.fi> Date: Mon, 31 Jan 2005 16:27:01 +0200 From: Tero Kivinen To: "Vishwas Manral" Subject: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt In-Reply-To: <1876F5823FEE8B428E5AD3D56724709D02B70985@sinett-sbs.SiNett.LAN> References: <1876F5823FEE8B428E5AD3D56724709D02B70985@sinett-sbs.SiNett.LAN> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 9 min X-Total-Time: 29 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Vishwas Manral writes: > 2. Section 3.3.2 - Transform type Values: - > > Encryption Algorithm (ENCR) 1 (IKE and ESP) > Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) > > I think we can remove the "optional" in ESP part for Integrity > Algorithm. The optional part could be added instead to the > Encryption Algorithm part. No, we cannot remove that. Integrity is optional in ESP. Encryption is NOT optional in the ESP. If you do not want to use encryption in ESP, you need to negotiate cipher called ENCR_NULL. > 4. Section 1.2 states: - > > "All but the headers of all the messages that follow are encrypted and integrity protected." > > Do we also mean to say that the header is integrity protected but > not encrypted? We may want to clarify the text, and instead state > "For all messages that folllow, the header is encrypted and the > message including the header is integrity protected." Header is not encrypted, the data after header is encrypted, so your text is actually incorrect. It is true we could clarify that the header is also integrity protected.... > 6. In Section 2.13 we talk about (K, S) but never specify what K or > S mean. I think it is quite obvious that they are inputs to the function prf+... > 8. We may want to state(obvious) that IKE message on port 4500, > MUST have the first 4 bytes as zero on receipt and should always > send the bytes as 0. I think the section 3.1 says that: ---------------------------------------------------------------------- When sent on UDP port 4500, IKE messages have prepended four octets of zero. These four octets of zero are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 31 12:32:55 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26851 for ; Mon, 31 Jan 2005 12:32:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfDG-0007u6-JH; Mon, 31 Jan 2005 12:19:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvf9E-0005ov-Mk for ipsec@megatron.ietf.org; Mon, 31 Jan 2005 12:15:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24897 for ; Mon, 31 Jan 2005 12:15:33 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvfRD-0000X8-5Z for ipsec@ietf.org; Mon, 31 Jan 2005 12:34:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt Date: Mon, 31 Jan 2005 09:24:51 -0800 Message-ID: Thread-Topic: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt thread-index: AcUHoldCymOYL6QUQPCb4UOF1jBbZAAFaBWu From: "Vishwas Manral" To: "Tero Kivinen" X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0682521258==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0682521258== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C507B9.C56C9920" This is a multi-part message in MIME format. ------_=_NextPart_001_01C507B9.C56C9920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tero, =20 Thanks a lot for the reply. My comments are prefixed with a "VM>" =20 > "All but the headers of all the messages that follow are encrypted and = integrity protected." > > Do we also mean to say that the header is integrity protected but > not encrypted? We may want to clarify the text, and instead state > "For all messages that folllow, the header is encrypted and the > message including the header is integrity protected." Header is not encrypted, the data after header is encrypted, so your text is actually incorrect. It is true we could clarify that the header is also integrity protected.... VM> I guess I agree the text I gave confused it further. What I meant is = everything after the header is encrypted, and including the header is = integrity protected. Maybe the text you state is clearer. =20 > 2. Section 3.3.2 - Transform type Values: - > > Encryption Algorithm (ENCR) 1 (IKE and ESP) > Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) > > I think we can remove the "optional" in ESP part for Integrity > Algorithm. The optional part could be added instead to the > Encryption Algorithm part. No, we cannot remove that. Integrity is optional in ESP. Encryption is NOT optional in the ESP. If you do not want to use encryption in ESP, you need to negotiate cipher called ENCR_NULL. VM> I think we can remove the "INTEG part is optional" in ESP part of = it. If I see the Architecture document right, that is what is stated = very clearly. Am I missing something there? This discrepancy seems to be = in a lot of drafts.=20 > 6. In Section 2.13 we talk about (K, S) but never specify what K or > S mean. I think it is quite obvious that they are inputs to the function prf+... VM> Being a first time reader, I couldn't figure out what K and S stand = for(inputs to the function for sure, what do they mean). It was not = defined before or even in the same section(though everything else was). =20 > 8. We may want to state(obvious) that IKE message on port 4500, > MUST have the first 4 bytes as zero on receipt and should always > send the bytes as 0. I think the section 3.1 says that: ---------------------------------------------------------------------- When sent on UDP port 4500, IKE messages have prepended four octets of zero. These four octets of zero are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE. VM> I do not agree, it anywhere states that a value of non-zero on input = is a wrong value. I think as a good protocol specification, we should = clearly specify the behavior even in cases where an incorrect value is = received(spcefying the values to receive). I know things may seem = obvious to you but I guess to anyone implementing this, it may not. = Though I have not worked on IKE for long enough, I have figured this out = working and documenting other protocols. =20 Thanks, Vishwas ________________________________ From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Mon 1/31/2005 6:27 AM To: Vishwas Manral Cc: ipsec@ietf.org Subject: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt Vishwas Manral writes: > 2. Section 3.3.2 - Transform type Values: - > > Encryption Algorithm (ENCR) 1 (IKE and ESP) > Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) > > I think we can remove the "optional" in ESP part for Integrity > Algorithm. The optional part could be added instead to the > Encryption Algorithm part. No, we cannot remove that. Integrity is optional in ESP. Encryption is NOT optional in the ESP. If you do not want to use encryption in ESP, you need to negotiate cipher called ENCR_NULL. > 4. Section 1.2 states: - > > "All but the headers of all the messages that follow are encrypted and = integrity protected." > > Do we also mean to say that the header is integrity protected but > not encrypted? We may want to clarify the text, and instead state > "For all messages that folllow, the header is encrypted and the > message including the header is integrity protected." Header is not encrypted, the data after header is encrypted, so your text is actually incorrect. It is true we could clarify that the header is also integrity protected.... > 6. In Section 2.13 we talk about (K, S) but never specify what K or > S mean. I think it is quite obvious that they are inputs to the function prf+... > 8. We may want to state(obvious) that IKE message on port 4500, > MUST have the first 4 bytes as zero on receipt and should always > send the bytes as 0. I think the section 3.1 says that: ---------------------------------------------------------------------- When sent on UDP port 4500, IKE messages have prepended four octets of zero. These four octets of zero are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE. -- kivinen@safenet-inc.com ------_=_NextPart_001_01C507B9.C56C9920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt=0A= =0A= =0A=
=0A=
Hi = Tero,
=0A=
 
=0A=
Thanks a lot for the reply. My comments are prefixed with = a =0A= "VM>"
=0A=
 
=0A=
> "All but the headers of all the = messages that =0A= follow are encrypted and integrity protected."
>
> Do we = also mean =0A= to say that the header is integrity protected but
> not encrypted? = We may =0A= want to clarify the text, and instead state
> "For all messages = that =0A= folllow, the header is encrypted and the
> message including the = header is =0A= integrity protected."

Header is not encrypted, the data after = header is =0A= encrypted, so your
text is actually incorrect. It is true we could = clarify =0A= that the
header is also integrity protected....
=0A=
VM> I guess I agree the text I gave = confused it =0A= further. What I meant is everything after the = header is =0A= encrypted, and including the header is integrity protected.  Maybe = the text =0A= you state is clearer.
=0A=
 
=0A=
> 2. Section 3.3.2 - Transform type = Values: =0A= -
>
> Encryption Algorithm (ENCR)     = 1  =0A= (IKE and ESP)
> Integrity Algorithm = (INTEG)     =0A= 3  (IKE, AH, optional in ESP)
>
> I think we can remove = the =0A= "optional" in ESP part for Integrity
> Algorithm. The optional = part could =0A= be added instead to the
> Encryption Algorithm part.

No, we = cannot =0A= remove that. Integrity is optional in ESP. Encryption is
NOT optional = in the =0A= ESP. If you do not want to use encryption in ESP,
you need to = negotiate =0A= cipher called ENCR_NULL.
VM> I think we can remove the = "INTEG part =0A= is optional" in ESP part of it. If I see the Architecture document = right, that =0A= is what is stated very clearly. Am I missing something there? This =0A= discrepancy seems to be in a lot of drafts.
=0A=
> 6.  In Section 2.13 we talk = about (K, S) but =0A= never specify what K or
>     S mean.
I = think it is =0A= quite obvious that they are inputs to the = function
prf+...
VM> =0A= Being a first time reader, I couldn't figure out what K and S stand = for(inputs =0A= to the function for sure, what do they mean). It was not defined before = or even =0A= in the same section(though everything else was).
=0A=
 
=0A=
> 8.  We may want to = state(obvious) that IKE =0A= message on port 4500,
>     MUST have the = first 4 =0A= bytes as zero on receipt and should = always
>     send =0A= the bytes as 0.
I think the section 3.1 says =0A= that:
----------------------------------------------------------------= ------
   =0A= When sent on UDP port 4500, IKE messages have prepended four =0A= octets
   of zero. These four octets of zero are not part = of the =0A= IKE message
   and are not included in any of the length = fields or =0A= checksums
   defined by IKE.
VM> I do not = agree, it =0A= anywhere states that a value of non-zero on input is a wrong  = value. I =0A= think as a good protocol specification, we should clearly specify the = behavior =0A= even in cases where an incorrect value is received(spcefying =0A= the values to receive). I know things may seem obvious to you but I = guess =0A= to anyone implementing this, it may not. Though I have not worked on IKE = for =0A= long enough, I have figured this out working and documenting other =0A= protocols.
=0A=
 
=0A=
Thanks,
=0A=
Vishwas
=0A=
=0A=
=0A=
=0A=
From: Tero Kivinen =0A= [mailto:kivinen@iki.fi]
Sent: Mon 1/31/2005 6:27 = AM
To: =0A= Vishwas Manral
Cc: ipsec@ietf.org
Subject: [Ipsec] = Comments: =0A= draft-ietf-ipsec-ikev2-17.txt

=0A=
=0A=

Vishwas Manral writes:
> 2. Section 3.3.2 - = Transform type =0A= Values: -
>
> Encryption Algorithm = (ENCR)     =0A= 1  (IKE and ESP)
> Integrity Algorithm =0A= (INTEG)     3  (IKE, AH, optional in =0A= ESP)
>
> I think we can remove the "optional" in ESP part = for =0A= Integrity
> Algorithm. The optional part could be added instead to =0A= the
> Encryption Algorithm part.

No, we cannot remove that. =0A= Integrity is optional in ESP. Encryption is
NOT optional in the ESP. = If you =0A= do not want to use encryption in ESP,
you need to negotiate cipher = called =0A= ENCR_NULL.

> 4. Section 1.2 states: -
>
> "All but = the =0A= headers of all the messages that follow are encrypted and integrity =0A= protected."
>
> Do we also mean to say that the header is = integrity =0A= protected but
> not encrypted? We may want to clarify the text, = and =0A= instead state
> "For all messages that folllow, the header is = encrypted =0A= and the
> message including the header is integrity =0A= protected."

Header is not encrypted, the data after header is = encrypted, =0A= so your
text is actually incorrect. It is true we could clarify that =0A= the
header is also integrity protected....

> 6.  In = Section =0A= 2.13 we talk about (K, S) but never specify what K =0A= or
>     S mean.

I think it is quite = obvious =0A= that they are inputs to the function
prf+...

> 8.  We = may want =0A= to state(obvious) that IKE message on port = 4500,
>     =0A= MUST have the first 4 bytes as zero on receipt and should =0A= always
>     send the bytes as 0.

I = think the =0A= section 3.1 says =0A= that:

------------------------------------------------------------= ----------
   =0A= When sent on UDP port 4500, IKE messages have prepended four =0A= octets
   of zero. These four octets of zero are not part = of the =0A= IKE message
   and are not included in any of the length = fields or =0A= checksums
   defined by =0A= IKE.
--
kivinen@safenet-inc.com

=0A= =0A= =0A= ------_=_NextPart_001_01C507B9.C56C9920-- --===============0682521258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0682521258==-- From ipsec-bounces@ietf.org Mon Jan 31 23:58:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21268 for ; Mon, 31 Jan 2005 23:58:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvq5b-0005a5-4n; Mon, 31 Jan 2005 23:56:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvq1K-0005CK-SZ for ipsec@megatron.ietf.org; Mon, 31 Jan 2005 23:52:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20443 for ; Mon, 31 Jan 2005 23:52:05 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvqJN-0005HQ-1x for ipsec@ietf.org; Tue, 01 Feb 2005 00:10:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt Date: Mon, 31 Jan 2005 21:00:12 -0800 Message-ID: Thread-Topic: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt thread-index: AcUHSkVC/dSOcxQlR+ioPA3e5bSLkwA0DFFw From: "Vishwas Manral" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: Brian E Carpenter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Steve/ Karen, I am resending an older mail, in case it got missed in transit.=20 Although the security architecture talks about how the outer header is generated from the inner header in tunnel mode while encapsulation, I think the document completely misses the part of fields being copied back into the inner header while decapsulation. I am CC'ing Brian Carpenter too, as he would probably have the best view on this. Thanks, Vishwas ________________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Monday, January 31, 2005 9:37 AM To: ipsec@ietf.org Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt Hi Steve, I think the security architecture does not specify copying of DSCP and ECN values from the outer header to the inner header in the case of decapsulation for tunnel mode for both IPv4 and IPv6. DSCP values will not be copied directly however, depending on the change of domain. Thanks, Vishwas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec